Reject
FIX Session rule violations are manifested through the Reject message. The receipt of a Reject message signals a serious violation of FIX Session rules. Appropriate action must immediately be taken by the receiver of a Reject message. A rejected message may be retransmitted by the sending application if a correction is appropriate.
The T4 FIX API can detect an extensive set of FIX session violations and will issue a Reject message. Even after a corrected retransmission, the T4 FIX API may choose to terminate the FIX Session per the gravity of the rejection.
Where possible, the T4 FIX API will provide a Reject message with:
- Reject Reason (Tag 373)
- Reference Message Type (Tag 372)
- Reference Sequence Number (Tag 45)
When a FIX session termination is forthcoming due to a FIX Session rejection, the T4 FIX API may provide a Logout message with further details of the violation.
FIX Session rejects can be generated for many reasons — including gross protocol violations such as empty tags, tags out of sequence, incorrect data types, etc. Following are common Rejection Reasons (Tag 373) detected by the T4 FIX API:
| Rejection Reason Code | Description |
|---|---|
| 0 | Invalid tag number |
| 1 | Required tag missing |
| 2 | Tag not defined for this message type |
| 3 | Undefined tag |
| 4 | Tag specified without a value |
| 5 | Value is incorrect (out of range) for this tag# |
| 6 | Incorrect data format for value |
| 7 | Decryption problem |
| 8 | Signature problem |
| 9 | CompID problem |
| 10 | SendingTime accuracy problem |
| 11 | Invalid MsgType |
| 12 | XML Validation error |
| 13 | Tag appears more than once |
| 14 | Tag specified out of required order |
| 15 | Repeating group fields out of order |
| 16 | Incorrect NumInGroup count for repeating group |
| 17 | Non “data” value includes field delimiter (SOH character) |
| 18 | Invalid Trader or No Trader specified |
When the FIX Session is terminated due to a FIX Session reject, the T4 FIX API will expect a restart with a new FIX Session and sequence numbers reset to 1.
Message Dictionary
| Tag | Field Name | Req'd | Comments |
|---|---|---|---|
 | Standard Header | Y | MsgType = 3 |
| 45 | RefSeqNum | Y | MsgSeqNum of rejected message |
| 371 | RefTagID | N | The tag number of the FIX field being referenced |
| 372 | RefMsgType | N | The MsgType of the FIX message being referenced |
| 373 | SessionRejectReason | N | Code to identify reason for a session-level Reject message |
| 58 | Text | N | Where possible, message to explain reason for rejection |
 | Standard Trailer | Y |
Sample Messages
Reject message generated by the receipt of an old Cancel Request message:
34=12|49=T4Example|50=TraderName|52=20120828-20:20:14.417|56=T4|57=G|369=11|1=123456|11=11FE|37=533408825203|41=11AN|48=CME_20121200_6EZ2|54=2|55=6E|60=20120828-20:20:14.376|107=Euro FX Dec12|167=FUT| [FIXCANCEL] [MsgSeqNum] 34 = 12 [SenderCompID] 49 = T4Example [SenderSubID] 50 = TraderName [SendingTime] 52 = 20120828-20:20:14.417 [TargetCompID] 56 = T4 [TargetSubID] 57 = G [LastMsgSeqNumProcessed] 369 = 11 [Account] 1 = 123456 [ClOrdID] 11 = 11FE [OrderID] 37 = 533408825203 [OrigClOrdID] 41 = 11AN [SecurityID] 48 = CME_20121200_6EZ2 [Side] 54 = 2 (SELL) [Symbol] 55 = 6E [SecurityExchange] 207 = CME_Fo [TransactTime] 60 = 20120828-19:20:14.376 [SecurityDesc] 107 = Euro FX Dec12 [SecurityType] 167 = FUT (FUTURE) 34=12|49=T4|56=T4Example|50=T4FIX|52=20120905-21:07:45.472|45=12|372=F|373=10|58=Sending Time Accuracy problem| [REJECT] [MsgSeqNum] 34 = 12 [SenderCompID] 49 = T4 [TargetCompID] 56 = T4Example [SenderSubID] 50 = T4FIX [SendingTime] 52 = 20120905-21:07:45.472 [RefSeqNum] 45 = 12 [RefMsgType] 372 = F [SessionRejectReason] 373 = 10 (SENDINGTIME_ACCURACY_PROBLEM) [Text] 58 = Sending Time Accuracy problem