Reject <3> message – FIX 4.0 – FIX Dictionary

FIX 4.0 : Reject <3> message

Structure | Sample Message | Related Messages

Description

The Reject <3> message should be issued when a message is received which cannot be passed through to the application level. An example of when 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> 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.

Note: When a message is received which is garbled, cannot be parsed or fails a data integrity check, the receiving application should disregard the message. Processing of the next valid FIX message will cause detection of a sequence gap and a Resend Request <2> will be generated. Logic should be included in the FIX engine to recognize the possible infinite resend loop which may be encountered in this situation.

Generation and receipt of a Reject <3> message should be dealt with as an indication of a serious error by both parties as it may be the result of faulty logic in either the sending or receiving application.

If the sending application chooses to retransmit the rejected message it should be assigned a new sequence number.

Whenever possible, it is strongly recommeded that the cause of the failure be described in the Text <58> field (e.g. INVALID DATA - FIELD 35).

Structure

Tag	Field Name	Req'd	Comments
<MessageHeader>		Y	MsgType <35> = 3
45	RefSeqNum	Y	MsgSeqNum <34> of rejected message
58	Text	N	Where possible, message to explain reason for rejection
<MessageTrailer>		Y

Sample Message

The '^' character is used to represent SOH character.

8=FIX.4.0^9=134^35=3^49=SellSide^56=BuySide^34=3^52=20190606-11:57:12.036^45=3^58=Invalid Resend Request: BeginSeqNo (5) is greater than expected (2)^10=088^