Fake fill price caused by marketable stop price

[YuriyGulyayev]

When I call ChangeOrder to make stop price marketable, historical fill happens exactly at the price I specified, which can be far away from the market.
I use the unmanaged approach and send 2 stop orders. Both have the same stop price. The 1st one is OCO with a limit order and the 2nd one is not an OCO. I call ChangeOrder on both stop orders unless the 1st one isn't working any more because its OCO limit order has already been filled. So this behavior appears to happen only to the 2nd stop order and only if I modify both stop orders at once. If the 2nd stop order is the only one that is still working it works correct.

This is somewhat related to another problem: NT refuses to send a stop order if its stop price is marketable. It's a really annoying pitfall that one has to remember about when coding a strategy. Why don't you guys make it configurable whether this policy is enforced?

The attached image shows a fill 400 pips away from the market.

[NinjaTrader_Jim]

Hello YuriyGulyayev,

Thanks for opening the thread.

I have put together an unmanaged strategy to test this where I am placing a Sell StopMarket with an order quantity of 1 OCO'd with a Sell Limit with an order quantity of 1. I am entering with a quantity of 3 and I have the remaining 2 contracts attached to a second stop loss at the same price.

I have created a video demonstrating: https://www.screencast.com/t/9r3Xci27

I have also attached the script I used so you may test as well on your end.

When I move my Sell StopMarket(s) down a certain number of ticks, the order moves as expected and does not fill.

When I move the Sell StopMarket(s) up above the current market price I get met with an error which would be expected for placing a Sell Stop Market order above the market price. If you would like to implement your own order rejection handling instead, I would recommend to have a look at the documentation on RealtimeErrorHandling.

I would suggest to review the order types used to place the orders to make sure the behavior is not resulting from an improper order type.

RealtimeErrorHandling - https://ninjatrader.com/support/help...orhandling.htm

[YuriyGulyayev]

Hi Jim

Thanks you for your response.

I modified your code to move exit order stop price 1000 ticks above the market, rather than 30. It's now making a tremendous amount of money. That can't be real, can it?

Please see attached.

[NinjaTrader_Jim]

Hello YuriyGulyayev,

When I make such a modification, I still see the error messages as I saw previously when moving Sell Stop Market orders above the market price.

if (stopLossLong != null)
	ChangeOrder(stopLossLong, 1, 0, Close[0] + 1000 * TickSize);
if ( stopLossLong2 != null)
	ChangeOrder(stopLossLong2, 2, 0, Close[0] + 1000 * TickSize);

We have recently released a new version of NinjaTrader 8. Could you test to see this behavior on the most recent build? The current build is Release 8.

New builds of NinjaTrader can be found here: http://ninjatrader.com/PlatformDirect

If you experience the issue with this script and the current build, could you provide me more detail to how you are enabling the strategy? I would like to know the instrument and bar type used.

[YuriyGulyayev]

I am observing the same behavior. Please see all settings attached.
30 ticks above the market will work too, except that the strategy will make proportionally less money.

[YuriyGulyayev]

I am also attaching my log.

[NinjaTrader_Jim]

Hello YuriyGulyayev,

Thank you for providing that detail.

We are reviewing this matter further and I will update this post or thread when more information becomes available.

EDIT: This split behavior issue is being tracked with the ticket ID NTEIGHT-11951 and can be found in the Release Notes section of the help guide when a release includes a fix for the issue.

Release Notes: https://ninjatrader.com/support/help...ease_notes.htm

I typically would not advise moving a Stop Market order above the market, and would instead suggest to cancel that order and submit an order of a different type as the expected result in real time would result in a rejection.

Thanks for bringing this matter to light.