Pre-trade messaging is characterized as messages which are typically communicated prior to the placement of an order.

The specific FIX pre-trade messaging categories are:


Descriptions of the specific FIX pre-trade application messages follow.

List of Component Blocks and Messages for Pre-Trade

Component Blocks

This section lists component blocks used by pre-trade messages defined in this part of the FIX specification. Some of these are Common Component blocks used by more than one category in this area. Messages may also reference Global Component blocks, which are components used by messages across all areas. Global Common Components are defined in the overall introduction to the FIX specification as well as online.

NOTE: If you are reading this as a document then detailed component and message layouts are available in the appendix. If you are reading the online version or wish to go there then detailed component and message layouts are available here.

Component blocks can be either repeating (aka a group) or non-repeating, i.e. contain multiple instances of a set of fields. Component blocks can be nested to any level.

Type Name Category
Non-Repeating BaseTradingRules Common
Repeating DerivativeEventsGrp SecuritiesReferenceData
Non-Repeating DerivativeInstrument SecuritiesReferenceData
Repeating DerivativeInstrumentAttribute SecuritiesReferenceData
Repeating DerivativeInstrumentParties SecuritiesReferenceData
Repeating DerivativeInstrumentPartySubIDsGrp SecuritiesReferenceData
Repeating DerivativeSecurityAltIDGrp SecuritiesReferenceData
Non-Repeating DerivativeSecurityDefinition SecuritiesReferenceData
Non-Repeating DerivativeSecurityXML SecuritiesReferenceData
Repeating ExecInstRules Common
Repeating InstrmtLegIOIGrp Indication
Repeating InstrmtLegSecListGrp SecuritiesReferenceData
Repeating InstrmtMDReqGrp MarketData
Repeating IOIQualGrp Indication
Repeating LeqQuotGrp QuotationNegotiation
Repeating LegQuotStatGrp QuotationNegotiation
Repeating LinesOfTextGrp EventCommunication
Repeating LotTypeRules Common
Repeating MarketDataFeedTypes Common
Repeating MarketSegmentGrp SecuritiesReferenceData
Repeating MatchRules Common
Repeating MaturityRules SecuritiesReferenceData
Repeating MDFullGrp MarketData
Repeating MDIncGrp MarketData
Repeating MDReqGrp MarketData
Repeating MDRjctGrp MarketData
Repeating NestedInstrumentAttribute SecuritiesReferenceData
Repeating NewsRefGrp EventCommunication
Repeating OrdTypeRules Common
Non-Repeating PriceLimits Common
Repeating QuotCxlEntriesGrp QuotationNegotiation
Repeating QuoteEntryAckGrp QuotationNegotiation
Repeating QuotEntryGrp QuotationNegotiation
Repeating QuotQualGrp QuotationNegotiation
Repeating QuotReqGrp QuotationNegotiation
Repeating QuotReqLegsGrp QuotationNegotiation
Repeating QuotReqRjctGrp QuotationNegotiation
Repeating QuotSetAckGrp QuotationNegotiation
Repeating QuotSetGrp QuotationNegotiation
Repeating RelSymDerivSecGrp SecuritiesReferenceData
Repeating RelSymDerivSecUpdGrp SecuritiesReferenceData
Repeating RFQReqGrp QuotationNegotiation
Repeating RoutingGrp Common
Repeating SecListGrp SecuritiesReferenceData
Repeating SecLstUpdRelSymGrp SecuritiesReferenceData
Repeating SecLstUpdRelSymsLegGrp SecuritiesReferenceData
Non-Repeating SecondaryPriceLimits SecuritiesReferenceData
Repeating SecSizesGrp MarketData
Repeating SecTypesGrp SecuritiesReferenceData
Non-Repeating SecurityTradingRules SecuritiesReferenceData
Repeating StatsIndGrp MarketData
Repeating StrikeRules SecuritiesReferenceData
Repeating StrmAsgnReqGrp MarketData
Repeating StrmAsgnRptGrp MarketData
Repeating StrmAsgnReqInstrmtGrp MarketData
Repeating StrmAsgnRptInstrmtGrp MarketData
Repeating TickRules Common
Repeating TimeInForceRules Common
Non-Repeating TradingSessionRules Common
Repeating TradingSessionRulesGrp SecuritiesReferenceData
Repeating TrdSessLstGrp MarketStructureReferenceData


This section lists the pre-trade messages and the single category each of them belongs to.

