Imported from previous forum
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
For executions, the spec states:
Note: Data reported in the CumQty 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.
I’m thinking that LeavesQty should be included in that list of fields.
And could someone please add some text to the spec to clarify the difference between the new ExecType field and OrdStatus?
Ryan Pierce
Townsend Analytics Ltd. / Archipelago LLC
rpierce@taltrade.com
[ original email was from Andrew Schorr - ]
I have a couple of questions regarding changes to
the Execution Report in 4.1. First, there is a new
column labeled “Precedence” in the table of OrdStatus
values. The existence of a Precedence value implies that
these values should be used to resolve conflicts. I’m
probably missing something, but I don’t see where it is
explained what conflicts are to be resolved by using those
Precedence values. Can someone please elaborate?
Also, regarding the addition of OrigClOrdID to the
Execution Report: this is a non-trivial change in behavior,
and I think this should be better explained. From studying
the Order State Change Matrices, I have deduced that
the ClOrdID field will no longer contain the ID of
the order affected by the Execution Report when the
OrdStatus value is Replaced, Canceled, or Pending Cancel.
In such cases, it would appear that the relevant order ID
will be contained in the OrigClOrdID field, and the ClOrdId
field will instead contain the ID of the message that
triggered the cancellation/replacement of the order
specified in the OrigClOrdID field. This change seems
questionable to me. Isn’t it much simpler if the ClOrdID
field always contains the ID of the order to which this
Execution Report pertains? If it is necessary to identify
the message that triggered the cancellation, then a new
field should be used for that purpose, perhaps called
CxlClOrdId. That would be much clearer in my opinion.
Does anyone else agree? If this change is made as
documented, then the code that processes the Execution
Reports will have to look at the FIX version and the
OrdStatus value in order to determine which field to
look at (ClOrdID or OrigClOrdID) to identify the order
being impacted by this report. Or would you argue to always
look at the OrigClOrdID field if it is present? At the
very least, someone should enhance the documentation
for the ClOrdID in the table to show which message is
being identified by that value. Simply to say that it
is required is not a good explanation.
Andrew Schorr
schorr@ead.dsa.com
Daiwa Securities America Inc.
[ original email was from johna@ms.com - ]
> The existence of a Precedence value implies that
> these values should be used to resolve conflicts. I’m
> probably missing something, but I don’t see where it is
> explained what conflicts are to be resolved by using those
> Precedence values. Can someone please elaborate?
I wouldn’t call it conflict. It’s really when the order
is in more than one state, e.g. when you’re order is in a PendingCancel state and you wish to report a PartialFill,
PendingCancel takes precedence over the fact that the order
is partially filled. The PartialFill will be denoted
in the ExecType.
Other examples:
- to report a Stopped on a order in Pending Cancel state
- or when the Stopped (guarantee) only partially applies to the order(if the order is really multiple orders on the exchange e.g. as the result of an increased order quantity).
>
> Also, regarding the addition of OrigClOrdID to the
> Execution Report: this is a non-trivial change in behavior,
> and I think this should be better explained. From studying
> the Order State Change Matrices, I have deduced that
> the ClOrdID field will no longer contain the ID of
> the order affected by the Execution Report when the
> OrdStatus value is Replaced, Canceled, or Pending Cancel.
> In such cases, it would appear that the relevant order ID
> will be contained in the OrigClOrdID field, and the ClOrdId
> field will instead contain the ID of the message that
> triggered the cancellation/replacement of the order
> specified in the OrigClOrdID field. This change seems
> questionable to me. Isn’t it much simpler if the ClOrdID
> field always contains the ID of the order to which this
> Execution Report pertains? If it is necessary to identify
> the message that triggered the cancellation, then a new
> field should be used for that purpose, perhaps called
> CxlClOrdId. That would be much clearer in my opinion.
> Does anyone else agree?
Good point. A conditionally required Cxl(Rpl)ClOrdID
is clearer and more backward compatible.
>
> Andrew Schorr
> schorr@ead.dsa.com
> Daiwa Securities America Inc.
>
[ original email was from johna@ms.com - ]
Didn’t mean to be anonymous on this.
The previous reply was from John Armstrong.
> > The existence of a Precedence value implies that
> > these values should be used to resolve conflicts. I’m
> > probably missing something, but I don’t see where it is
> > explained what conflicts are to be resolved by using those
> > Precedence values. Can someone please elaborate?
>
I wouldn’t call it conflict. It’s really when the order
is in more than one state, e.g. when you’re order is in a PendingCancel state and you wish to report a PartialFill,
PendingCancel takes precedence over the fact that the order
is partially filled. The PartialFill will be denoted
in the ExecType.
Other examples:
- to report a Stopped on a order in Pending Cancel state
- or when the Stopped (guarantee) only partially applies to the order(if the order is really multiple orders on the exchange e.g. as the result of an increased order quantity).
>
> >
> > Also, regarding the addition of OrigClOrdID to the
> > Execution Report: this is a non-trivial change in behavior,
> > and I think this should be better explained. From studying
> > the Order State Change Matrices, I have deduced that
> > the ClOrdID field will no longer contain the ID of
> > the order affected by the Execution Report when the
> > OrdStatus value is Replaced, Canceled, or Pending Cancel.
> > In such cases, it would appear that the relevant order ID
> > will be contained in the OrigClOrdID field, and the ClOrdId
> > field will instead contain the ID of the message that
> > triggered the cancellation/replacement of the order
> > specified in the OrigClOrdID field. This change seems
> > questionable to me. Isn’t it much simpler if the ClOrdID
> > field always contains the ID of the order to which this
> > Execution Report pertains? If it is necessary to identify
> > the message that triggered the cancellation, then a new
> > field should be used for that purpose, perhaps called
> > CxlClOrdId. That would be much clearer in my opinion.
> > Does anyone else agree?
>
Good point. A conditionally required Cxl(Rpl)ClOrdID
is clearer and more backward compatible.
>
> >
> > Andrew Schorr
> > schorr@ead.dsa.com
> > Daiwa Securities America Inc.
> >
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
I noticed that in FIX 4.0, neither Price nor StopPx were conditionally required. I interpreted this as meaning you don’t need to state the original limit / stop price of an order when you report a fill, confirm that it is new, etc. amd one should not expect this data to be provided.
In the FIX 4.1 draft, StopPx is conditionally required in Execution Reports for Stop / StopLimit orders. This is inconsistent. Could someone please clarify the intent of conditionally requiring StopPx? Was it a search-and-replace error that added this condition to a message where it didn’t belong? Or should Price be conditionally required as well in an Execution Report for Limit / StopLimit orders?
Ryan Pierce
Townsend Analytics Ltd. / Archipelago LLC
rpierce@taltrade.com