There’s a slight issue with option (a), namely that it is impossible to
send an unsolicited cancel in FIX to reduce order quantity; an
unsolicited cancel just kills the order. The only way for an unsolicited
reduction of order quantity to happen is through ExecType=Restated, and
that wasn’t introduced until FIX 4.2.
Although, in option (a), I said unsolicited cancel I meant to say restatement. My apologies. Thanks to Ryan for pointing out the mistake. So the two options should read as follows:
(a) Decrease CumQty by the quantity busted and increase LeavesQty by the quantity busted. Immediately after this, send a restatement to reduce the OrderQty by the quantity busted. This would not break the “OrderQty = CumQty + LeavesQty” rule but would mean sending out two executions reports.
(b) Decrease CumQty by the quantity busted and leave LeavesQty unchanged. This would be an exception to the “OrderQty = CumQty + LeavesQty” rule.
The ECN will use FIX 4.2 so we will be able to use ExecType=Restated. Sounds like option (a) is the preferred option. We will go with that. My thanks to everyone on this thread for their valuable input.
[ original email was from Matt Simpson - msimpson@cme.com ] I’d like to see if there is a consensus on the value of the order status after restating the order due to a trade bust.
Case1 - Set OrdStatus to “Partially Filled” if CumQty greater than 0 but less than OrderQty
Case2 - Set OrdStatus to “Filled” if CumQty equal to OrderQty
Case3 - Set OrdStatus to “New”??? if CumQty is reduced to 0 and OrderQty is greater than 0.
It doesn’t necessarily seem correct to reset OrdStatus to “New” in this case. Any thoughts? What about a new OrdStatus of “Restated due to Bust” in this case?
There’s a slight issue with option (a), namely that it is impossible
to send an unsolicited cancel in FIX to reduce order quantity; an
unsolicited cancel just kills the order. The only way for an
unsolicited reduction of order quantity to happen is through
ExecType=Restated, and that wasn’t introduced until FIX 4.2.
Although, in option (a), I said unsolicited cancel I meant to say
restatement. My apologies. Thanks to Ryan for pointing out the mistake.
So the two options should read as follows:
(a) Decrease CumQty by the quantity busted and increase LeavesQty by the
quantity busted. Immediately after this, send a restatement to
reduce the OrderQty by the quantity busted. This would not break the
“OrderQty = CumQty + LeavesQty” rule but would mean sending out two
executions reports.
(b) Decrease CumQty by the quantity busted and leave LeavesQty
unchanged. This would be an exception to the “OrderQty = CumQty +
LeavesQty” rule.
The ECN will use FIX 4.2 so we will be able to use ExecType=Restated.
Sounds like option (a) is the preferred option. We will go with that. My
thanks to everyone on this thread for their valuable input.
[ original email was from Alexander Rivkind - alik@btobits.com ] Entities should not be multiplied beyond necessity. Using “New” looks consistent in this case.
I’d like to see if there is a consensus on the value of the order status
after restating the order due to a trade bust.
Case1 - Set OrdStatus to “Partially Filled” if CumQty greater than 0 but
less than OrderQty
Case2 - Set OrdStatus to “Filled” if CumQty equal to OrderQty
Case3 - Set OrdStatus to “New”??? if CumQty is reduced to 0 and OrderQty
is greater than 0.
It doesn’t necessarily seem correct to reset OrdStatus to “New” in this
case. Any thoughts? What about a new OrdStatus of “Restated due to Bust”
in this case?
This thread is an interesting topic as I am indeed working on an exchange. In particular, for the following, is it possible to use TCR to relay trade busts?
@robertlau That is OK, just was curious because you mentioned it.
I remember that the SIX Group SWX Exchange used Trade Capture Reports to report their so-called Trade Slips (booking records from clearing and settlement). So I checked the Standard Trading Interface gain.
It seems that they still use the TCR with 487/TradeReportTransType with value 4=Reverse to reverse a Trade Slip previously reported 0=New. There is also 1=Cancel in the FIXimate, so I would guess that Reverse refers to a previously reported trade and Cancel could be used unsolicitedly.
Therefore I would answer YES - you can use TCR to relay trade busts.
@robertlau for you, when you say “trade bust” is this done by the exchange operator rather than once a trade goes into clearing and settlement? I would think there is a difference between the two worlds.
@jorgthonnes mentions “trade slips” (I think this is supposed to be “trade splits”?) and “reverse” which to me are clearing terminology.
“trade bust” in equities exchanges does happen and the exchange communicates this using ExecutionReport with ExecType=H (trade cancel). “trade bust” in this context is about cancelling out a fill/partial fill of an order. Is this what you mean by “trade bust”?
@ltaikit Thanks for the clarifying questions. I think 4=Reverse is more related to the clearing & settlement stage. And yes, they called these booking records actually “Trade Slip” like e.g. packing slip. So no spelling error
@ltaikit, yes, assume it sends out an Execution report with with ExecType=F first. Can we later use a TCR to convey the trade cancel? The reason why using the TCR is that, based on the discussion on this thread, it is unable/impossible to maintain the total qty = cum qty + leave qty if using ExecutionReport. And this is my question and sorry for the confusion.
@robertlau To summarize on this question: SIX Swiss Exchange does it this way. The reversal of a trade transmitted by ExecType=F is done by a TCR of the type Reversal.
