Imported from previous forum
We are working on using the FIX protocol to provide broker-to-exchange and exchange-to-exchange links, as opposed to Institution-to-Broker links for which FIX was initially developed. In this scenario the exchange uses an Order Management System (OMS) with a FIX server as a way of providing access to its markets. FIX 4.2 will be used to provide order entry, to report order executions and provide real time market data, security status and market status information (initially for equity markets only).
I have the following questions:
-
Is anyone else using FIX in this way and for this purpose?
-
There does not seem to be a way of letting the FIX client application know whether an order has been accepted by the ‘real’ market or by the OMS. For example, a broker firm sends a New Order message to the exchange, the OMS in the exchange receives the order. Should the OMS generate an Execution Report with Order Status = ‘New’ to confirm it has accepted the order or should it send it only when the order has been accepted by the ‘real’ market. In the first alternative the client application can not distinguish between orders which are only in the OMS and ones which are really in the market. In the second alternative, if the market is not available, the client application does not get the Execution Report until the market re-opens. It seems there is a need for an additional Order Status like ‘New- Accepted by Market’. Status ‘New’ would be sent when the order is accepted by the OMS and ‘New – Accepted by Market’ when it is accepted by the market.
-
The FIX protocol specifies valid values for fields like SecurityType (167), SecurityTradingStatus (326), CorporateAction (292) and TradSesStatus (340). Different exchanges (and different markets within an exchange) support vastly different sets of valid values to that of FIX and to each other. Normalizing market specific values to current FIX valid values is impractical because of the extent of the mismatch. One solution we are considering is to have an optional field ‘MarketSpecificValues’ (char) which when set to ‘Y’ indicates that fields within the message which are documented as supporting ‘market specific values’ will take values that have been agreed to by the two parties. Any better solutions available?
Gabriel Viera
-
Yes there are other present and future cases of this.
-
Maybe you should consider sending OrdStatus = "Pending New" when the order is accepted by OMS and then OrdStatus = "New" when the order has been properly accepted and is being worked/live (in your case accepted by the market).
-
I would recommend communicating unmet or unique requirements to the ECN and Exchanges Working Group.
> We are working on using the FIX protocol to provide broker-to-exchange and exchange-to-exchange links, as opposed to Institution-to-Broker links for which FIX was initially developed. In this scenario the exchange uses an Order Management System (OMS) with a FIX server as a way of providing access to its markets. FIX 4.2 will be used to provide order entry, to report order executions and provide real time market data, security status and market status information (initially for equity markets only).
>
> I have the following questions:
>
> 1. Is anyone else using FIX in this way and for this purpose?
>
> 2. There does not seem to be a way of letting the FIX client application know whether an order has been accepted by the ‘real’ market or by the OMS. For example, a broker firm sends a New Order message to the exchange, the OMS in the exchange receives the order. Should the OMS generate an Execution Report with Order Status = ‘New’ to confirm it has accepted the order or should it send it only when the order has been accepted by the ‘real’ market. In the first alternative the client application can not distinguish between orders which are only in the OMS and ones which are really in the market. In the second alternative, if the market is not available, the client application does not get the Execution Report until the market re-opens. It seems there is a need for an additional Order Status like ‘New- Accepted by Market’. Status ‘New’ would be sent when the order is accepted by the OMS and ‘New – Accepted by Market’ when it is accepted by the market.
>
> 3. The FIX protocol specifies valid values for fields like SecurityType (167), SecurityTradingStatus (326), CorporateAction (292) and TradSesStatus (340). Different exchanges (and different markets within an exchange) support vastly different sets of valid values to that of FIX and to each other. Normalizing market specific values to current FIX valid values is impractical because of the extent of the mismatch. One solution we are considering is to have an optional field ‘MarketSpecificValues’ (char) which when set to ‘Y’ indicates that fields within the message which are documented as supporting ‘market specific values’ will take values that have been agreed to by the two parties. Any better solutions available?
>
> Gabriel Viera
>
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> 1. Is anyone else using FIX in this way and for this purpose?
A good case study of FIX implementation in this environment is the development of ECNs in the US. A sudden change in market regulation created an opportunity for ECNs to form. As many of these systems were new, they didn’t have the burden of legacy systems and protocols. The timing couldn’t have been better; FIX had already evolved into quite a stable, useable, rather widely implemented protocol (FIX 4.0 when the rules were implemented), and ECNs naturally gravitated towards it.
They also have given a lot back to FIX. The ECNs / Exchanges working group has been extremely active, and a good number of the changes in FIX 4.2 were a result of new initiatives in the ECNs / Exchanges group.
> 2. There does not seem to be a way of letting the FIX client application know whether an order has been accepted by the ‘real’ market or by the OMS. For example, a broker firm sends a New Order message to the exchange, the OMS in the exchange receives the order. Should the OMS generate an Execution Report with Order Status = ‘New’ to confirm it has accepted the order or should it send it only when the order has been accepted by the ‘real’ market. In the first alternative the client application can not distinguish between orders which are only in the OMS and ones which are really in the market. In the second alternative, if the market is not available, the client application does not get the Execution Report until the market re-opens. It seems there is a need for an additional Order Status like ‘New- Accepted by Market’. Status ‘New’ would be sent when the order is accepted by the OMS and ‘New – Accepted by Market’ when it is accepted by the market.
FIX generally takes a design philosophy of not dictating what business practices people should take. When routing orders to an Exchange, ECN, or broker, the spec is, in my view, purposefully vague regarding whether one should send the New on receiving the order, or waiting for the liquidity source to acknowledge the order.
I agree that the lack of separate acknowledgment states can be an issue. Personally, I prefer to take the view of waiting until the exchange acks the order; this way, should the order get stuck or lost along the way, the customer will know by lack of a New message.
I agree with what Scott said, that sending Pending New is a good answer to that problem. While I’m tempted to implement it, at the same time the state change diagrams illustrate that this state is only sent on a status request. I’m not sure whether sending it would be FIX compliant. My guess is that one can enable it by bilateral agreement.
> 3. The FIX protocol specifies valid values for fields like SecurityType (167), SecurityTradingStatus (326), CorporateAction (292) and TradSesStatus (340). Different exchanges (and different markets within an exchange) support vastly different sets of valid values to that of FIX and to each other. Normalizing market specific values to current FIX valid values is impractical because of the extent of the mismatch. One solution we are considering is to have an optional field ‘MarketSpecificValues’ (char) which when set to ‘Y’ indicates that fields within the message which are documented as supporting ‘market specific values’ will take values that have been agreed to by the two parties. Any better solutions available?
I wish you had said this just a few weeks before. Widespread implementation of FIX by as many Exchanges and ECNs as possible is something we want, and anything that we can reasonably do to enable this is good.
I disagree that all exchanges and markets cannot agree on mappings to FIX values. For example, SIAC and the CBOE already came forward, and several members of the ECNs / Exchanges working group spent more hours than I care to count working with them to make the specification compatible with what they were trying to do in a way that is general and consistent with the design goals of FIX.
From what I can gather of the process, the preferred approach is to express things in general terms if possible. If that’s not possible, there are examples of exchange-specific values in an enumerated field. If an entire field is exchange-specific, then it generally is left as a custom (5000-9999) field.
While I believe the working group would have been glad to implement additional enumeration values prior to the spec being released, I see a couple options possibly open now:
-
Errata to 4.2. I know adding new fields is out of the question, but I’m wondering if additional values to an existing enumeration would be possible.
-
I wonder if it might be possible for the Technical Committee to pre-approve changes which will be part of the next revision of the spec, and assign real values to them now so that people developing to them won’t have as big a shock in the next version.
[ original email was from Dave Howorth - Dave.Howorth@omgroup.com ]
> I disagree that all exchanges and markets cannot agree on mappings to FIX values. For example, SIAC and the CBOE already came forward, and several members of the ECNs / Exchanges working group spent more hours than I care to count working with them to make the specification compatible with what they were trying to do in a way that is general and consistent with the design goals of FIX. <
It’s notable that both exchanges are in the USA and so subject to the same laws, conventions and expectations. Yet you say it still took “more hours than I care to count” to converge.
Markets in other countries are subject to different laws and local customs, and the convergence problem is much worse if you took two exchanges in different places as examples. And then you have to multiply it by the number of countries and the number of exchanges in those countries.
So I guess that even if it is possible to converge everything, it would take too long. The spirit of FIX seems to be to make something useful in as short a time as possible. I’d say that permitting some variation in this area is the pragmatic way to achieve that.
The level of standardization achieved can likely be increased by taking a lead from the efforts to date of the market data vendors. Even so, they sometimes make compromises to increase standardization at the expense of ultimate accuracy. Exchanges may not be able or willing to compromise when they’re transmitting the data themselves.
Cheers,
Dave Howorth
OM Technology
London
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> It’s notable that both exchanges are in the USA and so subject to the same laws, conventions and expectations. Yet you say it still took “more hours than I care to count” to converge.
>
> Markets in other countries are subject to different laws and local customs, and the convergence problem is much worse if you took two exchanges in different places as examples. And then you have to multiply it by the number of countries and the number of exchanges in those countries.
I’d like to clarify this a bit.
I develop software for an ECN. The first draft of the Market Data specification I wrote over a year ago was more focused on ECN needs, as it is the area I know best. Exchanges are different beasts with different requirements and different rules and regulations. When working with SIAC, we had to tackle transitioning the draft from the ECN to the Exchange world. Yes, both are governed by the SEC, but the differences are quite pronounced, and I would think it comparable to the differences between a US exchange and a non-US exchange.
Further, during these countless hours, a lot more was accomplished. For instance, SIAC used their experience with multicast data distribution to help develop multicast extensions to FIX. Both SIAC, the CBOE, and others (including, I believe, non-US exchanges) worked on developing concepts such as expressing the status of securities and trading sessions, trading halts, and market imbalances. The CBOE, being an options exchange, falls into yet a different category, in that changes in the price of one stock may cause a market maker to reprice numerous bids and offers for related options. This, incidentally, was developed to be similar to other foreign options exchanges.
I guess my point in emphasizing the time wasn’t to imply that the process takes forever, but rather, that people believe in the benefits of FIX enough to invest that kind of time and energy to make it work. I believe that the effort in making different types of US markets (ECNs, Stock Exchanges, and Options Exchanges) covered by the specification is greater than the work to extend from a US stock exchange to a foreign stock exchange.
Further, FIX supports international symbologies. Nothing is stopping non-US exchanges from implementing these new messages, and I have a feeling it would work rather well, with the possible exception of a lack of fields or enumerations, which is easily remedied.
> So I guess that even if it is possible to converge everything, it would take too long. The spirit of FIX seems to be to make something useful in as short a time as possible. I’d say that permitting some variation in this area is the pragmatic way to achieve that.
I think the process of convergence isn’t as complex as you’re implying. It’s just a matter of seeing if any needs the exchange believes are unmet really can be covered by existing functionality, or what new fields or enumeration values, if any, should be added.