Common FIX Reject Codes Explained
FIX reject messages (MsgType=3) indicate that a message failed validation at either the session level or business level. Understanding reject codes is essential for debugging FIX connectivity issues and ensuring message compliance.
RefTagID (371) and RefMsgType (372)
When a FIX message is rejected, the reject message includes two critical reference fields:
- RefTagID (371): Identifies the specific tag number that caused the rejection. This pinpoints exactly which field was problematic.
- RefMsgType (372): Identifies the message type that was rejected (e.g., D=NewOrderSingle, F=OrderCancelRequest).
For example, if a NewOrderSingle is rejected because Side (tag 54) is missing, the reject message will have RefTagID=371 with value "54" and RefMsgType=372 with value "D".
Session Rejects vs Business Rejects
Session-Level Rejects
Session-level rejects occur when a message fails structural or protocol-level validation. These rejections happen before the message reaches business logic. Common causes include:
- Invalid tag numbers or undefined tags
- Missing mandatory session-level tags (BeginString, BodyLength, MsgType, etc.)
- Incorrect message format or encoding
- Checksum validation failure
- CompID mismatch
Business-Level Rejects
Business-level rejects occur when a message passes session validation but fails business rules. These rejections happen after the message is parsed and validated structurally. Common causes include:
- Invalid order parameters (price out of range, quantity too large)
- Business rule violations (e.g., trading outside market hours)
- Invalid symbol or security identifier
- Account or permission issues
- Duplicate ClOrdID
Top 10 Common Reject Causes
| Reject Code | Reason | Description |
|---|---|---|
| 5 | Invalid tag number | A tag number in the message is not recognized or is invalid for the FIX version being used. |
| 6 | Required tag missing | A mandatory tag required by the FIX specification or business rules is missing from the message. |
| 7 | Tag not defined for this message type | A tag is present in a message type where it is not allowed or defined. |
| 8 | Undefined tag | A tag number is not defined in the FIX specification version being used. |
| 9 | Tag specified without a value | A tag is present but has no value (empty tag=value pair). |
| 10 | Value is incorrect (out of range) | The value for a tag is outside the valid range or format (e.g., negative price, invalid enum). |
| 11 | Incorrect data format for value | The data format is incorrect (e.g., timestamp format wrong, non-numeric value in numeric field). |
| 12 | Decryption problem | The message could not be decrypted, often due to encryption key issues. |
| 13 | Signature problem | The message signature verification failed, indicating potential tampering. |
| 14 | CompID problem | The SenderCompID or TargetCompID is incorrect or not recognized. |
How to Fix Rejects
When you receive a reject message, follow these steps:
- Check RefTagID (371): Identify which tag caused the rejection
- Check RefMsgType (372): Confirm which message type was rejected
- Review SessionRejectReason (373): Read the numeric reject code
- Inspect the original message: Look at the rejected message to see what was wrong
- Fix the issue: Correct the tag value, add missing tags, or fix format issues
- Resubmit: Send a corrected message with a new ClOrdID
Example Reject Message
8=FIX.4.4|9=123|35=3|34=5|49=EXCHANGE|56=CLIENT|52=20231116-10:30:00|
371=54|372=D|373=6|58=Required tag missing: Side|10=123|
This reject indicates that a NewOrderSingle (372=D) was rejected because tag 54 (Side) was missing (373=6, RefTagID=371=54).
Related Resources
Learn more about FIX rejects and troubleshooting:
- FIX Reject 371 – Deep dive into RefTagID
- FIX Troubleshooting Guide – Step-by-step diagnostics
- FIX Tag Glossary – Understand all FIX tags
- Upload a FIX Log – Analyze reject messages in your logs