Imported from previous forum
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
One concern raised at the meeting was what to do in the case where a trader places an order for 1000 shares, gets a partial execution on 500, tries to reduce the order to 700, but another partal execution on 300 happens before the change can be processed.
One solution mentioned would be to reject the cancel/replace. From a protocol standpoint, I don’t see anything wrong with implementing it this way. But it may not achieve what the trader wants. The cancel/replace rejects, the trader has 200 shares open, and that very easily could get filled before the trader fires off another cancel.
Another solution mentioned was accepting the change, and trying to do a cancel of the remaining quantity. But this would involve a negative LeavesQty. (OrderQty - CumQty = LeavesQty, and in this case OrderQty < CumQty) This I do not believe should be a valid approach as I don’t like the idea of negative LeavesQty, and confirming that an order has been reduced yet still filling it past the new OrderQty seems highly deceptive.
I suggest instead this alternate approach:
- The sell-side sends a Cancel Reject on the Cancel/Replace.
- The sell-side tries to cancel the balance of the order.
- The sell-side relays any partial fills that happen, using just the ClOrdID of the original order, not the Cancel/Replace request. If the order can’t be canceled in time, it will become Filled.
- If the cancel succedes, the sell-side sends an execution message that the order is canceled.
This has one significant drawback. It seems executions of type Canceled need both a ClOrdID (of the cancel request, which in this case was never sent) and an OrigClOrdID of the order in question. Is it possible to send an execution of type Canceled without a cancel request from the buy-side, i.e. OrigClOrdID = ClOrdID?
Thoughts?