MsgType(35) Name Category
7 Advertisement Indication
6 IOI Indication
C Email EventCommunication
B News EventCommunication
i MassQuote QuotationNegotiation
b MassQuoteAcknowledgement QuotationNegotiation
S Quote QuotationNegotiation
Z QuoteCancel QuotationNegotiation
R QuoteRequest QuotationNegotiation
AG QuoteRequestReject QuotationNegotiation
AJ QuoteResponse QuotationNegotiation
AI QuoteStatusRequest QuotationNegotiation
a QuoteStatusReport QuotationNegotiation
AH RFQRequest QuotationNegotiation
X MarketDataIncrementalRefresh MarketData
V MarketDataRequest MarketData
Y MarketDataRequestReject MarketData
W MarketDataSnapshotFullRefresh MarketData
CD StreamAssignmentReport MarketData
CE StreamAssignmentReportACK MarketData
CC StreamAssignmentRequest MarketData
AA DerivativeSecurityList SecuritiesReferenceData
z DerivativeSecurityListRequest SecuritiesReferenceData
BR DerivativeSecurityListUpdateReport SecuritiesReferenceData
d SecurityDefinition SecuritiesReferenceData
c SecurityDefinitionRequest SecuritiesReferenceData
BP SecurityDefinitionUpdateReport SecuritiesReferenceData
y SecurityList SecuritiesReferenceData
x SecurityListRequest SecuritiesReferenceData
BK SecurityListUpdateReport SecuritiesReferenceData
f SecurityStatus SecuritiesReferenceData
e SecurityStatusRequest SecuritiesReferenceData
v SecurityTypeRequest SecuritiesReferenceData
w SecurityTypes SecuritiesReferenceData
BU MarketDefinition MarketStructureReferenceData
BT MarketDefinitionRequest MarketStructureReferenceData
BV MarketDefinitionUpdateReport MarketStructureReferenceData
BJ TradingSessionList MarketStructureReferenceData
BI TradingSessionListRequest MarketStructureReferenceData
BS TradingSessionListUpdateReport MarketStructureReferenceData
h TradingSessionStatus MarketStructureReferenceData
g TradingSessionStatusRequest MarketStructureReferenceData

Category – Indication



Advertisement messages are used to announce completed transactions. The Advertisement(35=7) message can be transmitted in various transaction types; NEW, CANCEL and REPLACE with AdvTransType(5). All transaction types other than NEW modify the state of a previously transmitted advertisement identified in AdvRefID(3).

Indications of Interest

Indication of interest messages are used to market merchandise which the broker is buying or selling in either a proprietary or agency capacity. The indications can be time bound with a specific expiration value. Indications are distributed with the understanding that other firms may react to the message first and that the merchandise may no longer be available due to prior trade.

IOI(35=6) messages can be transmitted in various transaction types; NEW, CANCEL, and REPLACE with IOITransType(28). All transaction types other than NEW modify the state of the message identified in IOIRefID(26).

Category Event Communication



News messages are general, free format messages between the broker and institution. The message contains flags to identify the news item’s urgency and to allow sorting by subject company (symbol). The News(35=B) message can be originated at either the broker or institution side, or exchanges and other marketplace venues.

The news message also provides the capability to support categorization of news being published. This allows the news to be filtered by the news consumer. For example:

  • Exchanges may need to provide the MarketID(1301) and MarketSegmentID(1302) so users can filter news to the segments that are of relevance for them.
  • In multi-lingual environments, news may be published in a variety of languages; a user should be able to filter out messages in irrelevant languages by defining a specific language with LanguageCode(1474).
  • By providing a categorization of the News messages with NewsCategory(1473), users can choose how to render them in different GUIs or ignore certain categories altogether.

Additionally, news messages allow news to reference one or more other news messages with the NewsRefGrp component. When a message references another one with NewsRefID(1476), it may also need to provide the reason for the reference with NewsRefType(1477)- e.g. an update of the previous message, a complement or simply that it is a version in another language.


The Email(35=C) message is similar to the format and purpose of the News(35=B) message. However, it is intended for private use between two parties.

Category – Quotation / Negotiation

The quotation messages fall into two main sub-categories – those used for quoting in single instruments ‘Single product quoting’ and those used to quote on multiple instruments such as option series – ‘Mass quoting’

Within the ‘Single product quoting’ suite of messages, three business models have been identified

  • Indicative quoting – the predominant business model for retail quoting, where the expected response to a quote is a ‘previously quoted’ order which may be accepted or rejected. In the retail model the quote may be preceded by a QuoteRequest(35=R) message.
  • Tradeable quoting – a model where the response to a quote may be an execution (rather than an order). A common model where participants are posting quotes to an exchange. The Quote(35=S) message may be issued in response to a QuoteRequest(35=R) in a ‘quote on demand’ market.
  • Restricted tradeable quoting – as per tradeable quoting but the response to a quote may be either an execution or an order depending on various parameters.

