Re: Racing between last execution and cancel confirm
Lisa Taikitsadaporn / Brook Path Partners, Inc. <>
12 Oct 2008 10:53AM ETWhat 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>?
