Session-level rejects (35=3)
Tag specified out of required order (373=14)
A field sits where the receiver does not allow it. BeginString (8), BodyLength (9) and MsgType (35) must be the first three fields in that order, header fields must come before body fields, and CheckSum (10) must be last.
What it means
Outside the first three fields and the trailer, FIX does not fix the order of header or body fields. Many engines still check that header fields come before body fields; QuickFIX does this unless ValidateFieldsOutOfOrder is set to N.
Fields inside a repeating group have their own ordering rules, reported with 373=15 instead.
Common causes
- A message builder that sorts all fields by tag number, which moves 35 after 34 and body fields among header fields.
- A header field such as PossDupFlag (43) or OrigSendingTime (122) appended after the body during a replay.
- Fields added by a gateway at the end of the message, after the body.
How to fix it
On the side that sent the message
- Write 8, 9 and 35 first, then the other header fields, then the body, then 10.
- Do not sort fields by tag number.
On the side that raised the error
- If a counterparty cannot change quickly, QuickFIX's ValidateFieldsOutOfOrder=N accepts header fields in the body.
Example
A message with SenderCompID (49) before MsgType (35).
1. Buy side: 49 before 35
8=FIX.4.4|9=143|49=BUYSIDE|35=D|56=SELLSIDE|34=140|52=20261020-10:12:00.000|11=ORD-1001|21=1|55=MSFT|54=1|60=20261020-09:30:00.000|38=1000|40=2|44=187.50|59=0|10=118|
2. Sell side: Reject with 373=14
8=FIX.4.4|9=121|35=3|49=SELLSIDE|56=BUYSIDE|34=1130|52=20261020-10:12:00.002|45=140|371=35|373=14|58=Tag specified out of required order|10=094|
SOH (0x01) is shown as |. BodyLength (9) and CheckSum (10) are calculated as if every | were SOH.
Open this example in the parserQuestions
- Does FIX require tags in numeric order?
- No. Only 8, 9 and 35 at the start and 10 at the end are fixed, plus the rule that header comes before body and group fields follow their group definition.