The Negotiation (a.k.a. counter quoting) dialog is also supported. The Negotiation dialog may begin with either an indicative quote or a tradeable quote.

The common thread linking the models is the use of the Quote(35=S) message.


Quote Requests

In some markets it is the practice to request quotes from brokers prior to placement of an order. The QuoteRequest(35=R) message is used for this purpose. This message is commonly referred to as an RFQ (Request For Quote).

Quotes can be requested on specific securities, on specified stipulations when the specific security is not known or forex rates. The QuoteRequest(35=R) message can be used to request quotes on single products or multiple products.

Securities quotes can be requested as either market quotes or for a specific quantity and side. If OrderQty(38) and Side(54) are absent, a market-style quote (bid x offer, size x size) will be returned.

In the tradeable and restricted tradeable quote models the QuoteRequest(35=R) message may be preceded by the RFQRequest(35=AH) message described further below.

For tradeable quote requests it is possible to specify the time period in which the request is valid for with ExpireTime(126) and the time period which the resulting quote must be valid for with ValidUntilTime(62).

Quote Responses

The QuoteResponse(35=AJ) message is used to respond to an IOI(35=6) message or Quote(35=S) message. It is also used to counter a quote or end a negotiation dialog.

Quote Request Rejections

The QuoteRequestReject(35=AG) message is used to reject QuoteRequest(35=R) messages for all quoting models.

RFQ Requests

In tradeable and restricted tradeable quoting markets – QuoteRequest(35=R) messages are issued by counterparties interested in ascertaining the market for an instrument. QuoteRequest(35=R) messages are then distributed by the market to liquidity providers who make markets in the instrument. The RFQRequest(35=AH) message is used by liquidity providers to indicate to the market for which instruments they are interested in receiving quote requests. It can be used to register interest in receiving quote requests for a single instrument or for multiple instruments

Tradeable Quote Model – Using the RFQ Request

In the quote on demand model – markets are not necessarily available until someone interested in the market generates a request. The model involves two parties and a market. The second party, usually a market maker or specialist, starts the workflow by issuing an RFQRequest(35=AH) message to the market. This starts a subscription to QuoteRequest(35=R) messages for instruments in which the party is interested in making markets.

The first party issues QuoteRequest(35=R) messages to the market for specific instruments which are distributed to appropriate subscribers, i.e. the second party then receives these quote requests from the market. The second party can then respond with Quote(35=S) messages in response to the quote requests. Quote(35=S) messages result in changes to the market – causing market data to be distributed.


The Quote(35=S) message is used as the response to a QuoteRequest(35=R) or a QuoteResponse(35=AJ) message in both indicative, tradeable, and restricted tradeable quoting markets.

In tradeable and restricted tradeable quoting models, the market maker sends quotes into a market as opposed to sending quotes directly to a counterparty.

For Fixed Income in the indicative and tradeable quoting models, the quotes are typically sent directly to an interested counterparty as opposed to a market place.

The Quote(35=S) message can be used to send unsolicited quotes in both indicative, tradeable, and restricted tradeable quoting markets.

The Quote(35=S) message contains a quote for a single product.

If the issuer of the quote requires a response (i.e. notification that the quote has been accepted) then the QuoteResponseLevel(301) should be populated on the Quote(35=S) message – the response would be made using the QuoteStatusReport(35=AI) message.

The Quote(35=S) message should not be used in tradeable and restricted tradeable quoting markets, such as electronic trading systems, to broadcast quotes to market participants. The recommended approach to reporting market state changes that result from quotes received by a market is to use the FIX market data messages.

Quotes supplied as the result of a QuoteRequest(35=R) message will specify the appropriate QuoteReqID(131), unsolicited quotes can be identified by the absence of a QuoteReqID(131).

Orders can be generated based on quotes. Quoted orders include the QuoteID(117) and have OrdType(40) = D (Previously Quoted).

The TimeInForce(59) value for a quote is determined by agreement between counterparties.

A quote can be cancelled either using the QuoteCancel(35=Z) message or by sending a Quote(35=S) message with bid and offer prices and sizes all set to zero (BidPx(132), OfferPx(133), BidSize(134), OfferSize(135)).

Quote Cancellations

The QuoteCancel(35=Z) message is used by an originator of quotes to cancel quotes.

