Imported from previous forum
Fix: 4.2
If an order is partially filled when a cancel request is made what should the CumQty(14) and LeavesQty(151) reflect in the cancelled execution report?
According to the spec. both are required tags and LeavesQty should equal 0.
What about CumQty?
I don’t see anything stated about this field and one of our brokers is setting the value to zero in the Cancelled report even after reporting partial fills with correct CumQty set.
I would think this is ok as upstream systems should not be changing order state based on a cancelled report.
[ original email was from Andrew Scott - ascott@latentzero.com ]
> Fix: 4.2 If an order is partially filled when a cancel request is made
what should the CumQty(14) and LeavesQty(151) reflect in the cancelled
execution report?According to the spec. both are required tags and LeavesQty
should equal 0.What about CumQty?
I don’t see anything stated about this field and one of our brokers is
setting the value to zero in the Cancelled report even after reporting
partial fills with correct CumQty set.I would think this is ok as upstream systems should not be changing
order state based on a cancelled report.
I agree that there should not be an issue with setting 14 CumQty to zero on an Execution Report Cancel Accept message. This is not something that should matter as only the status change is relevant in these circumstances.
The upstream system should be changing order status in response to this message, but should not amend the cumulative executed quantity, even if this is set to 0 on the cancel accept message.
Setting CumQty to zero in the ER responding to the Cancel takes away the possibility to cross check if you have received and processed all fills by comparing the quantities from the fills with the “final” value of CumQty in the response to the Cancel.
The rule to have LeavesQty=0 is there to allow an exception to the usual rule LeavesQty = OrderQty - CumQty as soon as (the remainder of) an order is cancelled.
I would therefore try to persuade your broker to send a “proper” CumQty value when responding to the Cancel as it represents an added value.
Regards,
Hanno.
Fix: 4.2 If an order is partially filled when a cancel request is made
what should the CumQty(14) and LeavesQty(151) reflect in the cancelled
execution report?According to the spec. both are required tags and LeavesQty
should equal 0.What about CumQty?
I don’t see anything stated about this field and one of our brokers is
setting the value to zero in the Cancelled report even after reporting
partial fills with correct CumQty set.I would think this is ok as upstream systems should not be changing
order state based on a cancelled report.
[ original email was from Andrew Scott - ascott@latentzero.com ]
Hanno,
I agree that 14 CumQty should indeed be populated with the correct value, however would suggest that this is a ‘nice to have’ rather than an essential requirement, as there will be other indicators that something is amiss, and upstream systems will ignore this value on the cancel accept message anyway. It’s value comes in checking the logs afterwards.
Setting CumQty to zero in the ER responding to the Cancel takes away the
possibility to cross check if you have received and processed all fills
by comparing the quantities from the fills with the “final” value of
CumQty in the response to the Cancel.The rule to have LeavesQty=0 is there to allow an exception to the usual
rule LeavesQty = OrderQty - CumQty as soon as (the remainder of) an
order is cancelled.I would therefore try to persuade your broker to send a “proper” CumQty
value when responding to the Cancel as it represents an added value.Regards, Hanno.
Fix: 4.2 If an order is partially filled when a cancel request is made
what should the CumQty(14) and LeavesQty(151) reflect in the cancelled
execution report?According to the spec. both are required tags and LeavesQty should
equal 0.What about CumQty?
I don’t see anything stated about this field and one of our brokers is
setting the value to zero in the Cancelled report even after reporting
partial fills with correct CumQty set.I would think this is ok as upstream systems should not be changing
order state based on a cancelled report.
Andrew,
I would say having a proper CumQty value even on cancel conformations would be best. Specially when you consider low touch trading, partial fills on pending cancels (with 150=1) is not unusual.
Having an incorrect tag 14 value in such cases could confuse the buy side applications.
PS: I do not think this is something too difficult for the engines to develop as summing up quantities seems to be one of the most mundane things…
See Order State Matrix D4 in Appendix D of the 4.2 spec for guidance. You will see that CumQty contains a non-zero value when a cancel request is successful for a partially filled order - CumQty contains the qty already filled. LeavesQty is 0.
Fix: 4.2 If an order is partially filled when a cancel request is made
what should the CumQty(14) and LeavesQty(151) reflect in the cancelled
execution report?According to the spec. both are required tags and LeavesQty
should equal 0.What about CumQty?
I don’t see anything stated about this field and one of our brokers is
setting the value to zero in the Cancelled report even after reporting
partial fills with correct CumQty set.I would think this is ok as upstream systems should not be changing
order state based on a cancelled report.
The example shows it thus but says this on pg. 97:
Execution information (e.g. new partial fill or complete fill) should not be communicated in the same report as one which communicates other state changes (such as pending cancel, pending replacecanceled, replaced, accepted, done for day etc).
See Order State Matrix D4 in Appendix D of the 4.2 spec for guidance.
You will see that CumQty contains a non-zero value when a cancel request
is successful for a partially filled order - CumQty contains the qty
already filled. LeavesQty is 0.Fix: 4.2 If an order is partially filled when a cancel request is made
what should the CumQty(14) and LeavesQty(151) reflect in the cancelled
execution report?According to the spec. both are required tags and LeavesQty should
equal 0.What about CumQty?
I don’t see anything stated about this field and one of our brokers is
setting the value to zero in the Cancelled report even after reporting
partial fills with correct CumQty set.I would think this is ok as upstream systems should not be changing
order state based on a cancelled report.
This text refers to not sending lastShares when cumunicating an cancelled or replaced status change. This does not refer to cumQty.
The example shows it thus but says this on pg. 97:
Execution information (e.g. new partial fill or complete fill) should
not be communicated in the same report as one which communicates other
state changes (such as pending cancel, pending replacecanceled,
replaced, accepted, done for day etc).See Order State Matrix D4 in Appendix D of the 4.2 spec for guidance.
You will see that CumQty contains a non-zero value when a cancel
request is successful for a partially filled order - CumQty contains
the qty already filled. LeavesQty is 0.Fix: 4.2 If an order is partially filled when a cancel request is
made what should the CumQty(14) and LeavesQty(151) reflect in the
cancelled execution report?According to the spec. both are required tags and LeavesQty should
equal 0.What about CumQty?
I don’t see anything stated about this field and one of our brokers
is setting the value to zero in the Cancelled report even after
reporting partial fills with correct CumQty set.I would think this is ok as upstream systems should not be changing
order state based on a cancelled report.