MarketDataIncrementalRefresh <X> message – FIX 5.0 – FIX Dictionary

Structure | Related Messages

Description

The second Market Data message format is used for incremental updates. Market Data Entries may have an MDEntryID <278> unique among all currently active Market Data Entries so they can be referenced for the purposes of deleting and changing them later. When changing a Market Data Entry, it may keep the same MDEntryID <278>, in which case only MDEntryID <278> would be populated, or the MDEntryID <278> may change, in which case MDEntryID <278> will contain the new ID, and MDEntryRefID <280> will contain the ID of the Market Data Entry being changed. An MDEntryID <278> can be reused within a day only if it has first been deleted.

Alternately, in the case of displaying the best quotes of Market Makers or Exchanges, and not orders in an order book, MDEntryID <278> can be omitted for simplification. In this case, a New Market Data Entry will replace the previous best quote for that side and symbol for the specified Market Maker or Exchange. Deletion of a Market Data Entry would not specify an MDEntryID <278> or MDRefID, and would remove the most recent Market Data Entry for the specified symbol, side, and Market Maker or Exchange. A Change of a Market Data Entry would not specify an MDEntryID <278> or MDRefID, and would replace the most recent Market Data Entry for the specified symbol, side, and Market Maker or Exchange.

The Market Data message for incremental updates may contain any combination of new, changed, or deleted Market Data Entries, for any combination of instruments, with any combination of trades, imbalances, quotes, index values, open, close, settlement, high, low, and VWAP prices, trade volume and open interest so long as the maximum FIX message size is not exceeded. All of these types of Market Data Entries can be changed and deleted.

Adding, Changing, or Deleting Market Data Entries requires special consideration of the MDEntryPositionNo <290> field, if the sender wishes to specify it and the receiver wishes to process it. For example, assume ten bids for a security. Adding a bid with MDEntryPositionNo <290> = 4 requires the receiver to shift down other Market Data Entries, i.e. the Market Data Entry in the 4th display position will shift to the 5th, the 5th shifts to the 6th, etc. until the 10th shifts to the 11th. The sender must NOT send a modification of all MDEntries in the 4th through 10th positions just to update the MDEntryPositionNo <290> field; the recipient must infer the change. Similarly, deleting a Market Data Entry in the 7th position causes the 8th Market Data Entry to move into the 7th position, the 9th to shift into the 8th position, etc. A Change of the MDEntryPositionNo <290> field of a Market Data Entry causes the Market Data Entries lying between the old and new positions to shift. For instance, a Market Data Entry that occupied the 5th position is changed to the 8th position. This means that the Market Data Entry in the 6th position shifts up to the 5th position, the 7th position shifts to the 6th, and what was in the 8th position shifts into the 7th to make room for the changed Market Data Entry that is being moved into the 8th position.

Several techniques are employed to conserve bandwidth:

• An instrument only needs to be identified when a Market Data Entry is first created.
• In cases where the identification of an instrument is long, the sender has the option of referring to a previous active Market Data Entry of the same instrument instead of duplicating the information.
• A new Market Data Entry will default to the same instrument of the previous Market Data Entry in the same Market Data message if neither Symbol <55> nor MDEntryRefID <280> are specified.
• In the case of a change in a Market Data Entry, only the fields changing need to be sent as part of the change to the Market Data Entry; for example, a change of the MDEntrySize <271> but not the MDEntryPx <270> or other attributes of the Market Data Entry only requires listing the MDEntrySize <271> field, in addition to MDUpdateAction <279> and MDEntryID <278> if used in the original Market Data Entry
• When creating a new Market Data Entry with a future or option instrument similar to the instrument in the previous Market Data Entry in the same FIX message, one may send just symbol identification fields that have changed, such as MaturityMonthYear <200>, MaturityDay <205>, StrikePrice <202>, OptAttribute <206>, and SecurityExchange <207>.
• MDEntryID <278> can be reused within the same day after it is deleted. This is helpful for distributing order books because an order that is suspended and then reinstated can have its MDEntryID <278> deleted upon suspension and later reused, with MDUpdateAction <279> = New(0) upon reinstatement, thus avoiding having to re-map the MDEntryID <278>.

Market Data - Incremental Refresh

Structure