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.

The purpose of this document is to provide a technical description of the FIX Market Data Gateway. This document outlines the service, its logic, and message types and fields involved.

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

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

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

Please note that 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 address and port to establish a TCP/IP session with the server. The client will initiate a FIX session by sending the Logon (A) message. The client will identify itself using the SenderCompID (49) field. At each connection MsgSeqNum (34) is reset to 1, the client should set ResetSeqNumFlag (141) to "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, invalid TargetCompID, invalid IP address, invalid password or not having the appropriate privileges to login 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, the server receives a second connection attempt while a valid FIX session is already underway for that same SenderCompID, the server will break the TCP/IP connection with the second connection without sending a Logout or Reject message.

As outlined in the FIX protocol, the client and server will each maintain a separate and independent set of incoming and outgoing message sequence numbers. Sequence numbers should be initialized to 1 (one) at the start of the FIX session and be incremented throughout the session.

If any message sent by the client contains a sequence number that is less than what is expected and the PossDupFlag (43) is not set to “Y”, the server will send a Logout message and terminate the FIX connection. The Logout will contain the next expected sequence number as well as the received sequence number in the Text (58) field.

The client and server will use the Heartbeat 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’s Logon message.

The server will send a Heartbeat 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 the HeartBtInt is set to 0.

If the server detects inactivity for a period longer than the heartbeat interval plus a reasonable transmission time, it will send a Test Request message to force a Heartbeat from the client. If a response to the Test Request is not received by a reasonable transmission time, the server will send a Logout 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 Market Data Request 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 ID of the Subscription Request they wish to cancel.

A successful Market Data Subscription Request returns one or more Market Data (type W or type X) messages, each containing one or more Market Data Entries. Each Market Data Entry can be a Bid, an Offer or a Trade associated with a currency pair.

Requesting just the top of book will result in receipt of just the Best Bid and Best Offer. For a full book, the Bid and Offer 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 Market Data — Snapshot / Full Refresh (W) message contains a full order book for only one currency pair.

A Market Data Request Reject (message type Y) may be sent in response to a request that cannot be honoured.

Client-initiated:

Server-initiated:

The Market Data Snapshot Full Refresh message (type W) is used as the response to a Market Data Request (type 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 Market Data Request (V) message, where the message type is 0 = Snapshot or 1 = SnapshotAndUpdates. In the second case, after the Snapshot only the Market Data - Incremental Refresh (X) messages will come.

The Market Data Incremental Refresh (X) message is used as the response to a Market Data Request (type V) message with SubscriptionRequestType (263) set to '1' = SnapshotAndUpdates. 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. Incremental updates may arrive before Snapshots. To handle this, accumulate Increments in a buffer and wait for the next Snapshot to arrive before appending them to the received Snapshot.

Subscription to incremental updates apart from snapshots 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 snapshot with zero sequence number as the response to a successful subscription.
​

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

Security Status

The Security Status (type f ) message is used as the response to a Security Status

Request (type e) message or sent after trading on a symbol was started or

stopped.

Security Status Request (type e)

Security Status Request (type e) is being used for checking availability of trading on a symbol.

Security Status Message (type f )

​