Imported from previous forum
Hello,
In FIX 4.2, the most common way to denote a trade bust is with 35=8, 20=1, and 150=1 or 2 depending on if trade bust is a cancel on an order that has been partially filled or fully filled. Other tags are to be included as well such as 17, 19, etc but my question is more so around the appropriate logic of a trade bust message using tags 35, 20 and 150 for FIX 4.2.
Sample Scenario:
- Request is sent to buy 10,000 shares of IBM @ $20
- Order is received by the executing party and accepted -> (35=8, 20=0, 150=0)
- Order is partially fill (i.e. 2000 of the 10,000) -> 35=8, 20=0, 150=1. Additionally, 151=8000, 14=2000, etc.
- Another partial fill (i.e. 1000 of the remaining 8000) -> 35=8, 20=0, 150=1. Additionally, 151=7000, 14=3000, etc.
- Full Fill (i.e. the remaining 7000 is full filled) -> 35=8, 20=0, 150=2. Additionally, 151=0, 14=10000, etc
Questions:
-
If the intent by the executing party is to bust the entire fill, in most cases, is it expected that only 35=8, 20=1, and 150=2 should be sent to denote a Full Trade Bust? In addition, it would be expected that cumQty be equal to that of the leaves quantity of the previous request, and leaves quantity equal that of the cum qty on the previous request. Using the example above, it is expected that leavesQty=10000 and cumQty=0?
-
If the intent is to bust one of the partially filled order (i.e. step #3), is expected that only 35=8, 20=1, 150=1 should be sent to denote a Partial Trade Bust. In turn, it would be expected that cumQty be equal to that of the leaves quantity of the previous request, and leaves quantity equal that of the cum qty on the previous request. Using the example above, it is expected that leavesQty=2000 and cumQty=2000 (should be greater than zero for partial trade bust)?
-
If the intent is to bust step #5, then is it expected that only 35=8, 20=1, 150=2 should be sent to denote a Full Trade Bust, though step 5 can be considered a partial fill that made the order completely filled?
-
Is there a case where another execution report should proceed after a bust message (i.e. whether the bust was partial or full)? For example, 35=8, 20=1, and 150=0 (i.e. trade cancel with exec type == New).
-
If the intent is to denote a full trade bust, could an alternative be to send three different partial trade bust messages that reference each of step 3-5? Or, two partial trade bust that reference step #3 and #4, and a full trade bust that reference step #5?
-
Could the following be define as such in relation to trade bust:
tag 35=8 - Execution Report
tag 39 - indicates the order status of the transaction being canceled. I assume this can vary but typically would be a value of 39=1 or 2.
tag 20=1 - indicates the transaction type of this action is to cancel.
tag 150=1 or 2 - indicates the execution type of the message that is canceled - a filled execution.
Note: I am already aware of the additional required tags and information needed to be passed.
I would gladly appreciate the help.
Thanks,
Dwayne
Hi Dwayne,
In my opinion, the reply depends on if the quantity of the cancelled trade is back in the book or not.
Regards,
Xavier.
Hi Dwayne, Basically Executing party does the bust by referring 'ExecRefID'(Tag 19) which corresponds to the actual ExecID(Tag 17) which could be either Partial or Full Fill. That means, in your case executing party must issue three bust messages for each execution individually to cancel the entire quantity. Regards, Bhavani
Agree with Bhavani. ExecutionReports give you a current snapshot of the order status in addition to the execution information. Busts need to refer to the individual executions and not to the order as a whole. Putting busted quantity back on the order is often subject to debate. I can only recommend to avoid this as the order submitter may longer want to execute that quantity, i.e. automatically adding it may cause an overfill from his perspective.
Hi, here is my understanding of this scenario:
1- For an order being executed with multiple partial fills there can not be only one “Full Trade Bust”. Different trade bust messages should be sent with reference of each execution . LeavesQty=10000 and cumQty=0 can only occur in the last trade bust (the 3rd trade bust in this case).
2- If the intent is to bust one of the partially filled order (i.e. step #3)where 32=2000, 20=1, 150=1 it is expected that leavesQty=2000 and cumQty=8000.
3- If the intent is to bust step #5, then is it expected that 35=8, 20=1, 150=1 39=1.
4- 35=8, 20=1, 150=0 and 39=0 can only occur in the last trade bust with leavesQty=10000 and cumQty=0 as said previously.
5- If the intent is to denote a full trade bust, three different trade bust messages that reference each of step 3,4 and 5 should be sent.
6- trade bust:
tag 35=8 : Execution Report
tag 20=1 : indicates the transaction type of this action is to cancel.
tag 39 : indicates the status of the order AFTER the trade bust (current status). We should only see 39=1 (for all trade busts) and 39=0 (only in the last trade bust where all executions have been cancelled and order status is New).
tag 150 : 1 or 0 in this case often same as tag 39.
leavesQty and cumQty : indicate the current leavesQty and cumQty of the order AFTER the trade bust.
Regards,
Ines.
Thanks guys, this was helpful. I am still confused about step #4 Ines mentioned, which some would call a zero filled bust. I was always under the impression that when doing a bust 35=8, 20=1, and 150=1 or 2 and never 0.
This is my theory:
If 35=8, 20=1, 150=0, it is expected that cumQuantity == 0.
If 35=8, 20=1, 150=1, it is expected that cumQuantity will always be greater than zero.
If 35=8, 20=1, 150=2, it is expected that cumQuantity ==0 as well as leavesQuantity could be <0 (in the event of possible overfills) or =0.
Dwayne, you mean the trade bust should show the status of the execution you are about to cancel. But in my opinon the status should be the one the order will have after each trade bust.
Volume 4 of the FIX Spec states the following “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.”.
This means that the ExecutionReport serves two purposes:
a) report the transaction on the order (which could also be a correction of a previous transaction)
b) report the current status of the order
Hence, there should never be historic order status information in the message. Reasoning is that you should not have to replay historic transactions to calculate the current order status. The so-called “Order State Change Matrices” in the FIX Spec (also Volume 4) show some sample scenarios for this. It does not cover all cases but shows the underlying paradigms quite well.