FIX 4.4 : Market Data Request <V> message

Structure | Related Messages

Description

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 Market Data Request <V> is a general request for market data on specific securities or forex quotes.

A successful Market Data Request <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. Or 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 foreign exchange, conventions for identifying the forex transaction are as follows:

  • The forex Symbol <55> is defined in Electronic Broking Services, Ltd. (see http://www.ebs.com) format: "CCY1/CCY2".
    • Rates are expressed as "currency1 in currency2" (or "currency2 per currency1") and are calculated as CCY2 divided by CCY1 (NOT CCY1 divided by CCY2)
    • e.g. "GBP/USD" represents a rate expressed as USD per GBP, "USD/JPY" represents a rate expressed as JPY per USD, etc.).
    • CCY1 and CCY2 are ISO currency codes
  • The value of the Currency <15> field represents the denomination of the Quantity <53> fields (e.g. JPY represents quantity of JPY).
  • See VOLUME 7 - PRODUCT: FOREIGN EXCHANGE

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.

A Snapshot causes the current state of the market to be sent. A Snapshot + Updates causes the current state of the market to be sent, and any updates as they occur, until the client requests that the Snapshot + Updates be disabled.

When just a Snapshot is requested, the complete data for only one security or forex quote will be returned per FIX Market Data message.

When Snapshot + Updates is requested, updates may be full or incremental:

  • Full Refresh. This mode is optimized to trade off increased bandwidth for simplicity in processing and is intended for requests on only a few instruments. Each FIX Market Data message in response to the request will contain the complete data requested for one instrument. If more than just the top of book is requested, this means that both sides, and all price tiers, must be reported in that Market Data message.
  • Incremental Refresh. This mode is optimized for handling requests for many instruments while conserving bandwidth. Each Market Data Entry is assigned an MDEntryID <278> unique among all other active entries, and several incremental updates of entries for different instruments can be included in one FIX Market Data message.

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 NoMDEntryTypes <267> field and MDEntryType <269> repeating group to list all MDEntryType <269> values that should be returned.

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 Market Data Request Reject <Y> may be sent in response to a request indicating that it cannot be honored.

Structure

Tag Field Name Req'd Comments
<MessageHeader> Y MsgType <35> = V
262 MDReqID Y

Must be unique, or the ID of previous Market Data Request <V> to disable if SubscriptionRequestType <263> = Disable previous Snapshot + Updates Request (2).

263 SubscriptionRequestType Y

SubcriptionRequestType indicates to the other party what type of response is expected. A snapshot request only asks for current information. A subscribe request asks for updates as the status changes. Unsubscribe will cancel any future update messages from the counter party.

264 MarketDepth Y
265 MDUpdateType N

Required if SubscriptionRequestType <263> = Snapshot + Updates (1).

266 AggregatedBook N
286 OpenCloseSettlFlag N

Can be used to clarify a request if MDEntryType <269> = Opening Price <44>(4), Closing Price <44>(5), or Settlement Price <44>(6).

546 Scope N

Defines the scope(s) of the request

547 MDImplicitDelete N

Can be used when MarketDepth <264> >= 2 and MDUpdateType <265> = Incremental Refresh(1).

267 NoMDEntryTypes Y

Number of MDEntryType <269> fields requested.

=> 269 MDEntryType Y

Must be the first field in this repeating group. This is a list of all the types of Market Data Entries that the firm requesting the Market Data is interested in receiving.

146 NoRelatedSym Y

Number of symbols (instruments) requested.

=> Component Block - <Instrument> Y

Insert here the set of "<Instrument>" (symbology) fields defined in "COMMON COMPONENTS OF APPLICATION MESSAGES"

=> 711 NoUnderlyings N

Number of underlyings

=> => Component Block - <UnderlyingInstrument> N

Must be provided if Number of underlyings > 0

=> 555 NoLegs N

Required for multileg quotes

=> => Component Block - <InstrumentLeg> N

Required for multileg quotes

For Swaps one leg is Buy and other leg is Sell

386 NoTradingSessions N

Number of trading sessions for which the request is valid.

=> 336 TradingSessionID N
=> 625 TradingSessionSubID N
815 ApplQueueAction N

Action to take if application level queuing exists

812 ApplQueueMax N

Maximum application queue depth that must be exceeded before queuing action is taken.

<MessageTrailer> Y

 

Related Messages

Onix Solutions