OverFill detection example code?

[lavalampmj]

Exploring writing an "unmanaged" order manager, where IgnoreOverFill = true on NT7.

From the documentation:

"An overfill is categorized as when an order returns a "Filled" or "PartFilled" state after the order was already marked for cancellation. The cancel request could have been induced by an explicit CancelOrder() call, from more implicit cancellations like those that occur when another order sharing the same OCO ID is filled, or from things like order expirations"

Given that the IOrder object only documents it's current order.OrderState (not it's state transitions over time), does this mean that every order object must be tracked in the event it's state becomes order.OrderState == OrderState.PendingCancel and subsequently its order.Filled units increases on subsequent Filled / PartFilled events?

Does every explicit and implicit cancellation occurrence go through OrderState.PendingCancel before OrderState.Cancelled?

When does the order.Overfill bool get set? What is it used for?

Is there any example code of how to properly structure overfill detection and subsequent overfill handling?

[NinjaTrader_Jim]

Hello lavalampmj,

Thanks for your post.

I don't have an Unmanaged OverFill example on hand but there are a couple ways to implement overfill handling. In OnOrderUpdate() you could check if the iterating IOrder object has the OverFill bool set to true. This will become true under the circumstances you have quoted in your first post.

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

Another approach to handling OverFills would be to store temporary variables for your desired order sizes before submitting your order than to monitor the position sizer in OnPositionUpdate(). If you see a quantity filled that is greater than what you had stored for your desired size, you have detected an overfill.

OnPositionUpdate() - https://ninjatrader.com/support/help...tionupdate.htm

Handling the overfill would be subjective to what you wanted to do in the event of an overfill. (I.E. submitting another order to flatten the position or to stay in position and submit additional orders to protect the position that is still open.)

Please let us know if you have any additional questions

[lavalampmj]

To detect overfill within OnOrderUpdate() would you also need to check for (order.OrderState == OrderState.Cancelled && order.Filled != 0) to account for the condition where an implicit or explicit cancel occurs after a PartFilled event but before being Filled? The documentation does not seem to account for this condition or am I missing something?

[NinjaTrader_Jim]

Hello lavalampmj,

Submitting a cancel and receiving the cancellation before the order part fills again will cancel the order and will not result in an overfill.

Submitting a cancel and receiving another PartFill or Filled will result in an overfill, specifically due to an inflight execution. (The exchange fills the order before it sees the cancel. NinjaTrader sees a fill after a submitted cancel.)

This particular scenario could happen with very large orders and a fast moving market but would be extremely rare to encounter.

[lavalampmj]

I was thinking more about the case of an implicit cancellation, because of an OCO being invoked, where there are two entry orders in the same direction, say a limit and stop market long orders. One order gets filled, after the other one had already PartFilled. So in this case we have an "OCO group" overfill situation, not an order specific overfill.

I understand what to do now, OCO group overfill will need to be handled in OnPositionUpdate not on an order by order basis.

I've read somewhere that OCO groups have intelligent reductions of quantities (both exits and applicable entry orders) to try to avoid the above situation and other situations, is this the case for "unmanaged" ? I'm guessing it is because this logic would be broker side.

[NinjaTrader_Jim]

Hello lavalampmj,

The Unmanaged approach allows you to submit orders with OCO pairs. If the connection supports OCO, the exchange will handle OCO orders. You can check the thread here for more information: https://ninjatrader.com/support/foru...rader-7?t=5349

On NinjaTrader's end, simulated OCO's will cancel the other order immediately when a partfill is seen for one of the orders. If the exchange does not offer OCO handling, then NinjaTrader will send a cancel order. In this case there could be an over fill if the exchange fills the order before the cancel is received. The over fill could be detected in OnOrderUpdate() with the iterating Order object's OverFill property.

Questions on exchange side OCO handling would be best answered by your broker since there could be differing behaviors between exchanges. The exchange could have logic that updates order sizes for an OCO pair instead of immediately cancelling an order, but these behaviors would be subjective to the broker/exchange.

If you have any additional questions on how you can react to these cases, please let us know.

[lavalampmj]

I've just opened a NinjaTrader Brokerage account (not listed on the https://ninjatrader.com/support/foru...rader-7?t=5349), with Dorfman for clearing.
Is NinjaTrader Brokerage the old Mirus Futures Brokerage?
Is NTB on CQG tech stack?

[NinjaTrader_Jim]

Hello lavalampmj,

Yes and yes.

Let us know if there is anything else we can help out with.

[lavalampmj]

My specific questions:

Under https://ninjatrader.com/ConnectionGu...nnection-Guide under disclaimers.

" 1. When cancelling orders, working orders within an OCO group will only be cancelled if any order of the group is cancelled directly within NinjaTrader. In all other scenarios these working orders will remain working."

a) Does this mean, from a strategies perspective, when explicitly cancelling an order by calling CancelOrder(order) only other members of an OCO group will be canceled if their IOrder state is OrderState.Working? Which if true would infer the need for some member cleanup code for all other states.

b) "In all other scenarios these working orders will remain working." Please confirm that this text does not relate to implicit cancellations, due to an OCO member order being PartFilled or Filled, resulting in other members getting canceled (which is the point of having an OCO group in the first place!)


" 4. There will be an approximated 200ms delay between submission of strategy based stop and target orders. "

c) Is this a "managed" order feature or is this a CQG exchange submission thing?

[NinjaTrader_Jim]

Hello lavalampmj,

In the context of this message, a working order would be an order that has at least been accepted at the exchange. (OrderState.Accepted, orders will reach Accepted before reaching Working)

To address b, you could test this on a Paper Trading account with a bracketed entry with large orders and to watch what happens when you submit a large order that would likely result in a partial fill. However since this is a matter dictated by the broker/exchange and not the platform, these hypotheticals would be best answered by your broker. NinjaTrader Brokerage can be reached at brokeragesupport [at] ninjatrader [dot] com. (Our forums are currently managed by our Platform Support team.)

To address c, this is a delay that is added by the CQG adapter in NinjaTrader so NinjaTrader works more reliably with that connection technology. It isn't a Managed or Unmanaged feature and would also be related to ATM strategies.

We will be happy to assist further with any platform related questions. Please refer to your broker for account/exchange based questions.