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:

  1. INDICATION
  2. EVENT COMMUNICATIONS
  3. QUOTATION / NEGOTIATION
  4. MARKET DATA
  5. MARKET STRUCTURE REFERENCE DATA
  6. SECURITIES REFERENCE DATA
  7. APPENDIX: COMPONENTS AND MESSAGES

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.

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.

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 Components
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 Components
Repeating InstrmtLegIOIGrp Indication
Repeating InstrmtLegSecListGrp SecuritiesReferenceData
Repeating InstrmtMDReqGrp MarketData
Repeating IOIQualGrp Indication
Repeating LegQuotGrp QuotationNegotiation
Repeating LegQuotStatGrp QuotationNegotiation
Repeating LinesOfTextGrp EventCommunication
Repeating LotTypeRules Common Components
Repeating MarketDataFeedTypes Common Components
Repeating MarketSegmentGrp SecuritiesReferenceData
Repeating MatchRules Common Components
Repeating MaturityRules SecuritiesReferenceData
Repeating MDFullGrp MarketData
Repeating MDIncGrp MarketData
Repeating MDReqGrp MarketData
Repeating MDRjctGrp MarketData
Repeating NestedInstrumentAttribute SecuritiesReferenceData
Repeating NewsRefGrp EventCommunication
Repeating OrdTypeRules Common Components
Non-Repeating PriceLimits Common Components
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 Components
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 Components
Repeating TimeInForceRules Common Components
Non-Repeating TradingSessionRules Common Components
Repeating TradingSessionRulesGrp SecuritiesReferenceData
Repeating TrdSessLstGrp MarketStructureReferenceData

Messages

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

Common Components

BaseTradingRules

This component is part of the SecurityTradingRules component as well as the MarketDefinition(35=BU) and MarketDefinitionUpdateReport(35=BV) messages. It contains the components LotTypeRules, PriceLimits, and TickRules as well as a number of individual attributes used to convey the trading rules, such as default price type, minimum / maximum order size. The component layout is available here.

ExecInstRules

This component is a repeating group that is part of the common TradingSessionRules component as well as the MarketDefinition(35=BU) and MarketDefinitionUpdateReport(35=BV) messages. It conveys one or more execution instructions supported for trading. The component layout is available here.

LotTypeRules

This component is a repeating group that is part of the common BaseTradingRules component to convey one or more lot types together with its minimum lot size. It can 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 common BaseTradingRules component 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.

MatchRules

This component is a repeating group that is part of the common TradingSessionRules component. It conveys one or more valid matching algorithms (e.g. FIFO), possibly limited 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 common TradingSessionRules component as well as the MarketDefinition(35=BU) and MarketDefinitionUpdateReport(35=BV) messages. It conveys one or more valid order type(s) applicable for the market or trading session. The component layout is available here.

PriceLimits

This component is part of the common BaseTradingRules component 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.

RoutingGrp

This component is a repeating group that is part of the messages Email(35=C), IOI(35=6), News(35=B), MarketDataIncrementalRefresh(35=X), and MarketDataSnapshotFullRefresh(35=W). It conveys one or more routing targets that are permitted or blocked by the sender of the message containing this component. The component layout is available here.

TickRules

This component is a repeating group that is part of the common BaseTradingRules component 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 common TradingSessionRules component as well as the MarketDefinition(35=BU) and MarketDefinitionUpdateReport(35=BV) messages. It conveys one or more 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 trading session and contains the common components OrdTypeRules, TimeInForceRules, ExecInstRules, MatchRules, and MarketDataFeedTypes and has no individual attributes. The component layout is available here.

Category – Indication

Components

InstrmLegIOIGrp

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” (AOL) by means of IOIQualifier(104), applicable for the IOI. The component layout is available here.

Messages

Advertisements

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). The message layout is available here.

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). The message layout is available here.

Category Event Communication

Components

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.

Messages

News

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 message layout is available here.

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. The message 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.

Components

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 can 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 general InstrmtLegGrp component. The component layout is available here.

QuoteEntryAckGrp

This component is a repeating group that can be used in the MassQuoteAck(35=b) message to acknowledge individual quote entries as part of the acknowledgement of a quote set (see QuotSetAckGrp). 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 identifier and full components for an instrument and its legs (for multileg quotes). The instrument legs are specified by means of the general InstrmtLegGrp component. The component layout is available here.

QuotQualGrp

This component is is a repeating group that supports one or more qualifiers as part of a single quote. QuoteQualifier(695) uses the values from IOIQualifier(104) in the IOIQualGrp, e.g. “All or None” (AON). The component layout is available here.

QuotReqGrp

