[This message was posted by Tushar Deshpande of Citigroup <[EMAIL PROTECTED]> to the "4.2 Changes" discussion forum at http://fixprotocol.org/discuss/5. You can reply to it on-line at http://fixprotocol.org/discuss/read/687b0e17 - PLEASE DO NOT REPLY BY MAIL.]
The OMS upstream to EC can apply the fills on the order even after the order is canceled. May need special logic in the OMS. We had to revamp several components to implement it. But I think it's worth the extra effort. > Great suggestion, thanks a lot! > > > This is something that became an issue a while back. Any time there > > are multiple paths from an exchange, matching engine, etc. to a > > client, and round-robin routing among them is used, it is possible > > that an out will arrive before a partial fill. FPL addressed something > > similar to this in FIX 4.2, called a "Partial Decline." > > > > Of the options you list, I would say: > > > > > a) For the cancel confirm and last execution as it is. Concern: > > > Downstream OMS and DMA probably not support, as this is not > > > conform to FIX standard. > > > > I agree; not FIX compliant. One can't assume an OMS will check CumQty > > on the Cancelled message, and it probably will not like a partial fill > > on what it thinks is a dead order. Some systems may quietly ignore > > them, or send an automatic DK which might not get processed by the > > other end. The net result is that one might not know there's a problem > > until the trade breaks the next day. > > > > > b) Detect the racing via LeaveQty at the cancel confirm message and > > > Execution report at 3) in EC internally, wait until last > > > execution come back, then send that cancel cofirm after sending > > > the last execution report Concern: This will introduce status > > > management inside AEC and possible to cause performance issue. > > > > This is the best solution in terms of OMS compatibility. But, as you > > said, it requires keeping state. > > > > Note that if someone reports an order as cancelled, LeavesQty=0, so > > CumQty might be a better field to check to see if there is a missing > > partial fill. An unexplained jump in CumQty on a Cancelled message > > indicates that a partial fill may be missing. > > > > > c) Detect the racing via LeaveQty at the cancel confirm message and > > > Execution report at 3) in EC internally, if this is racing then > > > just drop the cancel confirm. Concern: If the last execution > > > report come back doesn't fully fill the order, this will leave > > > the order in P. CANC status and require manual work afterward. > > > > This doesn't sound very good to me. Traders and algos don't like > > having stuck orders. > > > > > d) Detect the racing via LeaveQty at the cancel confirm message and > > > Execution report at 3) in EC internally, if this is racing case > > > then convert the cancel confirm into amend confirm ( change > > > OrdStatus=5 and ExecType=5 ) with correct Qtys, after last > > > execution coming back, the order will become execution > > > completed. Concern: This is also not exactly conform to FIX and > > > require Downstream OMS and DMA if this is supported . > > > > This is close to what FPL standardized upon in FIX 4.2. The key is to > > send this with ExecRestatementReason(378) = 5 "Partial decline of > > OrderQty (e.g. exchange-initiated partial cancel" and > > ExecType=Restated. > > > > This is illustrated in FIX 4.2 Appendix D as D21. Note that this isn't > > exactly the case you mention, as the "decline" wasn't exchange > > initiated; there's no cancel submitted by the user. But I think it is > > close enough in meaning. > > > > Note that even though "Restatement" has been in the FIX spec since > > 2000, some firms might not implement it. Your option "b" is probably > > the most universal, even if it does require keeping state and may have > > a performance impact. [You can unsubscribe from this discussion group by sending a message to mailto:[EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
