This document contains descriptions of all the functionalities, even if some of them are not available for client’s users. That must be taken into account during communicating with users.

The FIX5 Market Data Gateway enables clients to anonymously receive order book market data in real time. The interface is a point-to-point service based on the technology and industry standards TCP/IP, FIXT and FIX. The session and application event models and messages are based on versions 1.1 and 5.0 (Service Pack 2) of the FIXT and FIX protocols respectively.

Market data consists of snapshots, increments, and trades. Trades are sent in the same messages as increments.

A snapshot is the current state of the order book for some specific trading pair and depth. Snapshots are sent periodically for all trading pairs and for different depths.

An increment is an incremental update from the previous state of the order book, based on the last snapshot. On the sending side, increments are buffered into a batch. Increments can be sent from this batch:

This means that, if interval = 40 ms and limit = 100, an increment would be sent to the client either after 40 ms, or after the 100th update to the market (e.g., 100 new orders were placed), whichever comes first.

Snapshots and increments, sent independently of each other by separate services, both may contain market data for the same time frame. Changes in Market data are indicated by a sequence number increased by 1 after any snapshot or increment.

Required key:

Field properties:

Placeholders:

All placeholders are series of upper case letters with words separated by underscores (_). For example: in user_ACCOUNT_ID pattern, user_ is the constant part and ACCOUNT_ID is a placeholder.

The CompID of each client must be registered before FIX communications can begin. A single client may have multiple connections to the server (i.e., multiple FIX sessions, or logins, each with its own CompID).

The CompID of the server is ME. The messages sent to the server should contain the CompID assigned to the client in the field SenderCompID(49) and ME in the field TargetCompID(56). The messages sent from the server to the client will contain ME in the field SenderCompID(49) and the CompID assigned to the client in the field TargetCompID(56). The client may also specify ME_MD in the field TargetCompID(56) in order to differentiate connections between FIX5 Trading Gateway and FIX5 Market Data Gateway. In that case, requests with TargetCompID(56) = ME will be processed on FIX5 Trading Gateway only and with TargetCompID(56) = ME_MD—on FIX5 Market Data Gateway or otherwise rejected. Once chosen the same TargetCompID(56) value must be used in all request throughout the entire session.

Each new CompID will be assigned a username and a password on registration.

A scheme for throttling message traffic is implemented, where each CompID is only permitted to submit up to a specified number of messages per second.

Every message which exceeds the maximum rate of a CompID will be rejected via a Business Message Reject (with BusinessRejectReason(380) of ThrottleLimitExceeded(8)).

Client Heartbeat messages, reject messages and any other client-initiated administrative messages are not counted towards the throttling limits.

FIX connections and sessions between the client and server are maintained as specified in the FIX protocol.

Each client will use the assigned IP addresses and ports to establish TCP/IP sessions with the server. Subscription to market data is available after establishing connection via ports according to the table below.

These ports must be used by default if there were no specific ports assigned.

System supports sending increments independently of snapshots, so incoming snapshots would not affect the intensity of increments' publication. In order to access this functionality per symbol, the client performs the following steps:

The client will initiate a FIX session by sending the Logon(35=A) message. The client will identify themselves using the SenderCompID(49) field. At each connection MsgSeqNum(34) is reset to 1, the client should set ResetSeqNumFlag(141) = Y. The server will validate the CompID, password and IP address of the client. Once the client is authenticated, the server will respond with a Logon message.

The client must wait for the server’s Logon response before sending additional messages. If the client sends messages prior to sending the Logon message or prior to receiving the Logon response, the server will break the TCP/IP connection with the client without sending any message.

If a logon attempt fails because of an invalid SenderCompID(49), invalid TargetCompID, invalid IP address, invalid password or not having the appropriate privileges to log in to the gateway, or if the user sends a Logon message with duplicated tags, the server will break the TCP/IP connection with the client without sending a Logout or Reject message.

If during a logon of a SenderCompID(49), the server receives a second connection attempt while a valid FIX session is already underway for that same SenderCompID(49), the server will break the TCP/IP connection with the second connection without sending a Logout or Reject message.

The client and server will use the Heartbeat(35=0) message to exercise the communication line during periods of inactivity and to verify that the interfaces at each end are available. The heartbeat interval will be the HeartBtInt(108) specified in the client Logon(35=A) message.

The server will send a Heartbeat(35=0) anytime it has not transmitted a message for the heartbeat interval. The client is expected to employ the same logic.

As a safety mechanism, the system will not allow the user to login if HeartBtInt(108) = 0.

