Session-level rejects (35=3)
Repeating group fields out of order (373=15)
The fields inside a repeating group entry are not in the order the receiver expects. Every entry must start with the group's first field, its delimiter; strict engines also expect the remaining fields in the order the dictionary defines.
What it means
A receiver finds the boundaries between group entries by the delimiter field: each time it appears, a new entry starts. If an entry starts with another field, the receiver cannot tell which entry the field belongs to.
For the Parties group the delimiter is PartyID (448), so each entry starts with PartyID, followed by PartyIDSource (447) and PartyRole (452).
Common causes
- Group fields written from an unordered map or dictionary.
- Fields sorted by tag number, which puts 447 before 448 in a Parties entry.
- An optional delimiter left out of one entry.
How to fix it
On the side that sent the message
- Write each entry's fields in the order of the group definition, delimiter first.
- Check the group layout on the message page for your FIX version.
On the side that raised the error
- Name the group counter or the misplaced field in the Reject so the sender can find the entry.
Example
A Parties entry that starts with PartyRole (452) instead of PartyID (448).
1. Buy side: group entry starts with 452
8=FIX.4.4|9=174|35=D|49=BUYSIDE|56=SELLSIDE|34=150|52=20261020-10:14: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|453=1|452=11|448=TRADER1|447=D|10=181|
2. Sell side: Reject with 373=15
8=FIX.4.4|9=120|35=3|49=SELLSIDE|56=BUYSIDE|34=1140|52=20261020-10:14:00.002|45=150|372=D|373=15|58=Repeating group fields out of order|10=089|
SOH (0x01) is shown as |. BodyLength (9) and CheckSum (10) are calculated as if every | were SOH.
Open this example in the parserQuestions
- Which field is the delimiter of a repeating group?
- The first field in the group definition. The message pages on this site show each group with its fields in definition order.