Hi all.
I have a question regarding the coherence of tag 39, 14 , 6 & 151 in this scenario:
With FIX 4.2, I have sent an order for qty 200 that has been filled as follow:
- a first fill with LastShares=20 (39=1).
- a second fill with LastShares=180 (39=2).
Then I have received:
- a first fill correct - 35=8 with 20=2 - with reference to the first partial fill. LastShares=20
- a second fill correct - 35=8 with 20=2 - with reference to the second fill. LastShares=180
In the first “fill correct” the sender has set:
39=1
14=20
151=180
In my opinion this is wrong because these are not the last known OrdStatus, CumQty & LeavesQty values, but I would like to know the opinion of experts!
Many thanks
Alessandro
@alessandro.caffarr, I believe you could be right. What is missing is information about what was actually corrected in both instances.
Please refer to Section J - Execution Cancels/Corrects of the Order State Changes and the scenario J.1.a, lines 5 and 6. They show a cancel and a correct after a partial fill followed by a complete fill.
The FIX 4.2 spec states for ExecTransType(20) = 2 (CORRECT): 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.
There is no explicit mention of OrdStatus(39) in this list but I believe it should have been included in the list. The message serves a double purpose, i.e. it corrects a previous execution and restates the current/remaining order. The recipient hence has to update his order book accordingly with this information.
You can see in J.1.a line 5 that OrdStatus(39) goes back to partially filled (i.e. it does not copy OrdStatus from line 3, which happens to be identical!) due to the cancel of the execution from line 3. It remains partially filled (i.e. it does not copy OrdStatus from line 4) in line 6 correcting the price of the second fill from line 4.
Going back to your example, the first “fill correct” should indeed reflect the current CumQty(14) and LeavesQty(151) values, not the ones originally reported with the first fill. So that is certainly an error. As said before, I believe the same should apply to OrdStatus(39) and the value depends on the type of correction made (did it affect quantities?).
Thank you very much for your time Hanno.
In this case the 20=2 have’t changed anything in terms of quantity nor price. It has only added tag, such as the 851 (LastLiquidityInd).
Alessandro