[This message was posted by Hanno Klein of Deutsche Börse Systems <[email protected]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/d658a434 - PLEASE DO NOT REPLY BY MAIL.]
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 [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
