Reject

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?

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, CheckSum <10> and 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:

• Garbled
• Cannot be parsed
• Fails a data integrity check

When is a Resend Request generated?

A 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?

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.

Note: Other session-level rule violations may exist in which case SessionRejectReason <373> is not specified.