The QuoteCancel(35=Z) message supports cancellation of:

  • All quotes
  • Quotes for a specific Symbol(55) or SecurityID(48)
  • All quotes for a SecurityType(167)
  • All quotes for one or more underlying instruments (UndInstrmtGrp component)

Canceling a quote is accomplished by indicating the type of cancellation with QuoteCancelType(298).

It is recommended that all QuoteCancel(35=Z) messages be acknowledged using the QuoteStatusReport(35=AI) message.

The quote cancellation only applies to quotes made by the current FIX user.

Options usage notes:

Normal usage would be to cancel the quotes for a Symbol(55). This is the reason that the use of further nesting similar to the Quote(35=S) message is not used in this message. You are able to cancel quotes for specific series by specifying each option series in the QuotCxlEntriesGrp component which is a repeating group.

Quote Status Requests

The QuoteStatusRequest(35=a) message is used for the following purposes in markets that employ tradeable or restricted tradeable quotes:

  • For the issuer of a quote in a market to query the status of that quote (using the QuoteID(117) to specify the target quote).
  • To subscribe and unsubscribe for QuoteStatusReport(35=AI) messages for one or more securities with SubscriptionRequestType(263) and the Instrument component.

Application of QuoteStatusRequest(35=a) messages to options markets using tradeable or restricted tradeable quoting models:

To retrieve status of all quotes for a given underlying symbol for options, enter the Symbol(55) and optionally the SecurityType(167) along with a CFICode(537)=“OXXXXX”.

Quote Status Reports

The QuoteStatusReport(35=AI) message is used:

  • as the response to a QuoteStatusRequest(35=a) message
  • as a response to a QuoteCancel(35=Z) message
  • as a response to a QuoteResponse(35=AJ) message in a negotiation dialog

Mass Quotes

The MassQuote(35=i) message can contain quotes for multiple securities to support applications that allow for the mass quoting of an option series. Two levels of repeating groups have been provided to minimize the amount of data required to submit a set of quotes for a class of options (e.g. all option series for IBM).

The quote set (QuotSetGrp component) specifies the first level of repeating fields for the MassQuote(35=i) message. It represents a group of related quotes and can, for example, represent an option class.

Each quote set contains an optional repeating group of quote entries (QuotEntryGrp component) which can represent an option series.

It is possible that the number of quote entries for a quote set (option class) exceeds one’s physical or practical message size. It may be necessary to fragment a message across multiple MassQuote(35=i) messages with LastFragment(893). Message size limits must be mutually agreed to with one’s counterparties.

The grouping of quotes is as follows:

  • NoQuoteSets(296) – specifies the number of sets of quotes contained in the message
    • QuoteSetID(302) – Is a unique ID given to the quote set
    • Information regarding the security to which all of the quotes belong
    • TotNoQuoteEntries(304) – defines the number of quotes for the quote set across all messages
    • LastFragment(893) – identifies the last physical message for a given quote set identified by QuoteSetID(302)
    • NoQuoteEntries(295) – defines the number of quotes contained within this message for this quote set
      • QuoteEntryID(299) – Is a unique ID given to a specific quote entry
      • Information regarding the specific quote (bid/ask size and price)

If there are too many quote entries for a quote set to fit into one physical message, then the quotes can be continued in another MassQuote(35=i) message by repeating all of the quote set information and then specifying the number of quote entries (related symbols) in the continued message. TotNoQuoteEntries(304) is provided to optionally indicate to the counterparty the total number of quote entries for a quote set in multiple quote messages. This permits, but does not require, a receiving application to react in a stateful manner where it can determine if it has received all quotes for a quote set before carrying out some action. However, the overall approach to fragmentation is to permit each mass quote message to be processed in a stateless manner as it is received. Each mass quote message should contain enough information to have the quote entries applied to a market without requiring the next message if fragmentation has occurred. Also, a continued message should not require any information from the previous message.

Maximum message size for fragmentation purposes can be determined by using the optional field MaxMessageSize(383) in the Logon(35=A) message or by mutual agreement between counterparties.

Requesting Acknowledgement for Mass Quotes

Applications can optionally support acknowledgement of quotes using the field QuoteResponseLevel(301). It is used to specify the level of acknowledgement requested from the counterparty. QuoteResponseLevel(301) = 0 indicates that no acknowledgement is requested. A response level of 1 requests acknowledgement of invalid or erroneous quotes. A response level of 2 requests acknowledgement of each MassQuote(35=i) message.

Mass Quote Acknowledgments

