Hey all,
I’m implementing a parser for 4.4, and I’m not sure how safe it is to make some assumptions regarding fields ordering. In general my parser doesn’t rely on ordering with two exceptions.
Say NewOrderSingle is being processed, and Instrument is an optional component. Once the parser realizes the there’s one field that belongs to Instrument, is there any guarantees that the immediate following fields (if any) belong to Instrument before switching the context back to the newordersingle fields?
Similar question regarding groups: If I encounter NoPartyIDs, can I safely assume the next fields will be Party related?
Thanks in advance
The rule-of-thumb is this: When formatting an outgoing message, order fields and components exactly as specified in the standard or as extended in your ROE. When parsing an incoming message expect and allow discrepancies.
Even though the official rules require strict field ordering for repeating groups you can require just this: The NumInGroup field gives the count of instances of the first tag in the component. If there are to be three instances then the fields between the first appearance of the first tag and the second appearance belong in the first instance, between the second appearance and the third appearance in the second instance. After the third appearance is the challenge - the first tag in sequence that is not defined in the repeating group - not necessarily in proper order - ends the third instance.
The fields in a non-repeating component at the base of a message, e.g. Instrument in NewOrderSingle often appear randomly throughout the base - all expectations are off. The fields of a non-repeating component embedded in a repeating component, e.g. InstrumentLeg within LegOrdGrp, OUGHT to appear in standard order but the incoming-message parser should not require it.
By the way: The Instrument component is required in NewOrderSingle.
Dean
1 Like
That’s helpful. Thanks Dean
You should always add the encoding your parser is expecting as FIX has quite a large number now. I assume you meant the legacy syntax tag=value. Other encodings may have strict ordering rules based on the meta-data, e.g. in case of fixed length binary encodings. Here is the complete list of current encodings for FIX:
tag=value
FIXML
FAST
SBE
GPB
ASN.1
JSON
Please see encodings on FIX Standards – FIX Trading Community v2.1 for details.