FINANCIAL INFORMATION EXCHANGE (FIX)

FIX APPLICATION LAYER

Business Area: Pre-Trade

FIX Latest

As of EP258, July 2020

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. PARTIES REFERENCE DATA
  8. PARTIES ACTION
  9. 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 Components and Messages for Pre-Trade

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.

TypeNameCategory
RepeatingAuctionTypeRuleGrpCommon Components
Non-RepeatingBaseTradingRulesCommon Components
RepeatingClearingAccountTypeGrpSecurities Reference Data
RepeatingClearingPriceParametersGrpSecurities Reference Data1
RepeatingDerivativeEventsGrpSecurities Reference Data
Non-RepeatingDerivativeInstrumentSecurities Reference Data2
RepeatingDerivativeInstrumentAttributeSecurities Reference Data3
RepeatingDerivativeInstrumentPartiesSecurities Reference Data
RepeatingDerivativeInstrumentPartySubIDsGrpSecurities Reference Data
RepeatingDerivativeSecurityAltIDGrpSecurities Reference Data
Non-RepeatingDerivativeSecurityDefinitionSecurities Reference Data4
Non-RepeatingDerivativeSecurityXMLSecurities Reference Data
RepeatingEntitlementGrpParties Reference Data
RepeatingEntitlementAttribGrpParties Reference Data
RepeatingEntitlementTypeGrpParties Reference Data
RepeatingExecInstRulesCommon Components
RepeatingFlexProductEligibilityGrpMarket Structure Reference Data5
RepeatingInstrmtLegIOIGrpIndication
RepeatingInstrmtLegSecListGrpSecurities Reference Data
RepeatingInstrmtMDReqGrpMarket Data
Non-RepeatingInstrumentScopeCommon Components
RepeatingInstrumentScopeGrpCommon Components
RepeatingInstrumentScopeSecurityAltIDGrpCommon Components
RepeatingIOIQualGrpIndication
RepeatingLegQuotGrpQuotation Negotiation
RepeatingLegQuotStatGrpQuotation Negotiation
RepeatingLinesOfTextGrpEvent Communication
RepeatingLotTypeRulesCommon Components
RepeatingMarketDataFeedTypesCommon Components
RepeatingMarketSegmentGrpSecurities Reference Data
RepeatingMarketSegmentScopeGrpCommon Components
RepeatingMatchRulesCommon Components
RepeatingMaturityRulesSecurities Reference Data
RepeatingMDFullGrpMarket Data
RepeatingMDIncGrpMarket Data
RepeatingMDReqGrpMarket Data
RepeatingMDRjctGrpMarket Data
Non-RepeatingMDStatisticParametersMarket Data
RepeatingMDStatisticReqGrpMarket Data
RepeatingMDStatisticRptGrpMarket Data
RepeatingNestedInstrumentAttributeSecurities Reference Data
RepeatingNewsRefGrpEvent Communication
RepeatingOrdTypeRulesCommon Components
RepeatingPartyDetailAckGrpParties Reference Data
RepeatingPartyDetailsUpdateGrpParties Reference Data
RepeatingPartyEntitlementAckGrpParties Reference Data
RepeatingPartyEntitlementGrpParties Reference Data
RepeatingPartyEntitlementUpdateGrpParties Reference Data
RepeatingPartyRiskLimitsAckGrpParties Reference Data
RepeatingPartyRiskLimitsGrpParties Reference Data
RepeatingPartyRiskLimitsUpdateGrpParties Reference Data
Non-RepeatingPriceLimitsCommon Components
RepeatingPriceMovementGrpSecurities Reference Data
RepeatingPriceMovementValueGrpSecurities Reference Data
RepeatingPriceRangeRuleGrpCommon Components
RepeatingQuotCxlEntriesGrpQuotation Negotiation
RepeatingQuoteEntryAckGrpQuotation Negotiation
RepeatingQuotEntryGrpQuotation Negotiation
RepeatingQuotQualGrpQuotation Negotiation
RepeatingQuotReqGrpQuotation Negotiation
RepeatingQuotReqLegsGrpQuotation Negotiation
RepeatingQuotReqRjctGrpQuotation Negotiation
RepeatingQuotSetAckGrpQuotation Negotiation
RepeatingQuotSetGrpQuotation Negotiation
RepeatingQuoteAttributeGrpQuotation Negotiation6
RepeatingQuoteSizeRuleGrpCommon Components
RepeatingRelatedMarketSegmentGrpMarket Structure Reference Data7
RepeatingRelSymDerivSecGrpSecurities Reference Data
RepeatingRelSymDerivSecUpdGrpSecurities Reference Data
RepeatingRequestedRiskLimitTypesGrpParties Reference Data
RepeatingRequestedPartyRoleGrpCommon Components
RepeatingRequestingPartyGrpCommon Components
RepeatingRequestingPartySubGrpCommon Components
RepeatingRFQReqGrpQuotation Negotiation
RepeatingRiskInstrumentScopeGrpParties Reference Data
RepeatingRiskLimitsGrpParties Reference Data
RepeatingRiskLimitTypesGrpParties Reference Data
RepeatingRiskWarningLevelGrpParties Reference Data
RepeatingRoutingGrpCommon Components
RepeatingSecListGrpSecurities Reference Data
RepeatingSecLstUpdRelSymGrpSecurities Reference Data
RepeatingSecLstUpdRelSymsLegGrpSecurities Reference Data
RepeatingSecMassStatGrpSecurities Reference Data
Non-RepeatingSecondaryPriceLimitsSecurities Reference Data
RepeatingSecSizesGrpMarket Data
RepeatingSecTypesGrpSecurities Reference Data
RepeatingSecurityClassificationGrpSecurities Reference Data8
Non-RepeatingSecurityTradingRulesSecurities Reference Data
RepeatingStatsIndGrpMarket Data
RepeatingStrikeRulesSecurities Reference Data
RepeatingStrmAsgnReqGrpMarket Data
RepeatingStrmAsgnRptGrpMarket Data
RepeatingStrmAsgnReqInstrmtGrpMarket Data
RepeatingStrmAsgnRptInstrmtGrpMarket Data
RepeatingTickRulesCommon Components
RepeatingTimeInForceRulesCommon Components
Non-RepeatingTradingSessionRulesCommon Components
RepeatingTradingSessionRulesGrpSecurities Reference Data9
RepeatingTrdSessLstGrpMarket Structure Reference Data