The MassQuoteAck(35=b) message is used as the application level response to a MassQuote(35=i) message. The MassQuoteAck(35=b) message contains a field QuoteRejectReason(300) for reporting the reason in the event that the entire quote is rejected. The MassQuoteAck(35=b) message also contains a field QuoteEntryRejectReason(368) for each quote that is used in the event that the quote entry is rejected. The ability to reject an individual quote entry is important so that the majority of quotes can be successfully applied to the market instead of having to reject the entire MassQuote(35=i) message for a minority of rejected quotes.

Derivative markets are characterized by high bandwidth consumption – due to a change in an underlying security price causing multiple (often in the hundreds) of quotes to be recalculated and retransmitted to the market. For that reason the ability for market participants (and the market) to be able to set the level of response requested to a MassQuote(35=i) message is specified using the field QuoteResponseLevel(301).

Category – Market Data


Market Data Requests

Some systems allow the transmission of real-time quote, order, trade, trade volume, open interest, and/or other price information on a subscription basis. A MarketDataRequest(35=V) is a general request for market data on specific securities or forex quotes.

A successful MarketDataRequest(35=V) returns one or more market data messages containing one or more market data entries. Each market data entry is a bid, an offer, a trade associated with a security, the opening, closing, or settlement price of a security, the buyer or seller imbalance for a security, the value of an index, the trading session high price, low price, or VWAP, or the trade volume or open interest in a security. Market data entries usually have a price and a quantity associated with them. For example, in an order book environment, requesting just the top of book will result in only two active market data entries at a time – one for the best Bid and one for the best Offer. For a full book, the Bid and Offer side may each have several market data entries. Each market data entry might represent an aggregate for each price tier, and only one market data entry per side per price would be active at a time. This is referred to as an aggregated book. When several market data entries at one price tier could each represent a broker, market maker, ECN or exchange’s quote in a security, or individual orders in a book, this is a non-aggregated book. Alternately, a market data entry could represent a completed trade in a security, the value of an index, the opening, closing, or settlement price of an instrument, the trading session high price, low price, or VWAP, or the volume traded or open interest in a security.

If the message is used for disseminating imbalance information, conventions are as follows:

  • MDEntrySize(271) represents the size of the imbalance and is always a positive integer.
  • A TradeCondition(277) of either P or Q is required to indicate the side of the imbalance.
  • Markets may wish to indicate the presence of an imbalance but not the actual size. In this case, MDEntrySize(271) need not be specified.

One specifies whether a list of trades, a 1-sided or 2-sided book, index, opening, closing, settlement, high, low and VWAP prices and imbalance volumes should be returned by using the MDReqGrp repeating group to list all MDEntryType(269) values that should be returned.

Types of Market Data Requests

  1. A market data feed may consist of both MarketDataSnapshotFullRefresh(35=W) messages and MarketDataIncrementalRefresh(35=X) messages.
  2. The MarketDataRequest(35=V) message is used to request a static book snapshot or subscribe to a stream of snapshots and updates.
  3. The MarketDataSnapshotFullRefresh(35=W) message should be used to provide a snapshot of the market when snapshot is requested using SubscriptionRequestType(263) = 0. Use of MarketDataIncrementalRefresh(35=X) is being discouraged for this purpose.
  4. The MarketDataSnapshotFullRefresh(35=W) message will be used to provide initial snapshot when snapshot plus updates are requested using SubscriptionRequestType(263) = 1.
  5. The market data request scenarios that will be supported are as follows:
Customer Requests Subscription RequestType (263) MDUpdateType (265) Response Messages
Requests state of the book and receives one and only one snapshot for each request (i.e. customer only wants single snapshot of prices) 0=Snapshot Not Provided (customer is not requesting a subscription) MarketDataSnapshot-FullRefresh(35=W) message (only one message is sent)
Requests state of the book + updates and specifies that only MarketDataSnapshotFullRefresh(35=W) message is used (i.e. full refresh update of data is to be sent) 1 = Snapshot + Updates 0 = Full Refresh MarketDataSnapshot-FullRefresh(35=W) messages only
Requests state of the book + updates and specifies that updates are to be sent using MarketDataIncrementalRefresh(35=X) message (i.e. incremental updates on data is to be sent) 1 = Snapshot + Updates 1 = Incremental Refresh MarketDataSnapshot-FullRefresh(35=W) message with updates provided using MarketDataIncremental-Refresh(35=X) messages

