FIX 4.4 : Market Data - Incremental Refresh <X> message

Structure | Related Messages

Description

The Market Data messages are used as the response to a Market Data Request <V> message. In all cases, one Market Data message refers only to one Market Data Request <V>. It can be used to transmit a 2-sided book of orders or list of quotes, a list of trades, index values, opening, closing, settlement, high, low, or VWAP prices, the trade volume or open interest for a security, or any combination of these.

Market Data messages sent as the result of a Market Data Request <V> message will specify the appropriate MDReqID <262>. Unsolicited Market Data messages can be sent; in such cases, MDReqID <262> will not be present.

If the message is used for foreign exchange, conventions for identifying the forex transaction are as follows:

  • The forex Symbol <55> is defined in Electronic Broking Services, Ltd. (see http://www.ebs.com) format: "CCY1/CCY2".
    • Rates are expressed as "currency1 in currency2" (or "currency2 per currency1") and are calculated as CCY2 divided by CCY1 (NOT CCY1 divided by CCY2)
    • e.g. "GBP/USD" represents a rate expressed as USD per GBP, "USD/JPY" represents a rate expressed as JPY per USD, etc.).
    • CCY1 and CCY2 are ISO currency codes
  • The value of the Currency <15> field represents the denomination of the Quantity <53> fields (e.g. JPY represents quantity of JPY).
  • See VOLUME 7 - PRODUCT: FOREIGN EXCHANGE

Market Data messages include many fields, and not all are required to be used. A firm may, at its option, choose to send the minimum fields required, or may choose to send more information, such as tick direction, tagging of best quotes, etc.

Market Data messages can take two forms:

  1. Full Refresh (see Market Data - Snapshot/Full Refresh <W> message)
  2. Incremental Refresh (Market Data - Incremental Refresh <X> message)

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 MDEntryRefID <280>, 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 MDEntryRefID <280>, 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>='0'(New) upon reinstatement, thus avoiding having to re-map the MDEntryID <278>.

Structure

Tag Field Name Req'd Comments
<MessageHeader> Y MsgType <35> = X
262 MDReqID N

Conditionally required if this message is in response to a Market Data Request <V>.

268 NoMDEntries Y

Number of entries following.

=> 279 MDUpdateAction Y

Must be first field in this repeating group.

=> 285 DeleteReason N

If MDUpdateAction <279> ='2'(Delete), can be used to specify a reason for the deletion.

=> 269 MDEntryType N

Conditionally required if MDUpdateAction <279> ='0'(New). Cannot be changed.

=> 278 MDEntryID N

If specified, must be unique among currently active entries if MDUpdateAction <279> ='0'(New), must be the same as a previous MDEntryID <278> if MDUpdateAction <279> ='2'(Delete), and must be the same as a previous MDEntryID <278> if MDUpdateAction <279> ='1'(Change) and MDEntryRefID <280> is not specified, or must be unique among currently active entries if MDUpdateAction <279> ='1'(Change) and MDEntryRefID <280> is specified.

=> 280 MDEntryRefID N

If MDUpdateAction <279> ='0'(New), for the first Market Data Entry in a message, either this field or a Symbol <55> must be specified. If MDUpdateAction <279> ='1'(Change), this must refer to a previous MDEntryID <278>.

=> Component Block - <Instrument> N

Insert here the set of "<Instrument>" (symbology) fields

Either Symbol <55> (the <Instrument> component block) or MDEntryRefID <280> must be specified if MDUpdateAction <279> ='0'(New) for the first Market Data Entry in a message. For subsequent Market Data Entries where MDUpdateAction <279> ='0'(New), the default is the instrument used in the previous Market Data Entry if neither Symbol <55> nor MDEntryRefID <280> are specified, or in the case of options and futures, the previous instrument with changes specified in MaturityMonthYear <200>, MaturityDay <205>, StrikePrice <202>, OptAttribute <206>, and SecurityExchange <207>. May not be changed.

=> 711 NoUnderlyings N

Number of underlyings

=> => Component Block - <UnderlyingInstrument> N

Must be provided if Number of underlyings > 0

=> 555 NoLegs N

Required for multileg quotes

=> => Component Block - <InstrumentLeg> N

Required for multileg quotes

For Swaps one leg is Buy and other leg is Sell

=> 291 FinancialStatus N
=> 292 CorporateAction N
=> 270 MDEntryPx N

Conditionally required when MDUpdateAction <279> ='0'(New) and MDEntryType <269> is not 'A'(Imbalance), 'B'(Trade Volume), or 'C'(Open Interest).

=> 15 Currency N

Can be used to specify the currency of the quoted price.

=> 271 MDEntrySize N

Conditionally required when MDUpdateAction <279> ='0'(New) andMDEntryType <269> ='0'(Bid), '1'(Offer), '2'(Trade), 'B'(Trade Volume), or 'C'(Open Interest).

=> 272 MDEntryDate N
=> 273 MDEntryTime N
=> 274 TickDirection N
=> 275 MDMkt N

Market posting quote / trade.

Valid values: see Appendix 6-C

=> 336 TradingSessionID N
=> 625 TradingSessionSubID N
=> 276 QuoteCondition N

Space-delimited list of conditions describing a quote.

=> 277 TradeCondition N

Space-delimited list of conditions describing a trade

=> 282 MDEntryOriginator N
=> 283 LocationID N
=> 284 DeskID N
=> 286 OpenCloseSettlFlag N

Used if MDEntryType <269> = '4'(Opening Price), '5'(Closing Price), or '6'(Settlement Price).

=> 59 TimeInForce N

For optional use when this Bid or Offer represents an order

=> 432 ExpireDate N

For optional use when this Bid or Offer represents an order. ExpireDate <432> and ExpireTime <126> cannot both be specified in one Market Data Entry.

=> 126 ExpireTime N

For optional use when this Bid or Offer represents an order. ExpireDate <432> and ExpireTime <126> cannot both be specified in one Market Data Entry.

=> 110 MinQty N

For optional use when this Bid or Offer represents an order

=> 18 ExecInst N

Can contain multiple instructions, space delimited.

=> 287 SellerDays N
=> 37 OrderID N

For optional use when this Bid, Offer, or Trade represents an order

=> 299 QuoteEntryID N

For optional use when this Bid, Offer, or Trade represents a quote

=> 288 MDEntryBuyer N

For optional use in reporting Trades

=> 289 MDEntrySeller N

For optional use in reporting Trades

=> 346 NumberOfOrders N

In an Aggregated Book, used to show how many individual orders make up an MDEntry

=> 290 MDEntryPositionNo N

Display position of a bid or offer, numbered from most competitive to least competitive, per market side, beginning with 1

=> 546 Scope N
=> 811 PriceDelta N
=> 451 NetChgPrevDay N
=> 58 Text N

Text to describe the Market Data Entry. Part of repeating group.

=> 354 EncodedTextLen N

Must be set if EncodedText <355> field is specified and must immediately precede it.

=> 355 EncodedText N

Encoded (non-ASCII characters) representation of the Text <58> field in the encoded format specified via the MessageEncoding <347> field.

=> 355 EncodedText N

Encoded (non-ASCII characters) representation of the Text <58> field in the encoded format specified via the MessageEncoding <347> field.

813 ApplQueueDepth N

Depth of application messages queued for transmission as of delivery of this message

814 ApplQueueResolution N

Action taken to resolve application queuing

<MessageTrailer> Y

 

Related Messages