Racing between last execution and cancel confirm
Carfield Yim / JPMorgan Chase
11 Oct 2008 12:04PM ETSome 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>?