Indicating an Empty Book

  1. An empty book contains no bids or asks and indicates that the market has no open orders in a given instrument. This can also be referred to as a “null” book.
  2. When this occurs in a scenario in which the MarketDataSnapshotFullRefresh(35=W) message is being used to provide a static snapshot or snapshot + updates then MDEntryType(269) = J (Null Market) should be used.
  3. The MarketDataSnapshotFullRefresh(35=W) message should contain a single market data entry with MDEntryType (269) = J specified. MDEntryPrice(270) = 0 and MDEntrySize(271) = 0 may also be provided but are not required. Other tags may be specified as well in order to convey the time and conditions under which the market generated a null book.

Indicating a Crossed Book

  1. If MDBookType(1021) = 1 (Top-of-Book) or 2 (Price Depth), this indicates that the market is crossed.
  2. If MDBookType(1021) = 3 (Order Depth), this indicates that the (order) entry is associated with conditions that can cause the book to lock or be locked or crossed. Such conditions include quantity conditions like All-Or-None (ExecInst(18) = G (AON)), minimum quantity (MinQty(110)) and minimum quantity per execution (MatchIncrement(1089)) but also counterparty conditions such as Acceptable or Unacceptable Counterparty (PartyRole(452) = 56 or 57). In case such orders are included in the same book feed as normal orders, the user may choose to display crossed orders in a separate book view or indicate the “crossed” fact in another way.

While this document specifies many parameters and modes in a request, the recipient of the request is not required to support all of them. A MarketDataRequestReject(35=Y) message may be sent in response to a request indicating that it cannot be honored.

Market Data – Snapshot / Full Refresh

MarketDataSnapshotFullRefresh(35=W) messages are used as response to a MarketDataRequest(35=V) message and provide a market data snapshot. In all cases, one MarketDataSnapshotFullRefresh(35=W) message refers only to one MarketDataRequest(35=V) message. 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 snapshots sent as the result of a MarketDataRequest(35=V) message will specify the appropriate MDReqID(262). Unsolicited market data snapshots can be sent; in such cases, MDReqID(262) will not be present.

Market data snapshots 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 snapshots can take two forms. The first format used for a snapshot, or a snapshot plus updates where MDUpdateType(265) = 0 (Full Refresh) 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 MarketDataSnapshotFullRefresh(35=W) 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 only offers, for the depth requested, must be sent in one market data snapshot.
  • A market data snapshot 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.
  • Market data snapshots 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 entries.

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 MarketDataSnapshotFullRefresh(35=W) 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 snapshots for one complete pass of the instruments.

The MarketDataSnapshotFullRefresh(35=W) messages will always transmit the market data in the state that it was as of the last MarketDataIncrementalRefresh(35=X) 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 can be ignored by the recipient. The RefreshIndicator(1187) is used to indicate to the recipient, which of the MarketDataSnapshotFullRefresh(35=W) messages is 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 snapshots to recover their data, especially if the feed is for orderbook data. Once recovered, recipients can ignore snapshots that have RefreshIndicator(1187) = N. If RefreshIndicator(1187) = Y then the recipient should discard their data and replace it with the information in the snapshot.

Market Data – Incremental Refresh

The second market data message, MarketDataIncrementalRefresh(35=X), 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 MarketDataIncrementalRefresh(35=X) message 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 MDEntryPositionNo(290), 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 market data entries in the 4th through 10th positions just to update MDEntryPositionNo(290); 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 MDEntryPositionNo(290) 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 MarketDataIncrementalRefresh(35=X) message if neither Symbol 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 MDEntrySize(271) but not MDEntryPx(270) or other attributes of the market data entry only requires listing MDEntrySize(271), 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 MarketDataIncrementalRefresh(35=X) message, one may send just instrument identification fields that have changed, such as MaturityMonthYear(200), MaturityDay(541), 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).

Market Data Request Rejections

The MarketDataRequestReject(35=Y) message is used when the broker cannot honor the MarketDataRequest(35=V) message due to business or technical reasons. Brokers may choose to limit various parameters, such as the size of requests, whether just the top of book or the entire book may be displayed, and whether full or incremental updates must be used.

Stream Assignment Requests

In certain markets where market data aggregators fan out to end clients the pricing streams provided by the price makers, the price maker may assign the clients to certain pricing streams that the price maker publishes via the aggregator. An example of this use is in the FX markets where clients may be assigned to different pricing streams based on volume bands and currency pairs.

The stream assignment messages facilitate the automation of assigning clients to specific price streams by the price makers and allow the price maker to notify the aggregator of these assignments.

