Imported from previous forum
[ original email was from Vinay Gaur - vinay.gaur@ubsw.com ]
Hi,
It’s clear from earlier discussions on this website that in FIX 4.0, when the only remaining trade is busted (ie ExecTransType = 1 and CumQty = 0), the OrdStatus on the Execution Report should be New (and not partial-fill or fill).
By the same logic, in FIX 4.1 and 4.2, when busting the only trade, should the ExecType not be New (vs partial-fill)? And, OrdStatus should be New (or a higher state, if exists).
I see in Appendix D example D35 line 7 that ExecType is Partial-fill and not New, even though the trade bust results in CumQty = 0.
Will appreciate any clarification.
Thanks in advance
Vinay Gaur
UBS Warburg
> Hi,
>
> It’s clear from earlier discussions on this website that in FIX 4.0, when the only remaining trade is busted (ie ExecTransType = 1 and CumQty = 0), the OrdStatus on the Execution Report should be New (and not partial-fill or fill).
>
> By the same logic, in FIX 4.1 and 4.2, when busting the only trade, should the ExecType not be New (vs partial-fill)? And, OrdStatus should be New (or a higher state, if exists).
>
> I see in Appendix D example D35 line 7 that ExecType is Partial-fill and not New, even though the trade bust results in CumQty = 0.
>
> Will appreciate any clarification.
>
> Thanks in advance
> Vinay Gaur
> UBS Warburg
>
>
The real issue here is that in the case of a cancel execution or amend execution, ExecTransType is performing the role that ExecType normally fulfils, with the result that ExecType has no obvious value in these scenarios.
One suggestion for FIX 4.3 is that we fold ExecTransType and ExecType together, effectively having three additional values for ExecType:
CancelExec
AmendExec
Status
to reflect 3 of the 4 values that ExecTransType currently takes (the other one being the ‘default’ value New) and doing away with ExecTransType
Can anyone foresee any issues with doing this ?
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> One suggestion for FIX 4.3 is that we fold ExecTransType and ExecType together, effectively having three additional values for ExecType:
>
> CancelExec
> AmendExec
> Status
>
> to reflect 3 of the 4 values that ExecTransType currently takes (the other one being the ‘default’ value New) and doing away with ExecTransType
>
> Can anyone foresee any issues with doing this ?
I agree in the Status case and the Cancel case. I disagree in the Amend case.
For instance, a partial fill may get amended to a fill, or vice versa. In this case, ExecType needs to change.
Now one way around this is to eliminate the ExecType’s Fill and Partial Fill, and create a new ExecType called Trade. The execution itself is a trade, and whether the order is filled or partially filled as a result is indicated by OrdStatus. In this case, I believe one could then make the requirement that ExecType must not change as the result of a correction to an ExecRpt, and could use an ExecType to indicate the correction of the ExecRpt. However, I recognize that while it seems a better representation, changing ExecType Fill and Partial Fill to Trade would have an extremely significant impact on the protocol, hence I am not sure the benefits would be worth the effort. Thoughts?
> > One suggestion for FIX 4.3 is that we fold ExecTransType and ExecType together, effectively having three additional values for ExecType:
> >
> > CancelExec
> > AmendExec
> > Status
> >
> > to reflect 3 of the 4 values that ExecTransType currently takes (the other one being the ‘default’ value New) and doing away with ExecTransType
> >
> > Can anyone foresee any issues with doing this ?
>
> I agree in the Status case and the Cancel case. I disagree in the Amend case.
>
> For instance, a partial fill may get amended to a fill, or vice versa. In this case, ExecType needs to change.
>
> Now one way around this is to eliminate the ExecType’s Fill and Partial Fill, and create a new ExecType called Trade. The execution itself is a trade, and whether the order is filled or partially filled as a result is indicated by OrdStatus. In this case, I believe one could then make the requirement that ExecType must not change as the result of a correction to an ExecRpt, and could use an ExecType to indicate the correction of the ExecRpt. However, I recognize that while it seems a better representation, changing ExecType Fill and Partial Fill to Trade would have an extremely significant impact on the protocol, hence I am not sure the benefits would be worth the effort. Thoughts?
>
What’s the deal with Exectype = execAmend. The ordStatus tells you whether the order is filled or partially filled (taking into account the amended execution). execType = fill/part-fill has always seemed pretty redundant when you have the ordStatus telling you precisely that. The fill/part-fill is a property of the order not the execution. I like the idea of not having execType ever set to partial-fill or fill (look at the mess you get into if you single fill an order and then cancel the execution - again no obvious value for execType other than set it to New). I like the idea of adding ExecType = execNew in lieu of partially-filled and filled
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> What’s the deal with Exectype = execAmend. The ordStatus tells you whether the order is filled or partially filled (taking into account the amended execution). execType = fill/part-fill has always seemed pretty redundant when you have the ordStatus telling you precisely that. The fill/part-fill is a property of the order not the execution. I like the idea of not having execType ever set to partial-fill or fill (look at the mess you get into if you single fill an order and then cancel the execution - again no obvious value for execType other than set it to New). I like the idea of adding ExecType = execNew in lieu of partially-filled and filled
When amending an Execution Report, one populates it just like a normal Execution Report. Hence I would normally expect ExecType to indicate the type of Execution Report that is replacing the referenced ExecRpt.
Now if a requirement is put in place that one must not change ExecType when amending an Execution Report, then I support the idea of using an ExecType for amendments. The receiver of the ExecRpt correction knows to look at the ExecType of the referenced execution to know what action to do.
In general, one SHOULDN’T ever have to change the ExecType of an ExecRpt except in one case. One should not be allowed to amend an ExecRpt representing a trade into an ExecRpt representing an unsolicited cancel; rather, you bust the trade first and then send a new unsolicited cancel.
But the one exception I know of where ExecType can change is a Partial Fill beoming a Fill or vice versa. Hence I believe that ExecType on an amendment needs to represent the type of the corrected execution.
But I don’t think that ExecType for normal trades makes sense. Hence I made an additional proposal that we remove ExecType=Partial Fill and Fill, and create one ExecType called Trade. The typical sequence for an order in this model would be ExecType=Trade OrdStatus=Partially Filled, then ExecType=Trade, OrdStatus=Filled.
If this proposal is adopted, then I see no need for ExecType to change on an ExecRpt amendment. Hence I then agree fully with you that ExecType=AmendedExec would be fine.
Maybe we could just eliminate ExecType="Partial Fill" and keep ExecType="Fill". To me, "Fill" and "Trade" are synonymous. "Trade" also has different connotations from a post-trade/back-office perspective. You would still have OrdStatus="Partially Filled" or "Filled".
> > What’s the deal with Exectype = execAmend. The ordStatus tells you whether the order is filled or partially filled (taking into account the amended execution). execType = fill/part-fill has always seemed pretty redundant when you have the ordStatus telling you precisely that. The fill/part-fill is a property of the order not the execution. I like the idea of not having execType ever set to partial-fill or fill (look at the mess you get into if you single fill an order and then cancel the execution - again no obvious value for execType other than set it to New). I like the idea of adding ExecType = execNew in lieu of partially-filled and filled
>
> When amending an Execution Report, one populates it just like a normal Execution Report. Hence I would normally expect ExecType to indicate the type of Execution Report that is replacing the referenced ExecRpt.
>
> Now if a requirement is put in place that one must not change ExecType when amending an Execution Report, then I support the idea of using an ExecType for amendments. The receiver of the ExecRpt correction knows to look at the ExecType of the referenced execution to know what action to do.
>
> In general, one SHOULDN’T ever have to change the ExecType of an ExecRpt except in one case. One should not be allowed to amend an ExecRpt representing a trade into an ExecRpt representing an unsolicited cancel; rather, you bust the trade first and then send a new unsolicited cancel.
>
> But the one exception I know of where ExecType can change is a Partial Fill beoming a Fill or vice versa. Hence I believe that ExecType on an amendment needs to represent the type of the corrected execution.
>
> But I don’t think that ExecType for normal trades makes sense. Hence I made an additional proposal that we remove ExecType=Partial Fill and Fill, and create one ExecType called Trade. The typical sequence for an order in this model would be ExecType=Trade OrdStatus=Partially Filled, then ExecType=Trade, OrdStatus=Filled.
>
> If this proposal is adopted, then I see no need for ExecType to change on an ExecRpt amendment. Hence I then agree fully with you that ExecType=AmendedExec would be fine.
>
>