ExecTransType Cancel (fill bust)

, ,
1

Imported from previous forum

2

Can someone please confirm if I’m understanding the ExecTransType=1 (Cancel) on an Execution Report in FIX 4.2 correctly?

Submit new order

MsgType(35)=D Price(44)=10 OrderQty(38)=2

ExecReport (Pending New)

MsgType(35)=8 ExecID(17)=1 ExecType(150)=A ExecTransType(20)=0 OrdStatus(39)=A

ExecReport (New)

MsgType(35)=8 ExecID(17)=2 ExecType(150)=0 ExecTransType(20)=0 OrdStatus(39)=0

ExecReport (Filled)

MsgType(35)=8 ExecID(17)=3 ExecType(150)=2 ExecTransType(20)=0 OrdStatus(39)=2 LastPx(31)=10 AvgPx(6)=10 CumQty(14)=2 LastShares(32)=2

Correct the previous ExecReport (ExecID=3) with a new fill price

MsgType(35)=8 ExecID(17)=4 ExecRefID(19)=3 ExecType(150)=2 ExecTransType(20)=2 OrdStatus(39)=2 LastPx(31)=9 AvgPx(6)=9 CumQty(14)=2 LastShares(32)=2

Correct the previous ExecReport (ExecID=4) with a new fill size (order is now only partially filled and “live” again)

MsgType(35)=8 ExecID(17)=5 ExecRefID(19)=4 ExecType(150)=1 ExecTransType(20)=2 OrdStatus(39)=1 LastPx(31)=9 AvgPx(6)=9 CumQty(14)=1 LastShares(32)=1

Cancel the previous ExecReport (ExecID=5)

MsgType(35)=8 ExecID(17)=6 ExecRefID(19)=4 ExecType(150)=2 ExecTransType(20)=1 OrdStatus(39)=2 LastPx(31)=9 AvgPx(6)=9 CumQty(14)=1 LastShares(32)=1

My questions are:

  1. Is there any difference between a “fill bust” and any other type of ExecTransType=Cancel? Does a fill bust apply to a correct or just an ExecReport where a fill occurs?

  2. Does the fill bust (ExecTransType=1) cancel the previous correction so that only the first correction now stands?

My expectation is that after this sequence of messages, the order is filled with CumQty=2 and AvgPx and LastPx of 9.

Thanks,

Chris

3

Have you looked at the FIX 4.2 spec pages 93/94?

It says that you cannot correct or cancel a cancel. A cancel takes back a specific ER as if it was never sent. If you cancel a correction then the last non-canceled correction is still valid. In your example you cancel the last correction, i.e. ExecID 4 so that ExecID 3 is now valid. Had you canceled ExecID 3, then ExecID 4 would be valid. Hence, it only makes sense to cancel the last correction as that one already “canceled” previous corrections.

Maybe this kind of confusion also led to FIX 4.3 removing ExecTransType. Hope you soon have a chance to get past FIX 4.2 :slight_smile:

Here is an excerpt of the spec on your issue:

Execution report messages are transmitted with a  transaction type (ExecTransType)  NEW, CANCEL, CORRECT or STATUS.  Transaction types CANCEL and CORRECT modify the state of the message identified in field ExecRefID, and are used to cancel or correct a previously reported execution.  Transaction type STATUS indicates that the execution message contains no new information, only summary information regarding order status.

*	The NEW transaction type indicates that this message represents a new order, a change in status of the order, or a new fill against an existing order.  The combination of the ExecTransType, ExecType, and OrdStatus fields will indicate how the message is to be applied to an order.

*	The CANCEL transaction type applies at the execution level.  The Cancel transaction  will be used to cancel an execution which has been reported in error.  The canceled execution will be identified in the ExecRefID field.  Note: ExecTransType of Cancel should not be used to cancel a previous ExecutionRpt with ExecTransType of Cancel (e.g. cannot cancel a cancel).