The StreamAssignmentRequest(35=CC) message is used by the aggregator and sent to the price maker to request stream assignments for one or more clients. The response to this message is the StreamAssignmentReport(35=CD).

Stream Assignment Reports

The StreamAssignmentReport(35=CD) message is in response to the StreamAssignmentRequest(35=CC) message. It provides information back to the aggregator as to which clients to assign to receive which price stream based on requested CCY pair. This message can be sent unsolicited to the aggregator from the price maker.

Stream Assignment Report Acknowledgements

The StreamAssignmentReportACK(35=CE) message is used to respond to the StreamAssignmentReport(35=CD) message, to either accept or reject an unsolicited assignment.

Category – Market Structure Reference Data


Market Definition Requests

The MarketDefinitionRequest(35=BT) message is used to request for market structure information from the Respondent that receives this request. Fields that are specified will act as “filters” for the request. For example, if MarketID(1301) is specified then only market structure information for that specified market should be sent back if available. If MarketID(1301) is not specified then the request is for all available market structure information.

The MarketDefinitionRequest(35=BT) message can also indicate to the respondent whether the request is for a snapshot of requested information, subscribe to market structure information, or to unsubscribe from an earlier subsription request. This is done via SubscriptionRequestType(263).

Market Definitions

The MarketDefinition(35=BU) message is used to respond to a MarketDefinitionRequest(35=BT) message. In a subscription, it will be used to provide the initial snapshot of the information requested. Subsequent updates are provided by the MarketDefinitionUpdateReport(35=BV) message.

This message is associated with a list of trading sessions (and subsessions) applicable for the segment – the list is published using the TradingSessionList(35=BJ) message.

Market Definition Update Reports

In a subscription for market structure information, the MarketDefinitionUpdateReport(35=BV) message is used once the initial snapshot of the information has been sent using the MarketDefinition(35=BU) message.

Trading Session Status Requests

The TradingSessionStatusRequest(35=g) message is used to request information on the status of a market. With the move to multiple trading sessions occurring for a given trading party (morning and evening sessions for instance) there is a need to be able to provide information on what product is trading on what market.

The TradingSessionStatusRequest(35=g) message can be used to inquire the trading status of a trading party. The TradingSessionStatusRequest(35=g) message can be used to subscribe to updates to the status of a trading session with SubscriptionRequestType(263) = 1.

Use the SecurityDefinitionRequest(35=c) message to request the securities available during a particular trading session with TradingSessionID(336).

Trading Session Status

The TradingSessionStatus(35=h) provides information on the status of a market. For markets with multiple trading sessions occurring (morning and evening sessions for instance), this message is able to provide information on what products are trading on what market during what trading session.

Trading Session List Requests

