OrderId (tag 37)

, ,
1

Imported from previous forum

2

All,

I wanted to get some clarification about this. Per the FIX standard, if a NEW order is submitted by a buy-side party yet rejected by the broker, before being placed at the exchange, should the REJECTED execution report contain an OrderId (tag 37)?

My current broker does generate and send us an OrderId, however I am interested in knowing what the FIX standard is in this case.

thanks!
azmat

3

Hi Azmat,

In every system I’ve encountered OrderID is always provided in an order reject (ExecutionMsg with ordStatus=8 execType=8). It is a required field so the party rejecting the order should generate an ID. This is regardless of whether the buy-side is interested in this field in this scenario.

-Greg

4

[ original email was from John Prewett - jprewett@lavatrading.com ]
> All,

I wanted to get some clarification about this. Per the FIX standard, if
a NEW order is submitted by a buy-side party yet rejected by the broker,
before being placed at the exchange, should the REJECTED execution
report contain an OrderId (tag 37)?

My current broker does generate and send us an OrderId, however I am
interested in knowing what the FIX standard is in this case.

thanks! azmat

OrderID is a mandatory field in an ExecutionReport. It should therefore always be populated. This has nothing to do with what state the order was in when it was rejected.
This is a simple issue of adherence (or lack thereof) to the protocol standard.

You can easily discover this by using FIXimate which is available on the FIX Protocol website:
http://www.fixprotocol.org/FIXimate3.0/

Thanks

JohnP

5

All,

I wanted to get some clarification about this. Per the FIX standard,
if a NEW order is submitted by a buy-side party yet rejected by the
broker, before being placed at the exchange, should the REJECTED
execution report contain an OrderId (tag 37)?

My current broker does generate and send us an OrderId, however I am
interested in knowing what the FIX standard is in this case.

thanks! azmat

OrderID is a mandatory field in an ExecutionReport. It should therefore
always be populated. This has nothing to do with what state the order
was in when it was rejected. This is a simple issue of adherence (or
lack thereof) to the protocol standard.

You can easily discover this by using FIXimate which is available on the
FIX Protocol website: http://www.fixprotocol.org/FIXimate3.0/

Thanks

JohnP

Beware of “NONE” value.

6

If your broker does not simply route the order to the exchange but does validation and initiates a response to you, he also has to issue order IDs and provide them to you in general. You then use these (field OrderID) to communicate with the broker. Additionally, he could use SecondaryOrderID to tell you about the order IDs issued by the exchange.

Rejections of new orders are a special case, similar to the rejection of cancelations or replacements. ClOrdID is an entity identifier as well as a message identifier (unfortunately in my view). Your NewOrderSingle with a ClOrdID is rejected, i.e. no entity is created. The ClOrdID value should not be re-used as it also uniquely identifies the transaction. The OrderID issued by the broker normally does not change over the lifetime of the order, i.e. it is a pure entity identifier.

I would therefore argue that the lack of an entity creation (broker rejects your request to do so) does not justify to issue an OrderID value. It does not add any information as you cannot use this ID as a reference. The ExecutionReport carries the ExecID field that uniquely identifies the response (rejection). The field OrderID is mandatory and must be filled according to the spec. However, as pointed out in another post, the value “NONE” is to be used when attempting to cancel an order that is unknown (see OrderCancelReject).

The case maybe becomes more obvious if one looks at rejection reasons such as a lack of authorization or simply the unavailability of the service accepting orders. I do not see a business reason to issue OrderID values for such cases. One could argue that these cases should trigger a SessionReject and not an ExecutionReport but OrdRejReason enum value 2=“Exchange closed” does not fit this definition.

Exchanges often have gateway systems performing initial validations prior to routing it to a matching engine that needs to be the sole issuer of exchange order IDs to ensure uniqueness within a well-defined scope. If a request for a new order never makes it there, there will simply be no value (other than e.g. “NONE”) to pass back in the response.

Regards,
Hanno.

All,

I wanted to get some clarification about this. Per the FIX standard, if
a NEW order is submitted by a buy-side party yet rejected by the broker,
before being placed at the exchange, should the REJECTED execution
report contain an OrderId (tag 37)?

My current broker does generate and send us an OrderId, however I am
interested in knowing what the FIX standard is in this case.

thanks! azmat

7

Many thanks for the all the help. So it seems like the spec allows for “NONE”, however most sell-side parties do indeed generate and send out an OrderId, even on rejected transaction messages where no ‘entity’ has ever been created.

Basically the FIX standard allows for both scenarios and I guess it is dependent on the implementor to decide which way to go.

thanks!

If your broker does not simply route the order to the exchange but does
validation and initiates a response to you, he also has to issue order
IDs and provide them to you in general. You then use these (field
OrderID) to communicate with the broker. Additionally, he could use
SecondaryOrderID to tell you about the order IDs issued by the exchange.

Rejections of new orders are a special case, similar to the rejection of
cancelations or replacements. ClOrdID is an entity identifier as well as
a message identifier (unfortunately in my view). Your NewOrderSingle
with a ClOrdID is rejected, i.e. no entity is created. The ClOrdID value
should not be re-used as it also uniquely identifies the transaction.
The OrderID issued by the broker normally does not change over the
lifetime of the order, i.e. it is a pure entity identifier.

I would therefore argue that the lack of an entity creation (broker
rejects your request to do so) does not justify to issue an OrderID
value. It does not add any information as you cannot use this ID as a
reference. The ExecutionReport carries the ExecID field that uniquely
identifies the response (rejection). The field OrderID is mandatory and
must be filled according to the spec. However, as pointed out in another
post, the value “NONE” is to be used when attempting to cancel an order
that is unknown (see OrderCancelReject).

The case maybe becomes more obvious if one looks at rejection reasons
such as a lack of authorization or simply the unavailability of the
service accepting orders. I do not see a business reason to issue
OrderID values for such cases. One could argue that these cases should
trigger a SessionReject and not an ExecutionReport but OrdRejReason enum
value 2=“Exchange closed” does not fit this definition.

Exchanges often have gateway systems performing initial validations
prior to routing it to a matching engine that needs to be the sole
issuer of exchange order IDs to ensure uniqueness within a well-
defined scope. If a request for a new order never makes it there,
there will simply be no value (other than e.g. “NONE”) to pass back in
the response.

Regards, Hanno.

All,

I wanted to get some clarification about this. Per the FIX standard,
if a NEW order is submitted by a buy-side party yet rejected by the
broker, before being placed at the exchange, should the REJECTED
execution report contain an OrderId (tag 37)?

My current broker does generate and send us an OrderId, however I am
interested in knowing what the FIX standard is in this case.

thanks! azmat