*	The CORRECT transaction type applies at the execution level and is used to modify an incorrectly reported fill.  The incorrect execution will be identified in the ExecRefID field.  If a single execution is corrected more than once, ExecRefID should refer to the ExecID of the last corrected ExecutionRpt (same convention as ClOrdID and OrigClOrdID).  To correct an ExecutionRpt which was previously canceled, an ExecutionRpt with ExecTransType=New should be sent (e.g. cannot send ExecTransType=Correct for an ExecutionRpt with ExecTransType=Cancel).  Note:  Data reported in the CumQty, LeavesQty, and AvgPx fields represent the status of the order as of the time of the correction, not as of the time of the originally reported execution.

Can someone please confirm if I’m understanding the ExecTransType=1 (Cancel) on an Execution Report in FIX 4.2 correctly?

Submit new order

MsgType(35)=D Price(44)=10 OrderQty(38)=2

ExecReport (Pending New)

MsgType(35)=8 ExecID(17)=1 ExecType(150)=A ExecTransType(20)=0 OrdStatus(39)=A

ExecReport (New)

MsgType(35)=8 ExecID(17)=2 ExecType(150)=0 ExecTransType(20)=0 OrdStatus(39)=0

ExecReport (Filled)

MsgType(35)=8 ExecID(17)=3 ExecType(150)=2 ExecTransType(20)=0 OrdStatus(39)=2 LastPx(31)=10 AvgPx(6)=10 CumQty(14)=2 LastShares(32)=2

Correct the previous ExecReport (ExecID=3) with a new fill price

MsgType(35)=8 ExecID(17)=4 ExecRefID(19)=3 ExecType(150)=2 ExecTransType(20)=2 OrdStatus(39)=2 LastPx(31)=9 AvgPx(6)=9 CumQty(14)=2 LastShares(32)=2

Correct the previous ExecReport (ExecID=4) with a new fill size (order is now only partially filled and “live” again)

MsgType(35)=8 ExecID(17)=5 ExecRefID(19)=4 ExecType(150)=1 ExecTransType(20)=2 OrdStatus(39)=1 LastPx(31)=9 AvgPx(6)=9 CumQty(14)=1 LastShares(32)=1

Cancel the previous ExecReport (ExecID=5)

MsgType(35)=8 ExecID(17)=6 ExecRefID(19)=4 ExecType(150)=2 ExecTransType(20)=1 OrdStatus(39)=2 LastPx(31)=9 AvgPx(6)=9 CumQty(14)=1 LastShares(32)=1

My questions are:

  1. Is there any difference between a “fill bust” and any other type of ExecTransType=Cancel? Does a fill bust apply to a correct or just an ExecReport where a fill occurs?

  2. Does the fill bust (ExecTransType=1) cancel the previous correction so that only the first correction now stands?

My expectation is that after this sequence of messages, the order is filled with CumQty=2 and AvgPx and LastPx of 9.

Thanks,

Chris

4

Thanks Hanno,

Do you agree that with ExecTransType=Cancel, the only field I need to look at is ExecRefID and I should be able to calculate the correct order state once I have undone the effects of the cancelled message?

Have you looked at the FIX 4.2 spec pages 93/94?

It says that you cannot correct or cancel a cancel. A cancel takes back a specific ER as if it was never sent. If you cancel a correction then the last non-canceled correction is still valid. In your example you cancel the last correction, i.e. ExecID 4 so that ExecID 3 is now valid. Had you canceled ExecID 3, then ExecID 4 would be valid. Hence, it only makes sense to cancel the last correction as that one already “canceled” previous corrections.

Maybe this kind of confusion also led to FIX 4.3 removing ExecTransType. Hope you soon have a chance to get past FIX 4.2 :slight_smile:

Here is an excerpt of the spec on your issue:

Execution report messages are transmitted with a transaction type (ExecTransType) NEW, CANCEL, CORRECT or STATUS. Transaction types CANCEL and CORRECT modify the state of the message identified in field ExecRefID, and are used to cancel or correct a previously reported execution. Transaction type STATUS indicates that the execution message contains no new information, only summary information regarding order status.

  • The NEW transaction type indicates that this message represents a new order, a change in status of the order, or a new fill against an existing order. The combination of the ExecTransType, ExecType, and OrdStatus fields will indicate how the message is to be applied to an order.

  • The CANCEL transaction type applies at the execution level. The Cancel transaction will be used to cancel an execution which has been reported in error. The canceled execution will be identified in the ExecRefID field. Note: ExecTransType of Cancel should not be used to cancel a previous ExecutionRpt with ExecTransType of Cancel (e.g. cannot cancel a cancel).

  • The CORRECT transaction type applies at the execution level and is used to modify an incorrectly reported fill. The incorrect execution will be identified in the ExecRefID field. If a single execution is corrected more than once, ExecRefID should refer to the ExecID of the last corrected ExecutionRpt (same convention as ClOrdID and OrigClOrdID). To correct an ExecutionRpt which was previously canceled, an ExecutionRpt with ExecTransType=New should be sent (e.g. cannot send ExecTransType=Correct for an ExecutionRpt with ExecTransType=Cancel). Note: Data reported in the CumQty, LeavesQty, and AvgPx fields represent the status of the order as of the time of the correction, not as of the time of the originally reported execution.

Can someone please confirm if I’m understanding the ExecTransType=1 (Cancel) on an Execution Report in FIX 4.2 correctly?

Submit new order

MsgType(35)=D Price(44)=10 OrderQty(38)=2

ExecReport (Pending New)

MsgType(35)=8 ExecID(17)=1 ExecType(150)=A ExecTransType(20)=0 OrdStatus(39)=A

ExecReport (New)

MsgType(35)=8 ExecID(17)=2 ExecType(150)=0 ExecTransType(20)=0 OrdStatus(39)=0

ExecReport (Filled)

MsgType(35)=8 ExecID(17)=3 ExecType(150)=2 ExecTransType(20)=0 OrdStatus(39)=2 LastPx(31)=10 AvgPx(6)=10 CumQty(14)=2 LastShares(32)=2

Correct the previous ExecReport (ExecID=3) with a new fill price

MsgType(35)=8 ExecID(17)=4 ExecRefID(19)=3 ExecType(150)=2 ExecTransType(20)=2 OrdStatus(39)=2 LastPx(31)=9 AvgPx(6)=9 CumQty(14)=2 LastShares(32)=2

Correct the previous ExecReport (ExecID=4) with a new fill size (order is now only partially filled and “live” again)

MsgType(35)=8 ExecID(17)=5 ExecRefID(19)=4 ExecType(150)=1 ExecTransType(20)=2 OrdStatus(39)=1 LastPx(31)=9 AvgPx(6)=9 CumQty(14)=1 LastShares(32)=1

Cancel the previous ExecReport (ExecID=5)

MsgType(35)=8 ExecID(17)=6 ExecRefID(19)=4 ExecType(150)=2 ExecTransType(20)=1 OrdStatus(39)=2 LastPx(31)=9 AvgPx(6)=9 CumQty(14)=1 LastShares(32)=1

My questions are:

  1. Is there any difference between a “fill bust” and any other type of ExecTransType=Cancel? Does a fill bust apply to a correct or just an ExecReport where a fill occurs?

  2. Does the fill bust (ExecTransType=1) cancel the previous correction so that only the first correction now stands?

My expectation is that after this sequence of messages, the order is filled with CumQty=2 and AvgPx and LastPx of 9.

Thanks,

Chris

5

I do not know what the matching engine does after cancelling a fill. Does it reinstate the order qty or not? The only easy case is when ExecRefID points you to the last ER you received for the order prior to the cancel. then you just take away this last ER and the ER before that is the current status.

If ExecRefID points to an ER somewhere in the chain with modifications and further fills coming thereafter, it gets tricky unless the ER with ExecTransType=Cancel already gives you the current state of the order. This would be the most efficient solution, no need to recalculate anything. ExecRefID is all you need to take out the ER that is cancelled. The other fields can give you the current state and quantities of the order. However, this could be wishful thinking if the matching engine sends you a copy of the old ER with a new ExecID, the old one in ExecRefID and ExecTransType=Cancel. The order might have been completely filled in the meantime and now “comes back to life” due to a reinstatement of the busted amount. You need to see the Rules of Engagement from your counterparty for that.

Thanks Hanno,

Do you agree that with ExecTransType=Cancel, the only field I need to look at is ExecRefID and I should be able to calculate the correct order state once I have undone the effects of the cancelled message?