The TradingSessionListRequest(35=BI) is used to request a list of trading sessions available in a market place and the state of those trading sessions. The request can be modified to request status on a particular trading session (by specifying the TradingSessionID(336) and TradingSessionSubID(625) (if used by the market place). The request can be used to request a list of trading sessions that use a particular trading method or mode (such as electronic) by specifying TradSesMethod(338) and/or TradSesMode(339).

A successful request will result in a response from the counterparty by means of a TradingSessionList(35=BJ) message that contains a list of zero or more trading sessions.

It is recommended that TradSesReqID(335) be used to provide a unique identifier for the request. This value should be returned by the counterparty in the TradingSessionList(35=BJ) messages sent in response to the request.

The TradingSessionListRequest(35=BI) message follows the standard request model in providing SubscriptionRequestType(263) which can be used to obtain a snapshot of trading session information, subscribe for a snapshot with subsequent updates, or to unsubscribe from a previous subscription request.

Trading Session Lists

The TradingSessionList(35=BJ) message is sent as a response to a TradingSessionListRequest(35=BI). The TradingSessionList(35=BI) message should contain the characteristics of the trading session and the current state of the trading session.

The message could be relayed every trading day, or at least when trading sessions are changed. The user of the message has the ability to relay either trading sessions only or, if applicable, trading subsessions. Depending on characteristics of the market, different timestamps apply.

The TradingSessionList(35=BJ) should return the TradSesReqID(335) value from the TradingSessionListRequest(35=BI) originally sent by a counterparty.

Trading Session List Update Reports

The TradingSessionListUpdateReport(35=BS) message is used by marketplaces to provide intra-day updates of trading sessions when there are changes to one or more trading sessions.

Category – Securities Reference Data


Security Definition Requests

The SecurityDefinitionRequest(35=c) message is used for the following:

  1. Request a specific security to be traded with the second party. The request security can be defined as a multileg security made up of one or more instrument legs.
  2. Request a set of individual securities for a single market segment.
  3. Request all securities, independent of market segment.

Subscription for security status can be optionally specified by including SubscriptionRequestType(263) on the message.

Security Definitions

The SecurityDefinition(35=d) message is used for the following:

  1. Accept the security defined in a SecurityDefinition(35=d) message.
  2. Accept the security defined in a SecurityDefinition(35=d) message with changes to the definition and/or identity of the security.
  3. Reject the security requested in a SecurityDefinition(35=d) message.
  4. Respond to a request for securities within a specified market segment.
  5. Convey comprehensive security definitions for all market segments that the security participates in.
  6. Convey the security’s trading rules that differ from default rules for the market segment.

Security Definition Update Reports

The SecurityDefinitionUpdateReport(35=BP) message is used for reporting updates to a Product Security Masterfile. Updates could be the result of corporate actions or other business events. Updates may include additions, modifications or deletions.

Security Type Requests

The SecurityTypeRequest(35=v) message is used to return a list of security types available from a counterparty or market.

The request can include a specific TradingSessionID(336) for which security types should be returned.

Security Types

The SecurityTypes(35=w) message is used to return a list of security types available from a counterparty or market.

Security List Requests

The SecurityListRequest(35=x) message is used to return a list of securities from a counterparty that match criteria provided on the request.

Subscription for security status can be optionally specified by including the SubscriptionRequestType(263) field on the message.

SecurityListRequestType(559) specifies the criteria of the request:

  • 0 – Symbol
  • 1 – SecurityType and/or CFICode
  • 2 – Product
  • 3 – TradingSessionID
  • 4 – All Securities

The SecurityListRequest(35=x) message may also be used to request a list of securities for a given market segment.

Security Lists

The SecurityList(35=y) message is used to return a list of securities that matches the criteria specified in a SecurityListRequest(35=x).

Security List Update Reports

The SecurityListUpdateReport(35=BK) message is used for reporting updates to a Contract Security Masterfile. Updates could be due to corporate actions or other business events. Update may include additions, modifications and deletions.

Derivative Security List Requests

The DerivativeSecurityListRequest(35=z) message is used to return a list of securities from the counterparty that match criteria provided on the request.

Subscription for security status can be optionally specified by including the SubscriptionRequestType(263) field on the message.

SecurityListRequestType(559) specifies the criteria of the request:

  • 0 – Symbol
  • 1 – SecurityType and/or CFICode
  • 2 – Product
  • 3 – TradingSessionID
  • 4 – All Securities

The DerivativeSecurityListRequest(35=z) message may also be used to:

  1. Request for option classes for a given market segment.
  2. Allows a request for derivative securities to be made independent of market segment. The option classes may carry all relevant market segments and their corresponding trading rules.

Derivative Security Lists

The DerivativeSecurityList(35=AA) message is used to return a list of securities that matches the criteria specified in a DerivativeSecurityListRequest(35=z) message.

The DerivativeSecurityList(35=AA) message is used to send a predefined list of securities (usually options) based on a common underlying and option class. It can also be used to send the rules for security creation (usually options) which imply the existence of a set of securities.

Other uses of this message may include:

  1. Convey comprehensive set of option classes for all market segments in which these option classes participates in.
  2. Convey the option classes’ trading rules that differ from the default trading rules for the market segment.

Derivative Security List Update Reports

The DerivativeSecurityListUpdateReport(35=BR) message is used to send updates to an option family or the strikes that comprise an option family.

Security Status Requests

The SecurityStatusRequest(35=e) message provides for the ability to request the status of a security. One or more SecurityStatus(35=f) messages are returned as a result of a SecurityStatusRequest(35=e) message.

The SecurityStatusRequest(35=e) message contains SubscriptionRequestType(263). This field tells the counter party what type of request is being made:

  • 0 – indicates that the requestor only wants a snapshot of the current status.
  • 1 – indicates that the requestor wants a snapshot (the current status) plus updates as the status changes. This is similar to subscribing for information and can be implemented in applications as a subscription mechanism.
  • 2 – indicates that the requestor wishes to cancel any pending snapshots or updates – in essence making this an unsubscribe operation.

Security Status

The SecurityStatus(35=f) message provides for the ability to report changes in status of a security. The SecurityStatus(35=f) message contains fields to indicate trading status, corporate actions, financial status of the company. The SecurityStatus(35=f) message is used by one trading entity (for instance an exchange) to report changes in the state of a security.


The detailed layouts of the components and messages are available here.