This component is a repeating group that supports one or more quote requests 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 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 can be used in the MassQuoteAck(35=b) message to acknowledge an entire set of quotes. It contains the QuotEntryAckGrp component 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 in case of message fragmentation being used, see QuotSetGrp component). The component layout is available here.

QuotSetGrp

This component is a repeating group that is required in the MassQuote(35=i) message to convey quote sets. It is required to contain the QuotEntryGrp component to convey individual quote entries. 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 in case of fragmentation) with TotNoQuoteEntries(304). Message fragmentation is supported to allow a split of logical quote sets across multiple physical messages and requires the use of LastFragment(893). 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 instrument legs are specified by means of the global InstrmtLegGrp component. The component layout is available here.

Messages

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). 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 for all quoting models. 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 can 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) 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)). The message layout is available here.

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. 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. 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”. The message layout is available here.

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

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 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. The message layout is available here.

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). The message layout is available here.

Category – Market Data

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 instrument legs are specified by means of the global InstrmtLegGrp component. 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 market data elements for a single instrument. These data elements are identified by the MDEntryType(269) field and may include bids and/or offers, imbalances, index values, opening, closing, settlement, high, low, and/or VWAP prices, trade volume, or open interest. Apart from many individual attributes it also contains 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. The instrument legs are specified by means of the global InstrmtLegGrp component. MDIncGrp can 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 incremental update, has the possibility to reference a previous entry by means of MDEntryRefID(280), and can define whether a market data entry impacts statistics (see StatsIndGrp). 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 can 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.

SecSizesGrp

This component is a repeating group that can 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 MDIncGrp to include market data entries eligible to be included into statistics such as exchange last, high, or low. Note that 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 global Parties component together with the optional StrmAsgnReqInstrmtGrp which specifies the related streams, e.g. EUR/USD prices. 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, which specifies the related streams, e.g. EUR/USD prices, the client is assigned to receive. The component layout is available here.

StrmAsgnReqInstrmtGrp

This component is a repeating group that specifies 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.

StrmAsgnRptInstrmtGrp

This component is a repeating group that provides 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.

Messages

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. The message layout is available here.

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.

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 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).

The message layout is available here.

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. The message layout is available here.

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). 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 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. 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.

Category – Market Structure Reference Data

Components

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 common component TradingSessionRules. The component layout is available here.

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 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 subscription request. This is done via SubscriptionRequestType(263). The message layout is available here.

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. The message layout is available here.

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. 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. 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. The message layout is available here.

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. The message layout is available here.

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. 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 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. 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. The message layout is available here.

Category – Securities Reference Data

Components

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 global EvntGrp component that is part of the global 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 global 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 is identical to the global AttrbGrp component that is part of the global 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 identical to the global 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 global Parties component. The component layout is available here.

DerivativeInstrumentPartySubIDsGrp

This component is a repeating group that is part of the DerivativeInstrumentParties component and identical to the global 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 identical to the global 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. DerivativeSecurityAltIDSource(1220) uses the values from SecurityIDSource(22). 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 identical to the global SecurityXML component to carry 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 and 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 that is part of the DerivativeSecurityDefinition component. It supports the definition of one or more markets and/or market segments together with the applicable trading rules via the SecurityTradingRules component and rules to determine new strike prices using the StrikeRules. 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 and is identical to the global AttrbGrp component that is part of the global 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. NestedInstrAttribType(1210) uses the values from InstrAttribType(871). The component layout is available here.

RelSymDerivSecGrp

This component is a repeating group that is part of the DerivativesSecurityList(35=AA) message 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 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. ListUpdateAction(1324) allows to make changes to add, modify or remove related instruments from the list. This component is 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 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. The component layout is available here.

SecLstUpdRelSymGrp

This component is a repeating group that is part of the SecurityListUpdateReport(35=BK) message 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. ListUpdateAction(1324) allows to make changes to add, modify or remove related instruments from the list. Otherwise this component is 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 identical to the InstrmtLegSecListGrp component that is part of the SecListGrp component. 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 common 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.

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. It contains the components TradingSessionRulesGrp, NestedInstrumentAttribute as well as the common BaseTradingRules component and has no individual attributes. 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 trading 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 (common component TradingSessionRules) related to a specific trading (sub)session. The component layout is available here.

Messages

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. The message layout is available here.

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.

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. 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.

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, see FIXimate for details.

The SecurityListRequest(35=x) message may also be used to request a list of securities for a given market segment. 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). 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. The message layout is available here.

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, see FIXimate for details.

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.

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.

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.

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. 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 contains SubscriptionRequestType(263). This field tells the counterparty 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.

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.