If the server detects inactivity for a period longer than the heartbeat interval plus a reasonable transmission time, it will send a TestRequest(35=1) message to force a Heartbeat(35=0) from the client. If a response to the TestRequest(35=1) is not received by a reasonable transmission time, the server will send a Logout(35=5) and break the TCP/IP connection with the client. The client is expected to employ similar logic if inactivity is detected on the part of the server.

The client and server will use the Heartbeat(35=0) message to exercise the communication line during periods of inactivity and to verify that the interfaces at each end are available. The heartbeat interval will be the HeartBtInt(108) specified in the client Logon(35=A) message.

The server will send a Heartbeat(35=0) anytime it has not transmitted a message for the heartbeat interval. The client is expected to employ the same logic.

As a safety mechanism, the system will not allow the user to login if HeartBtInt(108) = 0.

If the server detects inactivity for a period longer than the heartbeat interval plus a reasonable transmission time, it will send a TestRequest(35=1) message to force a Heartbeat(35=0) from the client. If a response to the TestRequest(35=1) is not received by a reasonable transmission time, the server will send a Logout(35=5) and break the TCP/IP connection with the client. The client is expected to employ similar logic if inactivity is detected on the part of the server.

Clients can use the MarketDataRequest(35=V) message to both subscribe to and unsubscribe from real-time receipt of Market Data from the exchange.

When making a subscription request, clients must supply the symbols they are requesting market data for and whether they want the entire order book or just the top of the book. Clients can request a one-time Snapshot, or a Snapshot plus ongoing streamed updates.

When unsubscribing, the client must pass the identifier of the subscription request they wish to cancel.

A successful MarketDataRequest(35=V) returns one or more market data messages, each containing one or more market data entries. Each market data entry can be a bid, an ask or a trade associated with a currency pair.

Requesting just the top of the book will result in receipt of just the "best" bid and "best" ask. For a full book, the bid and ask side may each have several market data entries.

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.

Each MarketDataSnapshotFullRefresh(35=W) message contains a full order book for only one currency pair.

A MarketDataRequestReject(35=Y) may be sent in response to a request that cannot be honored.

Client-initiated:

Server-initiated:

Client-initiated:

Server-initiated:

A standard message includes message header, message body, and message trailer. Fields inside the header, body, and trailer consist of TAG=VALUE pairs, and, unless otherwise noted, these fields can be defined in any order.

During formation of a request message, it is necessary to follow the order of tags exactly as given in this specification.

Tags in the range from 10000 to 10100 are custom. Any of them may be ignored if it doesn’t occur in this specification.

The message body fields can be defined in any order, except NoFIELD tags (where FIELD is a field being counted). These tags start repeating data groups. The fields inside these groups must be defined in the order specified in this document.

The message header fields are given in the table below. The first three fields in the header must be BeginString(8), BodyLength(9) and MsgType(35). Other fields can be defined in any order.

The message trailer described in the table below.

The MarketDataSnapshotFullRefresh(35=W) is used as the response to a MarketDataRequest(35=V) message.

A Snapshot is the current state of the order book at the time of the request; it contains only bids and offers for the depth specified in the request.

A Snapshot is always sent in response to a MarketDataRequest(35=V) message, where SubscriptionRequestType(263) = 0 (Snapshot), 1 (Snapshot + Updates). In the second case, after the Snapshot only the MarketDataIncrementalRefresh(35=X) messages will come.

The MarketDataIncrementalRefresh(35=X) message is used as the response to a MarketDataRequest(35=V) message with SubscriptionRequestType(263) = 1 (Snapshot + Updates), 50 (Updates). It contains trades and incremental updates for the order book, such as new, changed, or deleted order book levels. A single message may contain several updates, but it may contain data for only one symbol.

In the case of subscription to Snapshots and Updates via separate feeds (refer to Establishing Connection), Updates arrive before a Snapshot and must be collected in a buffer for the purposes of preserving data continuity. They will share the same MDSeqNum(10020) with the upcoming Snapshot. After Snapshot arrives, clear the buffer from the Increments up to this sequence number inclusively. Then append Increments with higher sequence numbers to the received Snapshot.

Subscription to incremental updates with SubscriptionRequestType(263) = 50 (Updates) may result in a situation when the client cannot determine if they missed any updates since the subscription and before requesting a snapshot because of, possibly, low trading activity. To avoid that, the server will immediately send an empty MarketDataSnapshotFullRefresh(35=W) with zero sequence number in response to a successful subscription.

An additional info message is sent after the futures contract expiration: in this case mark price and index price will be equal to the settlement price, and the open interest will be 0.

The Security Status (type f) message is used as the response to a Security Status Request (type e) message or sent after the Flow emits a message with updated funding information including the following parameters:

A message is also sent after the symbol configuration was changed. In that case, FundingRate(10018), NextFundingTS(10017), and IndicativeFundingRate(10019) fields will be omitted.