Imported from previous forum
In terms of the FIX protocol “A Cancel on an execution (trade bust) happening the same day of the trade will result in CumQty and DayCumQty each decreasing by the quantity busted, and LeavesQty increasing by the quantity busted. OrderQty and DayOrderQty will remain unchanged.”
I am currently working on implementing a matching system at an exchange. In terms of the current business rules of the exchange, if a trade/execution is busted, the busted quantity is not reinstated in the order book. In this case, would it be correct to increase the LeavesQty by the quantity busted?
Wouldn’t it be more appropriate to reduce the CumQty and by the quantity busted but to leave the LeavesQty unchanged. If we do this, OrderQty will no longer equal CumQty + LeavesQty but isn’t that acceptable in this particular scenario? How can we increase LeavesQty if the quantity busted will never be available for execution?
[ original email was from Bernt Sandén - bernt.sanden@om.com ]
In the exchange world it normally does not make sense to reinstate the busted quantity. The most common reason for trade busts in the exchange world is participant making mistakes when entering orders, e.g. a price way off the market price. If these orders should be reinstated after a bust the same erroneous matching would occur again.
It gets even worse if the order no longer exists in the matching system. How do you reinstate order volume for an order that does no longer exist?
The LeavesQty shall reflect the order volume open for further execution. In your case the busted order volume should not be open for further execution so you should not increase the LeavesQty by the quantity busted.
The correct procedure in your case would be to decrease the CumQty and leave the LeavesQty unchanged as you suggested even if it breaks the FIX specification.
In terms of the FIX protocol “A Cancel on an execution (trade bust)
happening the same day of the trade will result in CumQty and DayCumQty
each decreasing by the quantity busted, and LeavesQty increasing by the
quantity busted. OrderQty and DayOrderQty will remain unchanged.”I am currently working on implementing a matching system at an exchange.
In terms of the current business rules of the exchange, if a
trade/execution is busted, the busted quantity is not reinstated in the
order book. In this case, would it be correct to increase the LeavesQty
by the quantity busted?Wouldn’t it be more appropriate to reduce the CumQty and by the quantity
busted but to leave the LeavesQty unchanged. If we do this, OrderQty
will no longer equal CumQty + LeavesQty but isn’t that acceptable in
this particular scenario? How can we increase LeavesQty if the quantity
busted will never be available for execution?
Very true. Some people call this situation as “Execution cancel”.
In “Execution Bust” the busted qty is re-instated into the order.
The downside issue comes on the client side which receives a notification of this “Excecution cancel” via FIX message with inconsistent Leaves/Cum/OrdQty.
Though these things don’t happen a lot, some application show red-flags on the UI so traders can manually handle the situation.
In the exchange world it normally does not make sense to reinstate the
busted quantity. The most common reason for trade busts in the exchange
world is participant making mistakes when entering orders, e.g. a price
way off the market price. If these orders should be reinstated after a
bust the same erroneous matching would occur again.It gets even worse if the order no longer exists in the matching
system. How do you reinstate order volume for an order that does no
longer exist?The LeavesQty shall reflect the order volume open for further
execution. In your case the busted order volume should not be open for
further execution so you should not increase the LeavesQty by the
quantity busted.The correct procedure in your case would be to decrease the CumQty and
leave the LeavesQty unchanged as you suggested even if it breaks the FIX
specification.In terms of the FIX protocol “A Cancel on an execution (trade bust)
happening the same day of the trade will result in CumQty and
DayCumQty each decreasing by the quantity busted, and LeavesQty
increasing by the quantity busted. OrderQty and DayOrderQty will
remain unchanged.”I am currently working on implementing a matching system at an
exchange. In terms of the current business rules of the exchange, if a
trade/execution is busted, the busted quantity is not reinstated in
the order book. In this case, would it be correct to increase the
LeavesQty by the quantity busted?Wouldn’t it be more appropriate to reduce the CumQty and by the
quantity busted but to leave the LeavesQty unchanged. If we do this,
OrderQty will no longer equal CumQty + LeavesQty but isn’t that
acceptable in this particular scenario? How can we increase LeavesQty
if the quantity busted will never be available for execution?
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
In general, I agree that if the shares are never going back into the book and absolutely can never be traded, then LeavesQty shouldn’t be increased to show them. And CumQty, obviously, must be adjusted downward. I would say that this makes sense in the case specified, i.e. when an exchange chooses to bust executions for reasons like bad prices, an out of control program trading engine, an erroneously large order sweeping through an entire side of a book, etc.
While CumQty + LeavesQty = OrderQty under most situations, there is a big exception, namely that LeavesQty can be 0 on a dead order. So in a case where an order is filled and then one or more partial fills is busted, I can see leaving LeavesQty = 0, and I don’t feel it would “break” the spec too terribly. I’m not sure what OrdStatus should be in this case, though. But this is a good candidate for A FIX 4.4 service pack; it seems FPL should document this case explicitly.
Now things become more complicated if an order is partially filled and then busted. For example, on a 1000 share order, there is a partial for 600, and the rest is busted. Does that mean that:
A. The 600 shares are busted and the whole order is dead?
B. The 600 shares are busted but 400 still stay live on the book?
In case A, I believe there should be an unsolicited cancel followed by a bust. (And in this case, LeavesQty=0; it’s just like the example of an order that is filled and then busted.)
In case B, it’s a lot more complex. My personal feeling is that a bust with OrderQty=1000, CumQty=0, and LeavesQty=400 seems wrong to me. I believe the proper course of action is to bust the trade with LeavesQty = 1000 and then immediately submit a Restatement to change the order so that OrderQty=400, CumQty=0, and LeavesQty=400.
Also, I must respond to one idea in this thread that I interpreted as implying that in all cases exchange busts don’t put volume back on the book. From what I understand, in exchanges where there is a lot of human interaction with order flow, it may be common to send a bust and a new trade to represent a price correction. In those cases, I feel that LeavesQty absolutely must be increased by the bust volume, since that way the new trade will decrease LeavesQty as usual.
[ original email was from Andrew Scott - ascott@latentzero.com ]
In my opinion, and from a buy-side perspective, there should never be any exceptions to the qty = cumqty + leavesqty rule for trade busts. Sending in leavesqty = 0 does not make sense for a dealer who may wish to send the qty affected elsewhere, or else send it again at a different price. Perhaps 39 OrdStatus could be 3 ‘Done for Day’ for dead orders in which a partial is being busted?
Also, for Case B above, in which we have a partial for 600 with ExecID = 1 and another at 400 with ExecID = 2, it doesn’t make any sense to bust the full 10000 in one message and issue an unsolicited amend [39 OrdType = ‘D’] to ‘correct’ the execution, when we could instead straightforwardly bust with RefExecID = 1 and leave the remaining 400 on the book. A trade correction method could be used if it is desired to adjust the executed qty on an order.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> In my opinion, and from a buy-side perspective, there should never be
any exceptions to the qty = cumqty + leavesqty rule for trade busts.
Sending in leavesqty = 0 does not make sense for a dealer who may wish
to send the qty affected elsewhere, or else send it again at a different
price. Perhaps 39 OrdStatus could be 3 ‘Done for Day’ for dead orders in
which a partial is being busted?
For most cases where a buy-side is sending a FIX order for execution by the sell side either using an algorithm or human traders, you are right that the dealer will want to send the busted quantity elsewhere. In that case, LeavesQty must increase, and OrderQty = LeavesQty + CumQty holds.
But in the DMA case, the rules of engagement of the exchange may specify that busted quantities are dead, for good. These are the scenarios where LeavesQty = 0 and OrderQty = LeavesQty + CumQty doesn’t hold.
I maintain that there should be a method in the FIX spec to differentiate between a bust that is dead for good and a bust that is still subject to execution.
Also, for Case B above, in which we have a partial for 600 with ExecID =
1 and another at 400 with ExecID = 2, it doesn’t make any sense to bust
the full 10000 in one message and issue an unsolicited amend [39 OrdType
= ‘D’] to ‘correct’ the execution, when we could instead
straightforwardly bust with RefExecID = 1 and leave the remaining 400 on
the book. A trade correction method could be used if it is desired to
adjust the executed qty on an order.
Sorry, I wasn’t clear on the language of the example.
600 shares trade (ExecID = 1) leaving 400 untraded and live. So if ExecID = 1 gets busted in the “these shares are never going back on the book” case, it creates a question of what to do with the remaining 400 shares, assuming the customer hasn’t yet cancelled the order. In this case, I can see either an unsolicited cancel, or a case where the shares do stay live but then the exchange, I feel, must restate the order.
[ original email was from Andrew Scott - ascott@latentzero.com ]
> > In my opinion, and from a buy-side perspective, there should never be
any exceptions to the qty = cumqty + leavesqty rule for trade busts.
Sending in leavesqty = 0 does not make sense for a dealer who may wish
to send the qty affected elsewhere, or else send it again at a
different price. Perhaps 39 OrdStatus could be 3 ‘Done for Day’ for
dead orders in which a partial is being busted?For most cases where a buy-side is sending a FIX order for execution by
the sell side either using an algorithm or human traders, you are right
that the dealer will want to send the busted quantity elsewhere. In that
case, LeavesQty must increase, and OrderQty = LeavesQty + CumQty holds.But in the DMA case, the rules of engagement of the exchange may specify
that busted quantities are dead, for good. These are the scenarios where
LeavesQty = 0 and OrderQty = LeavesQty + CumQty doesn’t hold.I maintain that there should be a method in the FIX spec to
differentiate between a bust that is dead for good and a bust that is
still subject to execution.
Isn’t this already done? How about:
Bust that is dead for good = Trade Bust + Unsolicited Cancelled on the order;
Bust that is still subject to execution = Trade Bust.
Therefore, no need to vary the OrderQty = LeavesQty + CumQty rule, and the functionality required is provided by existing protocol messages.
Also, for Case B above, in which we have a partial for 600 with
ExecID = 1 and another at 400 with ExecID = 2, it doesn’t make any
sense to bust the full 10000 in one message and issue an unsolicited
amend [39 OrdType
= ‘D’] to ‘correct’ the execution, when we could instead
straightforwardly bust with RefExecID = 1 and leave the remaining 400
on the book. A trade correction method could be used if it is desired
to adjust the executed qty on an order.Sorry, I wasn’t clear on the language of the example.
600 shares trade (ExecID = 1) leaving 400 untraded and live. So if
ExecID = 1 gets busted in the “these shares are never going back on the
book” case, it creates a question of what to do with the remaining 400
shares, assuming the customer hasn’t yet cancelled the order. In this
case, I can see either an unsolicited cancel, or a case where the shares
do stay live but then the exchange, I feel, must restate the order.
Thank you for the clarification. I agree. It all depends on the reason for the bust, and the exchange RoE.
[ original email was from Bernt Sandén - bernt.sanden@om.com ]
> > In my opinion, and from a buy-side perspective, there should never be
any exceptions to the qty = cumqty + leavesqty rule for trade busts.
Sending in leavesqty = 0 does not make sense for a dealer who may wish
to send the qty affected elsewhere, or else send it again at a
different price. Perhaps 39 OrdStatus could be 3 ‘Done for Day’ for
dead orders in which a partial is being busted?For most cases where a buy-side is sending a FIX order for execution by
the sell side either using an algorithm or human traders, you are right
that the dealer will want to send the busted quantity elsewhere. In that
case, LeavesQty must increase, and OrderQty = LeavesQty + CumQty holds.But in the DMA case, the rules of engagement of the exchange may specify
that busted quantities are dead, for good. These are the scenarios where
LeavesQty = 0 and OrderQty = LeavesQty + CumQty doesn’t hold.I maintain that there should be a method in the FIX spec to
differentiate between a bust that is dead for good and a bust that is
still subject to execution.
Agree. Exchanges must be able to have that option.
Also, for Case B above, in which we have a partial for 600 with
ExecID = 1 and another at 400 with ExecID = 2, it doesn’t make any
sense to bust the full 10000 in one message and issue an unsolicited
amend [39 OrdType
= ‘D’] to ‘correct’ the execution, when we could instead
straightforwardly bust with RefExecID = 1 and leave the remaining 400
on the book. A trade correction method could be used if it is desired
to adjust the executed qty on an order.Sorry, I wasn’t clear on the language of the example.
600 shares trade (ExecID = 1) leaving 400 untraded and live. So if
ExecID = 1 gets busted in the “these shares are never going back on the
book” case, it creates a question of what to do with the remaining 400
shares, assuming the customer hasn’t yet cancelled the order. In this
case, I can see either an unsolicited cancel, or a case where the shares
do stay live but then the exchange, I feel, must restate the order.
The exchange might cancel the rest of the order depending on their rules. I am not sure that the order has to be restated. It should be enough to send the trade bust and telling the user that “these shares are never going back”.
Assume the following scenario:
- New order single with volume 1000
- Execution Report returned with OrderQty=1000, CumQty=0, LeavesQty=1000
- Partiall fill of 600, OrderQty=1000, Cum=600, Leaves=400
- Trade cancel (bust) of 600, OrderQty=1000, Cum=0, Leaves=400.
The client have all information here. Why restating the order?
[ original email was from Andrew Scott - ascott@latentzero.com ]
> > > In my opinion, and from a buy-side perspective, there should never
be any exceptions to the qty = cumqty + leavesqty rule for trade
busts. Sending in leavesqty = 0 does not make sense for a dealer who
may wish to send the qty affected elsewhere, or else send it again
at a different price. Perhaps 39 OrdStatus could be 3 ‘Done for Day’
for dead orders in which a partial is being busted?For most cases where a buy-side is sending a FIX order for execution
by the sell side either using an algorithm or human traders, you are
right that the dealer will want to send the busted quantity elsewhere.
In that case, LeavesQty must increase, and OrderQty = LeavesQty +
CumQty holds.But in the DMA case, the rules of engagement of the exchange may
specify that busted quantities are dead, for good. These are the
scenarios where LeavesQty = 0 and OrderQty = LeavesQty + CumQty
doesn’t hold.I maintain that there should be a method in the FIX spec to
differentiate between a bust that is dead for good and a bust that is
still subject to execution.Agree. Exchanges must be able to have that option.
IMHO this is not necessary. Please see reply at:
http://www.fixprotocol.org/discuss/read/015f4faa
Also, for Case B above, in which we have a partial for 600 with
ExecID = 1 and another at 400 with ExecID = 2, it doesn’t make any
sense to bust the full 10000 in one message and issue an unsolicited
amend [39 OrdType
= ‘D’] to ‘correct’ the execution, when we could instead
straightforwardly bust with RefExecID = 1 and leave the remaining
400 on the book. A trade correction method could be used if it is
desired to adjust the executed qty on an order.Sorry, I wasn’t clear on the language of the example.
600 shares trade (ExecID = 1) leaving 400 untraded and live. So if
ExecID = 1 gets busted in the “these shares are never going back on
the book” case, it creates a question of what to do with the
remaining 400 shares, assuming the customer hasn’t yet cancelled the
order. In this case, I can see either an unsolicited cancel, or a
case where the shares do stay live but then the exchange, I feel,
must restate the order.
The exchange might cancel the rest of the order depending on their
rules. I am not sure that the order has to be restated. It should be
enough to send the trade bust and telling the user that “these shares
are never going back”.Assume the following scenario:
- New order single with volume 1000
- Execution Report returned with OrderQty=1000, CumQty=0,
LeavesQty=1000- Partiall fill of 600, OrderQty=1000, Cum=600, Leaves=400
- Trade cancel (bust) of 600, OrderQty=1000, Cum=0, Leaves=400.
The client have all information here. Why restating the order?
- above is a protocol violation as things stand. It is also not necessary as the functionality required can be supported using existing messages i.e. trade bust of the 600 in the sense of ‘returning the qty’ followed by unsolicited amended ‘restatement’ adjusting the qty down from 1000 to 400. If the upstream client do not support unsolicited amended then an unsolicited cancelled can be used instead combined with a non-FIX request to resubmit the 400.
The whole thing depends on intent and RoE: pleae see
http://www.fixprotocol.org/discuss/read/015f4faa
[ original email was from John Prewett - jprewett@lavatrading.com ]
I agree with Ryan on one fundamental thing:
All possible scenarios need to be thoroughly documented and added to the protocol specification.
The standard should demonstrate the official way to convey whether busted shares are re-opened or not. I can think of the following scenarios that should be explicitly documented:
A bust occurs on a partially filled order. CumQty is still > 0 after the bust due to another partial fill that wasn’t the subject of the bust.
A bust occurs on a partially filled order. CumQty = 0 after the bust as the only partial fill was busted.
A bust occurs on a filled order. CumQty is still > 0 after the bust due to another partial fill that wasn’t the subject of the bust.
A bust occurs on a filled order. CumQty = 0 after the bust as the only fill was busted.
A bust occurs on a partially filled order that has expired or been canceled. CumQty is still > 0 after the bust due to another partial fill that wasn’t the subject of the bust.
A bust occurs on a partially filled order that has expired or been canceled. CumQty = 0 after the bust as the only partial fill was busted.
All the above scenarios need to be documented as to what happens if the busted shares are re-opened or not.
The state of the order after the bust is of the utmost importance. Two problematic scenarios are:
A.
The state of a previously finished (filled/expired/canceled etc) order must be well understood after the bust. If shares are re-opened on a finished order, it is possible that the order re-opens (or not), depending on the behavior of the execution venue.
B.
The state of an order when the CumQty becomes 0 as a result of the bust.
Let me put in a vote for NOT adhering to the (OrderQty = CumQty + LeavesQty) rule under the circumstance where busted shares are not re-opened. I also see no need for restatement. In this situation, the bust should decrement CumQty and not touch LeavesQty. This is an unambiguous way of conveying that information IMHO.
I am generally not in favor of implementations where you need to send two messages to convey one event. Thus I don’t particularly care for “bust followed by restatement”. In this case, using LeavesQty to indicate the remaining open quantity and CumQty to indciate the quantity currently filled seems just fine.
Thanks for listening.
John Prewett
[ original email was from Andrew Scott - ascott@latentzero.com ]
> I agree with Ryan on one fundamental thing: All possible scenarios need
to be thoroughly documented and added to the protocol specification.
I agree that more documentation is definitely a good thing, however I do not think that the Protocol itrself needs modification.
The standard should demonstrate the official way to convey whether
busted shares are re-opened or not. I can think of the following
scenarios that should be explicitly documented:1.A bust occurs on a partially filled order. CumQty is still > 0
after the bust due to another partial fill that wasn’t the subject
of the bust.2.A bust occurs on a partially filled order. CumQty = 0 after the bust
as the only partial fill was busted.3.A bust occurs on a filled order. CumQty is still > 0 after the bust
due to another partial fill that wasn’t the subject of the bust.4.A bust occurs on a filled order. CumQty = 0 after the bust as the only
fill was busted.5.A bust occurs on a partially filled order that has expired or been
canceled. CumQty is still > 0 after the bust due to another partial
fill that wasn’t the subject of the bust.6.A bust occurs on a partially filled order that has expired or
been canceled. CumQty = 0 after the bust as the only partial fill
was busted.All the above scenarios need to be documented as to what happens if the
busted shares are re-opened or not.The state of the order after the bust is of the utmost importance. Two
problematic scenarios are:A.The state of a previously finished (filled/expired/canceled etc) order
must be well understood after the bust. If shares are re-opened on a
finished order, it is possible that the order re-opens (or not),
depending on the behavior of the execution venue.B.The state of an order when the CumQty becomes 0 as a result of the
bust.Let me put in a vote for NOT adhering to the (OrderQty = CumQty +
LeavesQty) rule under the circumstance where busted shares are not re-
opened. I also see no need for restatement. In this situation, the bust
should decrement CumQty and not touch LeavesQty. This is an unambiguous
way of conveying that information IMHO.I am generally not in favor of implementations where you need to send
two messages to convey one event. Thus I don’t particularly care for
“bust followed by restatement”. In this case, using LeavesQty to
indicate the remaining open quantity and CumQty to indciate the quantity
currently filled seems just fine.
This will work under certain scenarios which are already defined for FIX 4.2:
"The general rule is: OrderQty = CumQty + LeavesQty.
There can be exceptions to this rule when ExecType and/or OrdStatus are Canceled, DoneForTheDay (e.g. on a day order), Expired, Calculated, or Rejected in which case the order is no longer active and LeavesQty could be 0."
Hence I do not see that there would be a problem setting LeavesQty to zero, PROVIDED THAT the OrdStatus is clearly communicated as above.
In our example, setting OrdStatus to Expired or Cancelled will clearly communicate the information that the remaining qty is not being left on the exchange / book.
Just setting LeavesQty to zero by itself is however ambiguous and is sure to cause issues.
Thanks for listening.
John Prewett
Welcome,
Andrew Scott
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> This will work under certain scenarios which are already defined
for FIX 4.2:
"The general rule is: OrderQty = CumQty + LeavesQty. There can be exceptions to this rule when ExecType and/or OrdStatus are Canceled, DoneForTheDay (e.g. on a day order), Expired, Calculated, or Rejected in which case the order is no longer active and LeavesQty could be 0."Hence I do not see that there would be a problem setting LeavesQty to
zero, PROVIDED THAT the OrdStatus is clearly communicated as above.In our example, setting OrdStatus to Expired or Cancelled will clearly
communicate the information that the remaining qty is not being left on
the exchange / book.
I agree. In the case of a filled order having a trade busted, with the open shares not going back into the book, sending the bust with LeavesQty=0 and OrdStatus=Done for Day sounds good. As you pointed out, there is precedent for OrderQty != CumQty + LeavesQty. And Done for Day is explicitly mentioned as an exception to the rule.
However, that exception only applies, in my view, when LeavesQty = 0 and with those specific OrdStatus values. So in the case where a 1000 share order has 600 shares filled, is live, and has a bust of those 600 shares, and those busted shares are not put back onto the book but the remaining 400 stay live, I do not like sending the bust with LeavesQty=400.
While my suggestion that the order is first busted with LeavesQty=1000 and then restated with OrderQty = LeavesQty = 400 will work, I’m favoring it less after what John Prewitt said. Doing this in one message allows for atomic operation. I know that in the OMS my firm develops, we’ve added a flag to our internal representation of a bust to indicate whether those shares are still live and subject to execution, or whether they’re dead for good, so it would be convenient if this info could be conveyed in one message.
Still, this scenario is rare. I would imagine that if a live, partially filled order was busted, either those shares go back on the book (and may likely be traded again if this was due to a trade price correction), or the whole order would be killed as part of the bust. I don’t envision the above scenario of the 600 busted shares gone for good while the remaining 400 shares are still live would be at all common.
[ original email was from Andrew Scott - ascott@latentzero.com ]
> > This will work under certain scenarios which are already defined
for FIX 4.2:
"The general rule is: OrderQty = CumQty + LeavesQty. There can be exceptions to this rule when ExecType and/or OrdStatus are Canceled, DoneForTheDay (e.g. on a day order), Expired, Calculated, or Rejected in which case the order is no longer active and LeavesQty could be 0."Hence I do not see that there would be a problem setting LeavesQty to
zero, PROVIDED THAT the OrdStatus is clearly communicated as above.In our example, setting OrdStatus to Expired or Cancelled will clearly
communicate the information that the remaining qty is not being left
on the exchange / book.I agree. In the case of a filled order having a trade busted, with the
open shares not going back into the book, sending the bust with
LeavesQty=0 and OrdStatus=Done for Day sounds good. As you pointed out,
there is precedent for OrderQty != CumQty + LeavesQty. And Done for Day
is explicitly mentioned as an exception to the rule.However, that exception only applies, in my view, when LeavesQty = 0 and
with those specific OrdStatus values. So in the case where a 1000 share
order has 600 shares filled, is live, and has a bust of those 600
shares, and those busted shares are not put back onto the book but the
remaining 400 stay live, I do not like sending the bust with
LeavesQty=400.While my suggestion that the order is first busted with LeavesQty=1000
and then restated with OrderQty = LeavesQty = 400 will work, I’m
favoring it less after what John Prewitt said. Doing this in one message
allows for atomic operation. I know that in the OMS my firm develops,
we’ve added a flag to our internal representation of a bust to indicate
whether those shares are still live and subject to execution, or whether
they’re dead for good, so it would be convenient if this info could be
conveyed in one message.
This seems contrary to the spirit of the FIX Protocol in which one operation is mapped to by one FIX message. The operation you are seeking to support, trade bust of a partial for 600 followed by cancellation of the 600 on the order, is by definition not one but two atomic operations, that are best supported by:
a. the trade bust; followed by;
b. the restatement [or cancellation].
Please bear in mind that according to the FIX 4.2 specification:
“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 replace, canceled, replaced, accepted, done for day etc).”
This arrangement has the added advantage that there would then be no need to amend the Protocol to support the desired functionality.
Still, this scenario is rare. I would imagine that if a live, partially
filled order was busted, either those shares go back on the book (and
may likely be traded again if this was due to a trade price correction),
or the whole order would be killed as part of the bust. I don’t envision
the above scenario of the 600 busted shares gone for good while the
remaining 400 shares are still live would be at all common.
I agree - this does seem to be rather an edge condition. No need to change the protocol definition, then 
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> This seems contrary to the spirit of the FIX Protocol in which one
operation is mapped to by one FIX message. The operation you are seeking
to support, trade bust of a partial for 600 followed by cancellation of
the 600 on the order, is by definition not one but two atomic
operations, that are best supported by:a. the trade bust; followed by;
b. the restatement [or cancellation].Please bear in mind that according to the FIX 4.2 specification:
“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 replace, canceled,
replaced, accepted, done for day etc).”This arrangement has the added advantage that there would then be no
need to amend the Protocol to support the desired functionality.
I wouldn’t necessarily say that one message would be doing two things. I consider whether busted shares are live or gone for good to be an integral part of the bust business action.
In an ideal world, if we could redesign this all over again, I would recommend either two different ExecTypes for busts (one in which busted shares are live and the other in which they aren’t), or a Boolean value to convey this same information.
Now given that this isn’t an ideal world, and we have an installed user base of FIX implementations that expect certain behaviors, I don’t know whether this would be implementable. But I figure that this is something not directly addressed in the spec and therefore worth discussing.
[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
This is an area where we would be well off with improved clarity in FIX. I am aware of the practices Ryan is discussing (reinstating order quantity), but FIX should recognize that this is uncommon in many (or even most) European and Asian exchanges.
In the case of algo trading or similar practices where orders are sent as “baits” to the market and have a very short lifetime (including IOC and FOK orders), restatement may be a bad practice. Time may have passed and price expectations moved. One should also recognize that a trade bust might occur after the order has expired or filled. If the user cancelled the order, it would be highly suspicious if the exchange restated it (it could have been cancelled due to an error, the same error that was the source of the trade bust). This is a case where the whole order is “dead”, I agree with Ryan here.
The trade bust could also occur in (from the exchange point of view) downstream processes as clearing and settlement. I do not think anyone would expect such processes to restate orders (the source of the trade may be other mechanisms than an order message too, e.g. privately negotiated trades, quotes or quote requests). Downstream systems often use other API’s than FIX, but may use FIX 4.4 Trade Capture Reports (TradeReportType [856] = 6 or 7) instead of Execution Reports - so the broker out there need to have alternative ways of restating the order quantity if he so wishes. This case may occur even if the order is partially filled and I see no way of enforcing a restatement.
FIX 4.4 users may consider using Trade Capture Reports relaying trade busts in cases where the order is not restated - but naturally it would be best if the FIX spec itself was clear regarding such scenarios.
[ original email was from Andrew Scott - ascott@latentzero.com ]
What you say makes sense for connections between brokers and exchanges, but it may not make sense for buy-side connections into brokers.
-
For sell-sides into exchanges, surely one can use unsolicited amends and trabe busts to distinguish between busting and restating, by bilateral agreement?
-
It is essential to provide an operation that ensures consistency between the order book on the buy-side and the sell-side. Trade bust, with the interpretation that the busted quantity is made available to the buy-side for further actions, suits this need well.
-
It is acknowledged that #2 above may not work in practice for DMA pipes straight into exchanges, in which case the difference in interpretation can be noted accordingly.
From the comments in this thread, in a case where a trade is busted and the busted quantity is not reinstated in the order book, we seem to have two options:
(a) Decrease CumQty by the quantity busted and increase LeavesQty by the quantity busted. Immediately after this, send an unsolicited cancel to reduce the OrderQty by the quantity busted. This would not break the “OrderQty = CumQty + LeavesQty” rule but would mean sending out two executions reports.
(b) Decrease CumQty by the quantity busted and leave LeavesQty unchanged. This would be an exception to the “OrderQty = CumQty + LeavesQty” rule.
The system is for a new US ECN. We are happy to go wither either of the above options. We will go with what works best for the FIX community. Should we go with option (a)?
[ original email was from Andrew Scott - ascott@latentzero.com ]
> From the comments in this thread, in a case where a trade is busted and the busted quantity is not reinstated in the order book, we seem to have two options:
(a) Decrease CumQty by the quantity busted and increase LeavesQty by the
quantity busted. Immediately after this, send an unsolicited cancel
to reduce the OrderQty by the quantity busted. This would not break
the “OrderQty = CumQty + LeavesQty” rule but would mean sending out
two executions reports.(b) Decrease CumQty by the quantity busted and leave LeavesQty
unchanged. This would be an exception to the “OrderQty = CumQty +
LeavesQty” rule.The system is for a new US ECN. We are happy to go wither either of the
above options. We will go with what works best for the FIX community.
Should we go with option (a)?
I would go with option (a) as this will give you fewer problems downstream. It is after all the most ‘vanilla’ FIX implementation strategy of the two.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> > From the comments in this thread, in a case where a trade is busted and the busted quantity is not reinstated in the order book, we seem to have two options:
(a) Decrease CumQty by the quantity busted and increase LeavesQty by
the quantity busted. Immediately after this, send an unsolicited
cancel to reduce the OrderQty by the quantity busted. This would
not break the “OrderQty = CumQty + LeavesQty” rule but would mean
sending out two executions reports.(b) Decrease CumQty by the quantity busted and leave LeavesQty
unchanged. This would be an exception to the “OrderQty = CumQty +
LeavesQty” rule.The system is for a new US ECN. We are happy to go wither either of
the above options. We will go with what works best for the FIX
community. Should we go with option (a)?I would go with option (a) as this will give you fewer problems
downstream. It is after all the most ‘vanilla’ FIX implementation
strategy of the two.
There’s a slight issue with option (a), namely that it is impossible to send an unsolicited cancel in FIX to reduce order quantity; an unsolicited cancel just kills the order. The only way for an unsolicited reduction of order quantity to happen is through ExecType=Restated, and that wasn’t introduced until FIX 4.2.