[This message was posted by Lisa Taikitsadaporn of Brook Path Partners, Inc. <[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/7e5f55f6 - PLEASE DO NOT REPLY BY MAIL.]
What is important that is missing from your illustration is an indication of what the OrdStatus is from the exchange. In #5 you should be receiving OrdStatus=Canceled, LeavesQty=8k, CumQty=42K, LastShares and LastPx = 0. Note that CumQty should not be zero has in your illustration as CumQty + LeavesQty = OrdQty Then in #6 you should be receiving OrdStatus=Canceled, LeavesQty=8k, CumQty=42k, LastShares=17k, LastPx=whatever price. An order state of "canceled" has a higher precedence than an order state of "partial fill" - see the precedence table in the Execution Report section of the 4.2 spec. The LeavesQty and CumQty in #5 implies that there was additional qty filled already before the cancel can be confirmed. If for some reason in #6 the exchange sends you OrdStatus=PFill, LeavesQty=8k, CumQty=42k, LastShares=17k, LastPx=price, the OMS needs to be smart enough to know that the OrdStatus is still "canceled" based on having received that cancel confirm in #5. What information the OMS gets out of this PFill would be the LastShares and LastPx. > Some exchanges will have racing sometime about last execution report and > cancel confirm if user send an cancel request, here is any example: > > 1) User create Market Order with 50k qty > 2) Confirmed > 3) Order filled 25k [ LastShares ( tag 32 ), CumQty ( tag 14 ) and > LeaveQty ( tag 151 ) = 25k ) ] > 4) Cancel request issued > 5) Cancel confirmed replied, but with LeaveQty = 8k , CumQty and > LastShares both equal 0 > 6) Then the last execution report back, with LeaveQty = 8k , CumQty = > 42k and LastShares = 17k > > How should the exchange connectivity (EC) layer approach to this > problem? Our colleagues concluded there are 4: > > 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. > > 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. > > 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. > > 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 . > > > What is your opinions about those>? [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 -~----------~----~----~----~------~----~------~--~---
