8=FIX.4.2 9=107 34=1920 35=3 45=2371 49=TEST1 52=20160203-14:31:52.235 56=DWFIX01 58=Invalid tag number 371=8005 372=8 373=0 10=224
When should a
Reject <3> rejection be issued?
Reject <3>rejection be issued?
A rejection should be issued whenever a message is received but cannot be properly processed due to a session-level rule violation.
- Example: An instance where a reject may be appropriate would be the receipt of a message with invalid basic data (e.g.
MsgType <35>=&) which successfully passes de-encryption,
BodyLength <9>which successfully passes de-encryption checks.
As a rule, messages should be forwarded to the trading application for business level rejections whenever possible. All rejected messages should be logged and the incoming sequence number incremented.
When is a message disregarded?
A receiving application should disregard any message that is:
- Cannot be parsed
- Fails a data integrity check
When is a Resend Request generated?
Resend Request <2> is generated when the processing of the next valid FIX message causes detection of a sequence gap.
Note: All logic should be included in the FIX engine to recognize the possible infinite resend loop, which may be encountered in this situation.
When is a
Reject <3> message generated and sent?
Reject <3>message generated and sent?
When a serious error that may be the result of faulty logic in either the sending or receiving application occurs, a
Reject <3> message is generated.
Note: If the sending application chooses to retransmit the rejected message, it should be assigned a new sequence number and sent with
PossResend <97>=Y. The cause of the failure can be described in the
Text <58> field (e.g.
INVALID DATA - FIELD 35).
Business-level Messaging Processing Initiation
- If an application-level message received fulfills session-level rules, it should then be processed at a business message-level.
Business-level Rejection Message Initiation
- If this processing detects a rule violation, a business-level rejection should be issued. Many business-level messages have specific "reject" messages, which should be used. All others can be rejected at a business-level via the
Business Message Reject <j>message (see the
Business Message Reject <j>message).
Note: In the event a business message is received and fulfills session-level rules, however, the message cannot be communicated to the business-level processing system, a
Business Message Reject <j> with
BusinessRejectReason <380> = "Application not available at this time" should be issued.
|Invalid tag number|
|Required tag missing|
|Tag not defined for this message type|
|Tag specified without a value|
|Value is incorrect (out of range) for this tag|
|Incorrect data format for value|
|Signature <89> problem|
|SendingTime <52> accuracy problem|
|Invalid MsgType <35>|
Note: Other session-level rule violations may exist in which case
SessionRejectReason <373> is not specified.
|Tag||Tag Description||Value||Value Description||Required|
|BodyLength||Length of message||Yes|
|MsgSeqNum||Message sequence number||Yes|
|RefSeqNum||2371||Reference message sequence number||Yes|
|RefTagID||The tag number of the FIX field being referenced||Yes|
|SessionRejectReason||0||Code to identify reason for a session-level Reject message.||Yes|
|CheckSum||Checksum of message||Yes|
Updated less than a minute ago