[This message was posted by Carfield Yim of JPMorgan Chase <[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/ca5217f5 - PLEASE DO NOT REPLY BY MAIL.]
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 -~----------~----~----~----~------~----~------~--~---
