Session-level rejects (35=3)
Incorrect NumInGroup count for repeating group (373=16)
The NumInGroup counter says one number of entries and the message contains a different number. The receiver answers with a Reject carrying 373=16 and the counter tag in RefTagID (371).
What it means
A repeating group starts with a NumInGroup field, such as NoPartyIDs (453) for Parties or NoAllocs (78) for allocations, whose value is the number of entries that follow.
Too high a count makes the receiver look for entries that are not there; too low a count leaves extra entries that may also produce 373=13.
Common causes
- The count was computed before an entry was filtered out or added.
- Nested groups counted at the wrong level.
- A counter of 0 sent with no entries. Some engines reject it; leave the counter out instead.
How to fix it
On the side that sent the message
- Compute the counter from the final list of entries when you write the group.
- Omit the group entirely when it has no entries.
On the side that raised the error
- Name the counter tag in RefTagID (371).
Example
NoPartyIDs (453) says 2 but only one entry follows.
1. Buy side: 453=2 with one entry
8=FIX.4.4|9=174|35=D|49=BUYSIDE|56=SELLSIDE|34=160|52=20261020-10:16: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=2|448=TRADER1|447=D|452=11|10=185|
2. Sell side: Reject, RefTagID 453
8=FIX.4.4|9=139|35=3|49=SELLSIDE|56=BUYSIDE|34=1150|52=20261020-10:16:00.002|45=160|371=453|372=D|373=16|58=Incorrect NumInGroup count for repeating group|10=074|
SOH (0x01) is shown as |. BodyLength (9) and CheckSum (10) are calculated as if every | were SOH.
Open this example in the parserQuestions
- Can I send NumInGroup=0?
- The data type allows it, but many engines reject an empty group. Leaving the counter out is always accepted when the group is optional.