Extended backtesting mode needs tweaking
Extended backtesting mode needs tweaking
There are three issues that I've identified that will significantly improve modelling assumptions of extended backtests. I think MC is a great product and I'm sure it is obvious to most that modelling assumptions are the cornerstone of effective trading system development.
I invite feedback from MC and criticism from MC users.
The first issue:
If bid>=sell limit price then sell order = filled.
My issue is that additionally, sell order = filled when last traded price >= sell limit price (depending on backtest setting).
This second condition needs adding to the extended backtesting engine.
I've attached a screenshot displaying this example
Last edited by wilkinsw on 09 Sep 2015, edited 1 time in total.
Re: Extended backtesting mode needs tweaking
The second issue I found, when using tick charts, occurs in the event of a large single matching event (a large aggressor order going through or a cascade of stops being triggered), aka a "blip".
Because of the way market data is handled (FIX/FAST, MDP3.0 messaging etc), info on how the book is left will follow the cascade of matching event messages. So, when a large event goes through, on a tick chart, this means lots of ticks with no bid/ask updates for a long time (until the matching cascade has finished).
Do note that a "tick" is not necessarily a single trade. A tick is a match against a resting limit order. Hence a blip is diplayed as multiple ticks.
The issue with MC in extended backtesting mode is that should an entry condition = true in the middle of a blip, then MC will reference the last known bid/ask to determine if and where the fill occured. This, of course, is wrong. MC should wait for the next update of the bid ask, following a entry signal=true event.
I've attached an illustration.....
Because of the way market data is handled (FIX/FAST, MDP3.0 messaging etc), info on how the book is left will follow the cascade of matching event messages. So, when a large event goes through, on a tick chart, this means lots of ticks with no bid/ask updates for a long time (until the matching cascade has finished).
Do note that a "tick" is not necessarily a single trade. A tick is a match against a resting limit order. Hence a blip is diplayed as multiple ticks.
The issue with MC in extended backtesting mode is that should an entry condition = true in the middle of a blip, then MC will reference the last known bid/ask to determine if and where the fill occured. This, of course, is wrong. MC should wait for the next update of the bid ask, following a entry signal=true event.
I've attached an illustration.....
Re: Extended backtesting mode needs tweaking
It would make ones life easier if MC can address both of these incorrect modelling assumptions.
There is a workaround that I use for handling the "price improvement / false fill on blip" event. I also advise anyone use this when backtesting on tick data.
Simply put, you need to reference all variables and data values from t-latency using the following as an example (please note the variables here could be replaced with anything of importance to the developer, "latency" and "refbb" are the key components):
Therefore, instead of buying when x=true, you are buying when x[latency]=true with variables[latency]. Then waiting for entrytime+latency until placing position management orders [latency adjusted too].
I've attached the outcome when this is done. Compare is to my previous attachment......
There is a workaround that I use for handling the "price improvement / false fill on blip" event. I also advise anyone use this when backtesting on tick data.
Simply put, you need to reference all variables and data values from t-latency using the following as an example (please note the variables here could be replaced with anything of importance to the developer, "latency" and "refbb" are the key components):
Code: Select all
//////////////////
////lagging (latency driven) variables
inputs:latency(0.050);
vars:tl1(0),tl2(0),refbb(0),cl1(0);
for counter=0 to maxbarsback begin
tl1=((datetime-datetime[counter])/0.0000115740740740);
tl2=round(tl1,3);
if tl2>=latency then break;
end;
refbb=counter;
lagupb3[sens]=upb3[sens][refbb];
lagupwh[sens]=upwh[sens][refbb];
lagavgUW[sens]=avgUW[sens][refbb];
lagdpb3[sens]=dpb3[sens][refbb];
lagdnwh[sens]=downwh[sens][refbb];
lagavgDW[sens]=avgDW[sens][refbb];
cl1=close[refbb];
///////////////////////////
I've attached the outcome when this is done. Compare is to my previous attachment......
Last edited by wilkinsw on 09 Sep 2015, edited 2 times in total.
Re: Extended backtesting mode needs tweaking
The third issue is the triggering and filling of stops.
I simply don't understand the behavior in extended backtesting.
It should be (as I'm sure is obvious):
If last traded = sell stop trigger price then fill at bid (ideally wait for an updated bid first!)
What seems to be happening instead is that MC waits for..
If ask<=sell stop trigger then [when last traded price updates] fill at bid
Please see my attachments for further illustration.........
I hope MC agree that these are some fundamental flaws. Please challenge me on anything you think I might have wrong.
I simply don't understand the behavior in extended backtesting.
It should be (as I'm sure is obvious):
If last traded = sell stop trigger price then fill at bid (ideally wait for an updated bid first!)
What seems to be happening instead is that MC waits for..
If ask<=sell stop trigger then [when last traded price updates] fill at bid
Please see my attachments for further illustration.........
I hope MC agree that these are some fundamental flaws. Please challenge me on anything you think I might have wrong.