When To Use Various Types of 'Reject' Messages

, ,
1

Imported from previous forum

2

We are implementing FIX Protocol and we are looking at the different types of reject messages and need some guidance on when to use each one.

In Message Type Q, it has a lot of information in it but it seems to be a duplicate of the Execution Report with a ExecType = Reject. When would you use each one?

Additionally, I have seen it written that a Reject Message (3) can also be used instead of a Q.

Are there any definitive reasons as to why we would use one message type over another and when they should be used? What is the business norm?

Here’s our current plan:

  1. If we are missing required tags, the tags don’t have values, or the values are not as expected, then we are planning to reject with a Q.

  2. If we can receive the message but for some reason can’t process it (for example, the CUSIP isn’t valid), then we are going to send an execution report with the execution type of reject.

We do not plan on using the Business Reject message (3); however, it seems that the business reject message may cover a lot of the scenarios for when we plan on using the Q.

Any thoughts?

3

The three message types that you mentioned, Reject [type ‘3’], DontKnowTrade [type ‘Q’], and ExecutionReport [type ‘8’] with ExecType = Reject all have different purposes.

The Reject message belongs to the session and presentation layers rather than application layer. It is a response to violations of session protocol or to any malformed message. A missing required field in any message is answered by Reject message with SessionRejectReason = Required Tag Missing (1).

The other two message types are application layer responses. An ExecutionReport is a response to an order message such as NewOrderSingle. Rejection of an order for violation of business rules is set by ExecType = Rejected (8).

On the other hand, DontKnowTrade is a rejection of an ExecutionReport. (It’s typical cause is an error in identification, as sometimes happened in open outcry trading. Such an event is unlikely with electronic trade matching.) Therefore, it is not appropriate for the scenario you described.

4

Hi Katherine,

I would like to add to Don’s comments which I concur with. The title of the thread is misleading, i.e. it is probably meant to say “When To Use Various Types of Reject Messages”, or?

MsgType=3 is not a “Business Reject” message, it is what Don describes above. There is such a message and it is called BusinessMessageReject(MsgType=j). It is to be used if there is an application level error that cannot be responded with by means of an ExecutionReport.

DontKnowTrade is not only limited to a rejection of an ER but it is limited to ERs that express executions. It is not applicable to reject a confirmation of an order entry, modification or deletion.

Please have a look at Volume 1, 2 and 4 of the FIX V4.4 Specification. You did not mention any specific FIX version. Volume 1 describes the BusinessMessageReject message, Volume 2 the Reject message and Volume 4 the DontKnowTrade message.

Regards,
Hanno.