|
4.2 Changes
< Previous Next >
Re: Racing between last execution and cancel confirm
Carfield Yim / JPMorgan Chase
13 Oct 2008 11:05PM ETGreat suggestion, thanks a lot!
> This is something that became an issue a while back. Any time there are
> multiple paths from an exchange, matching engine, etc. to a client, and
> round-robin routing among them is used, it is possible that an out will
> arrive before a partial fill. FPL addressed something similar to this in
> FIX 4.2, called a "Partial Decline."
>
> Of the options you list, I would say:
>
> > 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.
>
> I agree; not FIX compliant. One can't assume an OMS will check CumQty on
> the Cancelled message, and it probably will not like a partial fill on
> what it thinks is a dead order. Some systems may quietly ignore them, or
> send an automatic DK which might not get processed by the other end. The
> net result is that one might not know there's a problem until the trade
> breaks the next day.
>
> > 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.
>
> This is the best solution in terms of OMS compatibility. But, as you
> said, it requires keeping state.
>
> Note that if someone reports an order as cancelled, LeavesQty=0, so
> CumQty might be a better field to check to see if there is a missing
> partial fill. An unexplained jump in CumQty on a Cancelled message
> indicates that a partial fill may be missing.
>
> > 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.
>
> This doesn't sound very good to me. Traders and algos don't like having
> stuck orders.
>
> > 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 .
>
> This is close to what FPL standardized upon in FIX 4.2. The key is to
> send this with ExecRestatementReason(378) = 5 "Partial decline of
> OrderQty (e.g. exchange-initiated partial cancel" and ExecType=Restated.
>
> This is illustrated in FIX 4.2 Appendix D as D21. Note that this isn't
> exactly the case you mention, as the "decline" wasn't exchange
> initiated; there's no cancel submitted by the user. But I think it is
> close enough in meaning.
>
> Note that even though "Restatement" has been in the FIX spec since 2000,
> some firms might not implement it. Your option "b" is probably the most
> universal, even if it does require keeping state and may have a
> performance impact.
Re: Racing between last execution and cancel confirm
Carfield Yim / JPMorgan Chase 13 Oct 2008 11:05PM ET
|
