This message should be issued when a message is received but cannot be properly processed due to a session-level rule violation. For example, upon receipt of a message with an invalid MsgType (35) that is otherwise valid. 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 should be incremented.

The receiving application should disregard any message that is garbled, cannot be parsed or fails a data integrity check. Processing of the next valid FIX message will cause detection of a sequence gap and a Resend Request <35=2> will be generated. FIX engines should be implemented to recognize a possibly infinite resend loop, which may be encountered in this situation.

Generation and receipt of a Reject message indicates a serious error that may be the result of faulty logic in one or both applications.

If the sending application chooses to retransmit the rejected message, it should be assigned a new sequence number and sent with PossResend (97)=Y.

It is strongly recommended that the cause of the failure be described in the Text (58) field. For example, "Invalid data - field 35".

If an application-level message fulfills session-level rules then it should then be processed at a business-message level. If this processing detects a rule violation, a business-level reject should be issued. Many business-level messages have specific rejection message types which should be used. All others can be rejected at a business-level with the Business Message Reject <35=j> message.

In the event that a business message is received, fulfills session-level rules, but cannot be processed by the business-level processing system, a Business Message Reject <35=j> with BusinessRejectReason (380) = "Application not available at this time" should be sent.

Scenarios for a session-level Reject are listed in the documentation for SessionRejectReason (373).