Delay Cancelling orders

[op1031]

Hi support,

I am trading with TDAmeritrade, and it seems like there is a delay in cancelling stop orders.

Here is how the trade is made

1. submit a buy order
2. buy order filled -> submit a stop loss order
3. when exit signal is hit, cancel the stop order
4. submits a sell order.


When I look at the order status in TDAmeritrade, I see that the sell order executed before I cancel the stop order, so it rejected the sell order. However, the sell order was eventually executed somehow.

So here is what I see in TDAmeritrade

1. buy order filled
2. submitted a stop loss order
3. reject a sell order due to not enough position to sell
4. cancel the stop loss order
5. execute the sell order

As you can see, it seems like the sell order was made prior to the cancel stoploss order, thus causing an error, and causing the strategy to exit.

How can I deal with this? I was thinking about cancelling the stoploss order first, and only submit a sell order after I receive the confirm of the cancel. However, is that the only way to deal with this?

[NinjaTrader_Jim]

Hello op1031,

Thanks for your post.

How can I deal with this? I was thinking about cancelling the stoploss order first, and only submit a sell order after I receive the confirm of the cancel. However, is that the only way to deal with this?

Yes, this would be the recommended path to take to avoid an overbought/oversold rejection with TD Ameritrade. We would suggest cancelling the stop loss, checking for its cancelation in OnOrderUpdate, and then to exit the position. I posted a small example in the thread below.

https://ninjatrader.com/support/forum/forum/ninjatrader-8/strategy-development/1160008-td-ameritrade-and-oco-s

OnOrderUpdate - https://ninjatrader.com/support/help...rderupdate.htm

Please let us know if you have any questions.

[op1031]

Hi Jim,

Thank you for the response. In your example, you used Account.CancelOrder, I tried it, and in my backtest, the stop order does not get cancelled for some reason, so eventually I reverted the code back to just CancelOrder (without the Account class), and it works fine in backtesting. Could you explain the difference?

Thanks!

[NinjaTrader_Jim]

Hello op1031,

CancelOrder would be used to cancel orders at the strategy level, and the orders specifically need to use IsLiveUntilCancelled = true. Set methods and market orders would not apply but Account.Cancel can be used to cancel these orders. (Account.Cancel would cancel orders at the account level.)

When I have tested on my end, I was not able to cancel the Set orders in the Strategy Analyzer with the either approach. It is a bit ambiguous if that would be expected with my example because the Set methods do not use IsLiveUntilCancelled and the Strategy Analyzer does not have a real account.

I'm discussing this particular matter with my colleagues and will follow up here with more definitive information when it is available.

[op1031]

Hi Jim,

I am using ExitLongStopMarket to set stoploss, and using CancelOrder (without the Account class) does cancel the order in both backtest and live trading (It canceled the order in live trading today, but it's now complaining that I am submitting sell order twice. I will debug that on my own)

I am still curious on the when to use Account.CancelOrder and CancelOrder.

Thanks!

[NinjaTrader_Jim]

Hello op1031,

CancelOrder should be used at strategy level, and there wouldn't be a need to use Account.Cancel (account level) in a strategy unless we wanted to cancel an order that was submitted from a Managed Approach order method that do not specify IsLiveUntilCancelled. I.E. if you needed to cancel a market order before it fills or if you needed to cancel an order submitted using a Set method that does not have a parameter for IsLiveUntilCancelled.

Account.Cancel is not working in my example for the case of backtesting, so I am checking into how cancels on Set methods should be treated for this case.

Ok, I got some clarity here.

For anyone that is using an approach described post #2 to cancel stop and target orderd on TDA, this approach would not be backtestable and would require branching your logic so instead of attempting to cancel the order with Account.Cancel, you can branch your logic when State == State.Historical to call ExitLong/ExitShort, instead of first cancelling the order.

It is also possible to use the Unmanaged Approach where you would not have to have a separate logical branch for backtesting, because you can cancel Unmanaged OCO orders with CancelOrder.