Imported from previous forum
[ original email was from Ed Teng - e.teng@crossbordex.com ]
When moving from 4.1 to 4.2, there have been numerous Reuters Exchange Codes (REX) added and deleted. So, if a client and broker are communicating under 4.1, and they choose to use a market code that is no longer valid in 4.2 (such as AL - Alberta Stock Exchange), will the order/trade still be valid? Or will the client’s OMS perform a lookup from the most recent REX list and kick out this code before submitting the order?
Conversely, if a new code has been added to the REX list in 4.2 (such as BY - Beirut Stock Exchange), will a client and broker communicating under 4.1 be able to use that REX code or are they confined to the set REX codes located in Appendix C?
Thanks!
Ed
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> When moving from 4.1 to 4.2, there have been numerous Reuters Exchange Codes (REX) added and deleted. So, if a client and broker are communicating under 4.1, and they choose to use a market code that is no longer valid in 4.2 (such as AL - Alberta Stock Exchange), will the order/trade still be valid? Or will the client’s OMS perform a lookup from the most recent REX list and kick out this code before submitting the order?
>
> Conversely, if a new code has been added to the REX list in 4.2 (such as BY - Beirut Stock Exchange), will a client and broker communicating under 4.1 be able to use that REX code or are they confined to the set REX codes located in Appendix C?
That’s an interesting question.
While we can all debate protocol compliance until we are blue in the face, one implements a protocol because it allows one to do their business.
If an exchange no longer exists, and a party directs an order to that exchange, regardless of whether the Reuters code is valid for that spec version, the order will be rejected. Whether the engine takes care of it, or the broker’s OMS, isn’t really material.
Similarly, if a new exchange is formed and a Reuters code is assigned, and a broker possesses the capability to route orders to that exchange, I doubt that broker will turn away client order flow until FPL releases a new FIX spec including that Reuters code. Now FIX engines that do strong validation will need to be extended to support the "non-standard" code, but such an extension is required to facilitate doing business.
FIX 4.3 initiated a transition away from Reuters codes towards eliminating the FIX spec as the repository for market identifiers. The preferred 4.3 method for identifying markets is the ISO MIC code. Swift, under ISO’s umbrella, is the repository for MICs. So addition or subtraction of MICs will be applicable to any FIX version >= 4.3, regardless of what MICs existed at the time the FIX spec was released.