[This message was posted by Ryan Pierce of Lehman Brothers <[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/e5ba7114 - PLEASE DO NOT REPLY BY MAIL.]
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 -~----------~----~----~----~------~----~------~--~---
