re: Book Proposal
John Lopez / eXchange Advantage, Inc.
2 Dec 1999 4:39PM ETFor consolidated feeds, Quotes and quote request need a contributor id field. The contributor specifies the source of each book entry within the quote (ECN, exchange, broker id, quote vendor, wildcard, etc).
Two basic use cases:
1. Snapshot quotes: may extend the current spec to include book depth.
2. Real-time pub/sub semantics.
I think the real-time pub/sub can’t send the full book for each update (if there is a >1 depth). There needs to be a stateful mechanism. I can see a quote request followed by full quote and new update (add) and update (delete). There will also need to be a mechanism to turn off updates.
I used to work at Microsoft on DNAfs for securities. Their STPML (XML securities messaging) is addressing the same problem and working with quote Vendors Bridge and Reuters. There may be value in collaborating with them. Contact Derek LaSalle derekla@microsoft.com.
John
> I've tried to produce a very rough outline of book functionality, leaning more towards abstract terms rather than getting into actual mappings to FIX messages. Given that different ECNs have different policies concerning how much of their book they are willing to display, the protocol should accomodate the different modes.
>
> I've also noticed that these kinds of messages could, in addition to allowing ECNs to communicate their book, optionally be used to provide real-time data (i.e. NASDAQ Level II data, or regional data, as well as simple time and sales / tickers) to trading terminals, and possibly historical data as well. Whether anyone wishes to use FIX in this way, or whether this working group wishes to address this issue, is another thing entirely. I've noted a few simple additions to these messages which would facilitate this.
>
> Existing FIX Quote and IOI messages seem unsuitable for implementing books without extensive changes, and the changes required to make them useable could cause incompatibilities with existing implementations. Thus it might be advantageous to create new message types for handling book queries and real-time book feeds.
>
> Book Types / Attributes:
>
> * Top Of File - only shows best bid, offer, and sizes.
> * Full Book - can show multiple entries per side, but only one per price.
> * Complete - shows full market depth.
> * Truncated - shows just first N price tiers.
> * Trades Only - just show completed trades.
>
> A user should be able to request any of these book attributes. The ECN may choose to support only a subset of these due to technical limitations or policies, and must have the ability [to reject the request.] I am wondering whether any ECN would care to announce individual orders per side per price tier, and if it warrants inclusion in the spec as separate options, i.e. Aggregated vs. Unaggregated.
>
> The Trades Only mode I suggest might be duplicating the purpose of the Advertisement message, but that message doesn't seem to have any way of selectively turning on and off what advertisements you want to receive, or requesting historical trades.
>
> Possible Book Queries:
>
> * Single Symbol
> * List of Symbols
> * All Symbols
> * All Symbols for a list of exchanges
> * All Symbols in an index (i.e. all DJIA stocks, or all S&P500 stocks)
>
> Book Request Modes:
>
> * Request Snapshot for given query
> * Request Snapshot + Turn On Updates for given query
> * Turn Off Updates for given query
> * Request historical data for given query
> * Request historical data + updates for a given query
>
> Book Entry Attributes:
>
> * Type = Bid, Offer, Trade
> * Volume
> * Price
> * Text Tag
> * Time stamp
> * Primary Market Maker (Y/N)
>
> For ECN books, only the Type (Bid/Offer), Volume, and Price would be required. Timestamps could be optional.
>
> For using this type of message to display regional / NQDS data, a text tag could indicate the Market Maker ID, and possibly whether the person in question was a primary market maker for that security. (Would anyone need this info? Should it be sent only once in the snapshot and the client would cache it? Would anyone also need an uptick / downtick indicator?) The Trade type would be used only for Trades Only updates, to provide ticker / time & sales data.
>
> Book Update Functionality:
>
> I would imagine that unlike an IOI, a book update would remain valid up until the time it is somehow refreshed, changed, or removed.
>
> Implementing Top Of File book broadcasts should be relatively straightforward. But full books pose a different problem. I see two approaches:
>
> Each time the book changes, broadcast the full book for a given instrument. The advantage here is it is simple; you get an update for MSFT, throw out your old MSFT book, and replace it with the new book. The disadvantage is that it is extremely wasteful of bandwidth.
>
> The other method is to give each book entry an ID. Then you can correct the price, volume, and possibly timestamp for the ID, or you can drop the entry entirely. This method would require a means of dropping all quotes for a given instrument, or dropping all quotes for all instruments.
>
> I'm guessing the choice of update strategy should be up to the client, subject to the server's approval.
>
> Ryan Pierce
> Townsend Analytics Ltd. / Archipelago LLC
>
