Use of CxlQty(84) in Execution Reports when trades are busted


I am working on a system where we would like to implement a rule that if an execution “trade bust” occurs then we cancel both the partial fill in question and the equivalent portion of the order. We were thinking this is best captured by setting a nonzero value for CxlQty(84) on the Order and sending this in the Execution Report that reports the “trade bust” event (i.e. the one that has ExecType=Trade Cancel). So for example, we want to bust a partial fill of size 2 from a fully filled order of size 10. The order state information changes from e.g. OrderQty=10, LeavesQty=0, CumQty=10, CxlQty=0, OrdStatus=Filled to OrderQty=10, LeavesQty=0, CumQty=8, CxlQty=2, OrdStatus=Filled. Does this make sense? Or should we only use CxlQty with the OrdStatus of “Cancelled” ?

I have been a little confused as to whether I can do this in cases where the Order is still working (i.e. it is partially filled and working, we bust one of the partial fills, and wish the working quantity (LeavesQty) of the order to remain constant. E.g. once again assuming we’re busting a partial fill of size 2, we’d like order state information to change from OrderQty=10, LeavesQty=5, CumQty=5, CxlQty=0, OrdStatus=Partially Filled to OrderQty=10, LeavesQty=5, CumQty=3, CxlQty=2, OrdStatus=Partially Filled. Is this a legitimate use case or should we instead send two Execution Reports: a Trade Cancel which reduces CumQty and increases LeavesQty followed (atomically) by a “Restated” Execution Report with ExecRestatementReason “Partial decline of OrderQty” which reduces OrderQty to 8 and LeavesQty to 5?


Orders are just a vehicle to get to executions and should be seen as a one-way street. In general, it is not a good idea to go back to the order when you change executions after having confirmed them to your counterparty. The FIX Standard requires the equation OrderQty=CumQty+LeavesQty to hold. The equation no longer holds in your examples, you would need to add CxlQty to it.

CxlQty should only be used in a transactional context, e.g. for a response to an IOC to say how much was cancelled (FIX Latest allows you to send a single response to an IOC order, see EP188 at for details). CxlQty should not be part of the entity-level information of an order. In other words, an order should not have a static cancelled quantity in addition to having a total, executed and remaining quantity.

Another example of a transactional context is the order modification when you reduce the order quantity. You may fail to reduce it the way you requested due to in-flight executions that occurred before it could be modified. CxlQty can send back the actually removed quantity from the order.


Thank you Hanno. This confirms my original thinking that definitely in the second example, where the order was not fully filled and we want to preserve the unfilled quantity on the order book, use of CxlQty as suggested violates the intended meaning of CxlQty. I don’t see any better option other than (from the exchange’s point of view) atomicallly sending the trade cancel followed immediately by an order size reduction equal to the size of the cancelled trade.

For the first example though, I wonder if in fact it is OK to use CxlQty as this order is in a final state (LeavesQty=0) already and we intend to keep it in a final state after the trade bust. In this case, setting CxlQty does seem like a transactional context as you describe (although perhaps a slightly odd one). It is very similar to the output of a partially filled IOC order in that LeavesQty=0 and OrderQty=CumQty+CxlQty.

This is more complex if we need to bust a second partial fill in the same order, in which case we’ve treated CxlQty as a part of the order state as we need to increase it the second time - but this is still an order that has LeavesQty=0, so is this definitely something you would consider incorrect?