Business Area: Pre-Trade
As of EP284, November 2023
Table of Contents
Introduction
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:
- INDICATION
- EVENT COMMUNICATIONS
- QUOTATION / NEGOTIATION
- MARKET DATA
- MARKET STRUCTURE REFERENCE DATA
- SECURITIES REFERENCE DATA
- PARTIES REFERENCE DATA
- PARTIES ACTION
Descriptions of the specific FIX pre-trade application messages follow. There is a diagram for each of the messages depicting its components. Required components are shown with a red outline and repeating groups contain an arrow symbol. Some messages do not have any components. The detailed layout of all messages and components is provided in the appendix.
List of Messages and Components for Pre-Trade
Messages
This section lists the pre-trade messages and the category each of them belongs to.
Components
This section lists components used by pre-trade messages defined in this part of the FIX specification. Some of these are Common Components used by more than one category in this area. Messages may also reference Global Components, which are components used by messages across more than one area. Global Components are defined in the overall Introduction to the FIX specification.
Components can be either non-repeating or repeating (a.k.a. a “group”), i.e. contain multiple instances of a set of fields. Components can be nested to any level.
Category – Indication
Messages
Advertisements
An Advertisement(35=7) message is used to announce completed transactions. It can be transmitted with 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). The message layout is available here.
Cross Requests
A CrossRequest(35=DS) message is used to indicate the submission of orders or quotes that may result in a crossed trade. Regulatory requirements can allow exchanges to match orders belonging to the same account, firm or other common attribute. This can include the requirement to first announce the intention to cross orders. The time permitted between the announcement and the actual cross is typically well defined and may depend on the maximum quantity announced. The message layout is available here.
Cross Request Acknowledgements
A CrossRequestAck(35=DT) message is used to confirm the receipt of a CrossRequest(35=DS) message. The message layout is available here.
Indications of Interest
An IOI(35=6) message is 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.
Indication of interest messages can be transmitted with 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).
The message layout is available here.
Components
The component listed below are components used exclusively by the messages within the Indication category.
InstrmtLegIOIGrp
This component is a repeating group that is required for multileg IOIs. It allows a full definition of individual instrument legs together with a relative leg-specific quantity (LegIOIQty(682)), e.g. small, medium, or large, which make up the multi-legged security for the IOI. The component includes a repeating group for stipulations per leg. The component layout is available here.
IOIQualGrp
This component is a repeating group that supports the definition of various qualifiers such as “All or None” (AON) by means of IOIQualifier(104), applicable for the IOI. The component layout is available here.
Category Event Communication
Messages
Emails
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.
When the InstrmtLegGrp component is used, then the InstrmtGrp component should contain only a single instrument.
The message layout is available here.
News
News(35=B) messages are general, free format messages between the broker and institution (or other sending and receiving entities). The message contains flags to identify the news item’s urgency and to allow sorting by subject or company (symbol). The News(35=B) message can be originated, for example, at either the broker or institution side, or exchanges and other marketplace venues, or by an intermediary.
The News(35=B) 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(35=B) messages with NewsCategory(1473), users can choose how to render them in different GUIs or ignore certain categories altogether.
Additionally, News(35=B) 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. When the InstrmtLegGrp component is used, then the InstrmtGrp component should contain only a single instrument.
The message layout is available here.
Components
The component listed below are components used exclusively by the messages within the Event Communication category.
LinesOfTextGrp
This component is a repeating group supporting an arbitrary number of text lines together with the related fields for encoded text. The component layout is available here.
NewsRefGrp
This component is a repeating group used to provide references to previous news messages by means of an identifier NewsRefID(1476) and a type NewsRefType(1477), to indicate the purpose for the reference. The component layout is available here.
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.
Messages
Quote Requests
In some markets it is the practice to request for quotes from liquidity providers or market makers 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 for forex rates. The QuoteRequest(35=R) message can be used to request quotes on a single product or multiple products.
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, a.k.a. 2-sided quote) should be returned.
In the tradeable and restricted tradeable quote models the QuoteRequest(35=R) message may be preceded by the RFQRequest(35=AH) message.
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). The message layout is available here.
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. The message layout is available here.
Quote Request Rejections
The QuoteRequestReject(35=AG) message is used to reject QuoteRequest(35=R) messages. The message layout is available here.
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 may be used to register interest in receiving quote requests for a single instrument or for multiple instruments. The message layout is available here.
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.
Quotes
The Quote(35=S) message is used as the response to a QuoteRequest(35=R) message or a QuoteResponse(35=AJ) message in 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 marketplace.
The Quote(35=S) message may be used to send unsolicited quotes in 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)). The message layout is available here.
Quote Acknowledgments
The QuoteAck(35=CW) message may be used to acknowledge a Quote(35=S) message. It may also be used to acknowledge the request to cancel an individual quote (i.e. QuoteCancel(35=Z) message with QuoteCancelType(298) = 5 (Cancel specified single quote)), particularly during a Quote/Negotiation dialog. The message layout is available here.
Quote Cancellations
The QuoteCancel(35=Z) message is used by an originator of quotes to cancel their 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).
QuoteCancel(35=Z) messages may be acknowledged using the QuoteStatusReport(35=AI) message or QuoteAck(35=CW) message, depending on the use case.
Quote cancel requests apply only to quotes issued by the quote originator. The message layout is available here.
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. Cancellation of quotes for specific series is possible 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.
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”.
The message layout is available here.
Quote Status Reports
The QuoteStatusReport(35=AI) message is used:
- as a response to a QuoteStatusRequest(35=a) message without a subscription request
- as a response to a QuoteStatusRequest(35=a) message with a subscription request. An initial snapshot will be provided as well as subsequent updates.
- as a response to a QuoteCancel(35=Z) message
- as a response to a QuoteResponse(35=AJ) message in a negotiation dialog
The message layout is available here.
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 message provides the grouping of quote sets and quotes in the following hierarchy:
- 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 (underlying) 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.
The message layout is available here.
Requesting Acknowledgement for Mass Quotes
Applications can optionally support acknowledgement of quotes using the field QuoteResponseLevel(301) 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 the field QuoteRejectReason(300) for reporting the reason in the event that the entire quote is rejected. The MassQuoteAck(35=b) message also contains the 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). The message layout is available here.
Components
The component listed below are components used exclusively by the messages within the Quotation/Negotiation category.
LegQuotGrp
This component is a repeating group that defines the individual instruments which make up a multi-legged security being quoted in the Quote(35=S) and QuoteResponse(35=AJ) messages. It supports the full definition of an instrument leg as well as a number of leg-level attributes, including parties (or accounts), stipulations and benchmark curve data. The component layout is available here.
LegQuotStatGrp
This component is a repeating group that is required in QuoteStatusReport(35=AI) messages when providing quoting status on a multi-legged security. It supports the full definition of an instrument leg as well as a number of leg-level attributes, including parties (or accounts) and stipulations. The component layout is available here.
QuotCxlEntriesGrp
This component is a repeating group that may be used in the QuoteCancel(35=Z) message when not cancelling all quotes. It contains the full definition of an instrument, its legs (for multileg quotes) and underlying instruments as well as financing details that all serve as filter criteria for the quotes of the specified instrument(s) to be cancelled. The instrument legs are specified by means of the InstrmtLegGrp component. The component layout is available here.
QuoteAttributeGrp
This component is a repeating group that provides additional attributes about the quote. Attributes included in this component are primarily “indicators” that may be associated with regulatory requirements and are typically not part of normal trading activities. The component layout is available here.
QuotEntryGrp
This component is a repeating group that is required in the MassQuote(35=i) message to convey individual quote entries as part of a quote set (see QuotSetGrp). Each quote entry contains QuoteEntryID(299) as unique quote identifier and full components for an instrument and its legs (for multileg quotes). The instrument legs are specified by means of the InstrmtLegGrp component. The component layout is available here.
QuoteEntryAckGrp
This component is a repeating group that may be used in the MassQuoteAck(35=b) message to acknowledge individual quote entries as part of the acknowledgement of a quote set (see QuotSetAckGrp component). The component layout is available here.
QuotQualGrp
This component is a repeating group that supports one or more qualifiers as part of a single quote. QuoteQualifier(695) uses the values from IOIQualifier(104) found in the IOIQualGrp component, e.g. “All or None” (AON). The component layout is available here.
QuotReqGrp
This component is a repeating group that supports request for quotes for one or more instruments in a single QuoteRequest(35=R) message with a large number of individual attributes serving as quoting criteria. It also supports the full definition of an instrument, its legs (for multileg quotes) and underlying instruments as well as quote qualifiers, financing details, stipulations and benchmark curve data, yield data that all serve as filter criteria for the quotes being requested. The instrument’s legs are specified by means of the specific QuotReqLegsGrp component. The component layout is available here.
QuotReqLegsGrp
This component is a repeating group within the QuotReqGrp and QuotReqRjctGrp components, which would be used in the QuoteRequest(35=R) and QuoteRequestReject(35=AG) messages when a multi-legged instrument is being expressed. It supports the full definition of an instrument leg as well as a number of leg-level attributes, including parties (or accounts), stipulations and benchmark curve data. The component layout is available here.
QuotReqRjctGrp
This component is a repeating group that may be used to echo the attributes provided in the QuotReqGrp component when the quote request is rejected. The component layout is available here.
QuotSetAckGrp
This component is a repeating group that may be used in the MassQuoteAck(35=b) message to acknowledge an entire set of quotes. It contains the QuotEntryAckGrp component which may be used to acknowledge individual quote entries. A number of fields are provided to convey the total number of quote entries that were accepted, reject, or cancelled for the given quote set (across all messages when message fragmentation is being used). The component layout is available here.
QuotSetGrp
This component is a repeating group that is required in the MassQuote(35=i) message to convey one or more quote sets. It is required to contain the QuotEntryGrp component to convey individual quote entries for each quote set. It is also required to identify each quote set with QuoteSetID(302) and its total number of quote entries (across all messages for the same quote set when message fragmentation is being used) with TotNoQuoteEntries(304). The component layout is available here.
RFQReqGrp
This component is a repeating group that is required in the RFQRequest(35=AH) message to convey the instruments for which an RFQ is requested. It supports the full definition of an instrument, its legs (for multileg quotes) and underlying instruments. The component layout is available here.
Category – Market Data
Messages
Market Data Requests
A MarketDataRequest(35=V) is a general request for market data on one or more specific securities or currency pairs from markets that allow the transmission of real time quotes, market prices, order, trade, trade volume, open interest, and/or other price information on a subscription basis. The values in the fields provided within the request will serve as further filter criteria for the result set. The MarketDataRequest(35=V) message is used to request a static book snapshot or subscribe to a stream of snapshots and updates.
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.
The message layout is available here.
Types of Market Data Requests
- A market data request may result in a feed consisting of both MarketDataSnapshotFullRefresh(35=W) messages and MarketDataIncrementalRefresh(35=X) messages.
- The MarketDataSnapshotFullRefresh(35=W) message should be used to provide a snapshot of the market when snapshot is requested using SubscriptionRequestType(263) = 0 (Snapshot). Use of MarketDataIncrementalRefresh(35=X) is being discouraged for this purpose.
- The MarketDataSnapshotFullRefresh(35=W) message will be used to provide initial snapshot when snapshot plus updates are requested using SubscriptionRequestType(263) = 1 (Snapshot + Updates).
- 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
- 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.
- 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.
- 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
- If MDBookType(1021) = 1 (Top-of-Book) or 2 (Price Depth), this indicates that the market is crossed.
- 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 Request Rejections
The MarketDataRequestReject(35=Y) message is used when the market data provider cannot honor the MarketDataRequest(35=V) message due to business or technical reasons. Data providers 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. The message layout is available here.
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 may be used to transmit a variety of market data types, for example 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 refers only to one MarketDataRequest(35=V) message, specifying the appropriate MDReqID(262) of the request message. Unsolicited market data snapshots can be sent; in such cases, MDReqID(262) will not be present.
The MarketDataSnapshotFullRefresh(35=W) message includes 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.
The message layout is available here.
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 may 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 MarketDataIncrementalRefresh(35=X) is used for incremental updates as part of a subscription. 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 one or more instruments, with any combination of market data entry types (e.g. 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.
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).
The message layout is available here.
Market Data Reports
The MarketDataReport(35=DR) message is used to provide delimiting references (e.g. start and end markers in a continuous broadcast) and details about the number of market data messages sent in a given distribution cycle. The message may be used when distributing reference and market data on an ongoing basis to convey start and end points for synchronization. The report contains multiple message counters that are provided at the beginning or end of a cycle. The message layout is available here.
Market Data Statistic Requests
The MarketDataStatisticsRequest(35=DO) message is used to request for statistical data. The request can be as simple as using an identifier (MDStatisticID(2475)) assigned by the marketplace which denotes a pre-defined statistical report. Alternatively, or also in addition, the request can define a number of parameters for the desired statistical information.
Fields specified in the request are used as filter criteria to restrict the resulting data returned. The resulting data set can be restricted to a specific market, market segment or pre-defined security list for which a single set of statistics will be returned. It is also possible to specify individual instruments or group of instruments by means of the Instrument, UndInstrmtGrp and InstrmtLegGrp components.
The message layout is available here.
Market Data Statistic Reports
The MarketDataStatisticsReport(35=DP) message is used to provide statistical information in response to a specific request or may be sent unsolicited to broadcast or publish the statistical information. Each report contains a set of statistics for a single entity which could be a market, a market segment, a security list or an instrument. The message layout is available here.
Stream Assignment Requests
The StreamAssignmentRequest(35=CC) message is used by data aggregators 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). 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. 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. 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 message layout is available here.
Stream Assignment Reports
The StreamAssignmentReport(35=CD) message is in response to the StreamAssignmentRequest(35=CC) message. It provides information back to the data aggregator as to which client(s) to assign to receive which price stream based on requested currency pair or security. This message can also be sent unsolicited to the aggregator from the price maker. The message layout is available here.
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. The message layout is available here.
Components
InstrmtMDReqGrp
This component is a repeating group that is required in the MarketDataRequest(35=V) message. It is used to define various filter criteria for the market data to be returned. It supports the full definition of an instrument, its legs (for multileg instruments) and underlying instruments. The component layout is available here.
MDFullGrp
This component is a repeating group that is required in the MarketDataSnapshotFullRefresh(35=W) message to convey one or more types of market data for a single instrument. The MDEntryType(269) field indicates the types of market data which may include bids and/or offers, imbalances, index values, opening, closing, settlement, high, low, and/or VWAP prices, trade volume, or open interest, etc. Associated with the type of market data are the many individual attributes that can be specified, as well as parties (or accounts), yield data, benchmark curve data, rate sources as well as an option to breakdown quantities (see SecSizesGrp). MDEntryID(278) may be used to support the maintenance of an order-depth book to identify individual entries as opposed to orders aggregated on a price level. The component layout is available here.
MDIncGrp
This component is a repeating group that is required in the MarketDataIncrementalRefresh(35=X) message. Although it is very similar to MDFullGrp there are some key differences. MDIncGrp supports the full definition of an instrument, its legs (for multi-legged instruments) and underlying instruments as part of each instance of the repeating group. MDIncGrp may be used to provide market data for one or more instruments in a single message. Each instance of MDIncGrp is required to provide MDUpdateAction(279) to characterize the nature of the incremental update (e.g. “add”, “update” or “delete”). The component layout is available here.
MDReqGrp
This component is a repeating group that is required in the MarketDataRequest(35=V) message to convey one or more values of MDEntryType(269) such as bid, offers, trades, etc., as request filter criteria. The component layout is available here.
MDRjctGrp
This component is a repeating group that may be used in the MarketDataRequestReject(35=Y) message to convey alternate market data sources to connect to on the session layer when rejecting a MarketDataRequest(35=V) message. The component layout is available here.
MDStatisticParameters
This component is part of the components MDStatisticReqGrp and MDStatisticRptGrp. It comprises all parameters that may be used to describe the market data statistics. These can be part of the request as well as the response. All parameters defined on the MarketDataStatisticsRequest(35=DO) message should be echoed back in the MarketDataStatisticsReport(35=DP) message, however the latter could also be sent unsolicited. The general category and the entities involved in the statistics are defined by MDStatisticType(2456), MDStatisticScope(2457), and MDStatisticIntervalType(2464) and must always be specified. The remaining fields are optional and restrict the data range in one way or another. The time range for the data can either be specified in terms of an interval for which the statistics are typically calculated on a regular basis or in terms of an absolute date and/or time range.
MDStatisticScope(2457), MDStatisticSubScope(2458) and MDStatisticScopeType(2459) form a set of scope relationships to filter further the type of statistic being requested or being provided. It should be noted that some of the enumeration values for MDStatisticScopeType(2459) may not be applicable or useful for a given MDStatisticScope(2457), e.g. MDStatisticScopeType(2459)=4 (Downward move) is more applicable to prices than to orders or trades.
The component layout is available here.
MDStatisticReqGrp
This component is a repeating group that is used within the MarketDataStatisticsRequest(35=DO) message to define a set of parameters requesting the desired statistics. The component layout is available here.
MDStatisticRptGrp
This component is a repeating group that is used within the MarketDataStatisticsReport(35=DP) message to provide market data statistics together with the related set of parameters. The component layout is available here.
SecSizesGrp
This component is a repeating group that may be used to identify portions of MDEntrySize(271) as being part of a secondary interest, e.g. the amount of customer volume on a given price level. The component layout is available here.
StatsIndGrp
This component is a repeating group that is part of the MDIncGrp component to indicate that the market data entry is eligible to be included into statistics such as exchange last, high, or low. All eligible entries must be flagged accordingly if this component is used. The component layout is available here.
StrmAsgnReqGrp
This component is a repeating group that is required in the StreamAssignmentRequest(35=CC) message. It is used by market data aggregators to convey one or more client pricing stream assignments to a price maker. One or more end clients are identified with the Parties component together with the optional StrmAsgnReqInstrmtGrp which specifies the related streams, e.g. EUR/USD prices. The component layout is available here.
StrmAsgnReqInstrmtGrp
This component is a repeating group that is part of the StrmAsgnReqGrp component. It is used to specify one or more requested price streams identified by an instrument definition (e.g. CCY pair) with an optional unique stream identifier MDStreamID(1500). Tenors are supported with SettlType(63), volume bands with MDEntrySize(271). The component layout is available here.
StrmAsgnRptGrp
This component is a repeating group that is required in the StreamAssignmentReport(35=CD) message from the price maker to respond to assignment requests from an aggregator. One or more end clients are identified with the Parties component together with the StrmAsgnRptInstrmtGrp component, which specifies the related streams, e.g. EUR/USD prices, the client is assigned to receive. The component layout is available here.
StrmAsgnRptInstrmtGrp
This component is a repeating group that is part of the StrmAsgnRptGrp component. It is used to provide responses to one or more requested price streams identified by an instrument definition (e.g. CCY pair) with an optional unique stream identifier MDStreamID(1500). The type of response is conveyed with StreamAsgnType(1617), together with StrmAsgnRejReaason(1502) in case of a rejection of the request. The component layout is available here.
Category – Market Structure Reference Data
Messages
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 supports the concept of message subscription. The message layout is available here.
Market Definitions
The MarketDefinition(35=BU) message is used to respond to a MarketDefinitionRequest(35=BT) message and defines entire market(s) or market segment(s). 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. The message layout is available here.
Market Definition Update Reports
The MarketDefinitionUpdateReport(35=BV) message is used to provide incremental updates to the definition of market(s) or market segment(s). The type of update is indicated with MarketUpdateAction(1395). 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. The message layout is available here.
Trading Session Status Requests
The TradingSessionStatusRequest(35=g) message is used to request information on the status of a market. It may be used to inquire the trading status of a market, market segment or trading session. It supports the concept of message subscription.
Use the SecurityDefinitionRequest(35=c) message to request the securities available during a particular trading session with TradingSessionID(336).
The message layout is available here.
Trading Session Status
The TradingSessionStatus(35=h) message is a response message to the TradingSessionStatusRequest(35=g) message, providing information on the trading status of a market or market segment. 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. The message layout is available here.
Trading Session List Requests
The TradingSessionListRequest(35=BI) is used to request a list of trading sessions and the state of those trading sessions. The results can be further refined by requesting status on a particular trading session (by specifying the TradingSessionID(336) and TradingSessionSubID(625) (if used by the marketplace)), as well as based on market and market segment. The request may also 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 respondent in the TradingSessionList(35=BJ) messages sent in response to the request.
The TradingSessionListRequest(35=BI) message supports the concept of message subscription. The message layout is available here.
Trading Session Lists
The TradingSessionList(35=BJ) message is sent as a response to a TradingSessionListRequest(35=BI). The TradingSessionList(35=BI) message contains the current state of the trading session(s) and optionally the characteristics of the trading session. In a subscription, it will be used to provide the initial snapshot of the information requested. Subsequent updates are provided by the TradingSessionListUpdateReport(35=BS) message.
The message could be sent every trading day, or at least when trading sessions are changed[HANNO: not when the status changes]. The sender of the message has the ability to send either trading sessions only or, if applicable, trading sub-sessions. Depending on the characteristics of the market or market segment, different timestamps may apply to the schedule of the trading session or sub-session.
When responding to a request, the TradingSessionList(35=BJ) shall return the TradSesReqID(335) value from the TradingSessionListRequest(35=BI) originally sent. The message layout is available here.
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. In a subscription for trading session information, the TradingSessionListUpdateReport(35=BS) message is used once the initial snapshot of the information has been sent using the TradingSessionList(35=BJ) message. The message layout is available here.
Components
FlexProductEligibilityGrp
This component is a repeating group that is used to specify whether securities within a product group or complex are eligible for creating flexible securities. The component layout is available here.
RelatedMarketSegmentGrp
This component is a repeating group that is used to identify market segments that are related to each other for a business purpose. This component should not be used in lieu of available explicit FIX fields that denote specific relationships (e.g. ParentMktSegmID(1325) for parent market segments), but rather should be used when no such fields exist. The component layout is available here.
TrdSessLstGrp
This component is a repeating group that is required in the TradingSessionList(35=BJ) and TradingSessionListUpdateReport(35=BS) messages to convey a list of trading (sub)sessions together with a number of session attributes. The attributes describe the characteristics of a trading (sub)session such as starting and ending times and the applicable market or market segment. TradSesUpdateAction(1327) allows to make updates to a given list by adding, modifying or removing a specific trading (sub)session. It supports the definition of the market model per trading (sub)session by means of the TradingSessionRules component. The component layout is available here.
Category – Securities Reference Data
Messages
Derivative Security List Requests
The DerivativeSecurityListRequest(35=z) message is used to request a list of derivative securities, e.g. from a market place, that match criteria specified in SecurityListRequestType(559) and any additional fields included.
The DerivativeSecurityListRequest(35=z) message may also be used to:
- Request for option classes for a single market segment.
- Request for derivative securities independent of a market segment. The option classes may carry all relevant market segments and their corresponding trading rules.
The DerivativeSecurityListRequest(35=z) message supports the concept of message subscription.
The message layout is available here.
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. In a subscription, it will be used to provide the initial snapshot of the information requested. Subsequent updates are provided by the DerivativeSecurityListUpdateReport(35=BR) message. This message may also be sent unsolicited without a request.
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:
- Convey comprehensive set of option classes for all market segments in which these option classes participate in.
- Convey the option classes’ trading rules that differ from the default trading rules for the market segment.
The message layout is available here.
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. In a subscription for derivative securities information, the DerivativeSecurityListUpdateReport(35=BR) message is used once the initial snapshot of the information has been sent using the DerivativeSecurityList(35=AA) message. The message layout is available here.
Security Definition Requests
The SecurityDefinitionRequest(35=c) message is used for the following:
- Request a specific security to be traded (as defined by the submitter of the request). The requested security can be defined as a multileg security made up of one or more instrument legs.
- Request for a set of individual securities for a single market, market segment or trading (sub)session.
- Request for all securities, independent of market segment.
The SecurityDefinitionRequest(35=c) message supports the concept of message subscription.
The message layout is available here.
Security Definitions
The SecurityDefinition(35=d) message is used for the following:
- Accept the security defined in a SecurityDefinitionRequest(35=c) message.
- Accept the security defined in a SecurityDefinitionRequest(35=c) message with changes to the definition and/or identity of the security.
- Reject the security requested in a SecurityDefinitionRequest(35=c) message.
- Respond to a request for securities within a single market, market segment or trading (sub)session.
- Convey comprehensive security definitions.
- Convey listing and trading rule details for market segments the security trades in when they differ from default rules for the market segment.
In a subscription, it will be used to provide the initial snapshot of the information requested. Subsequent updates are provided by the SecurityDefinitionUpdateReport(35=BP) message. This message may also be sent unsolicited without a request.
The message layout is available here.
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. In a subscription for securities information, the SecurityDefinitionUpdateReport(35=BP) message is used once the initial snapshot of the information has been sent using the SecurityDefinition(35=d) message.
The message layout is available here.
Security List Requests
The SecurityListRequest(35=x) message is used to request a list of securities, e.g. from a market place, that match criteria provided on the request. SecurityListRequestType(559) specifies the criteria of the request.
The SecurityListRequest(35=x) message supports the concept of message subscription.
The message layout is available here.
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). In a subscription, it will be used to provide the initial snapshot of the information requested. Subsequent updates are provided by the SecurityListUpdateReport(35=BK) message. This message may also be sent unsolicited without a request. The message layout is available here.
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. In a subscription for security list information, the SecurityListUpdateReport(35=BK) message is used once the initial snapshot of the information has been sent using the SecurityList(35=y) message. The message layout is available here.
Security Mass Status Requests
The SecurityMassStatusRequest(35=CN) message provides for the ability to request the status of a group of securities. A single SecurityMassStatus(35=CO) message or multiple SecurityStatus(35=f) messages are returned as a result of a SecurityMassStatusRequest(35=CN) message. The message layout is available here.
Security Mass Status
The SecurityMassStatus(35=CO) message provides the trading status for a group of securities. This can either be a previously defined security list identified by SecurityListID(1465) or all securities of a specific market, market segment, trading session, trading sub-session or by usage of one or more fields of the InstrumentScope component as selection criteria. The SecurityMassTradingStatus(1679) field defines the new state for the group of securities after a state change. Exceptions to the state change can be conveyed through a list of individual securities with a different trading status. The message layout is available here.
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 supports the concept of message subscription.
The message layout is available here.
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 message layout is available here.
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. The message layout is available here.
Security Types
The SecurityTypes(35=w) message is used to return a list of security types available from a counterparty or market. ‚ The message layout is available here.
Components
ClearingAccountTypeGrp
This component is a repeating group that is used to specify the type of clearing account types. When used within the PriceMovementGrp, it specifies the type of account the price movement data is applicable for. The component layout is available here.
ClearingPriceParametersGrp
This component is a repeating group that is used convey parameters that are relevant for the calculation of clearing prices that are different from the trading prices due to the nature of the product, e.g. variance futures. The component layout is available here.
DerivativeEventsGrp
This component is a repeating group that is part of the DerivativeInstrument component and supports one or more events related to a derivative instrument. It is similar to the EvntGrp component that is part of the Instrument component. DerivativeEventType(1287) uses the valid values from EventType(865). The component layout is available here.
DerivativeInstrument
This component is part of the DerivativeSecurityDefinition component to request a list of derivative instruments. It is similar to the Instrument component but with a focus on derivative instruments, i.e. it contains a large number of attributes applicable to an instrument in this asset class. The component layout is available here.
DerivativeInstrumentAttribute
This component is a repeating group that is part of the DerivativeSecurityDefinition component and conceptually identical to the AttrbGrp component that is part of the InstrumentExtension component. It is used to provide additional information about a derivative instrument. It contains two generic fields (type and value) for each attribute. DerivativeInstrAttribType(1313) uses the values from InstrAttribType(871). The component layout is available here.
DerivativeInstrumentParties
This component is a repeating group that is part of the DerivativeInstrument component and conceptually identical to the Parties component. It is used to provide reference information about a party related to a derivative instrument. The fields use the valid values from the corresponding fields in the Parties component. The component layout is available here.
DerivativeInstrumentPartySubIDsGrp
This component is a repeating group that is part of the DerivativeInstrumentParties component and conceptually identical to the PtysSubGrp component. It is used to provide additional information about a specified party related to a derivative instrument. DerivativeInstrumentPartySubIDType(1298) uses the values from PartySubIDType(803). The component layout is available here.
DerivativeSecurityAltIDGrp
This component is a repeating group that is part of the DerivativeInstrument component and conceptually identical to the SecAltID component. It is used to include alternate identifiers for the derivative instrument specified in DerivativeSecurityID(1216). The alternate identifier(s) specified must not be the same as the value in the DerivativeSecurityID(1216) field. The component layout is available here.
DerivativeSecurityDefinition
This component is used to summarize common attributes shared across a set of option instruments that belong to the same series. It contains the DerivativeInstrument component and the two repeating groups DerivativeInstrumentAttribute and MarketSegmentGrp, and has no individual attributes. The component layout is available here.
DerivativeSecurityXML
This component is part of the DerivativeInstrument component and conceptually identical to the SecurityXML component. It carries a derivative instrument description or definition in an XML format. The component layout is available here.
InstrmtLegSecListGrp
This component is a repeating group that is part of the SecListGrp component. It supports the full definition of one or more instrument legs together with stipulations and benchmark curve data for each leg. The component layout is available here.
MarketSegmentGrp
This component is a repeating group used as part of security definition messages to specify the market(s), market segment(s), strike rules and trading rules applicable for the security. The component layout is available here.
MaturityRules
This component is a repeating group that is part of the StrikeRules component. It supports the definition of one or more attributes related to the maturity of an instrument such as the format or its increments. The component layout is available here.
NestedInstrumentAttribute
This component is a repeating group that is part of the SecurityTradingRules component. It is conceptually identical to the AttrbGrp component that is part of the InstrumentExtension component. It is used to provide additional information about trading rules defined by the SecurityTradingRules component. It contains two generic fields (type and value) for each attribute. The component layout is available here.
PriceMovementGrp
This component is a repeating group that is part of the SecListGrp component. It contains theoretical profit and loss data at various price movement points account type(s) for which the price movement may apply to. The component layout is available here.
PriceMovementValueGrp
This component is a repeating group that is part of the PriceMovementGrp component. It is used to represent a value relative to a specific price movement point. The component layout is available here.
RelSymDerivSecGrp
This component is a repeating group that is part of the DerivativesSecurityList(35=AA) message. It is used to convey a list of related derivative instrument definitions where the overall definitions for the entire series are provided with the DerivativeSecurityDefinition component. This component contains the component SecondaryPriceLimits component for price limits per instrument. The component layout is available here.
RelSymDerivSecUpdGrp
This component is a repeating group that is part of the DerivativesSecurityListUpdateReport(35=BR) message. It is used to maintain a list of related derivative instrument definitions, e.g. a list of option series with the overall information provided with the DerivativeSecurityDefinition component. Related instruments from the list can be added, modified or removed with ListUpdateAction(1324). This component is conceptually identical to the RelSymDerivSecGrp component. The component layout is available here.
SecListGrp
This component is a repeating group that is part of the SecurityList(35=y) message. It is used to provide a list of instrument or security definitions (including strategies, options and other complex instruments through use of InstrumentLeg and UnderlyingInstrument components) together with financing details, stipulations, benchmark curve data, and yield data. It may also be used to convey market model information by means of the components SecurityTradingRules and StrikeRules. The component layout is available here.
SecLstUpdRelSymGrp
This component is a repeating group that is part of the SecurityListUpdateReport(35=BK) message. It is used to provide a list of complete instrument definitions (including legs and underlying instruments) together with financing details, stipulations, benchmark curve data, and yield data. It may also be used to convey market model information by means of the components SecurityTradingRules and StrikeRules. Related instruments from the list can be added, modified or removed with ListUpdateAction(1324). Otherwise this component is conceptually identical to the SecListGrp component. The component layout is available here.
SecLstUpdRelSymsLegGrp
This component is a repeating group that is part of the SecLstUpdRelSymGrp component and is used to update leg level information together with stipulations and benchmark curve data for each leg. It is conceptually identical to the InstrmtLegSecListGrp component that is part of the SecListGrp component. The component layout is available here.
SecMassStatGrp
This component is a repeating group that conveys the specified instrument’s trade status exceptions when different from SecurityMassTradingStatus(1679) on the level above. The component layout is available here.
SecondaryPriceLimits
This component is a repeating group that is part of the RelSymDerivSecGrp component and is used to define price limits for individual related instruments such as options of a series. It provides an ability to override the overall price limit settings defined in the DerivativeSecurityDefinition component by means of the PriceLimits component. The component layout is available here.
SecTypesGrp
This component is a repeating group that is part of the SecurityTypes(35=w) message used to convey a list of security (sub)types, products, and/or CFI codes per market (segment) and/or trading (sub)session. The component layout is available here.
SecurityClassificationGrp
This component is a repeating group that supports extended classification of products. The component layout is available here.
SecurityTradingRules
This component is a repeating group that is part of the components MarketSegmentGrp, SecListGrp, and SecLstUpdRelSymGrp to convey trading rules. It is used as part of a security definition to specify the specific security’s standard trading rules such as trading session eligibility and other attributes of the security. The component layout is available here.
StrikeRules
This component is a repeating group that is part of the components MarketSegmentGrp, SecListGrp, and SecLstUpdRelSymGrp to convey specific rules related to strike prices. It is used to define various strike price ranges with different increments, exercise style and maturity rules (via the MaturityRules component) for a market segment or security. The component layout is available here.
TradingSessionRulesGrp
This component is a repeating group that is part of the SecurityTradingRules component used to convey one or more sets of trading rules (TradingSessionRules component) and may be tied to a specific trading (sub)session. The component layout is available here.
Category – Parties Reference Data
Messages
Party Detail Definition Requests
A PartyDetailsDefinitionRequest(35=CX) message is used for defining new parties and modifying or deleting existing parties information, including the relationships between parties. The recipient of the message responds with a PartyDetailsDefinitionRequestAck(35=CY) message to indicate whether the request was accepted or rejected. The message layout is available here.
Party Detail Definition Request Acknowledgements
A PartyDetailsDefinitionRequestAck(35=CY) message is used as a response to the PartyDetailsDefinitionRequest(35=CX) message. The request can be accepted (with or without changes) or rejected. The message layout is available here.
Party Detail List Requests
A PartyDetailsListRequest(35=CF) message is used to request for information on one or more party(-ies) and their relationships from a central master reference system or another party that stores and maintains party reference information. The central master reference system can be an exchange that provides such information to trading applications that connect to it. Reference information may include relationships between parties. The message layout is available here.
Party Detail Lists
A PartyDetailsListReport(35=CG) message is used as a response to the PartyDetailsListRequest(35=CF) message to report party reference data information. It may also be used in an unsolicited manner to unilaterally disseminate party reference data. The message layout is available here.
Party Detail List Updates
A PartyDetailsListUpdateReport(35=CK) message is used to update party reference data information. The message layout is available here.
Party Entitlement Definition Requests
A PartyEntitlementsDefinitionRequest(35=DA) message is used for defining new entitlements and modifying or deleting existing entitlements for the specified party(-ies). The PartyEntitlementsDefinitionRequestAck(35=DB) message is the response, used to indicate whether the request was accepted or rejected. The message layout is available here.
Party Entitlement Definition Request Acknowledgements
A PartyEntitlementsDefinitionRequestAck(35=DB) message is used as a response to the PartyEntitlemensDefinitionRequest(35=DA) message to accept (with or without changes) or reject the definition of party entitlements. The message layout is available here.
Party Entitlement Requests
A PartyEntitlementsRequest(35=CU) message is used to request for entitlement information for one or more specific party(-ies), specific party role(s), or specific instrument(s). The message layout is available here.
Party Entitlement Reports
A PartyEntitlementsReport(35=CV) message is used to report entitlements for one or more specific party(-ies), specific party role(s), or specific instrument(s). The message layout is available here.
Party Entitlement Updates
A PartyEntitlementsUpdateReport(35=CZ) message is used to convey incremental changes to party entitlements. It is similar to the PartyEntitlementsReport(35=CV) message. This message uses the PartyEntitlementsUpdateGrp component which includes the ability to specify an update action using ListUpdateAction(1324). The message layout is available here.
Party Risk Limit Definition Requests
A PartyRiskLimitsDefinitionRequest(35=CS) message is used to define risk limits for a party. The message layout is available here.
Party Risk Limit Definition Request Acknowledgements
A PartyRiskLimitsDefinitionRequestAck(35=CT) message is used for accepting (with or without changes) or rejecting the definition of risk limits. The message layout is available here.
Party Risk Limit Requests
A PartyRiskLimitsRequest(35=CL) message is used to request for risk information for specific parties, specific party roles or specific instruments. The message layout is available here.
Party Risk Limits
A PartyRiskLimitsReport(35=CM) message is used as a response to the PartyRiskLimitsRequest(35=CL) message to report party risk limit information. It may also be used in an unsolicited manner to unilaterally disseminate party risk limit information. The message layout is available here.
Party Risk Limit Acknowledgements
A PartyRiskLimitsReportAck(35=DE) message is used as a response to the PartyRiskLimitReport(35=CM) or PartyRiskLimitUpdateReport(35=CR) messages to acknowledge or reject those messages. The message layout is available here.
Party Risk Limit Updates
A PartyRiskLimitsUpdateReport(35=CR) message is used to convey incremental changes to party risk limits. It is similar to the PartyRiskLimitsReport(35=CM) message. This message uses the PartyRiskLimitsUpdateGrp component which includes an update action using ListUpdateAction(1324). The message layout is available here.
Components
EntitlementGrp
This component is a repeating group that conveys a list of entitlements for one specific party, or relationship between two parties. Each entitlement may be further limited or clarified using optional fields and components. An entitlement may contain an EntitlementType(1775), which states what can be done at a gross or general level, e.g. that a party is entitled to make markets. It may be limited further within the InstrumentScopeGrp component, e.g. that such market making is allowed only for a list of stocks. The EntitlementAttribGrp component contains fine details clarifying or limiting the EntitlementType(1775), e.g. that such market making must be conducted with a specific minimum quote size and a specific maximum spread. The component layout is available here.
EntitlementAttribGrp
This component is a repeating group that conveys a list of one or more attributes related to an entitlement and thereby further reducing the scope of an entitlement. The component layout is available here.
EntitlementTypeGrp
This component is a repeating group that conveys a list of entitlement types. The component layout is available here.
PartyDetailAckGrp
This component is a repeating group that is used in the PartyDetailsDefinitionRequestAck(35=CY) message to provide the status of each action (add, modify or delete) requested by the PartyDetailsDefinitionRequest(35=CX) message. The PartyDetailDefinitionStatus(1879) field is used to indicate the status of the requested action. In the case where an add or modify request is accepted with changes, the PartyDetailGrp component is required, specifying the complete set of party details that have been accepted for the party included. The component layout is available here.
PartyDetailsUpdateGrp
This component is a repeating group that contains the PartyDetailGrp component and ListUpdateAction(1324) to define the type of update. The component layout is available here.
PartyEntitlementAckGrp
This component is a repeating group that is used in the PartyEntitlementsDefinitionRequestAck(35=DB) message to provide the status of each action (add, modify or delete) requested by the PartyEntitlementsDefinitionRequest(35=DA) message. The EntitlementStatus(1883) field is used to indicate the status of the requested action. In the case where an add or modify request is accepted with changes, the EntitlementGrp component is required, specifying the complete set of entitlements that have been accepted for the party included. The component layout is available here.
PartyEntitlementGrp
This component is a repeating group that conveys a list of parties (optionally including related parties) and the entitlements for each. The component layout is available here.
PartyEntitlementUpdateGrp
This component is a repeating group that is used to supply incremental entitlement definition changes for the party(-ies) specified in the PartyDetailGrp component. The update action type is specified using ListUpdateAction(1324). The component layout is available here.
PartyRiskLimitsAckGrp
This component is a repeating group based on the PartyRiskLimitsGrp component with an additional field RiskLimitStatus(1763) to accept (with or without changes) or reject individual risk limits. It is only used in the PartyRiskLimitDefinitionRequestAck(35=CT) message, the response to the request to define risk limits. An approval with changes requires the inclusion of the RiskLimitsGrp component with the complete set of risk limits that have been accepted for the party defined. The component layout is available here.
PartyRiskLimitsGrp
This component is a repeating group of parties and one or more risk limits for each party. The component layout is available here.
PartyRiskLimitsUpdateGrp
This component is a repeating group based on the PartyRiskLimitsGrp component with an additional field ListUpdateAction(1324) to support incremental changes of risk limit definitions. The group is part of both the (initial) definition request as well as part of the update report for risk limits. The component layout is available here.
RequestedRiskLimitTypesGrp
This component is a repeating group to convey a list of risk limit types being requested. The component layout is available here.
RiskInstrumentScopeGrp
This component is a repeating group of one or more instances of the InstrumentScope component. Used to specify the instruments to which a risk limit request applies or does not apply as defined by InstrumentScopeOperator(1535). The component layout is available here.
RiskLimitsGrp
This component is a repeating group of risk limit types and instruments for which the risk limits do or do not apply. The component layout is available here.
RiskLimitTypesGrp
This component is a repeating group that defines one or more risk limits with key attributes such as a limit type and an amount. The component layout is available here.
RiskWarningLevelGrp
This component is a repeating group that may be used to convey warning levels as percentages or absolute amounts which cause a RiskWarningLevelAction(1769) to be taken, e.g. a notification, rejection or even a disconnection of the trader or firm having surpassed the predefined limit. The component layout is available here.
Category – Parties Action
Messages
Party Action Requests
The PartyActionRequest(35=DH) message is used to request an action be taken on the specified party, e.g. suspend or halt the specified party from further trading activities at the respondent. The respondent must respond with a PartyActionReport(35=DI) message. The message layout is available here.
Party Action Reports
The PartyActionReport(35=DI) message is used to respond to the PartyActionRequest(35=DH) message, indicating whether the request has been received, accepted or rejected. It may also be used in an unsolicited manner to report on party actions taken, e.g. reinstatements after a manual intervention out of band. The message layout is available here.
Party Risk Limit Check Requests
The PartyRiskLimitCheckRequest(35=DF) message is used to request for approval of credit or risk limit amount intended to be used by a party in a transaction from another party that holds the information. The message layout is available here.
Party Risk Limit Check Request Acknowledgements
The PartyRiskLimitCheckRequestAck(35=DG) message is used to acknowledge a PartyRiskLimitCheckRequest(35=DF) message and to respond whether the limit check request was approved or not. When used to accept the PartyRiskLimitCheckRequest(35=DF) message the respondent may also include the limit amount that was approved. The message layout is available here.
Components
This category has no local components.
Common Components
Common components are components that are used within a single business area but across two or more categories. Common components are global if they are used across two or more business areas and are described in the overall Introduction of the normative specification of the application layer.
AuctionTypeRuleGrp
This component is a repeating group that is part of the TradingSessionRules component. It is used to specify the auction rule applicable for a given product group or complex, for example. The component layout is available here.
BaseTradingRules
This component is part of the SecurityTradingRules component as well as the market structure definition messages. It is used to specify trading rules that are applicable to a market, market segment or individual security independent of a trading session. The component layout is available here.
ExecInstRules
This component is a repeating group that is part of the TradingSessionRules component as well as the market structure definition messages. It is used to specify one or more execution instructions supported for trading applicable to a market, market segment or individual security definition independent of a trading session. The component layout is available here.
InstrumentScope
This component is part of the InstrumentScopeGrp component to specify instruments applicable to the scope operator. The component layout is available here.
InstrumentScopeGrp
This component is a repeating group of one or more instances of the InstrumentScope component. Used to specify the instruments to which a request or report applies or does not apply as defined by InstrumentScopeOperator(1535). The component layout is available here.
InstrumentScopeSecurityAltIDGrp
This component is a repeating group that is part of the InstrumentScope component. It is used to provide alternate identifiers for a given security. The component layout is available here.
LotTypeRules
This component is a repeating group that is part of the BaseTradingRules component. It is used to convey one or more lot types together with its minimum lot size. It may be used as a more generic alternative to RoundLot(561). The component layout is available here.
MarketDataFeedTypes
This component is a repeating group that is part of the BaseTradingRules component. It is used to convey one or more classes of service, possibly together with a market depth and type of order book (e.g. price depth). The component layout is available here.
MarketSegmentScopeGrp
This component is a repeating group that is used to conveys a list of markets and, optionally, their market segments. The component layout is available here.
MatchRules
This component is a repeating group that is part of the TradingSessionRules component as well as the market structure definition messages. It is used to convey applicable matching rules or algorithms (e.g. FIFO), to limit orders to a specific type of matching, such as continuous trading or auctions. The component layout is available here.
OrdTypeRules
This component is a repeating group that is part of the TradingSessionRules component as well as the market structure definition messages. It is used to convey order type(s) applicable for the market or trading session. The component layout is available here.
PriceLimits
This component is part of the BaseTradingRules component. It is used to convey price limit attributes such as a lower and/or upper limit price or a trading reference price. The component layout is available here.
PriceRangeRuleGrp
This component is a repeating group that is part of the BaseTradingRules component. It is used to specify the price range rules for a given product group or complex. The component layout is available here.
QuoteSizeRuleGrp
This component is a repeating group that is part of the BaseTradingRules component. It is used to specify rules for minimum bid and offer sizes of quotes. The component layout is available here.
RequestedPartyRoleGrp
This component is a repeating group that defines the scope of a query/request for one or more specific party roles. The component layout is available here.
RequestingPartyGrp
This component is a repeating group that is conceptually identical to the Parties component. It may be used to identify the party making the request and their role. The component layout is available here.
RequestingPartySubGrp
This component is a repeating group that is part of the repeating group RequestingPartyGrp and conceptually identical to the PtysSubGrp component. It is used to provide additional or supplemental information related to the instance of the identified party it is attached to. The component layout is available here.
RoutingGrp
This component is a repeating group that is used to allow the application message sender to instruct the intermediary distributing the message who to further send (i.e. target) the application message to. The original sender may also instruct who is not allowed to receive (i.e. block) the message. When provided, the routing instructions provided in this component are effective on a message by message basis. The component layout is available here.
TickRules
This component is a repeating group that is part of the BaseTradingRules component. It is used to convey one or more tick price ranges along with allowed increments reflecting how the prices inside this range can be quoted and traded. The component layout is available here.
TimeInForceRules
This component is a repeating group that is part of the TradingSessionRules component as well as the market structure definition messages. It is used to convey order validity (i.e. time in force) values applicable for the market or trading session. The component layout is available here.
TradingSessionRules
This component is part of the components TradingSessionRulesGrp and TrdSessLstGrp. It is used to define the applicable rules for a single trading session. The component layout is available here.