Messages

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

MsgType(35)NameCategory
7AdvertisementIndication
DSCrossRequestIndication
DTCrossRequestAckIndication
AADerivativeSecurityListSecurities Reference Data
zDerivativeSecurityListRequestSecurities Reference Data
BRDerivativeSecurityListUpdateReportSecurities Reference Data
CEmailEvent Communication
6IOIIndication
XMarketDataIncrementalRefreshMarket Data
DRMarketDataReportMarket Data
VMarketDataRequestMarket Data
YMarketDataRequestRejectMarket Data
WMarketDataSnapshotFullRefreshMarket Data
DOMarketDataStatisticsRequestMarket Data
DPMarketDataStatisticsReportMarket Data
BUMarketDefinitionMarket Structure Reference Data
BTMarketDefinitionRequestMarket Structure Reference Data
BVMarketDefinitionUpdateReportMarket Structure Reference Data
iMassQuoteQuotation Negotiation
bMassQuoteAckQuotation Negotiation
BNewsEvent Communication
DIPartyActionReportParties Action
DHPartyActionRequestParties Action
CXPartyDetailsDefinitionRequestParties Reference Data
CYPartyDetailsDefinitionRequestAckParties Reference Data
CGPartyDetailsListReportParties Reference Data
CFPartyDetailsListRequestParties Reference Data
CKPartyDetailsListUpdateReportParties Reference Data
DAPartyEntitlementsDefinitionRequestParties Reference Data
DBPartyEntitlementsDefinitionRequestAckParties Reference Data
CVPartyEntitlementsReportParties Reference Data
CUPartyEntitlementsRequestParties Reference Data
CZPartyEntitlementsUpdateReportParties Reference Data
DFPartyRiskLimitCheckRequestParties Action
DGPartyRiskLimitCheckRequestAckParties Action
CMPartyRiskLimitsReportParties Reference Data
DEPartyRiskLimitsReportAckParties Reference Data
CLPartyRiskLimitsRequestParties Reference Data
CRPartyRiskLimitsUpdateReportParties Reference Data
CSPartyRiskLimitsDefinitionRequestParties Reference Data
CTPartyRiskLimitsDefinitionRequestAckParties Reference Data
SQuoteQuotation Negotiation
CWQuoteAckQuotation Negotiation
ZQuoteCancelQuotation Negotiation
RQuoteRequestQuotation Negotiation
AGQuoteRequestRejectQuotation Negotiation
AJQuoteResponseQuotation Negotiation
aQuoteStatusReportQuotation Negotiation
AIQuoteStatusRequestQuotation Negotiation
AHRFQRequestQuotation Negotiation
dSecurityDefinitionSecurities Reference Data
cSecurityDefinitionRequestSecurities Reference Data
BPSecurityDefinitionUpdateReportSecurities Reference Data
ySecurityListSecurities Reference Data
xSecurityListRequestSecurities Reference Data
BKSecurityListUpdateReportSecurities Reference Data
COSecurityMassStatusSecurities Reference Data
CNSecurityMassStatusRequestSecurities Reference Data
fSecurityStatusSecurities Reference Data
eSecurityStatusRequestSecurities Reference Data
vSecurityTypeRequestSecurities Reference Data
wSecurityTypesSecurities Reference Data
CDStreamAssignmentReportMarket Data
CEStreamAssignmentReportACKMarket Data
CCStreamAssignmentRequestMarket Data
BJTradingSessionListMarket Structure Reference Data
BITradingSessionListRequestMarket Structure Reference Data
BSTradingSessionListUpdateReportMarket Structure Reference Data
hTradingSessionStatusMarket Structure Reference Data
gTradingSessionStatusRequestMarket Structure Reference Data

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

