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. 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. Unsolicited Market Data messages can be sent; in such cases, MDReqID (262) will not be present.
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. The first Market Data message format used for a Snapshot, or a Snapshot + Updates where MDUpdateType (265) = Full Refresh (0) is as follows:
For Market Data Requests where a Bid or Offer is added, changed, or deleted, every update to a Market Data Entry results in a new Market Data message that contains the entirety of the data requested for that instrument, not just the changed Market Data Entry. In other words, both sides of the market, or just one side in the case of a request of only bids or offers, for the depth requested, must be sent in one FIX Market Data message.
A Market Data message may contain several trades, imbalances, an index value, opening, closing, settlement, high, low, and/or VWAP price for one instrument, as well as the traded volume and open interest, but only one instrument per message.
Messages containing bids and/or offers cannot contain trades, imbalances, index value, opening, closing, settlement, high, low, and/or VWAP prices, trade volume, or open interest as separate entires.
Refreshing Market Data in a Multicast Environment
Dissemination of market data messages in a multicast environment creates an issue that recovery of lost packets is not always feasible using a query method in high message volume situations. The Market Data Snapshot / Full Refresh message can be used to disseminate periodic full snapshots of the data (e.g. order book data). Recipients that join late or otherwise miss packets can get their data aligned by processing the Market Data Snapshots for one complete pass of the instruments.
The snapshot messages will always transmit the market data in the state that it was as of the last incremental refresh message. Snapshots never provide updates and can be ignored in regular processing except in the case of a system failure. Upon system restart the data flow will begin with a snapshot of each instrument. For the most part the recipient cannot ignore these snapshots. However, in some cases the snapshots cannot be ignored by the recipient. The RefreshIndicator (1187) is used to indicate to the recipient of which Snapshot message are redundant and can be ignored, and which are mandatory and must be processed because the message contains new data.
When connecting to the data feed, or after a loss of data, recipients should process Snapshot messages to recover their data, especially if the feed is for orderbook data. Once recovered, recipients can ignore snapshots that have RefreshIndicator = N. If RefreshIndicator = Y then the recipient should discard their data and replace it with the information in the Snapshot message.
See VOLUME 7 - PRODUCT: FOREIGN EXCHANGE section for more detailed usage notes specific to Foreign Exchange.
| Tag | Field Name | FIXML | Req'd | Comments | |||
|---|---|---|---|---|---|---|---|
| <Standard Message Header> | Y | MsgType = W | |||||
| <ApplicationSequenceControl> | N | ||||||
| 911 | TotNumReports | @TotNumRpts | N | Total number or reports returned in response to a request. | |||
| 963 | MDReportID | @RptID | N | Unique indentifier for Market Data Report | |||
| 715 | ClearingBusinessDate | @BizDt | N | ||||
| 1021 | MDBookType | @MDBkTyp | N | Describes the type of book for which the feed is intended. Can be used when multiple feeds are provided over the same connection | |||
| 1173 | MDSubBookType | @MDSubBkTyp | N | Can be used to define a subordinate book. | |||
| 264 | MarketDepth | @MktDepth | N | Can be used to define the current depth of the book. | |||
| 1022 | MDFeedType | @MDFeedTyp | N | Describes a class of service for a given data feed, ie Regular and Market Maker | |||
| 1187 | RefreshIndicator | @RefInd | N | ||||
| 75 | TradeDate | @TrdDt | N | Used to specify the trading date for which a set of market data applies | |||
| 262 | MDReqID | @ReqID | N | Conditionally required if this message is in response to a Market Data Request. | |||
| 1500 | MDStreamID | @MDStrmID | N | ||||
| <Instrument> | Y | Insert here the set of "Instrument" fields defined in "Common Components of Application Messages". | |||||
| <UndInstrmtGrp> | N | Number of underlyings | |||||
| <InstrmtLegGrp> | N | Required for multileg quotes | |||||
| 291 | FinancialStatus | @FinclStat | N | ||||
| 292 | CorporateAction | @CorpActn | N | ||||
| 451 | NetChgPrevDay | @NetChgPrevDay | N | ||||
| <MDFullGrp> | Y | Number of entries following. | |||||
| 813 | ApplQueueDepth | @ApplQuDepth | N | Depth of application messages queued for transmission as of delivery of this message | |||
| 814 | ApplQueueResolution | @ApplQuResolution | N | Action taken to resolve application queuing | |||
| <RoutingGrp> | N | ||||||
| <Standard Message Trailer> | Y | ||||||
© 2026.
EPAM Systems. All Rights Reserved.
All material contained within the website is copyright of EPAM Systems, Inc. No material contained herein can be copied or otherwise used without the express permission of the copyright holder.