Fill event misalignment in backtesting

[anachronist]

I'm backtesting something using using the unmanaged approach, and I noticed a weird result.

If the next bar after the current bar would fill a limit order, the fill event fires off on the current bar rather than the next bar. In other words, a fill event for a limit order doesn't align with the bar that filled it.

This misalignment messes up the logic for adjusting stops and targets on the current bar if the entry order's status has already been set to Filled before it actually happens, resulting in occasional errors in the backtest results.

I got around this by delaying stoploss and target processing until the bar following the fill event (which is the bar that actually caused the fill).

If others are accounting for this misalignment in their code and NinjaTrader corrects this behavior, it might break some things.

-Alex

[NinjaTrader_Bertrand]

Thanks for the report Alex, I'm not aware of similiar issues seen sofar so would like to investigate with your help if possible.

Is there any way you could mask your proprietary logic and send me your script for testing to support at ninjatrader dot com Attn Bertrand?

Please include datafeed, instrument / expiry and timeframe / chart type as well.

Thanks much,

[anachronist]

It isn't a problem in my script. This should be easy to duplicate with a simple script. I was on a 2 minute chart of TF using a Zen-Fire data feed through Mirus Futures, with trades executed on a 20-second secondary data series.

• Find any bar in the history that makes a significant pivot low, several ticks below the prior several bars, on both time frames.
• Identify the bar number of this new low (I have a simple indicator that plots the value of CurrentBar on every bar, so I can view the bar number in the data window).
• Run a simple script that places an unmanaged limit order a few bars beforehand, to buy 1 or 2 ticks above the pivot low price. e.g. if (CurrentBar==pivotbar-3) SubmitOrder(...).
• In OnOrderUpdate(), print the primary and secondary bar numbers to the output window when the Fill event is captured. Also print the low of the current bar.
• You will find that the low of the current bar would not fill the order, but the low of the next bar would. The bar number printed for the fill bar will be 1 bar prior to the bar that would fill the order.

I've read other messages from support staff on this forum saying that the backtesting logic looks ahead to the next bar to determine if a limit order is filled. That makes sense, but it seems that the fill event isn't delayed until the next bar but instead gets fired off as soon as a fill is detected on the next bar.

-Alex

[NinjaTrader_Bertrand]

Alex, thanks - so this would be different for you in a managed script, is this correct?

I would be surprised since accessing bar info in the event order / execution method would not be a valid check for your situation, since the executions in backtesting are proccessed before the bar update events.

[anachronist]

It is no different in a managed script.

Here's an example. TF 09-11 contract loaded from ZenFire, 2-minute bars, Default 24/7 session template, 2 days ending on 7/4/2011.

• Place order on bar 296 (this is 08:28 Pacific time) to sell at 839.3 limit.
• Trading halts on bar 298, the 08:30 bar (this is a holiday). Note that trading has halted without the limit order being filled (price never reached it).
• Nevertheless, the fill event fires off on bar 298, even though price never touched it.
• The actual fill is hours later when trading resumes, on bar 299 at 17:02.
• Another problem observed: Even though ExitOnClose=false, the order is exited on the session close anyway. Why?

The script below prints the message:
7/4/2011 8:26:00 Entered internal PlaceOrder() method at 7/4/2011 8:26:00: BarsInProgress=0 Action=SellShort OrderType=Limit Quantity=1 LimitPrice=839.3 StopPrice=0 SignalName='test' FromEntrySignal=''
Filled on bar 298 at 839.3 where high=839 and low=838.8

Regardless of whether I use the managed or unmanaged approach, the fill event fires for 1 bar in the future, not on the bar where the order got filled.

PHP Code:


        #region Variables
        // Parameters for TF 09-11 2 minute, Default 24/7 template, 2 days ending 7/4/2011
        private int barNum = 296; // Default setting for BarNum
        private double limitPrice = 839.3; // Default setting for LimitPrice
        private IOrder entry;
        #endregion

        protected override void Initialize() {
            CalculateOnBarClose = true;
            ExitOnClose = false;
            TraceOrders = true;
        }

        protected override void OnOrderUpdate(IOrder o) {
            if (o == entry && o.OrderState == OrderState.Filled)
                Print("Filled on bar "+CurrentBar.ToString()+" at "+o.AvgFillPrice.ToString()+" where high="+High[0].ToString()+" and low="+Low[0].ToString());
        }

        protected override void OnBarUpdate() {
            if (CurrentBar == barNum)
                entry = EnterShortLimit(0, true, 1, limitPrice, "test");
        } 


I would be surprised since accessing bar info in the event order / execution method would not be a valid check for your situation, since the executions in backtesting are proccessed before the bar update events.

That's good to know. However, it still messes things up. Notwithstanding the example above, I don't access the bar information in the OnOrderUpdate() method. I access the bar information in the OnBarUpdate() method.

The problem is that I need to check order states in OnBarUpdate(), so that I can adjust stops and targets for any positions running. The order state is being set to "Filled" and the position is created before the bar that actually fills the entry.

-Alex

[NinjaTrader_Bertrand]

Thanks for the clarifications Alex, this would be expected in backtesting and it would not be different for managed vs unmanaged approach how the fill simulation would work - your CurrentBar print comes from the OnOrderUpdate() and it would report the last seen state, at the point your print this CurrentBar would not have advanced as OnBarUpdate() for the next bar has not yet been called. In simulation with CalculateOnBarClose = false this should align as you expext.

For the ExitOnClose issue - so is the position exited or the order expired at session boundary? For order expiration, please try with a TIF of GTC.

http://www.ninjatrader.com/support/h...imeinforce.htm