Imported from previous forum
[ original email was from Michael Austin - maustin@dial.pipex.com ]
Is the FIX protocol being considered as a means to standardise the delivery of real-time pricing data from exchanges.
There are hundreds of exchanges around the world and each develops a proprietary protocol and encoding standard to express their trading activity to consumers, most of whom are Financial Data Vendors.
A FIX standard pushed to the exchanges would allow them to utilise an existing protocol sure of the fact that the data vendors would be quick to process the feed and get their data "to market" in a timely and consistant manner. They can also use an underlying transport which is consitant with the telecoms infrastructure within their various countries.
The volume of data originating from the major exchanges will mean that the FIX protocol should be tuned to deliver exchange events (trades, quotes etc.) in a timely and efficient manner.
In essence the exchanges are attempting to replicate the current State of a record (which may translate to a traded entity like "IBM") across all systems interested in in maintaining that record. Each event which causes a change to the state of a record must be represented to each external instance of that record in real time.
FIX should define a set of events which derive from real world trading events, a set of relevant data values for each event and a set of rules which govern the application of those data values to the current state of a record to achieve the new state. The delivery of order book values and competing market maker quotations also fit into this model.
I am in constant contact with various exchanges regarding their system developments and how they should express their data to the outside world, so I am keen to push a standard.
Any comments
Michael
[ original email was from Jem Day - Jem.Day@bglobal.com ]
> Is the FIX protocol being considered as a means to standardise the delivery of real-time pricing data from exchanges.
>
I’m not convinced that FIX is a suitable vehicle
for Exchange price publishing as it’s more of
a point-to-point protocol, rather than broadcast.
I grant you that you can build broadcast over
point-to-point connections but i don’t believe
this is FIX’s aim in life.
Let the discussion commence…
Jem…
[ original email was from Martin McCaig - Martin.McCaig@reuters.com ]
> I’m not convinced that FIX is a suitable vehicle
> for Exchange price publishing as it’s more of
> a point-to-point protocol, rather than broadcast.
Exchange vendor feeds are typically point to point and it’s the vendor that does broadcast price dissemination. Therefore I don’t think FIX should be ruled out as a vendor feed protocol on this basis.
[ original email was from Bob Lamoureux - blamoureux@bridge.com ]
Fix is way to heavyweight for real time market data delivery. The header alone takes up more space than 30 price updates from a standard Bridge feed. I would not consider FIX for this kind of real-time application…
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Fix is way to heavyweight for real time market data delivery. The header alone takes up more space than 30 price updates from a standard Bridge feed. I would not consider FIX for this kind of real-time application…
>
I certainly agree that FIX has quite a lot of overhead. Yes, the FIX header is a problem. Putting each bid or ask change in its own FIX message would not be practical. But if you can pack a whole bunch of price updates in one FIX message, then you’ve decreased the overhead substantially.
I believe I noted in the last working group meeting that the same book messages used by ECNs to distribute their books might possibly be useful for exchanges as well. The questions are those of bandwidth, processing horsepower and latency. Depending on how tight the FIX format is, I’d venture a rough guess that an ECN book could fit on a 56k line, and something like NASDAQ Level II could fit on a T1. The real question comes down to whether the possible latency and definite bandwidth bloat will outweigh the benefits of an open standard for some applications.
Ryan
[ original email was from Martin McCaig - Martin.McCaig@reuters.com ]
> I certainly agree that FIX has quite a lot of
> overhead. Yes, the FIX header is a problem.
> Putting each bid or ask change in its own FIX
> message would not be practical. But if you can
> pack a whole bunch of price updates in one FIX
> message, then you’ve decreased the overhead
> substantially.
Obviously, one doesn’t want to delay updates as a result of some primitive update blocking algorithm. At any moment in time you’re preparing the next message to send. If there is only a single update waiting to go then it should go in a message on its own. If multiple updates are waiting then they should be packed together. In addition to this sort of approach, whose objective is to keep the bandwidth utilised, there are means for compressing and decompressing headers that FIX could adopt.
[ original email was from Michael Austin - michael.austin@dial.pipex.com ]
> Fix is way to heavyweight for real time market data delivery. The header alone takes up more space than 30 price updates from a standard Bridge feed. I would not consider FIX for this kind of real-time application…
> I agree that the FIX protocol is too fat for exchange data delivery and would say that the header contains mostly redundant fields for this type of data.
From an information vendor perspective a lot of time is spent decoding and maintaing the vast array of data feeds from exchanges. It would be far more productive for a standard to be adopted over time which could even be used to collect private contributions from the banking sector also.
The FIX organisation should focus on delivering standards for data interchange between the institutions in the financial sector. One product of this is the current FIX protocol which addresses a particular segment of the industries requirememts. This is not to say that the FIX protocol should be its only product but could deliver further products based on the original standard. The FIX organisation should ultimaltely deliver a family of protocols with a common theme and each designed to cater for specific information delivery and data interchange needs within the financial community, a common format for exchange/contributor data delivery being an example of a specific need.