Session-level rejects (35=3)
Required tag missing (SessionRejectReason 373=1)
The receiver's data dictionary marks a field as required for this message type and the message did not carry it. It answers with a session-level Reject (35=3) with 373=1 and RefTagID (371) naming the missing tag.
What it means
A session-level Reject means the message failed validation before it reached the application. The rejected message still used up its sequence number, so do not resend it with the same MsgSeqNum (34): send a corrected message as a new one.
RefSeqNum (45) gives the sequence number of the rejected message, RefMsgType (372) its MsgType and RefTagID (371) the missing tag. Text (58) often repeats this in words.
What is required depends on the FIX version and on the counterparty's own dictionary. FIX 4.2 requires HandlInst (21) on New Order Single; FIX 4.4 does not. Venues often add their own required fields, such as Account (1) or ExDestination (100).
Conditionally required fields, such as Price (44) on a limit order, are normally rejected by the application, with a Business Message Reject (35=j) (380=5) or an Execution Report with 39=8, not with a session Reject.
Common causes
- TransactTime (60) left out of New Order Single, Order Cancel Request or Order Cancel/Replace Request. It is required in FIX 4.2 and 4.4 and is the most frequent case.
- A message built for one FIX version sent on a session configured for another.
- The counterparty uses a customised dictionary with extra required fields.
- A field that is required inside each repeating group entry is missing from one entry.
How to fix it
On the side that sent the message
- Read RefTagID (371), add the field and send the corrected message as a new message with the next sequence number.
- Ask the counterparty for their rules of engagement or dictionary file, and check the required list on the message page for your version.
On the side that raised the error
- Always fill RefTagID (371) and a readable Text (58) so the sender can fix the message without a phone call.
- If you reject a field your published specification calls optional, fix your dictionary rather than asking every client to send it.
Example
A FIX 4.4 New Order Single without TransactTime (60), and the Reject it gets.
1. Buy side: New Order Single without tag 60
8=FIX.4.4|9=117|35=D|49=BUYSIDE|56=SELLSIDE|34=58|52=20261020-09:31:00.000|11=ORD-1001|21=1|55=MSFT|54=1|38=1000|40=2|44=187.50|59=0|10=156|
2. Sell side: Reject, RefTagID 60
8=FIX.4.4|9=109|35=3|49=SELLSIDE|56=BUYSIDE|34=912|52=20261020-09:31:00.002|45=58|371=60|372=D|373=1|58=Required tag missing|10=169|
SOH (0x01) is shown as |. BodyLength (9) and CheckSum (10) are calculated as if every | were SOH.
Open this example in the parserQuestions
- Do I resend the rejected message with the same MsgSeqNum?
- No. The Reject consumed that number. Fix the message and send it as a new message with your next sequence number.
- Where do I find which tags are required?
- In the counterparty's rules of engagement first, since venues add their own. For the standard rules, the message pages on this site list required fields for each FIX version.