Ninjatrader mishandled an Overfill

[westofpluto]

Ok folks, I'm pretty angry at this, and I have sent my logs to your platform team.

I have a strategy that uses unmanaged orders, but still used RealtimeErrorHandling.StopCancelCloseIgnoreRejects , so it SHOULD close all positions and disable the strategy if there is an error that occured.

In my case, I had a stop order that was for 2 contracts. The order overfilled, so I ended up with 2 more orders in the opposite direction than I wanted. Even worse, NT detected this and tried to close all my positions but what it actually did was enter 3 MORE positions in that direction! It seems there is a massive bug in NT that fails to properly detect what the current position actually is, and makes the situation even worse.

My original order was short for YM for 2 contracts. My stop was 20 points higher, and that overfilled, so I was left with 2 long positions. Then the strategy close operation added 3 more long positions so I ended up with 5 long positions. When I noticed this, YM had pulled back so I had to manually close for a big loss.

Obviously this is unacceptable behavior by the platform. I'd like to resolve this and find a way to make sure this never happens again. If RealtimeErrorHandling.StopCancelCloseIgnoreRejects is not reliable in actually closing the position, how should I go about doing this in my strategy code?

[NinjaTrader_Jesse]

Hello westofpluto,

We have an open case for you because you had emailed in, we are waiting for you to update to the current release so that we can know if this is still an issue. In the email that you sent in you are using 8.0.24 which we cannot help with as that version is out of date. If you are having problems in the current version we can assist and continue the existing case that you have open though the support email.

[bltdavid]

I have a strategy that uses unmanaged orders, but still used RealtimeErrorHandling.StopCancelCloseIgnoreRejects , so it SHOULD close all positions and disable the strategy if there is an error that occured.

In my case, I had a stop order that was for 2 contracts. The order overfilled, so I ended up with 2 more orders in the opposite direction than I wanted. Even worse, NT detected this and tried to close all my positions but what it actually did was enter 3 MORE positions in that direction! It seems there is a massive bug in NT that fails to properly detect what the current position actually is, and makes the situation even worse.

My original order was short for YM for 2 contracts. My stop was 20 points higher, and that overfilled, so I was left with 2 long positions. Then the strategy close operation added 3 more long positions so I ended up with 5 long positions. When I noticed this, YM had pulled back so I had to manually close for a big loss.

Obviously this is unacceptable behavior by the platform. I'd like to resolve this and find a way to make sure this never happens again. If RealtimeErrorHandling.StopCancelCloseIgnoreRejects is not reliable in actually closing the position, how should I go about doing this in my strategy code?

Stay calm, all is not lost.

Usually, NT is not at fault (mostly), and all we gotta do is fix someone's brain,
and doing that is not hard -- gentle efforts and clear writing helps.

Let me make my case. I'm usually pretty good at explaining things.

-=o=-

First off,
I was under the impression that RealtimeErrorHandling has nothing to do with overfills.

I mean, reading carefully, for the purpose of that setting, an overfill is not an error.

Therefore, that setting does not address overfills.

Do you agree?

-=o=-

Regarding overfiils, the help guide says,

"By default, NinjaTrader will protect against overfills even though you are using the
Unmanaged approach by halting the strategy, but should you decide to custom
program your own overfill handling it is up to you to either prevent overfills from
being a possibility in your code or by introducing logic to address overfills
should one occur."

A good question to support is:
Assuming IgnoreOverfill is false, when an overfill occurs and the strategy is
halted, what happens to the current (possibly overfilled) positions of that
strategy? What happens to any pending orders?

That is, when an overfill occurs, what does NT do before halting?
Are any open orders automatically canceled?
Are any open positions automatically closed?

I think the answer is 'no and no' -- this being unmanaged mode and all.

Remember, an overfill is not an error.
Unmanaged mode considers it more a 'condition' than an error.

-=o=-

What is your value of IgnoreOverfill?

Are you leaving it set to false, so that you can inherit NT's default behavior of
closing the strategy?

That may be the mistake.
I'm pretty sure the default behavior will not close the positions before halting.

My guess is, there is insufficient logic in your strategy to handle overfills.

What to do?
I'd recommend you set IgnoreOverfill to 'true' and handle all overfills yourself.
That is, add code to OnOrderUpdate to look for HasOverfill, and write logic
to handle the overfill yourself (which means you write the code to cancel all
pending orders and close all positions yourself) and then you halt the strategy
yourself.

Why do that?
I'm thinking that NT's default behavior for overfills is insufficient, since all it
does is disable the strategy. That is, since this is unmanaged mode, your
strategy positions are not automatically closed before the halt. You are
expected to do that yourself, if you need it.

Unmanaged mode imposes a much higher burden on the programmer.

If you need your unmanaged strategy to handle overfills by cancelling all
open orders and closing all positions (and then halt the strategy) then (this
being unmanaged mode) I think you have to write that extra middle-man
code yourself.

When an overfill occurs, which do you want?
NT --> halt strategy only.
You --> cancel orders & close positions and then halt strategy.

That extra code before halting is up to you. You do that by setting
IgnoreOverfill to 'true' and handling HasOverfill in OnOrderUpdate, or
OnExecutionUpdate, since the Execution object also has the Order.

Make sense?