Category – Indication

Components

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.

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.

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

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.

News

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

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

QuoteEntryGrp

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

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

The QuoteAck(35=CW) message is used to acknowledge a Quote(35=S) message submittal or request to cancel an individual quote using the QuoteCancel(35=Z) message during a Quote/Negotiation dialog. It is available for optional use to acknowledge the request to cancel an individual quote (QuoteCancel(35=Z) with QuoteCancelType(298) = 5 (Cancel specified single quote)). 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 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 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.

MDStatisticParameters

This component is part of the components MDStatisticReqGrp and MDStatisticRptGrp. It comprises all parameters that can 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 describing 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 results together with the related set of parameters. 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 the MDIncGrp component 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 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.

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. The values in the fields provided within the request will serve as further filter criteria for the result set.

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 RequestsSubscription 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=SnapshotNot 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 + Updates0 = Full RefreshMarketDataSnapshot-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 + Updates1 = Incremental RefreshMarketDataSnapshot-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 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.

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

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. Fields specified in the request are used as filter criteria to restrict the resulting data returned.

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

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

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

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 is 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 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 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 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. 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 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. NestedInstrAttribType(1210) uses the values from InstrAttribType(871). 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. 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. 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. 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. 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.

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

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

Derivative Security List Requests

The DerivativeSecurityListRequest(35=z) message is used to return a list of derivative 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 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 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.

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. SecurityMassTradingStatus(1679) defines the new state after the 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 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.

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.

Category – Parties Reference Data

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

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.

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.

Entitlements

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.

Category – Parties Action

Components

No local components.

Messages

Party Action Requests

The PartyActionRequest(35=DH) message is used to 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.


  1. Component is defined as Common but only used in the category Securities Reference Data.↩︎
  2. Component is defined as Common (being part of DerivativeSecurityDefinition component) but only used in the category Securities Reference Data.↩︎
  3. Component is defined as Common (being part of DerivativeSecurityDefinition component) but only used in the category Securities Reference Data.↩︎
  4. Component is defined as Common but only used in the category Securities Reference Data.↩︎
  5. Component is defined as Common but only used in the category Market Structure Reference Data.↩︎
  6. Component is defined as Common but only used in the category Quotation / Negotiation.↩︎
  7. Component is defined as Common but only used in the category Market Structure Reference Data.↩︎
  8. Component is defined as Common (being part of DerivativeSecurityDefinition component) but only used in the category Securities Reference Data.↩︎
  9. Component is defined as Common but only used in the category Securities Reference Data.↩︎