58=Invalid tag number

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.

SessionRejectReason <373>Tag Description
0Invalid tag number
1Required tag missing
2Tag not defined for this message type
3Undefined Tag
4Tag specified without a value
5Value is incorrect (out of range) for this tag
6Incorrect data format for value
7Decryption problem
8Signature <89> problem
9CompID problem
10SendingTime <52> accuracy problem
11Invalid MsgType <35>

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

TagTag DescriptionValueValue DescriptionRequired
8BeginStringFIX.4.2FIX VersionYes
9BodyLength63Length of messageYes
34MsgSeqNum1920Message sequence numberYes
35MsgType3Reject MessageYes
45RefSeqNum2371Reference message sequence numberYes
49SenderCompIDTEST1Sender IDYes
52SendingTime20160203-14:31:52.235Sending timestampYes
56TargetCompIDDWFIX01Target IDYes
58TextInvalid tag numberRejection messageYes
371RefTagID8005The tag number of the FIX field being referencedYes
372RefMsgType8The MsgType of the FIX message being referenced.Yes
373SessionRejectReason0Code to identify reason for a session-level Reject message.Yes
10CheckSum224Checksum of messageYes