Strategy Stop Loss or Profit Target Rejected!

[JeffB77]

Hello,
This morning I witnessed my strategy issue a sell order that also triggered the associated stop loss and profit target orders. The stop loss was very tight and triggered very quickly. So quickly in fact that the profit target order could not be cancelled because of its status and instead got rejected. According to NT documentation it states that when a stop loss or profit target order (from ATM or Strategy) gets rejected that all associated orders will get cancelled. But that is not what happened here. The buy profit target order that was rejected did not get canceled and instead spawned into a buy order that did not come from the strategy. To me that is a serious issue. Now I have to find a way to deal with this bizarre situation where the strategy creates stop loss or profit target orders that don't get canceled and instead get rejected. The concern is that "runaway orders" get created because these stop loss or profit target orders get rejected and then sit out there and create unintended buy or sell orders.
So in light of this how can I code to have a strategy on 60 minute bars to go out and check to see if the strategy has any active orders that fall below a set P/L? Since the strategy runs at the close of the bars how can I have it make it check on the orders associated with it on price change instead?
Given what happened I don't feel comfortable letting these strategies run with real money when I'm not near the computer. Any ideas how I could handle this?

Jeff B.

[NinjaTrader_BrandonH]

Hello JeffB77,

Thank you for your post.

It is possible for the Profit Target to become rejected if the Stop Loss is filled before the Profit Target processed/ The Stop Loss and Profit Target are connected by an OCO ID. If the Stop Loss is filled before the Profit Target is processed then the OCO ID could become invalid causing the Profit Target to be rejected since there is no valid OCO ID associated with it.

I would like to investigate this matter further so that I may accurately advise you. Please write into platformsupport[AT]ninjatrader.com with the subject field ATTN: Brandon H. Please include the following in your email.

• A link to this forum post.
• Log and Trace files.
• The Order ID associated with the rejected order.
• The time that the order was rejected.

Please follow the steps below to manually attach your log and trace files.

• Open your NinjaTrader folder under, "Documents" (sometimes called, "My Documents")
• Right click on the 'log' and 'trace' folders and select Send To> Compressed (zipped) Folder.
• Send the 2 compressed folders as attachments to this email.
• Once complete, you can delete these compressed folders.

Thanks in advance, I look forward to resolving this.

[JeffB77]

Hi Brandon, there is already a ticket for this and it is #2891376 and someone named Spencer is looking into it and has requested the database files. I have uploaded all the log and trace files and now the database file to the NT support desk via the "email support" option in the tool. If you can see that information it would be great to have extra eyes looking at this. I am really concerned about this because what your mentioning here implies (and it is what happened to me today) that one can get a "runaway" order because of this. In this case that order id is 1888506048. As I mentioned I don't feel comfortable using automated strategies with really tight windows on stop loss with this issue looming unless I code for it in my strategies.

[JeffB77]

I think I found the problem here but now I need help in knowing how to resolve this. The problem was with error handling. In NT error handling (default : StopCancelClose) when an order is rejected, the error handling code takes a position opposite to the entry signal in effort to wipe out the transaction altogether since it wants to recover the position to flat. However, this actually compounds the problem when the stop loss or profit target (but not both) are rejected. For some reason in using StopCancelClose error handling the rejected profit target order in this case caused the default error handling routine to think it needed a buy order for the strategy since the initial position was sell in an effort to "close the position". It did not take into account however that the stop loss order was already filled as a buy order and that the original order was already taken care of. How do I know this? Because the strategy name was set to blank on this problematic buy order. Any order placed by the strategy logic itself has a default name of "Buy" or "Sell" without me even specifying an order name. So what I need help with is what set of error handling can I use in NT when the stop loss or profit target order is what gets rejected. I very strongly believe this is an issue in NT error handling when set to default (StopCancelClose) in the case that the stop loss or profit target order gets rejected (unless they both get rejected then it's fine). Only orders processed using NT error handling would have no order name. Again, orders placed by the logic of the strategy will always have a name. It does not appear that "StopCancelCloseIgnoreRejects" would be the answer (I don't think).

[NinjaTrader_BrandonH]

Hello JeffB77,

Thank you for that information.

In your Log files, I see that your strategy got a reject on the profit target, and the stop filled the same time the strategy went into the Stop Cancel Close error handling behavior. This is an inflight execution meaning the strategy tried to cancel the stop loss and close the position because of the reject, but the stop loss had filled already.

We could use RealtimeErrorHandling to determine the behavior of a strategy when the strategy places an order that is returned "Rejected". The default behavior is to stop the strategy, cancel any remaining working orders, and then close any open positions.

RealtimeErrorHandling could be set to IgnoreAllErrors to ignore any order errors received or StopCancelCloseIgnoreRejects to perform the default strategy behavior on all errors except order rejections. Please note that setting this property value to IgnoreAllErrors can have serious adverse effects on a running strategy unless you have programmed your own order rejection handling in the OnOrderUpdate() method. To do this you would trap the rejected order by checking if the OrderState is Rejected within OnOrderUpdate() followed by defining your own order rejection handling behavior for the rejected order.

Please see the example in the help guide link below that demonstrates using RealtimeErrorHandling and trapping a rejected order in OnOrderUpdate().
RealtimeErrorHandling — https://ninjatrader.com/es/support/h...orhandling.htm
OnOrderUpdate() - https://ninjatrader.com/es/support/h...rderupdate.htm

Let us know if we may further assist.

[JeffB77]

Hey Brandon, thanks to you and Spencer for your help. I did some further research from questions out here from 2014 and even earlier regarding a very similar issue. I used Strategy Builder for this so I can't get as particular in terms of what you suggest here. One other suggestion was to use the local OCO setup for my connection, but that presents its own set of risks. But clearly NT is already aware of this issue as a whole and it's not a concern because there is a known lag time regarding the submission and timing of OCO orders and I went past the safety threshold with what I was doing. I have decided as a workaround to let the strategy handle the profit target in the logic itself versus submitting a separate profit target order.