Imported from previous forum
[ original email was from Carfield Yim - carfield.w.yim@jpmorgan.com ]
Some exchanges will have racing sometime about last execution report and cancel confirm if user send an cancel request, here is any example:
- User create Market Order with 50k qty
- Confirmed
- Order filled 25k [ LastShares ( tag 32 ), CumQty ( tag 14 ) and LeaveQty ( tag 151 ) = 25k ) ]
- Cancel request issued
- Cancel confirmed replied, but with LeaveQty = 8k , CumQty and LastShares both equal 0
- 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>?
What 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:
- User create Market Order with 50k qty
- Confirmed
- Order filled 25k [ LastShares ( tag 32 ), CumQty ( tag 14 ) and
LeaveQty ( tag 151 ) = 25k ) ]- Cancel request issued
- Cancel confirmed replied, but with LeaveQty = 8k , CumQty and
LastShares both equal 0- Then the last execution report back, with LeaveQty = 8k , CumQty =
42k and LastShares = 17kHow 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>?
[ original email was from Carfield Yim - carfield.w.yim@jpmorgan.com ]
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:
- User create Market Order with 50k qty
- Confirmed
- Order filled 25k [ LastShares ( tag 32 ), CumQty ( tag 14 ) and
LeaveQty ( tag 151 ) = 25k ) ]- Cancel request issued
- Cancel confirmed replied, but with LeaveQty = 8k , CumQty and
LastShares both equal 0- Then the last execution report back, with LeaveQty = 8k , CumQty =
42k and LastShares = 17kHow 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>?
[ original email was from Ryan Pierce - ryan.pierce@lehman.com ]
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.
[ original email was from Carfield Yim - carfield.w.yim@jpmorgan.com ]
Great 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.
[ original email was from Tushar Deshpande - tushar.deshpande@citi.com ]
The OMS upstream to EC can apply the fills on the order even after the order is canceled. May need special logic in the OMS. We had to revamp several components to implement it. But I think it’s worth the extra effort.
Great 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.
[ original email was from Carfield Yim - carfield.w.yim@jpmorgan.com ]
> The OMS upstream to EC can apply the fills on the order even after
the order is canceled. May need special logic in the OMS. We had to
revamp several components to implement it. But I think it’s worth the
extra effort.
It can, but is it a usual practice? Can we safely forward the execution after cancel confirm to DMA client? From the exactly discussion look like we cannot do that.