Imported from previous forum
Suppose there is cancel/replace chain (Order A cancel/replaced by order B, Order B cancel/replaced by order C, Order C cancel/replaced by order
D,…), if the first pair(Order A cancel/replaced by Order B) is
rejected(TLTC), Should I reject the rest of the cancel/replaces to TLTCs
or assume our clients will automatically reject them. Is there any FIX specs to support this (any version)?
It sounds like your logic is flawed.
(1) I think you’re sending cxl/replace requests. Not cancel/replaces.
(2) A user should not be allowed to send multiple
cxl/replace requests without seeing a “Modified” execution report.
[ original email was from John Prewett - jprewett@lavatrading.com ]
It is indeed permissable to send multiple Cxl/replace requests without seeing any ExecutionReport or CancelReject responses. Please look at examples 18 thru 21 in the order state matrices in Chapter 4 of the FIX.4.3 specification with errata. It is up to the sell-side to decide whether to attempt to honor them all (examples 18 or 19) or to reject all subsequent while the first Cxl/replace request is still pending (example 21).
The thread originator’s issue as to what should be done to subsequent queued Cxl/replace requests when the first Cxl/replace is rejected with TLTC is a good one. There are several potentially correct responses, depending on whether the TLTC meant that the order was completely filled or the TLTC meant that the request to reduce the quantity couldn’t be satisfied because the order was already partially filled with a quantity greater than the desired reduced quantity.
In the case where the original order was completely filled, I believe all Cxl/Replace requests should be rejected with TLTC. The suitable example (11) can be found in the chapter 4 order state matrices. Note that the OrigClOrdID on all the CancelReject responses appears to be X (or in the poster’s example, A) if you interpret this from example 20.
In the case where there was an failed attempt to reduce the order quantity because it was already partially filled above that quantity, please use examples 13 & 14 as your guide. The original Cxl/replace request should be honored (no CxlReject message with TLTC) although the order quantity is too low. The OrdStatus is reported as filled on the ExecutionReport(replaced). The processing of subsequent Cxl/replace requests should then be responded to with CancelReject(TLTC) messages.
I hope this helps (and it is correct).