Imported from previous forum
[ original email was from Kaaren Anderson - kanderson@driehaus.com ]
We are on FIX 4.2 and are curious about the usage of Tag 32 (LastShares) in the condition of a rejection message for unknown symbol.
Here is the flow:
- Order message sent from Firm A to Firm B where symbol XYZ is not known by Firm B (such as it is not setup on Firm B’s security master)
- Rejection message is sent from Firm B to Firm A with these fields populated:
Symbol: 55=XYZ
ExecTransType: 20=0 (New)
MsgType: 35=8 (Execution report)
OrdStatus: 39=8 (Rejected)
Text: 58=Instrument XYZ is inactive
Question is this: Rejection message does not include Tag 32 for LastShares. Should it? Per my FIX 4.2 spec, it notes for Tag 32: “Field not required for ExecTransType = 3 (Status)”. Do you concur that Tag 32 should be a required field on a rejection message for symbol not known? I am thinking yes in that ExecTransType = 0 (new) in this example, but I would appreciate your interpretation of the standard for this condition. Thank you very much for your help. -Kaaren
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> 2) Rejection message is sent from Firm B to Firm A with these fields
populated: Symbol: 55=XYZ ExecTransType: 20=0 (New) MsgType: 35=8
(Execution report) OrdStatus: 39=8 (Rejected) Text: 58=Instrument
XYZ is inactive Question is this: Rejection message does not
include Tag 32 for LastShares. Should it? Per my FIX 4.2 spec, it
notes for Tag 32: “Field not required for ExecTransType = 3
(Status)”. Do you concur that Tag 32 should be a required field on
a rejection message for symbol not known? I am thinking yes in that
ExecTransType = 0 (new) in this example, but I would appreciate
your interpretation of the standard for this condition. Thank you
very much for your help. -Kaaren
My understanding is that LastShares and LastPx are, indeed, required for FIX compliance. However, since it’s clear that there’s no trade, they are set to 0.
Are you acting as the buy side or the sell side in this case? If you’re acting as the sell side and sending the reject, then I suggest you send LastShares to maintain compliance with the spec. However, if you’re on the buy side and receiving the message, I question the need to validate the presence of that field on a message that quite clearly is rejecting the order. In this situation I’d much rather accept the message and inform the trader that the order is dead because “Instrument XYZ is inactive” rather than reject the message and let the trader wonder why the order hasn’t gone live, all because a field that has no business meaning in that message is missing.
[ original email was from Kaaren Anderson - kanderson@driehaus.com ]
> > 2) Rejection message is sent from Firm B to Firm A with these fields
populated: Symbol: 55=XYZ ExecTransType: 20=0 (New) MsgType: 35=8
(Execution report) OrdStatus: 39=8 (Rejected) Text: 58=Instrument
XYZ is inactive Question is this: Rejection message does not
include Tag 32 for LastShares. Should it? Per my FIX 4.2 spec, it
notes for Tag 32: “Field not required for ExecTransType = 3
(Status)”. Do you concur that Tag 32 should be a required field on
a rejection message for symbol not known? I am thinking yes in that
ExecTransType = 0 (new) in this example, but I would appreciate
your interpretation of the standard for this condition. Thank you
very much for your help. -KaarenMy understanding is that LastShares and LastPx are, indeed, required for
FIX compliance. However, since it’s clear that there’s no trade, they
are set to 0.Are you acting as the buy side or the sell side in this case? If you’re
acting as the sell side and sending the reject, then I suggest you send
LastShares to maintain compliance with the spec. However, if you’re on
the buy side and receiving the message, I question the need to validate
the presence of that field on a message that quite clearly is rejecting
the order. In this situation I’d much rather accept the message and
inform the trader that the order is dead because “Instrument XYZ is
inactive” rather than reject the message and let the trader wonder why
the order hasn’t gone live, all because a field that has no business
meaning in that message is missing.
Interesting you should ask. We are technically both Firm A (buy side asset manager) and Firm B (sell side associated B/D) in this condition. However, we are utilizing third party software for both the buy side OMS and the sell side OMS. At this point, both vendors are claiming they are complying with FIX standard. As Will Walter describes in his response, we’re going to have a hard time trying to encourage either side to make a change either way. Thanks for your responses.
Many firms have implemented Tag 32 (Last Shares) equal to 0 on all execution reports, even on FIX 4.2. Historically (versions prior to FIX 4.2), the FIX specification has required Tag 32 on all execution reports. So, many firms still add Tag 32 to execution reports even when the execution report is not a fill. Since FIX 4.2, however, the specification has made Tag 32 an optional field.
In the FIX 4.2 specification, the note you reference “Field not required for ExecTransType = 3” does exist. It adds a little bit of confusion because the field is defined as NOT required. The note doesn’t say Tag 32 is conditionally required for execution reports where ExecTransType does not equal 3, for example. In FIX 4.3, that note was removed to indicate that it is simply an optional field.
In reality, Tag 32 should be optional for execution reports. Because not all execution reports are indicating a fill. Tag 32 does not make sense for all execution reports.
I think it would be hard to say your counterparty is incorrect by not sending LastShares=0. While a large part of the FIX community is sending this tag on execution reports, it is not clearly required in the FIX 4.2 specification. Thus, you may have more counterparties that have not implemented Tag 32 on all execution reports.
We are on FIX 4.2 and are curious about the usage of Tag 32 (LastShares) in the condition of a rejection message for unknown symbol.
Here is the flow:
- Order message sent from Firm A to Firm B where symbol XYZ is not
known by Firm B (such as it is not setup on Firm B’s security master)- Rejection message is sent from Firm B to Firm A with these fields
populated: Symbol: 55=XYZ ExecTransType: 20=0 (New) MsgType: 35=8
(Execution report) OrdStatus: 39=8 (Rejected) Text: 58=Instrument
XYZ is inactive Question is this: Rejection message does not
include Tag 32 for LastShares. Should it? Per my FIX 4.2 spec, it
notes for Tag 32: “Field not required for ExecTransType = 3
(Status)”. Do you concur that Tag 32 should be a required field on
a rejection message for symbol not known? I am thinking yes in that
ExecTransType = 0 (new) in this example, but I would appreciate
your interpretation of the standard for this condition. Thank you
very much for your help. -Kaaren