Unmanaged Overfill Processing

[aslane]

I have read the doc and the forum posts on this topic, but still have some questions. I would like to address the following questions assuming a strategy that has a single logical position on with both stops and targets linked via OCO (could be multiple stop/targets). All orders are unmanaged, and total order qty on both sides always matches position size. New positions are initiated when flat or potentially reversed. When reversed, all current orders are canceled and position is flattened via market, then new position is entered.

In non-reversal scenario, it seems like overfills are a result of two items. First, orders are too close together and can both be triggered with normal volatility, which is a strategy issue to deal with. Second, a quick large price spike that can take out orders on both sides. In both cases the issue is orders being filled before being canceled via OCO.

When exactly is the HasOverfill flag set in an order? Does this depend on IgnoreOverfill setting?

When IgnoreOverfill is set to false, what actions does Ninja take to detect/correct an overfill? What orders would the strategy see come thru (i.e. order name or other signifying item) that correct the position?

Does setting IgnoreOverfill to true, disable the detection of overfill and setting the HasOverfill flag?

Is there any way to simulate/force this activity in replay?

[NinjaTrader_Jim]

Hello aslane,

Thanks for your post.

OverFills are qualified as an order getting a fill or a partial fill after a cancel has been seen. NinjaTrader would need to submit the cancel and then see a fill or part fill for an order it has attempted to cancel.

For your noted scenarios, this sounds to be specific with how the broker would process OCO's. Since the orders would reside at the exchange and then the broker would cancel the other OCO order, it would be a rare occurrence where the exchange fills both OCO legs before the broker can cancel them with OCO. Your broker's Order's Desk may have further specifics on this particular scenario. However, in the eyes of the NinjaTrader platform, there would not be an overfill because NinjaTrader did not attempt to cancel the order.

The order submitted by NinjaTrader would have an order ID that is known by the platform, and the associated Order properties would be relevant for the order that was submitted. You could check if the Order's Name property matches the Signal Name for the order method, and if the Order's HasOverfill property is set to true, this would mean that NinjaTrader has attempted to cancel the order, but has received a fill/partfill after it had attempted to cancel the order. Since IgnoreOverfill will control over fills in the strategy, checking Order.HasOverfill would only be relevant when the strategy has IgnoreOverfill set to true.

The default behavior for handling over fills is to attempt to stop, cancel and close. The strategy will disable, try to cancel active orders, and close positions it has created. The goal is to prevent the strategy from leaving an unprotected position due to the overfill.

Setting IgnoreOverfill to true will prevent the default behavior from occurring, and you can then check for orders with HasOverfill set to true in OnOrderUpdate to trap the occurrence and handle on your own.

I am not aware of any ways that overfills could be force encountered since we would have to call CancelOrder just as the fill is occurring. This may be possible trading against a paper trading account and submitting a CancelOrder when a partial fill is seen. The Cancel would be submitted and if market dynamics allow the order will fill further before the paper trading server sees the cancel.

Documentation links for the thread's reference are included below.

Unmanaged Approach - https://ninjatrader.com/support/help...d_approach.htm
IgnoreOverfill - https://ninjatrader.com/support/help...reoverfill.htm
Order properties - https://ninjatrader.com/support/help...nt8/?order.htm
OnOrderUpdate - https://ninjatrader.com/support/help...rderupdate.htm

I look forward to being of any further assistance.

[aslane]

Thanks, that is helpful.

[bjunaid]

Hi Jim,

Would you be able to provide me with an example of how to manage overfilling in unmanaged approach. I have tried to change the script to catch this error in OnOrderUpdate but it is not working at all . Unfortunately this error is only occurring in Realtime. When I tested in Market Replay, everything seems to working perfect.

Thanks,

[NinjaTrader_Jim]

Hello bjunaid,

Overfill handling would be done with realtime processing. They are typically seen involving in flight executions where a cancel is submitted and the order is filled or part filled after the cancel was submitted. This makes them harder to encounter on Playback/Sim because there is so little time between an order/cancel submission and the amount of time it take stop simulate the order fill/cancellation. (The orders/cancels do not have as much latency where overfills may be encountered.)

In your unmanaged strategy, you would check something like this, although you can add more restrictive checks to ensure that "order" is one of the Order objects your script manages.

protected override void OnOrderUpdate(Cbi.Order order, double limitPrice, double stopPrice,
    int quantity, int filled, double averageFillPrice,
    Cbi.OrderState orderState, DateTime time, Cbi.ErrorCode error, string comment)
{
    if (order.HasOverfill)
    {
        // OverFill trapped!
    }
}

You may start with something simple like this just to detect an overfill and you can test on a paper trading account to have better chances of reproducing an overfill than you can on Sim/Playback. Paper trading accounts would refer to demo accounts that reside outside of NinjaScript and simulate the actual order routing server. CQG demo accounts have a paper trading account and can be registered below, but please note that those demos are offered by CQG and are limited to one demo per user per year.

Free Live Data - https://ninjatrader.com/FreeLiveData

We look forward to assisting.