Imported from previous forum
I am creating a few acceptance tests for an Open Source FIX Engine (QuickFIX). I am trying to understand the Business Message Reject message.
Would an IOI message for an option without a Strike Price tag be rejected with a Business Message Reject message having a BusinessRejectReason = 5 "Conditionally Required Field Missing"? If this is the case, why is it that a New Order-Single for an option with a missing strike would be rejected (by the application process) with an execution report?
Thanks,
James C. Downs
Connamara Systems, LLC.
http://www.connamara.com
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> I am creating a few acceptance tests for an Open Source FIX Engine (QuickFIX). I am trying to understand the Business Message Reject message.
>
> Would an IOI message for an option without a Strike Price tag be rejected with a Business Message Reject message having a BusinessRejectReason = 5 "Conditionally Required Field Missing"? If this is the case, why is it that a New Order-Single for an option with a missing strike would be rejected (by the application process) with an execution report?
Given the number of messages in FIX, creating a specific reject message for each one would bloat the spec significantly. Prior to 4.2, the Session Reject was the only way to reject messages such as IOIs that don’t have explicit reject messages. 4.2 introduced the Business Message Reject, which was designed to be a generic, all-purpose way of rejecting messages which don’t have more specific application-level rejects.
FIX has no IOI Reject message, hence in the case you mention, one should use Business Message Reject.
As you note, orders do have specific reject messages (Execution Report with OrdStatus = ExecType = Rejected, and Order Cancel Reject.) In general, it is better to use these in the case you mention.
However, this has its drawbacks. Sending an Execution Report requires assigning an OrderID for an invalid order that will never go live. Many firms don’t want to do this. Some firms may want their FIX engines to do more intelligent validation, meaning less validation checking is needed in their application code. For example, an engine can verify that all required fields are present, and can validate the conditional requirements. In the case you mention of an option without a strike price, the engine can generate a Business Message Reject and never forward the message to the application layer, thus eliminating the need to assign an OrderID.
I consider both the Business Message Reject and the Execution Report valid in the case of an order. For an IOI, in 4.2 and 4.3, the only option is the Business Message Reject.
[ original email was from John Cameron - jc@cameronsystems.com ]
> I consider both the Business Message Reject and
> the Execution Report valid in the case of an
> order.
I understand your arguments relating to order rejects. However, the Fix spec is pretty emphatic about the use of Business Message Reject. Quoting from the spec:
"Business Message Reject -
The Business Message Reject message can reject an application-level message which fulfills session-level rules and cannot be rejected via any other means. Note if the message fails a session-level rule (e.g. body length is incorrect), a session-level Reject message should be issued.
See the session-level Reject message
It should NOT be used in the following situations:"
The emphasis (NOT) is taken directly from the spec.
One of the situations listed is order messages where Execution Report is listed as the appropriate reject response.
[ original email was from Hank Terrebrood - Hank.Terrebrood@csfb.com ]
In the original question, price is not a required IOI field - thus there should not be a session level reject but a Business Message Reject.
For an order, execution reports are used to maintain state of an order. The only exception for an orders is where the FIX engine is opperational, but some other downstream bit is not…then you may issue the BusinessRejectReason = “Application not available at this time.”
The session level
> > I consider both the Business Message Reject and
> > the Execution Report valid in the case of an
> > order.
>
> I understand your arguments relating to order rejects. However, the Fix spec is pretty emphatic about the use of Business Message Reject. Quoting from the spec:
>
> "Business Message Reject -
> The Business Message Reject message can reject an application-level message which fulfills session-level rules and cannot be rejected via any other means. Note if the message fails a session-level rule (e.g. body length is incorrect), a session-level Reject message should be issued.
> See the session-level Reject message
> It should NOT be used in the following situations:"
>
> The emphasis (NOT) is taken directly from the spec.
> One of the situations listed is order messages where Execution Report is listed as the appropriate reject response.
>
>
In the original question I was asking about a Strike Price for an IOI for an option order. I think the Strike Price is conditionally required for options. The spec does not specifically say that a strike price is conditionally required only that it is "For Options". I am making an assumption that it is conditionally required for options. I could be wrong as the symbol(55) could contain an OPRA code.
It is true that execution reports are used to maintain the state of an order (among a lot of other things). But is an order really an order if it is missing a conditionally required field? If an order is missing the symbol, a required field, it is rejected with a Reject message (not an order). What about a limit order with no price, a conditionally required field? How is this handled? Reject message, Business Message reject, or execution report? If the answer is execution report what makes this message an order and thus worthy of an OrderID from the application?
I’m not really trying to argue any one point here. I am just trying to understand how a standard FIX engine should handle these conditions.
> In the original question, price is not a required IOI field - thus there should not be a session level reject but a Business Message Reject.
>
> For an order, execution reports are used to maintain state of an order. The only exception for an orders is where the FIX engine is opperational, but some other downstream bit is not…then you may issue the BusinessRejectReason = “Application not available at this time.”
>
> The session level
> > > I consider both the Business Message Reject and
> > > the Execution Report valid in the case of an
> > > order.
> >
> > I understand your arguments relating to order rejects. However, the Fix spec is pretty emphatic about the use of Business Message Reject. Quoting from the spec:
> >
> > "Business Message Reject -
> > The Business Message Reject message can reject an application-level message which fulfills session-level rules and cannot be rejected via any other means. Note if the message fails a session-level rule (e.g. body length is incorrect), a session-level Reject message should be issued.
> > See the session-level Reject message
> > It should NOT be used in the following situations:"
> >
> > The emphasis (NOT) is taken directly from the spec.
> > One of the situations listed is order messages where Execution Report is listed as the appropriate reject response.
> >
> >
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> I understand your arguments relating to order rejects. However, the Fix spec is pretty emphatic about the use of Business Message Reject. Quoting from the spec:
>
> "Business Message Reject -
> The Business Message Reject message can reject an application-level message which fulfills session-level rules and cannot be rejected via any other means. Note if the message fails a session-level rule (e.g. body length is incorrect), a session-level Reject message should be issued.
> See the session-level Reject message
> It should NOT be used in the following situations:"
>
> The emphasis (NOT) is taken directly from the spec.
> One of the situations listed is order messages where Execution Report is listed as the appropriate reject response.
First, I need to clarify that I am most certainly NOT advocating widespread use of Business Message Reject with respect to orders. There are reasons why a well-written FIX system would send an order that would still get rejected, such as the market being closed, a stock halted, the broker not accepting stop orders, that the order would cross the market, or a symbol that exists on one system but not another. In all of these "normal" reject cases, an Execution Report is, and should be, the only valid response.
The situation we are discussing would only occur with a grossly non-compliant FIX system. No FIX-compliant system would ever send an option order without a strike price, a stop order without a StopPx, or a limit order without a Price.
Now in looking at the FIX 4.3 spec, I agree that for the order routing case, it is illegal to do what I suggest and send a Business Message Reject if a conditionally required field is missing.
I recommend that the next specification version, or an errata to 4.3, should make an exception so that for message types listed in the table, a conditionally required field missing would be a valid reason for a Business Message Reject, as is done for the case of the application layer being unavailable. I believe this should be done for two reasons:
-
Doing so allows vendors to add more value to their products by offering more intelligent message validation at an engine level, which means that FIX application developers using such engines have less validation work to do.
-
Doing so also helps close the gap between FIX and FIXML. Many conditional requirements in FIX are captured by the structure of the FIXML DTD. A FIXML option order without a strike price cannot pass DTD validation, and would be rejected without reaching the application layer. At present, if one wants to write a FIX application that can use either a FIX or FIXML engine, the application developer can rely on the FIXML engine enforcing conditional relationships, but cannot expect the FIX engine to do so. If a FIX engine could use Business Message Reject for conditionally required fields missing, then the application developer does not have to add validation code necessary for the FIX case that is redundant for the FIXML case.