Re: Racing between last execution and cancel confirm
Carfield Yim / JPMorgan Chase
13 Oct 2008 12:29AM ET> 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>?
