When to use Business Message Reject?

, ,
1

Imported from previous forum

2

[ original email was from Henrik Johansson - henrik.johansson@omxgroup.com ]
Reading the 4.4 FIX specification, I get different point of views when to use the Business Message Reject.

Vol 1 page 71 says:
"…In the event a business message is received, fulfills session-level rules, but lacks a field conditionally required by the FIX specification. In this situation a Business Message Reject with BusinessRejectReason = ‘Conditionally Required Field Missing’ can be issued if the system is unable to send the specific ‘reject’ message listed above. …".
My interpretation is that it is encouraged, if possible, not to use the Business Message Reject when a conditional required field is missing. Instead a corresponding ‘reject’ message shall be used, (Execution Report when a New Order Single stop order is received w/o StopPx). I do then not find a proper OrdRejectReason for this purpose, best match is either ‘Other’ or ‘Unsupported order characteristic’? This is applicable for all(?) ‘reject’ messages.

On the other hand the the scenario examples (vol 2 session test case 14.m (page 52) ) encourages the use of the Business Message Reject, which also have a corresponding RejectReason (‘Conditionally Required Field Missing’).

What is the common practice in this matter, shall Business Message Reject be used or not?

Thanks,
Henrik

3

Reading the 4.4 FIX specification, I get different point of views when
to use the Business Message Reject.

Vol 1 page 71 says: “…In the event a business message is received,
fulfills session-level rules, but lacks a field conditionally required
by the FIX specification. In this situation a Business Message Reject
with BusinessRejectReason = ‘Conditionally Required Field Missing’ can
be issued if the system is unable to send the specific ‘reject’ message
listed above. …”. My interpretation is that it is encouraged, if
possible, not to use the Business Message Reject when a conditional
required field is missing. Instead a corresponding ‘reject’ message
shall be used, (Execution Report when a New Order Single stop order is
received w/o StopPx). I do then not find a proper OrdRejectReason for
this purpose, best match is either ‘Other’ or ‘Unsupported order
characteristic’? This is applicable for all(?) ‘reject’ messages.

On the other hand the the scenario examples (vol 2 session test case
14.m (page 52) ) encourages the use of the Business Message Reject,
which also have a corresponding RejectReason (‘Conditionally Required
Field Missing’).

What is the common practice in this matter, shall Business Message
Reject be used or not?

Hmmm, while the vol. 1 description is quite clear, a test case as in vol. 2 is even more strict. IMHO, I would tend to use BusinessMessageReject since it has a specific RejectReason for this.
Maybe the spec is inconsistent here.

In our system, we use BusinessMessageReject for any optional field we are missing at application level.

According to the spec this is also not correct:

“However, a Business Message Reject message MUST NOT be used to
enforce proprietary rules more restrictive than those explicit in the FIX specification, such as a broker requiring an order to contain an Account, which the FIX specification considers an
optional field.”

So we may draw a fine line here:

  1. If the field is conditionally required according to the FIX spec
    (ie [OrdType=Stop, StopPx] or [SecurityID, IDSource] etc.),
    then we should use Business Message Reject.

  2. If the field is FIX optional, but required at application level,
    then we should use the message specific reject message. But if
    there is none, we have no choice…

I am looking forward to comments from the seasoned FIX experts…

Cheers, Jörg

4

So we may draw a fine line here:

  1. If the field is conditionally required according to the FIX spec (ie
    [OrdType=Stop, StopPx] or [SecurityID, IDSource] etc.), then we
    should use Business Message Reject.

  2. If the field is FIX optional, but required at application level, then
    we should use the message specific reject message. But if there is
    none, we have no choice…

Another interesting case is BusinessMessageReject(BusinessRejectReason=4 (Application N/A)):

If a client send an OrderStatusRequest and the fields provided are perfectly fine (OrderID is valid etc.), but the message fails due to some internal processing error, a ExecReport(Rejected) would be at least confusing, not to say wrong. It would suggest that ie the order does not exist etc.

Here the BusinessMessageReject is the right choice, IMHO.

Cheers, Jörg

5

And I am facing this dilemma when acting as an exchange which does some business-level validation. I am against using a Message specific reject, like an Allocation Instruction Ack (type reject) in response to a business-level invalid Allocation Instruction, since it appears to the party receiving it that the reject was generated by the counter-party and not the exchange , when in reality the counterparty will never get the 1st message to begin with.