[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/aed12b13 - PLEASE DO NOT REPLY BY MAIL.]
> 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 Should be, but it is zero from the exchange. > > Then in #6 you should be receiving OrdStatus=Canceled, LeavesQty=8k, > CumQty=42k, LastShares=17k, LastPx=whatever price. > Again, should be, but both OrdStatus and Exectype is 1 ( partial fill ) > 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. > So you mean OMS and DMA client should handle this? I afraid at least our in house don't support it... What will you suggest amony 2-4 suggestion? > > > > 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 -~----------~----~----~----~------~----~------~--~---
