|
General Q/A
< Previous Next >
Re: OrderId (tag 37)
Azmat Mohammed
13 May 2009 11:21AM ET 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
Re: OrderId (tag 37)
Azmat Mohammed 13 May 2009 11:21AM ET
|
