Imported from previous forum
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
I realize this may be a bit late, but I’d like to recommend a new field for FIX 4.1. It would be an optional char field in the Execution message called ExchangeOrderID.
When a client institution sends an order to a broker and the broker passes the order to an exchange, the order has 2 IDs in FIX - the ClOrdID assigned by the client and the OrderID assigned by the broker. But in reality the order may have a third ID - the one at the exchange itself.
In some cases it is not convenient or possible to have the OrderID assigned by the broker and the ID of the order at the exchange be the same. And the broker may find it desirable for the client to be aware of the ID at the exchange.
The ExchangeOrderID field I propose would serve that purpose. The broker can optionally populate it with the ID at the exchange when sending back Execution messages, and the client can database it. This field would be used for informational purposes only, and would not change the operation of the protocol. ClOrdID and OrderID are still what the client uses to identify an order for the purposes of cancelling and/or replacing it, and ExchangeOrderID would have no part in that.
Ryan Pierce
Townsend Analytics Ltd.
It’s not too late for additional recommendations to be considered for the second draft and final release. Note that we now have a Discussion category called “FIX 4.1 Changes” in which suggestions/discussions such as this should be posted.
> I realize this may be a bit late, but I’d like to recommend a new field for FIX 4.1. It would be an optional char field in the Execution message called ExchangeOrderID.
>
> When a client institution sends an order to a broker and the broker passes the order to an exchange, the order has 2 IDs in FIX - the ClOrdID assigned by the client and the OrderID assigned by the broker. But in reality the order may have a third ID - the one at the exchange itself.
>
> In some cases it is not convenient or possible to have the OrderID assigned by the broker and the ID of the order at the exchange be the same. And the broker may find it desirable for the client to be aware of the ID at the exchange.
>
> The ExchangeOrderID field I propose would serve that purpose. The broker can optionally populate it with the ID at the exchange when sending back Execution messages, and the client can database it. This field would be used for informational purposes only, and would not change the operation of the protocol. ClOrdID and OrderID are still what the client uses to identify an order for the purposes of cancelling and/or replacing it, and ExchangeOrderID would have no part in that.
>
> Ryan Pierce
> Townsend Analytics Ltd.
>