The reject message should be issued when a message is received but cannot be properly processed due to a session-level rule violation. An example of when a reject may be appropriate would be the receipt of a message with invalid basic data (e.g. MsgType=&) which successfully passes de-encryption, CheckSum and BodyLength checks. As a rule, messages should be forwarded to the trading application for business level rejections whenever possible.
Rejected messages should be logged and the incoming sequence number incremented.
The reject format is as follows.
Table 4 – Reject
|
Tag |
Field Name |
Req’d |
Comments |
Format |
|
Standard Header |
Y |
MsgType = 3 |
| |
|
45 |
RefSeqNum |
Y |
MsgSeqNum of rejected message |
SeqNum |
|
371 |
RefTagID |
N |
The tag number of the FIX field being referenced. |
Int |
|
372 |
RefMsgType |
N |
The MsgType of the FIX message being referenced. |
String |
|
373 |
SessionRejectReason |
N |
Code to identify reason for a session-level Reject message. |
Int |
|
58 |
Text |
N |
Free format text string |
String |
|
Standard Trailer |
Y |
|
| |