Trades Not Executing On Secondary Series In Multi-Series Strategy

[dave1992]

NT 7 Beta 23

[dave1992]

By the way, this problem doesn't happen in this case during market replay.

[NinjaTrader_JoshP]

Okay, then what is the setup you are using instead if not Market Replay? Is this Strategy Analyzer?

[dave1992]

Yes, this is strategy analyzer.

[NinjaTrader_JoshP]

Development is looking into it. We will get back to you.

[NinjaTrader_JoshP]

Okay. Here is the analysis. I assume your primary series is your daily series. When you do this, this means your Set() orders will execute based off of the primary series and not the secondary series. The fill algorithm checks the next bar of the primary series and sees that your stop loss would have been filled and that is what you end up getting in your output.

There are two options for how you can proceed.
1. Swap your primary and secondary series. Minute as primary, daily as secondary.
2. Use explicit Exit() methods instead of Set() methods for your stop loss. This option would allow you to preserve the use of daily bars as the primary series.

[BAltman]

Hi Josh,

Would you explain what (if any) difference there is between using SetStopLoss() and SetProfitTarget() compared to using ExitLongStopLimit with barsInProgressIndex (on a long trade) ?

If I understand correctly, using ExitLongStopLimit will in effect set both the stop loss (using the limit price) and the profit target (using the stop price).

Thanks,

Bob A.

[dave1992]

This has just been changed somehow in beta 21, so it's a shame you don't have - option 3: Fix the stop fill algorithm.

It's frustrating enough working in backtest without such common concepts as bid/ask, but now backtest is actually getting even further away from reality, instead of closer which should really be the goal.

[NinjaTrader_JoshP]

Bob,

ExitLongStopLimit() is probably not what you want to be using. That submits a stop-limit order which is not the same as setting a stop order and a limit order. A stop-limit order requires the stop price to be achieved before becoming into a limit order at the limit price. A regular stop order would just become a market order once the stop price was achieved.

Instead, ExitLongStop() would be comparable to SetStopLoss() and ExitLongLimit() would be comparable to SetProfitTarget().

Dave,

There was no change for this on B21. There was a change in B22 in terms of how Set() methods check stop prices in a multi-series strategy, but that change has no impact on this exact scenario here dealing with multi-series strategy of the same instrument. The change was more in relation to multi-series strategies with multiple instruments. There was also another change in B22 for timestamping in a multi-series environment which was for a different scenario than this one. The behavior discussed in my prior post has always been the case and is not an issue with the fill algorithm per se. It is simply the limitation of how Set() methods work off of the first BarsInProgress context for any given instrument.

[dave1992]

Bob,

There was no change for this on B21. There was a change in B22 in terms of how Set() methods check stop prices in a multi-series strategy, but that change has no impact on this exact scenario here dealing with multi-series strategy of the same instrument. .

Well, I can 100% guarantee that something changed. I've had to use beta 20 for the last few weeks because 22 gives me this problem immediately using identical data.

[NinjaTrader_JoshP]

All changes made were required to address malfunctioning behavior. What you are running into is actually also part of the reason why the docs explicitly say to trade on the first series of a multi-time framed strategy for the given instrument. The options to proceed and achieve your exact requirements would be to swap primary/secondary series or use explicit Exit() methods where you can identify exactly which BarsInProgress you want to submit against.

[dave1992]

I've read those docs quite a lot and must have missed that bit. It's certainly not obvious in the 'entering/exiting for multi time frame' section, where I would expect to find it.

I haven't noticed anyone else with this problem be aware of that either.

As I mentioned, neither of those two solutions are ideal for me, and this definitely used to work for me. I'll have to put extra code in and do different exits in backtest to live/replay. But like I said, we should be making backtest more like reality, not less.

[NinjaTrader_JoshP]

Not sure why you feel this is less realistic. It works exactly as you would expect when the strategy is programmed in a manner that does not hit against the usage model limitation of the Set() methods.

[dave1992]

To be fair Josh, this seems like a limitation that no one seems to have known about. In fact, if it is a known limitation, how come no one from support told me about it when I first reported this issue many weeks ago. How come I had to write a strategy for you to reproduce it, and then we all waited while dev analysed it.

In that light, your comment sounds much like it works fine if you leave out the bit that doesn't work.

Let me explain what I mean by 'less realistic'.

I had a strategy whose stop loss did exactly what you'd expect through numerous betas. The stop loss did the same in backtest as it did in replay/live. Starting with beta 21 (or poss 22), the stoploss did something completely diffferent in backtest to replay/or live. Hence, backtesting for me has become less realistic.

I realise you don't really believe me, and we're not going to see eye to eye on this, so I'll just thank you for your help.

kind regards
Dave

[NinjaTrader_JoshP]

Dave,

Each scenario is highly highly sensitive to the exact particulars. To understand the exact scenario you are running into requires indepth analysis before we can say anything one way or the other. Unfortunately we cannot just tell you a catch-all statement without isolating the exact scenario you are encountering.

What I can say is that prior behavior was not accurate with many unknown downstream implications. We applied fixes to several downstream issues we did isolate. If your code relied on the inaccurate behavior because it somehow did meet your requirements back then, then unfortunately those assumptions would not be applicable anymore after the fixes. The current behavior is the accurate one and your code would unfortunately need to be changed to reflect this instead of relying on the old assumptions.

We realize it can be frustrating to not be able to find information on this before spending a lot of time trying different things. As far as the Help Guide article on this goes, the Help Guide is still a work in progress and we do realize the information for this may not necessarily be conveyed completely. Expect more documentation and guidelines for this.