Lseg FX Market Data Api Spec v1.3

LSEG FX
FX MARKET DATA API SPECIFICATION (FIX SBE VERSION 2 RELEASE CANDIDATE 2)
Document version 1.3

Date of issue: 18 July 2023
Legal Information
© LSEG 2023. All rights reserved.
LSEG, by publishing this document, does not guarantee that any information contained herein is and will remain accurate or that
use of the information will ensure correct and faultless operation of the relevant service or equipment. LSEG, its agents and
employees, shall not be held liable to or through any user for any loss or damage whatsoever resulting from reliance on the
information contained herein.
This document contains information proprietary to LSEG and may not be reproduced, disclosed, or used in whole or part without
the express written permission of LSEG.
Any Software, including but not limited to, the code, screen, structure, sequence, and organization thereof, and Documentation are
protected by national copyright laws and international treaty provisions. This manual is subject to U.S. and other national export
regulations.
Nothing in this document is intended, nor does it, alter the legal obligations, responsibilities or relationship between yourself and
LSEG as set out in the contract existing between us.
LSEG FX Market Data API Specification (FIX SBE Version 2 Release Candidate 2)
Date of issue: 18 July 2023 2
Contents
Contents
About this document ......................................................................................................................................................................... 6

Intended Readership ....................................................................................................................................................................... 6
In this document .............................................................................................................................................................................. 6
XML Schema................................................................................................................................................................................... 6
For further information..................................................................................................................................................................... 6
Feedback ........................................................................................................................................................................................ 6
Glossary .......................................................................................................................................................................................... 6
Version History ................................................................................................................................................................................ 7
Chapter 1 Market Data API Overview......................................................................................................................................... 9
1.1 Scope .................................................................................................................................................................................. 9
1.2 Supported XML Schemas .................................................................................................................................................... 9
Chapter 2 System Architecture ................................................................................................................................................ 10
2.1 Overview ............................................................................................................................................................................ 10
2.2 Premium IP Multicast Feed ................................................................................................................................................ 10
2.3 Standard TCP/IP Feed ...................................................................................................................................................... 16
2.4 Conflation Setup ................................................................................................................................................................ 18

Chapter 3 Service Description ................................................................................................................................................. 20
3.1 Market Data Dissemination Specifics ................................................................................................................................ 20
3.2 High Availability and Disaster Recovery ............................................................................................................................ 21
3.3 Order Book Replenishment................................................................................................................................................ 22

3.4 Schema Backward Compatibility ....................................................................................................................................... 22
Chapter 4 Message Formats .................................................................................................................................................... 24
4.1 Session Layer Messages ................................................................................................................................................... 24
Contents
4.2 Application Layer Messages .............................................................................................................................................. 33
Appendix A Version History .................................................................................................................................................... 56
About this document ......................................................................................................................................................................... 6

Intended Readership ....................................................................................................................................................................... 6
In this document .............................................................................................................................................................................. 6
XML Schema................................................................................................................................................................................... 6
For further information..................................................................................................................................................................... 6
Feedback ........................................................................................................................................................................................ 6
Glossary .......................................................................................................................................................................................... 6
Version History ................................................................................................................................................................................ 7
Chapter 1 Market Data API Overview......................................................................................................................................... 9
1.1 Scope .................................................................................................................................................................................. 9
1.2 Supported XML Schemas .................................................................................................................................................... 9
Chapter 2 System Architecture ................................................................................................................................................ 10
2.1 Overview ............................................................................................................................................................................ 10
2.2 Premium IP Multicast Feed ................................................................................................................................................ 10
2.3 Standard TCP/IP Feed ...................................................................................................................................................... 16
2.4 Conflation Setup ................................................................................................................................................................ 18

Chapter 3 Service Description ................................................................................................................................................. 20
3.1 Market Data Dissemination Specifics ................................................................................................................................ 20
3.2 High Availability and Disaster Recovery ............................................................................................................................ 21
3.3 Order Book Replenishment................................................................................................................................................ 22

3.4 Schema Backward Compatibility ....................................................................................................................................... 22
Chapter 4 Message Formats .................................................................................................................................................... 24
4.1 Session Layer Messages ................................................................................................................................................... 24
Contents
4.2 Application Layer Messages .............................................................................................................................................. 33
Appendix A Version History .................................................................................................................................................... 56
About this document
About this document

INTENDED READERSHIP
This document is intended for LSEG’s client’s operational technology support and development teams and their respective
associates (i.e., approved vendors) to understand the technical specifications for the connections to receive and access LSEG FX
FIX Market Data API messages.
NOTE
The LSEG FX FIX Market Data API is not in production yet. This API has been made available for early integration.
IN THIS DOCUMENT
This document contains details of the methods and messages required to connect and subscribe to the FIX FX Market Data API.
For both the Premium Multicast Market Data Feed and the TCP/IP Standard Market Data Feed it provides the specifications
required to receive:
• Security Definitions
• Orderbook Updates (Snapshot Full Refresh and Incremental Updates)
• Relevant Statistics
• Security Status
XML SCHEMA
A new schema is released with this specification. See section 1.2 Supported XML Schemas for details.
FOR FURTHER INFORMATION

The QuickStart on the Refinitiv Developer portal describes how to connect and perform basic communication with the FX Market
Data API of the LSEG FXI Trading system.
See the Technical Overview for information on the two key methods to connect to LSEG FX FIX Market Data:
• The Standard TCP/IP Market Data Feed
• Premium Multicast Market Data Feed
For questions or further information related to LSEG Capital Markets Market Data API, please contact the global Refinitiv/LSEG
Help Desk using the link below.
MyRefinitiv – Contact Us
FEEDBACK
If you have any comments on this document, please contact the global Refinitiv/LSEG Help Desk using the link below.
MyRefinitiv – Contact Us
GLOSSARY
Term/abbreviation Description
AES Advanced Encryption Standard
Client Same as Subscriber
About this document
Term/abbreviation Description
Conflation Consolidating updates generated during a given time interval into a single update for dissemination. The
intention is to control and throttle the distribution of order book updates.
Conflation Quantum Configurable time interval in which updates will be conflated.
CTR Counter Mode
EoC End of Conflation
FIX Financial Information eXchange
FIXT FIX Transport - the label is used to identify the separate session layer specification and to identify the
FIX Session version being used
LTP Last Traded Price
M/Cast Multicast
RMO Recognised Market Operator
SBE Simple Binary Encoded
SOFH Simple Open Framing Header
Screened Filtered view of the order book disseminated to a subscriber based on both the bilateral credit
relationships and permissioning. This will only include prices that a subscriber can trade on as a
taker/aggressor/ consumer of liquidity.
Shard The point where Market Data is disseminated for one or more instruments.
TBD To be Decided
TCP Transmission Control Protocol
UDP User Datagram Protocol
Unscreened Unfiltered view of the order book disseminated to a subscriber
VWAP Volume Weighted Average Price
VERSION HISTORY
Any material change, with potential for client impact, is reflected in the first or second digit of the document version with the key
changes highlighted in the version history. Minor changes to improve understanding, grammar, or changes otherwise cosmetic in
nature, are reflected in an increment of the third digit without update to the version history.
Version Section Description

1.3 Market Data API Information containing details of supported XML schemas added. This includes the
Overview introduction of a new schema version number to align with the Spec. This schema is only
changing in name only. The contents are the same.
New Schema Released – Version 1.3
1.3 Standard TCP/IP Details on limitation of Market Data Password length
Feed
1.3 Application Layer Update to when MDHaltReason = Other(100). This can include a halt due to a Public
Messages Holiday.
1.3 High Availability and Updates to description of Multicast Feed Failover behaviour.
Disaster Recovery
1.2 Statistics Calculation Additional information to show differences between how statistics are disseminated.
and Dissemination
1.2 Application Layer Changes in message structure
Messages Reserved tags removed.
Additional tags added in Snapshot and Incremental refresh to handle order book refresh,
failover and slow consumers.
About this document

1.2 Session Layer Changes in message structure
Messages Reserved tags removed.
1.2 Sequencing and New section describing the packet sequencing and gap recovery on Premium IP Multicast
Recovery feed. Including expected Topic and Context messages.
1.2 Handling Slow New section detailing expected message sequences for slow consumers.
Consumers
1.2 Order Book New section detailing expected message sequences for Order book replenishment.
Replenishment
1.2 Schema Backward New section discussing the approach to backwards compatibility.
Compatibility
See Appendix A Version History for all changes prior to version 1.2.
Chapter 1 Market Data API Overview
Chapter 1 Market Data API Overview
1.1 SCOPE
This document overviews the specification for the FX Market Data API. The FX Market Data API is built based on the FIX/SBE
industry standard protocol designed for high performance trading systems. Streams of Simple Binary Encoded (SBE) messages are
conflated and exchanged via Standard TCP/IP and Premium IP Multicast feeds between Venue and Subscribers containing
information for each instrument traded on LSEG Capital Markets.
The session level and application event models and messages are based on FIX SBE Version 2 Release Candidate 2 and FIX
Performance Session Layer (FIXP) version 1.0 as published by the FIX Trading Community and comply with the best practices
outlined by the FIX Market Data Working Group.
1.2 SUPPORTED XML SCHEMAS

The following schema versions are currently supported, but only the most recent schema is aligned with this specification.
Schema File / Version Comment

lseg-fx-market-data-api-schema-v1.3.xml Released with a new name to harmonise versioning of the
(NEW) schema file.
lseg-fx-market-data-api-v1.2-schema-xml v1.0.xml Identical in content to the latest schema.
The latest schema can be downloaded here from the Refinitiv Developer Portal.
NOTE
The specification and schema versions can increment independently. To understand what schemas are supported always refer to
the latest specification.
Chapter 2 System Architecture
2.1 OVERVIEW
The Market Data API architecture reflects the needs and requirements of different groups of subscribers.
Market data disclosure is based on connection type and made available to subscriber groups as follows:
• A Premium Multicast market data feed (available to co-located subscribers only)
• A Standard TCP/IP-based market data feeds available to all subscribers
Subscribers may subscribe to screened or unscreened market data.

All Market Data subscribers can subscribe to data for:
• Security Definition Feed
• Order Book, Security Status and Statistics Feed
They can receive the following FIX/SBE messages via the aforementioned dedicated channels:
• Market Data Snapshot Full Refresh (MDSFR) – provides the latest available picture of the requested market data
• Market Data Incremental Refresh (MDIR) – provides delta updates on top of MDSFR.
• Market Data Rejection – provides reasoning in case of unsuccessful market data requests.
• Security Definitions – publishes instrument related information. Is also used as response in case of unsuccessful Security
Definition Requests.
• Security Status – publishes instrument session changes.
• End of Conflation – marks the end of a conflation quantum and provides the means of publishing the decryption key on the
Market Data on the Premium Feed.
• Encrypted Message Wrapper - provides the encrypted envelope for MDSFR and MDIR messages on the multicast market
data feeds. For Matching Cleared NDF Venues, the Market Data will be provided in this format, but the payload will be
unencrypted.
NOTE
The FIX SBE XML schema used to decode the Market Data messages is common for both the Premium IP Multicast Feed and the
Standard TCP/IP feed.
2.2 PREMIUM IP MULTICAST FEED

This feed is only available to co-located subscribers. Details on specific Multicast IP Addresses and Ports will be configured per
subscriber and communicated by Refinitiv Capital Markets.
Note: In the security definition there are two fields – MDPrimaryPort and MDSecondaryPort. These can be ignored for the Premium
IP Multicast Feed. They are only relevant to the Standard TCP/IP Feed. As above, for the IP and Port, Refinitiv Capital markets will
provide.
The Multicast Market Data Feed is very low latency and conflated. Multiple multicast groups are made available for subscribers,
each pre-configured to disclose market data for a specific range of instruments. The Matching Cleared NDF Venues will send data
unencrypted. All other Venues will send the feed partially encrypted as data such as decryption key is not encrypted.
2.2.1 Matching Cleared NDF Venues

Subscribers receive market data updates on a public multicast group. The messages will be wrapped using the same
EncryptedMessageWrapper, similar to encrypted data. However, the EncryptionType tag will be set to “0” (None) – No encryption.
The message will be tagged with a conflation ID. This data can be immediately decoded using the provided FIX SBE XML Schema
file. On receipt of an End of Conflation (EoC) message with a corresponding conflation ID, no more Market Data updates will be
received in that conflation quantum.
2.2.2 All other Venues

Subscribers can identify the Market Data is encrypted by the EncryptionType Tag in the Encrypted Message Wrapper.
EncryptionType will be set to 1 “AES-128 Counter Mode”. Subscribers are sent market data updates on their private multicast
groups that are encrypted using a common key specific to each quantum. Immediately subsequent to the encrypted market data
being delivered to all subscribers, the decryption key is disclosed to the subscribers on a public multicast group. In this way, even
though the market data consumers receive their encrypted market data updates at slightly different times, they will only be able to
decipher and act upon those updates at substantially the same time.
Figure 1 below shows the connectivity model for Premium IP Multicast Feed.
Figure 1: Connectivity Model for Premium IP Multicast Feed
2.2.3 Message encoding and decoding

When encrypted the Market Data messages (Market Data Snapshot Full Refresh, Market Data Incremental Refresh) are encoded
using the AES-128 algorithm with Counter (CTR) mode enabled and wrapped in the Encrypted Msg Wrapper envelope.
The decryption key is unique per conflation quantum and embedded in the End of Conflation marker.
The decryption key is disclosed via a separate public multicast group available to all subscribers and sent at the end of each
conflation quantum to provide the means of uniformly deciphering market data updates.
The SecurityStatus messages will be sent on the same private market data channels for each instrument, according to the multicast
group setup but unencrypted (no encrypted message wrapper).
When unencrypted, the Market Data message can immediately be read using the FIX SBE XML schema file.
Figure 2 on the following page shows the encapsulation of various sections of the market data messages for the Premium IP
Multicast Feed.
0 (Unencrypted) or 1 (AES-128 Counter
Figure 2: Message Encoding and Decoding Model for Premium IP Multicast Feed
The Advanced Encryption Standard (AES) is an algorithm for block encryption which uses the same key for both encryption and
decryption of data. Out of the multitude of standardized modes of operations of the AES algorithm, the Counter Mode (CTR) is used
for the purpose of encrypting the market data messages. The CTR mode used with the hardware acceleration (Intel AES New
Instructions) provides tremendous efficiency improvements as compared to alternate encryption algorithms and modes. The
encryption is achieved by using the XOR (exclusive OR) operation on the block cipher, constructed with the key and the
concatenated structure of the nonce and the counter, and the actual plain text market data message, as seen in the below diagram.
At the end of each conflation quantum, the decryption of the messages is accomplished by applying the XOR operation on the
resulted ciphertext and the block cipher.
Figure 3: Counter (CTR) mode Decryption
2.2.3.1 IGMP configuration

The multicast network will be implemented using IGMP version 2.
Multiple shards will send data to the same IGMP group, facilitating the market data traffic to the market data subscribers without
isolating or separating the multicast groups. Co-located subscribers will indicate their intention to become members of a public or
private multicast group by sending a report (join) message, whereas ceasing to be part of a multicast group will be indicated via the
leave group message.
2.2.4 Security Definition Feed

Details of the entire universe of instruments within the venue are periodically disclosed via Security Definition messages on a
dedicated public multicast group as well as on event-based triggers via the same multicast group. (i.e. at date roll)
The mechanism of disclosing Security Definitions on a periodic basis is an enabler for late joiners to be up to date with the latest
instrument data.
2.2.5 Order Book, Security Status and Statistics Feed

Subscribers have access to multiple multicast instrument groups which disseminate orderbook, Security Status and statistics
updates for the targeted instruments.
Security Status messages are included on the Market update feed. Therefore, for Matching Cleared NDF Venues, they will be
unencrypted on the public group where MDIR/MDSFRs are received. For all other venues they will be sent on the same private
group as the MDIR/MDSFRs will be received. – these messages indicate a session change or an intra-day instrument change.
Market Data Snapshot Full Refresh (MDSFR) and Market Data Incremental Refresh (MDIR) are encrypted and include statistics in-
line.
The encrypted Market data messages transmitted via these multicast groups are encrypted using a Nonce, generated at the
beginning of the conflation, and a Conflation ID denoting the UNIX timestamp of the conflation quantum. For the purposes of
recovering from dropped packets Market Data Snapshot Full Refresh (MDSFR) messages are sent on the private multicast groups
intermittently at regular predefined intervals. For the vast majority of conflation quantums however, Market Data Incremental
Refresh messages are sent and express ‘deltas’ from the previous communicated state of an instrument’s book. Sequence number
in the Sequence message which is packed to each datagram containing an application message can be used to detect a message
gap. The sequence number is tied to the Appl ID field in the application messages so gaps can only be detected on a per shard
basis.
The decryption key disclosure is communicated via a separate public multicast group. Co-located clients must all join this same
group to receive the multicasted End of Conflation marker containing the key used for deciphering the encrypted market data
messages at each quantum where at least one Premium Market Data Group publishes data. Subscribers will link the key with the
encrypted market data messages using the “Conflation ID” field present in the header of both types of messages.
For additional information about the message structures please see section 4.2 Application Layer Messages on page 33.
Please refer to Figure 4 below for a connectivity overview in the Colo Premium IP Multicast Feed.
Figure 4: Colo Premium Multicast Feed Connectivity Overview
2.2.6 Sequencing and Recovery

In order to ensure the latest correct view of the orderbook, the Premium IP multicast uses a sequenced and multiplexed FIXP
standard session flow using the Topic and Context messages.
2.2.6.1 Topic
The first message sent will be the Topic Message.
This message announces the sequenced flows and identifies them with a Session UUID.
On receiving the Topic Message, the client should then know to expect context messages on this flow.
2.2.6.2 Context
As above, the topic message will announce the flows for the market Data update flows.
Each packet sent on these flows will have the context details in the FIXP segment. This will include the session uuid and
NextSequenceNumber.
The client will need to track the sequence number for breaks in the event the NextSequenceNumber is different than expected.
If a break is detected the client should wait for the next MDSFR message relating to the partition and apply subsequent MDIR
messages.
Figure 5 on the following page illustrates these flows.
NOTE
The intention is to only have one application message per UDP packet. However, the illustration includes a scenario where there is
more than one application message per UDP Packet in the event this is introduced in the future.
Figure 5: Tracking Sequenced flows with Context and Topic Messages
2.3 STANDARD TCP/IP FEED

The TCP/IP-based Market Data Feed is a low latency and conflated feed.
All LSEG FX Venues Matching TCP/IP connections for Trading, Post Trade and Market Data will be SSL encrypted. This will
include remote and collocated clients. Instruments are distributed between multiple shards of the Market Data Feed and
connectivity (IP/Port) details will be provided by Refinitiv Capital Markets. To subscribe for market data, after the TCP/IP connection
to the targeted Market Data Feed shard is created, the subscribers must comply with the FIX Performance Session Layer
establishment mechanisms.
The logical session is created using the Negotiate message, communicating the login credentials to the server. Upon the first login
to the Feed, the password reset is mandatory. The logical session will be successfully created only if the Negotiate message
contains both "Password" and "NewPassword" fields configured accordingly. For the initial NDF release the password length will be
fixed at 15 characters. Resetting the password to a length not equal to 15 characters in length will be rejected. . Once the
negotiation is complete, the subscriber must send an Establish message to reach the established state, after which the exchange of
application messages may proceed. There is no application level encryption on the TCP/IP market data feed, hence application
messages fairness for long haul subscribers is achieved by varying the ordering at which market data updates are serialized onto
the network.
Figure 6 below shows the encapsulation of various sections of the market data messages for the Standard TCP/IP Feed.
Figure 6: Message Encoding and Decoding Model for Standard TCP/IP Feed
2.3.1 Security Definition Feed

Besides business-related instrument information, the Security Definition messages also include critical information for the TCP/IP
subscribers, as they carry the port numbers of the Market Data shards in which instruments are being distributed across.
While Security Definition messages can be retrieved for the entire universe of instruments within the venue from any shard, the
actual market data subscriptions are accepted only via the dedicated sockets constructed with the aforementioned ports.
Also, on an event-based model, Security Definition updates are automatically sent via the designated market data feed shard for
the entire set of instruments within the system. (i.e., at Date Roll)
If a client already has a current Market Data Request subscription open on a shard, the Security Definition Request will be rejected.
This assists in limiting the number of active Security Definition Requests for performance reasons. The advice to customers is to
subscribe to Security Definitions before making market data subscriptions.
2.3.2 Order Book and Statistics feed

As opposed to the Premium IP Multicast market data feed, the market data disclosure on the TCP/IP feed is achieved based on
subscriptions. Once connected to a Market Data Feed shard, subscribers must subscribe using Market Data Request messages. A
successful subscription would result in an initial Market Data Snapshot full refresh message communicating the latest state of the
targeted market data, followed by subsequent Market Data Incremental Refresh messages for any further updates. Security Status
messages are also disclosed via the same subscription at every session change or intra-day instrument status change.
The End of Conflation (EoC) marker is published to all connected subscribers via the respective TCP/IP access point at the trailing
end of the data transmitted for a conflation interval. The marker is disseminated only if there had been an update to an instrument in
at least one shard for that conflation interval.
For additional information about the messages please see section 4.1 Session Layer Messages on page 24 and section 4.2
Application Layer Messages on page 33.
2.4 CONFLATION SETUP

The FIX Market Data API provides configurable parameters for the setup of the conflation intervals for each user type. By default,
market data is disseminated to co-located clients in 5 milliseconds conflation quantum, whereas non-collocated users receive
market data updates in 100 milliseconds conflation quantums.
Please refer to Figure 7 for a connectivity overview in the TCP/IP Feed.
Figure 7: TCP/IP Feed Connectivity Overview
Chapter 3 Service Description
3.1 MARKET DATA DISSEMINATION SPECIFICS
3.1.1 Order Book Dissemination

Bids and Asks are disclosed in a Market-by-Price format for all client types, in a limited book-depth manner, according to the book
depth configuration of each instrument.
Order book information is communicated via Market Data Snapshot Full Refresh message providing an initial picture of the order
book and Market Data Incremental Refresh messages for active subscriptions if any changes occur within the top <preconfigured-
depth-of-book-level> price points on either side compared to the last published data.
Market Data Incremental Refresh message will disclose new price levels as 'Add' entries, changes in the quantity or price of a price
level will be denoted by 'Update' entries, whereas entire price point liquidations or removals will be communicated as 'Delete'
entries.
3.1.2 Statistics Calculation and Dissemination

Last Traded Price and Volume Weighted Average Price are the two types of statistics disclosed through the LSEG FX Market Data
API. The only trades considered for LTP/VWAP updates are new trades resulted from order matching, while amendments and
cancellations will not influence these statistics.
The statistics feed sends only unscreened data, as described below:
User Type LTP VWAP

Screened Unscreened Screened Unscreened
Premium IP Multicast subscribers (co-located)
Standard TCP/IP subscribers
While LTP is available in both Standard and Premium Feeds, the VWAP related updates will be retrievable only via the Premium
Feed.
Market Data messages will disclose LTP as 'Update' entries, whereas VWAP updates only as 'New' entries.
3.1.2.1 LTP
Last Traded Price subscriptions communicate the price and quantity of the last trade that occurred during a conflation quantum. It is
indefinitely carried over trading weeks.
3.1.2.2 VWAP
Volume Weighted Average Price is a more complex statistic which involves enhanced calculation at the venue side for sliding
window intervals.
VWAP is processed based on pre-configured instrument level parameters such as 'VWAP Calculation Period' and 'VWAP
Calculation Frequency'. VWAP publication is subject to an additional delay depending on the instrument level configuration of the
'VWAP Publication Delay' parameter provided for each instrument.
• VWAP Calculation Period - defines the time window in seconds of the trades that are included in the calculation formula for
VWAP
• VWAP Calculation Frequency - defines the frequency in seconds of VWAP recalculation
• VWAP Publication Delay - defines the delay in seconds for VWAP market data updates
The 'VWAP Calculation Period' will always be greater or equal than the 'VWAP Calculation Frequency' to ensure no trades are
being missed from the VWAP computation. In case 'VWAP Publication Delay' is not set, no delay will be applied on the updates
sent out by the Market Data Feed.
3.1.3 Security Status Dissemination

An instrument goes through multiple sessions during a trading cycle and this is reflected in its associated trading session.
Therefore, a subscriber listening to market data is notified of every session change due to instrument status change or
automatic/manual session changes through Security Status messages.
The message contains real time data and is disclosed in a real-time fashion for all subscribers based on their subscriptions on the
Standard TCP/IP Feed or for the entire set of instruments within a multicast instrument group.
For the Premium IP Multicast Feed, for a specific instrument, the security status is sent unencrypted on the relevant multicast
groups.
3.2 HIGH AVAILABILITY AND DISASTER RECOVERY

The intra-site mirror instances will be on hot standby, processing input data, but not providing any service until promoted to primary
upon a failover. The disaster recovery site instances will be on cold standby. Upon a site failover, the disaster recovery site instance
will be manually invoked and commence operation after purging all the orders that were existent prior to the site failover.
Firms connecting to the system will have the following recovery mechanisms in place.
3.2.1 Point-to-Point (TCP/IP) Market Data Subscribers

Receive a full snapshot of the visible depth of market-by-price book with trading status at the beginning of establishing the
connection with a "MessageEventSource" field set to "Normal". The identification of a failover will be possible based on the "ApplID"
field indicating the ID of the active Market Data Feed instance.
Will be able to request and receive security definition updates and snapshots on demand, in adherence with any applicable fairness
schemes. New instruments can be added to the system only during offline maintenance periods. All Market Data Feeds will provide
the universe of security definition download to identify the instrument distribution programmatically.
Clients will be provided a pair of IP/ port. However, only the primary instance will serve data. The goal of maintaining multiple
connections is to reduce the window of outage in the event of Market Data Feed failover. The primary and mirror Market Data
Feeds will allow concurrent connections and subscriptions. The mirror instance will keep heart-beating on the connections until the
instance is promoted to primary, upon failure of the prevailing instance. Upon failover, the newly promoted primary will continue
data transmission as per the prescribed approach (send snapshots followed by incremental updates). It should be noted that if one
or many clients lose connectivity to the primary Market Data Feed, while it is healthy, they will not be able to receive any data from
the mirror instance. The recommendation would be to keep re-connecting to the primary instance until successful.
3.2.2 Multicast (UDP) Market Data Subscribers

Clients will continue to listen to Security Definition updates from the same security definition dedicated multicast group. The
ApplSeqNo will reset at failover. They will continue to be sent at the same periodical frequency.
New topic messages will be sent to announce the new flows from mirror partitions. This will also result in a new context for each
flow.
Clients will receive a full snapshot of the visible depth of market-by-price book with trading status for each instrument on the
relevant multicast group, followed by incremental updates and additional periodic snapshots.
In case two different Incremental or Snapshot updates are received nearly contemporaneously (i.e. during failover), a subscriber
may determine the most up-to-date version of the book by comparing Book State Notifier (BookStateID) of the two updates and
selecting the highest value. Additionally, if the BookStateIDs are equal, but the bids and offers differ, the credit state notifier
(CreditStateID) may be used to determine the most up to date snapshot for the book (for screened data only). Handling Slow
Consumers
This section is applicable exclusively to TCP/IP market data clients, since UDP subscribers will periodically receive
"MarketDataSnapshotFullRefresh" messages at pre-defined intervals with "MessageEventSource" field indicating the source that
triggered the message publication.
There are two types of slow consumers to be distinguished, as follows:
• Consumers for whom buffering happen every once in a while.
• Consumers for whom buffering happens consistently.
Connection buffering over 2 seconds will move the clients in the throttled state and heartbeats exchange will stop,
"SecurityDefintion" and "SecurityStatus" messages will be dropped, and order book updates will be skipped for all client
subscriptions. The client connection will get terminated in case the socket continues to be un-writable for more than 10 minutes.
In case termination is not triggered and the client socket becomes writable again, in the very next conflation epoch the client will
receive either a "MarketDataSnapshotFullRefresh" or a "MarketDataIncrementalRefresh" message for each subscription with
"MessageEventSource" field indicating that the connection was previously buffered.
NOTE
For the initial NDF Release, only "MarketDataSnapshotFullRefresh" messages will be triggered for slow consumers.
After requesting Security Definitions or during an intra-week dynamic update triggering a new set of "SecurityDefinition" messages,
if the messages get buffered the rest of the "SecurityDefinition" messages will be dropped and as soon as the connection gets
unbuffered, the missed Security Definitions will be sent out with the latest data to the client with "SecurityResponseType" field
indicating that the connection was previously buffered.
In addition to the above, a rate limit of 10,000 messages within a period of 60 seconds is introduced for all client-initiated messages
and clients exceeding this limit will have the session terminated.
3.3 ORDER BOOK REPLENISHMENT

In addition to the above fault tolerance mechanisms, Market Operations Users can also provide support in case of intra-week
disruptive events. "MarketDataSnapshotFullRefresh" messages can be triggered by Market Operations Users via the Order Book
Replenishment option available in their monitoring interface.
Upon an Order Book Replenishment initiation, the "MarketDataSnapshotFullRefresh" message will be disseminated in the very next
conflation cycle for each client depending on their conflation setup, with the "MessageEventSource" field indicating the source of
the message is due to an Order Book Replenishment. In conflation cycles in which "MarketDataSnapshotFullRefresh" messages
are being triggered, no additional Market Data Incremental Updates will be disclosed, hence it is recommended for all clients to
always update their order book picture based on the latest "MarketDataSnapshotFullRefresh" message communicated by the
venue.
In terms of "MessageEventSource" priority, the Order Book Replenishment takes precedence over failover initiated snapshots.
Connection buffering initiated snapshots and periodic snapshots.
A single "MarketDataSnapshotFullRefresh" message will be triggered in case two or more events overlap, following the below
priority scheme:
Order Book Replenishment > Failover > Buffered Snapshot (TCP) / Periodic Snapshot (UDP)
3.4 SCHEMA BACKWARD COMPATIBILITY

For the initial NDF release schema backwards compatibility will be limited to the addition and deprecation of fields according to FIX
SBE XML schema change limitations, which are described below.
These allow for:
• Fields can be added to either the root of a message or to a repeating group, but in each case, they must be appended to the
end of a block. Newly introduced fields must have the "Presence" tag set as optional and the "SinceVersion" tag set to the
new schema version.
• Deprecation of fields.
• A variable-length data field may be added after existing variable-length data at the root level or within a repeating group.
• In general, metadata changes such as name or description corrections do not break compatibility as long as wire format does
not change.
The following changes will require the client to update their schema version:
• Adding new repeating groups.
• Adding new messages.
• Removing fields/messages.
• Changing data type of existing fields.
• Changing the message headers
We aim to avoid introducing any changes that would require a mandatory update on a single given date.
For the Matching release, the service will be enhanced to support multiple schema versions which do not have cross compatibility.
When introducing a change that would normally incur a mandatory update, instead a new schema will be released and enabled.
Customers within a defined timeframe can move to the new schema before the previous is disabled. This will ensure the service
fully supports backwards compatibility and provide steady alignment between the venue and client-side interfaces. More information
will follow on this topic.
Chapter 4 Message Formats
The format for the Simple Open Framing Header and Simple Binary Encryption Header is detailed below. All messages (both
session and application) will use these headers.
Header Field Offset Length Data Type

SOFH message length 0 4 uint32
SOFH encoding type 4 2 uint16
The SOFH encoding type used for both session and application messages is SBE Big Endian.
Header Field Offset Length Data Type

SBE block length 0 2 uint16
SBE template ID 2 2 uint16
SBE schema ID 4 2 uint16
SBE schema version 6 2 uint16
SBE numGroups 8 2 uint16
SBE numVarDataFields 10 2 uint16
The following pages provide details on the unit header, administrative messages and application messages utilised by the server.
For each message, a description of each field is provided along with the applicable offset and length (in bytes).
4.1 SESSION LAYER MESSAGES

The messages described in this section are applicable only for the Standard TCP/IP Feeds.
4.1.1 Message Types for Session Messages:

Message Type Enum Value
Negotiate N
Negotiation Response O
Negotiation Reject P
Establish E
Establishment ACK F
Establishment Reject G
Terminate T
Un-sequenced Heartbeat H
Context C
Topic A
4.1.2 Session Layer Event Flow and State Changes
Figure 8 Session Layer State Changes
4.1.3 Client-Initiated
4.1.3.1 Negotiate
Level Field Field Name Offset Length Interpreted Value Description
ID (octets)
Hdr - message length 0 4 - Total message length. Can vary based
SOF on the content of the message.
encodingType 4 2 Big Endian
Hdr - blockLength 0 2 72 Length of the root level of the message
SBE without counting any repeating groups
or variable-length fields. Used for
reading the fixed length fields fast.
template ID 2 2 500 The identifier of a message type in a
message schema.
schema ID 4 2 101 This is mentioned in the XML schema
file.
schema version 6 2 1 This is mentioned in the XML schema
file.
numGroups 8 2 0 No repeating groups
numVarDataFields 10 2 0 No variable length fields
FixP - MessageType 0 1 N - Negotiate
Session
Session Id 1 20 Session Identifier UUID.
Should be specified by the client but no
validation will be done.
Timestamp 21 8 1562852607699000000 Should be specified by the client but no
UTC Thursday, July 11, 2019
1:43:27.699 PM
FlowType 29 1 U - Unsequenced Type of flow from client to server.
Anything other than Unsequenced will
be rejected.
Credentials 30 41 Username 11 Composite containing the username,
password and new password.

ID (octets)
• User Name Password 15 If the new password is present in
New Password 15 conjunction with the correct password,
• Password the password will be updated. If a client
• New does not want to change their
Password password, the new password should be
null.
Credentials composite is defined in the
message template as above.
For the initial NDF release the

password length will be fixed at 15
characters. Resetting the password to a
length not equal to 15 characters in
length will be rejected.
4.1.3.2 Establish
ID (octets)
message schema.
file.
file.
numGroups 8 2 0
numVarDataFields 10 2 0
FixP - MessageType 0 1 E - Establish
Session
Session Id 1 20 Session Identifier UUID
UTC Tuesday, August 10, 2021
4:57:35.062 AM
KeepAliveInterval 29 4 5000 Client needs to specify the heartbeat
interval here. HB interval in milli-
seconds.
4.1.3.3 Heartbeat
ID (octets)
message schema.
A message with template ID of
Heartbeat is considered as a heartbeat.
No other field (such as message type)
will be validated for
UnsequencedHeartbeat messages.
file.
file.
numGroups 8 2 0
FixP - MessageType 0 1 H-
Session UnsequencedHeartbeat
4.1.3.4 Terminate
Level Field Field Name Offset Length Interpreted Description
ID (octets) Value
Hdr - message length 0 4 - Total message length. Can vary based on

SOF the content of the message.
SBE without counting any repeating groups or
variable-length fields. Used for reading the
fixed length fields fast.
message schema.
A message with template ID of Terminate is
considered as a terminate. No other field
(such as message type) will be validated for
Terminate messages.
schema ID 4 2 101 This is mentioned in the XML schema file.
schema version 6 2 1 This is mentioned in the XML schema file.
numGroups 8 2 0
FixP - MessageType 0 1 T - Terminate Should be specified by the client but no
Session validation will be done.
Session Id 1 20 qwertyui1234 Session Identifier UUID

ID (octets) Value
Termination Code 21 1 F - Finished Should be specified by the client but no
Reason 22 VARIABLE Length = 8
• Length Reason =
"Finished"
• Reason
4.1.4 Server-Initiated
4.1.4.1 Negotiation Response

Level Field ID Field Name Offset Length Interpreted Value Description
(octets)
Hdr - SOF message length 0 4 - Total message
length. Can vary
based on the
content of the
message.
Hdr - SBE blockLength 0 2 46 Length of the root
level of the
message without
counting any
repeating groups
or variable-length
fields. Used for
reading the fixed
length fields fast.
template ID 2 2 500 The identifier of a
message type in
a message
schema.
schema ID 4 2 101 This is mentioned
in the XML
schema file.
schema version 6 2 1 This is mentioned
in the XML
schema file.
numGroups 8 2 0 No repeating
groups
numVarDataFields 10 2 0 No variable length
fields
FixP - Session MessageType 0 1 O - Negotiation
Response
Session Id 1 20 Session Identifier
UUID.
Should be
specified by the
client but no
Level Field ID Field Name Offset Length Interpreted Value Description

(octets)
validation will be
done.
Timestamp 21 8 1562852607699000000 Should be
specified by the
client but no
validation will be
done.
UTC Thursday,
July 11, 2019
1:43:27.699 PM
FlowType 29 1 U - Unsequenced Type of flow from
client to server.
Credentials 30 41 Username 11 To avoid protocol
• User Name Password 15 violation, the
server will send
• Password New Password 15 the Negotiation
Response with
• New Password
credentials set to
NULL.
4.1.4.2 Negotiation Reject

ID (octets)
Hdr - message length 0 4 - Total message length. Can vary
SOF based on the content of the message.
Hdr - blockLength 0 2 30 Length of the root level of the
SBE message without counting any
repeating groups or variable-length
fields. Used for reading the fixed
length fields fast.
message schema.
file.
file.
numVarDataFields 10 2 0 No variable length fields
FixP - MessageType 0 1 P - Negotiation Reject
Session
Session Id 1 20 Session Identifier UUID.
Should be specified by the client but
no validation will be done.
Timestamp 21 8 1562852607699000000 Should be specified by the client but
no validation will be done.
UTC Thursday, July 11, 2019
1:43:27.699 PM
RejectCode 29 1 F-
FlowTypeNotSupported

ID (octets)
Reason 30 VAR Length = 20 Defines the reason for Negotiation
• Length Reason = "Invalid Rejection.
credentials."
• Reason
4.1.4.3 Establishment Ack

ID (octets)
message schema.
file.
file.
numGroups 8 2 0
FixP - MessageType 0 1 F - Establish Ack
Session
Session Id 1 20 Session Identifier UUID
UTC Tuesday, August 10, 2021
4:57:35.062 AM
KeepAliveInterval 29 4 5000 HB interval in milli-seconds provided by
the server.
4.1.4.4 Establishment Reject

ID (octets)
Hdr - message length 0 4 - Total message length. Can vary
SOF based on the content of the message.
Hdr - blockLength 0 2 30 Length of the root level of the
SBE message without counting any
repeating groups or variable-length
fields. Used for reading the fixed
length fields fast.

ID (octets)
message schema.
file.
file.
numVarDataFields 10 2 1 There will be one variable length field
in the message.
FixP - MessageType 0 1 G - Establishment Reject
Session
Session Id 1 20 "NULL" Session Identifier
Timestamp 21 8 1562852607699000000 UTC Tuesday, August 10, 2021
4:57:35.062 AM
RejectCode 29 1 F-
FlowTypeNotSupported
Reason 30 VAR Length = 20 Defines the reason for Establishment
• Length Reason = "User not Rejection
negotiated."
• Reason
4.1.4.5 Heartbeat
Each heartbeat sent by the server would incrementally increase the Book State Identifier, making the 'BookStateID' field of the
application messages display a sparsely incrementing number.

ID (octets)
message schema.
A message with template ID of
Heartbeat is considered as a heartbeat.
No other field (such as message type)
will be validated for
UnsequencedHeartbeat messages.
file.
file.
numGroups 8 2 0
FixP - MessageType 0 1 H-
Session UnsequencedHeartbeat
4.1.4.6 Terminate
ID (octets) Value
Hdr - message length 0 4 - Total message length. Can vary based on the
SOF content of the message.
SBE without counting any repeating groups or
message schema.
A message with template ID of Terminate is
considered as a terminate. No other field
(such as message type) will be validated for
Terminate messages.
numGroups 8 2 0
FixP - MessageType 0 1 T - Terminate

Session
Session Id 1 20 qwertyui1234 Session Identifier UUID
Termination Code 21 1 U- Supported Value: UnspecifiedError
Unspecified
Error
• Length Reason =
"Finished"
• Reason
The messages described below are applicable only for Colo clients who are using the Premium IP Multicast Feed.
4.1.4.7 Context Message

Level Field Name Offset Length Interpreted Description
(octets) Value
Hdr - message length 0 4 - Total message length. Can vary based on the content of
SOF the message.
Hdr - blockLength 0 2 91 Length of the root level of the message without counting
SBE any repeating groups or variable-length fields. Used for
template ID 2 2 7 The identifier of a message type in a message schema.
Schema ID 4 2 505 This is mentioned in the XML schema file.
Schema version 6 2 101 This is mentioned in the XML schema file.
numGroups 8 2 0

(octets) Value
FixP MessageType 0 1 C
SessionID 1 20 qwertyui1234 Session Identifier UUID
Generated by system
NextSeqNo 21 8
4.1.4.8 Topic Message

(octets) Value
Hdr - message length 0 4 - Total message length. Can vary based on the content of
SOF the message.
Hdr - blockLength 0 2 91 Length of the root level of the message without counting
SBE any repeating groups or variable-length fields. Used for
numGroups 8 2 0
FixP MessageType 0 1 C
SessionID 1 20 qwertyui1234 Session Identifier UUID
Generated by system
Flow 21 8 I Idempotent (see FIX SBE standard for more details)
Classification 22 2 MDPartitionID 1 Composite containing the MD Partition ID and MD
• MDPartitionID MDInstanceID 1 Instance ID
• MDInstanceID
4.2 APPLICATION LAYER MESSAGES

Message Types for Application Messages:
Message Type Enum Value

Security Definition Request c
Market Data Request V
Security Definition d
Market Data Snapshot Full Refresh W
Market Data Incremental Refresh X
Market Data Request Rejection Y
Security Status f
End of Conflation (applicable only for Colo clients in Premium IP Multicast Feed) z
Encrypted Msg Wrapper (applicable only for Colo clients in Premium IP Multicast Feed) A
Application Layer Event Flow and State Changes
Figure 9 Application Layer State Changes.
4.2.1 Client Initiated

The messages described in this section are applicable only for the Standard TCP/IP Feeds.
4.2.1.1 Security Definition Request

ID (octets) Value
Hdr - SOF message length 0 4 - Total message length. Can vary based on the
content of the message.
Hdr - SBE blockLength 0 2 10 Length of the root level of the message without
counting any repeating groups or variable-
length fields. Used for reading the fixed length
fields fast.
template ID 2 2 2 The identifier of a message type in a message
schema.
numGroups 8 2 0 Two repeating groups will be present in the
message.
numVarDataFields 10 2 0 No variable length fields.
Application Security Req ID 0 8 REQ01 Request ID - Unique identifier of the request
sent by the client.

ID (octets) Value
Subscription 8 1 0 The type of the request.

Request Type
Value Meaning
0 Snapshot
1 Snapshot + Incremental Updates
(Subscribe)
2 Disable previous “Snapshot +
Incremental Updates” Request
(Unsubscribe)
Security Request 9 1 9 Type of request.
Type
Value Meaning
8 All Securities
4.2.1.2 Market Data Request

ID (octets) Value
Hdr - SOF message length 0 4 Total message length

Hdr - SBE blockLength 0 2 9 Length of the root level of the message
without counting any repeating groups or
variable-length fields. Used for reading
the fixed length fields fast.
message schema.
file.
file.
numGroups 8 2 2 Two repeating groups will be present in
the message.
Application MDReqID 0 8 REQ01 Unique identifier of the market data
request sent by the client
SubscriptionRequestType 8 1 0 Type of subscription requested.
Value Meaning
0 Snapshot
1 Snapshot and Incremental
Updates
2 Unsubscribe
Group block length 0 2 9 MDEntryTypes repeating group begins
here.
NumInGroup 2 2 1
numGroups 4 2 0

ID (octets) Value
MDEntryType 0 1 NULL Indicates the type of market data
requested.
Value Meaning
0 Bid
1 Offer
g Last Traded Price
NOTE
A Market Data Request with VWAP will
be rejected.
Group block length 0 2 17 Related Symbol repeating group begins

here.
NumInGroup 2 2 1
numGroups 4 2 0
SecurityID 0 10 NULL Identification number for the security.
ScreenedMDRequestType 10 1 Null Defines the type of subscription from

credit perspective
Value Meaning
0 Unscreened
1 Screened
2 Both
NOTE
Fully or partially duplication of an existing subscription will be rejected. In a Market Data Request, even if there is at least one new
valid subscription for a given instrument, it will be rejected. For example if a user had already requested the bid of instrument_1 and
then sends another request for both bid and offer of instrument_1, the second request will be rejected. The subscription will also be
rejected if there is nothing new to subscribe to for a given instrument. For example, if a user is already subscribed for instrument_1
fully and then sends a second request for both instrument_1 and instrument_2, then the second request will be rejected as there is
nothing new to subscribe for instrument_1.
4.2.2 Server Initiated

The following messages described in this section are applicable for Standard TCP/IP and Premium IP Multicast Feeds as follows:
Message\Gateway Premium IP Multicast Feed Standard TCP/IP Feed

Security Definition
Market Data Snapshot Full Refresh
Market Data Snapshot Incremental Refresh
Security Status
Market Data Request Rejection
Message\Gateway Premium IP Multicast Feed Standard TCP/IP Feed

End of Conflation
Encrypted Msg Wrapper
4.2.2.1 Security Definition

(octets) Value
Hdr - SOF message length 0 4 - Total message length. Can vary based on
the content of the message.
Hdr - SBE blockLength 0 2 91 Length of the root level of the message
without counting any repeating groups or
message schema.
numGroups 8 2 3 Three repeating groups will be present in
the message.
Application Appl ID 0 8 e.g. Identifier of the server sending the
PVT_A message.
ApplSeqNo 8 8 1 Unique State Identifier of the message on

the Real-Time channel, continuously
incrementing for each Security Definition
subscription.
LastRptRequested 16 1 TRUE Indicates the last message sent in
response to a request.
Value Meaning
True Last Message
False Not the Last Message
SecurityStatus 17 1 1 Status of the instrument.
Value Meaning
1 Active
2 Inactive
8 Halted
9 Suspended
SecurityType 18 8 NULL Indicates the instrument type.
Supported value: FXSPOT, FXNDF,
FXSWP, FXFWD
SettlType 26 4 Indicates order settlement period. Required
for FXSPOTs and FXNDFs.
It will be possible to indicate whether a
given instrument created in the system is
the standard spot of a currency pair or not.
Each currency pair will have only one

(octets) Value
Standard Spot instrument. SettlType set to
0 will indicate that the currency pair is the
Standard Spot instrument.
For Spot Instruments i.e. SecurityType =
FXSPOT.
Value Meaning
0 Regular/FX Spot
Settlement (T+1 or T+2
depending on the
currency)
1 T+0
2 T+1
3 T+2
4 T+3
5 T+4
For NDF instruments i.e. SecurityType =
FXNDF/FXFWD. This field is mandatory for
NDFs.
Value Meaning
0 Regular / FX Spot settlement
(T+1 or T+2 depending on
currency)
1 TOD
2 TOM
B Broken Date
Dx FX tenor expression for "days",
e.g. "D3", where "x" is any
integer > 0
Wx FX tenor expression for
"weeks", e.g. "W2", where "x"
is any integer > 0
Mx FX tenor expression for
"months", e.g. "M3", where "x"
is any integer >
Yx FX tenor expression for
"years", e.g. "Y1", where "x" is
any integer > 0
MEx FX tenor expression for "Month
End", where "x" is any integer
> 0, e.g. "ME2" where 2 refers
to the second month end date
after Spot.
YEx FX tenor expression for "Year
> 0, e.g. "YE2" where 2 refers
to the second year end date
after Spot.
IMx FX tenor expression for "IMM",
where “x” is any integer > 0,

(octets) Value
e.g. "IM1” where 1 refers to the
first IMM date after Spot.
C FX Spot Next Settlement
(Spot+1, aka next day)
SettlType will be empty for instruments
other than FXNDF/FXFWD or FXSPOT.
SettlDate 30 2 18827 The instrument’s Settlement Date,
expressed in YYYYMMDD format.
Required for FXNDF and FXSPOT
instruments.
SettlDate will be stamped and
disseminated in Unix time as days offset
from January 1, 1970, the Unix epoch.
FixingDate 32 2 The date at which the difference between
the prevailing spot market rate and the
agreed-upon rate is calculated.
This field is specific to NDFs, but no
validation/filtration is done based on
product type.
Fixing Date will be in YYYYMMDD format
and will be stamped and disseminated in
Unix time as days offset from January 1,
1970, the Unix epoch.
Currency1 34 3 GBP For a Matching spot instrument, this is the
ISO Currency code indicating the base
currency for the instrument.
i.e. For “EUR/JPY” Currency1 is “EUR”.
Currency2 37 3 USD For a Matching spot instrument, this is the
ISO Currency code indicating the quoted
currency for the instrument.
i.e. For “EUR/JPY” Currency1 is “EUR”.
Symbol 40 7 NULL The instrument name, e.g. EUR/USD
BookDepthPriceThreshold 47 8 NULL The Book Depth Price Threshold for the
instrument is the maximum price offset
from TOB for which price updates are sent.
DepthOfBook 55 4 NULL Defines the maximum number of price
levels to be displayed in the Book for the
instrument.
MDPrimaryPort 59 2 NULL Defines the port number of the primary
Private Market Data Feed instance. Only
relevant for the Standard TCP Feed. For
the Premium Multicast Feed, the UDP IP
and Port will be communicated
independently.
MDSecondaryPort 61 2 NULL Defines the port number of the secondary
Private Market Data Feed instance. Only
relevant for the Standard TCP Feed. For
the Premium Multicast Feed, the UDP IP
and Port will be communicated
independently.
MinQty 63 8 NULL Minimum size of an order to be executed.
LotSize 71 8 Defines the minimum lot size for an order
to be accepted by the venue.

(octets) Value
ExDestination 79 1 Defines the Regulatory Regime

This is primarily required for FXNDF and
FXSWAP instruments (i.e any value except
for None). For FXSPOT instruments the
expected value is None (101). However,
there will be no validations implemented at
the instrument/trading room level to restrict
these based on the instrument types.
Value Meaning
101 None
102 RMO
103 SEF
104 MTF
105 Local
MarketSegmentID 80 1 Defines the Market Segment based on the
lot size setup.
This is primarily required for FXSPOT
instruments. For FXNDF and FXSWAP
instruments the expected value is Regular
(101). However, there will be no validations
implemented at the instrument/trading
room level to restrict these based on the
instrument types.
Value Meaning
101 Regular
102 Small
MDSubBookType 81 1 Type of trading to which the update relates.
This has the same value being sent in
OrderBook (30001) field in Trading API.
Value Meaning
1 Matching
2 ECN
SecurityResponseType 82 1 Indicates the Response Type as a result of
subscription request for Security
Definitions.
Value Meaning
1 Security Definition
Snapshot
Update
Buffered Update
5 Reject security
definition request

(octets) Value
SecurityRejectReason 83 1 Indicates the reject reason in case of an

unsuccessful Security Definition
subscription.
Value Meaning
1 Security Definition Request
must be initiated in advance of
any Market Data Requests
subscription is already active
on the current shard
3 Security Definition un-
subscription rejected as no
active subscription was found
4 Specified mandatory field
"SubscriptionRequestType" is
incorrect
5 Specified mandatory field
"SecurityRequestType" is
incorrect
TimedOrderMinDuration 84 4 Defines the minimum duration for the GTT
orders
TimedOrderMaxDuration 88 4 Defines the maximum duration for the GTT
orders
MinimumQuoteLife 92 4 Defines the minimum time that it needs to
reside on the order book before a cancel or
amendment request on that order will be
entertained
MinIcebergOrderTipSize 96 8 Defines the minimum iceberg disclosed
size
MaxIcebergOrderTipSize 104 8 Defines the maximum iceberg disclosed
size
Group block length 0 2 25
NumInGroup 2 2 1
No. of groups 4 2 0
No.of var data 6 2 0
MinimumValue 0 8 Minimum price of the interval
MaximumValue 8 8 Maximum price of the interval
RatePrecision 16 8 Integer value representing the price
increments used, with respect to the last
decimal place – which is determined by
RightDps.
RightDps 24 1 The maximum permitted number of right
decimal places. RatePrecision only makes
sense if RightDps is known.
NumInGroup 2 2 1
No. of groups 4 2 0
No.of var data 6 2 0

(octets) Value
SecurityAltID 0 12 NULL Identification number for the security.

SecurityAltIDSource 12 1 NULL Type of security identification number
used.
Required if SecurityAltID (455) is specified.
Value Meaning
4 ISIN
8 Instrument identifier
NumInGroup 2 2 1
numGroups 4 2 0
LegID 0 1 NULL Unique identifier for the leg within the
context of a message.
Value Meaning
1 Near Leg
2 Far Leg

(octets) Value
LegSettlType 1 4 Indicates settlement period of the leg.

Value Meaning
0 Regular/FX Spot Settlement
(T+1/T+2 depending on ccy)
1 TOD
2 TOM
C FX Spot Next Settlement
(Spot+1/Next Day)
B Broken Date
Wx FX tenor expression for
“weeks”, e.g. “W2”, where “x”
is any integer > 0
Mx FX tenor expression for
“months”, e.g. “M3”, where “x”
is any integer > 0
Yx FX tenor expression for
“years”, e.g. “Y1”, where “x” is
any integer > 0
IMx FX tenor expression for
"IMM", where “x” is any
integer > 0, e.g. "IM1” where 1
refers to the first IMM date
after Spot.
MEx FX tenor expression for
"Month End", where "x" is any
integer > 0, e.g. "ME2" where
2 refers to the second month
end date after Spot.
YEx FX tenor expression for "Year
> 0, e.g. "YE2" where 2 refers
to the second year end date
after Spot.
LegSettlDate 5 2 Required for multi-leg instruments.
LegSettlDate will be disseminated in Unix
time as days offset from January 1, 1970,
the Unix epoch.
LegSecurityID 7 12 Identification number for each leg of the
SWAP instrument. A unique ISIN will be
available for each trade date & value date
combination.
LegSecurityIDSource 19 1 Type of security identification number used
for multi leg instruments
Value Meaning
4 ISIN
NumInGroup 2 2 1
numGroups 4 2 0

(octets) Value
IcebergTipDelayID 0 10 Defines the Iceberg Tip Delay configuration

for orders subject to random delay
replenishment
MinReplenishDelay 10 4
MaxReplenishDelay 14 4
4.2.2.2 Market Data Snapshot Full Refresh

(octets) Value
Hdr - SOF message length 0 4 - Total message length. Can vary based on the
encodingType 4 2 Big-endian
Hdr - SBE blockLength 0 2 84 Length of the root level of the message without
counting any repeating groups or variable-
length fields. Used for reading the fixed length
fields fast.
template ID 2 2 8 The identifier of a message type in a message
schema.
numGroups 8 2 1 One repeating group will present in this
message.
Application Appl ID 0 8 e.g.: Identifier of the server sending the message.
PVT_A It is populated by fetching the "Application ID"
(APPL_ID) configuration from process level.
BookStateID 8 8 2 Book State Identifier - Unique State Identifier
of the message being sparsely incrementing
per instrument and orderbook combination.
ConflationID 16 8 It is stamped with the UNIX timestamp of each
conflation and is used to identify messages
that have been transmitted during a certain
conflation quantum.
LastFragment 24 1 TRUE Indicates the last message in a series of order
book snapshot messages for the instrument
per subscribed order book & per requested
MDEntryType combination.
Value Meaning
True Last Message
False Not last Message
If the value does not exist, the message will be
considered as the last snapshot message.
SecurityID 25 10 SEC24 Identification number for the security.

(octets) Value
MDSubBookType 35 1 1 Type of trading to which the update relates.

Value Meaning
1 Matching
2 ECN
SecurityType 36 8 NULL Indicates type of security.
Supported value: FXSPOT, FXNDF, FXSWP,
FXFWD
MDSecurityTradingStatus 44 1 171 Indicates the real time trading status of the

instrument.
Value Meaning
2 Halt
17 Regular Trading
26 Post-Close
100 Pre-Trading
111 Pause
199 No Active Session
MDHaltReason 45 1 NULL Reason for the trading halt.
Required if MDSecurityTradingStatus is Halt
(2).
MDHaltReason Name
4 News Pending
100 Other
(Includes a halt for a
public holiday)
101 Circuit Breaker
102 Fast Market
103 System Problem
104 Instrument Status
Change
105 System Failure
106 Invalid Instrument
Setup
107 Clearing Halt
CreditStateID 46 8 Credit State Identifier – Unique State Identifier
which provides the means to unambiguously
refer to a screened order book snapshot

(octets) Value
MessageEventSource 54 1 Indicates the origin/source for Snapshot

generation.
Value Meaning Additional
Info
0 Normal TCP/IP Feed:
Indicates
normal flow,
messages
received as a
result of a
subscription
UDP Feed:
Not applicable
1 MDReplenishme TCP/IP and
nt UDP Feeds:
Indicates
replenishment
flow,
messages
received as a
result of
Market Ops
triggering OB
replenishment
2 BufferedConnect TCP/IP Feed:
ion Indicates a
previously
buffered
connection,
received when
service is able
to start writing
on the socket
again
UDP Feed:
Not applicable
3 PeriodicMDUpda TCP/IP Feed:
te Not applicable
UDP Feed:
Indicates
periodic
market data
snapshot
messages
Group block length 0 2 68 MD Entries repeating group begins here.

NumInGroup 2 2 2
numGroups 4 2 1

(octets) Value
MDEntryType 0 1 0 – Bid First repetition starts here

Indicates the type of market data being
published.
This will be the first field in the repeating
group.
Value Meaning
0 Bid
1 Offer
9 Volume Weighted Average Price
g Last Traded Price
J Null Book
x No Operation
No Operation entry type will be used on the
encrypted multicast groups for co-located
clients to prevent side channel attacks.
MDEntryID 1 8 SEC24 Unique identifier of each order.
Required if MDEntryType is Bid (0) or Offer (1)
and the order book is published by order depth
(Market by Order – MBO).
MDEntryPx 9 8 1.23456 Price of the bid, offer or LTP being published.
MDEntryPx supports precision of up to 8
decimal points.
MDEntrySize 17 8 2310.19 Quantity of the market data entry being
published – bid, offer, LTP. MDEntrySize
supports precision of up to 2 decimal points.
MDEntryTime 25 8 NULL Time the order being published was submitted.
The time will be specified in UTC and in the
HH:MM:SS.sss format.
Required if MDEntryType is LTP (g).
NumberOfOrders 33 4 3 Number of orders represented in the
aggregate quantity published for a bid or offer.
and the order book is published by price
depth.
MDEntryPositionNo 37 4 NULL Display position of the order in the order book
within its price level.
and the order book is published by order
depth.
MDPriceLevel 41 4 NULL Display position of the price level in the order
book.
AggressorSide 45 1 Displays the aggressor side of a trade.
Required only for LTP(g) entries.
Value Meaning
1 Buyer
2 Seller

(octets) Value
ScreenedMDType 46 1 Defines the type of market data entry from

credit perspective
Value Meaning
0 Unscreened
1 Screened
OrdPFill 47 1 Indicates whether there is a possibility of an
order being partially filled in a screened
snapshot market data update if the credit
system had indicated there is not enough
credit between the counterparties to fill that
particular order entirely
Value Meaning
0 False
1 True
MDEntryCalculationPerio 48 4 Defines the time length for VWAP calculation
d (seconds)
Relevant for premium IP multicast feed only.
MDEntryClosingTime 52 8 Defines closing time of the calculation period
(UNIX timestamp)
Relevant for premium IP multicast feed only.
CreditCode 60 4 Defines which trade/credit code the credit
screened market data pertains to.
Group block length 0 2 10 Parties repeating group (of first MD Entry)
begins here. Parties not available – will not be
stamped.
NumInGroup 2 2 1 One party block is here
numGroups 4 2 0
PartyID 0 8 F1 Identifier of the party.
Required if NoPartyIDs is specified.
Not available as current feed is Market by
Price (MBP) – will be stamped with NULL.
PartyIDSource 8 1 D Required if PartyID is specified.
Value Meaning
D Proprietary/Custom Code
PartyRole 9 1 1 Role of the specified PartyID.
Required if PartyID is specified.
Value Meaning
TBD TBD
4.2.2.3 Market Data Incremental Refresh

(octets) Value
Hdr – SOF message length 0 4 - Total message length. Can vary based on the
encodingType 4 2 Big-endian Indicates that (only) the FIX SBE message body will
be AES-128 encrypted using CTR mode.
Hdr – SBE blockLength 0 2 48 Length of the root level of the message without
counting any repeating groups or variable-length
fields. Used for reading the fixed length fields fast.
Template ID 2 2 9 The identifier of a message type in a message
schema.
Schema ID 4 2 101 This is mentioned in the XML schema file. ID =
“101”
numGroups 8 2 1 Two repeating groups will be present in the
message.
Application Appl ID 0 8 e.g.: Identifier of the server sending the message.
PVT_A It is populated by fetching the “Application ID”
(APPL_ID) configuration at process level
BookStateID 8 8 3 Book State Identifier – Unique State Identifier of
message being sparsely incrementing per
instrument and orderbook combination.
ConflationID 16 8 It is stamped with the UNIX timestamp of each
conflation and is used to identify messages that
have been disclosed during a certain conflation
quantum.
CreditStateID 24 8 Credit State Identifier – Unique State Identifier
which provides the means to unambiguously refer
to a screened incremental order book update
MessageEventSource 32 1 Indicates the origin/source for Incremental Refresh
generation.
Value Meaning Additional Info
0 Normal This will be
default for both
Multicast and
TCP messages.
1 MDReplenishment Not expected on
MDIR messages
2 BufferedConnection TCP/IP Feed:
Indicates a
previously
buffered
connection,
received when
service is able to
start writing on
the socket again
UDP Feed:
Not applicable

(octets) Value
3 PeriodicMDUpdate Not expected on

MDIR messages
Group block length 0 2 94 MD repeating group begins here.
NumInGroup 2 2 2 Two repetitions of the group
numGroups 4 2 1
MDUpdateAction 0 1 0 – New First repetition starts here.
Indicates the update type.
Value Meaning
0 New
1 Change
2 Delete
MDSubBookType 1 1 NULL Type of trading to which the update relates.
Value Meaning
1 Matching
2 ECN
MDEntryType 2 1 0 – Bid Related Symbol repeating group begins here.
Indicates the type of market data being published.
Value Meaning
0 Bid
1 Offer
9 Volume Weighted Average Price
g Last Traded Price
x No Operation
No Operation entry type will be used on the
encrypted multicast groups for co-located clients to
prevent side channel attacks.
MDEntryID 3 8 NULL Unique identifier of a market data entry.
Required if MDEntryType is Bid (0) or Offer (1) and
the order book is published by order depth (Market
by Order – MBO).
SecurityID 11 10 SEC24 Identification number for the security.
MDEntryPx 21 8 2310.19764 Price of the market data entry – bid, offer, LTP.
MDEntryPx supports precision of up to 8 decimal
points.
Required if MDUpdateAction is New (0) or Change
(1).
MDEntrySize 29 8 23.10 Quantity of the market data entry – bid, offer or
LTP. MDEntrySize supports precision of up to 2
decimal points.
(1)

(octets) Value
MDEntryTime 37 8 NULL Time the trade being published was executed. The
time will be specified in UTC and in the
HH:MM:SS.sss format.
Populated if MDEntryType is LTP (g).
NumberOfOrders 45 4 NULL Number of orders represented in the aggregate
quantity published for a bid or offer.
(1), MDEntryType is Bid (0) or Offer (1) and the
order book is published by price depth.
MDEntryPositionNo 49 4 NULL Display position of an order in the order book within
a price level.
Required if MDEntryType is Bid (0) or Offer (1) and
the order book is published by order depth.
MDPriceLevel 53 4 NULL Display position of a price level in the order book.
Required if MDEntryType is Bid (0) or Offer (1).
AggressorSide 57 1 NULL Aggressor Side of a trade.
Value Meaning
1 Buyer
2 Seller
Stamped for LTP(g) entries.
ScreenedMDType 58 1 Defines the type of market data entry from credit
perspective
Value Meaning
0 Screened
1 Unscreened
OrdPFill 59 1 Indicates whether there is a possibility of an order
being partially filled in a screened snapshot market
data update if the credit system had indicated there
is not enough credit between the counterparties to
fill that particular order entirely
Value Meaning
0 False
1 True
MDEntryCalculationPeriod 60 4 Defines the time length for VWAP calculation
(seconds)
MDEntryClosingTime 64 8 Defines closing time of the VWAP calculation
period (UNIX timestamp)
CreditCode 72 4 Defines which trade/credit code the credit screened
market data pertains to.
Group block length 0 2 10 Party repeating group inside the first repetition of
the MD Entry group. Not available – will be
stamped with NULL
NumInGroup 2 2 1
numGroups 4 2 0
PartyID 0 8 F1 Identifier of the party.

(octets) Value
PartyIDSource 8 1 D Required if PartyID is specified.

Value Meaning
D Proprietary/Custom Code
PartyRole 9 1 1 Role of the specified PartyID.
Required if PartyID is specified.
Value Meaning
1 Trading Firm
4.2.2.4 Market Data Request Rejection

(octets) Value
Hdr – SOF message length 0 4 - Total message length. Can vary based on the
Template ID 2 2 6 The identifier of a MarketDataRequestRejection in
a message schema.
numGroups 8 2 0
Application MDReqID 0 8 MDRID012
• Length Reason =
“Type already
• Reason subscribed”
4.2.2.5 Security Status

(octets) Value
Hdr – SOF message length 0 4 - Total message length. Can vary based on the content
of the message.
Template ID 2 2 10 The identifier of a Security Status in a message
schema.
numGroups 8 2 0

(octets) Value
Application Transact Time 0 8 Time of the session/instrument status change in
nanoseconds since Unix epoch.
Appl ID 8 16 e.g.: Identifier of the server sending the message.
PUB_A It is populated by fetching the “Application ID”
(APPL_ID) configuration at process level
ApplSeqNo 16 24 Sequence number of the message being sparsely
incrementing per instrument and order book
combination.
SecurityID 24 10 Instrument identifier of the security.
SecurityTradingStatus 34 1 Indicates the trading status of the instrument.
Session Name ID
Halt 2
Regular Trading 17
Post Close 26
Pre-Trading 100
Pause 111
No Active Session 199
The Status for a security can be No Active Session in
the following cases:
• the market is closed
• the market is open and no session has been
configured for that security
• the security has no OB attached
• the security has no trading cycle attached to its
OB
• the instrument status is set to Suspended or
Inactive
MDSubBookType 35 1 Type of trading to which the update relates.

Value Meaning
1 Matching
2 ECN

(octets) Value
MDHaltReason 36 1 Reason for the trading halt.

Mandatory when SecurityTradingStatus is halt.
MDHaltReason Name
4 News Pending
100 Other
(Includes a halt for a public
holiday)
101 Circuit Breaker
102 Fast Market
103 System Problem
104 Instrument Status Change
105 System Failure
106 Invalid Instrument Setup
107 Clearing Halt
The messages described below are applicable only for Colo clients who are using the Premium IP Multicast Feed.
4.2.2.6 End of Conflation

(octets) Value
Hdr - SOF message length 0 4 - Total message length. Can vary based on the content of
the message.
Hdr - SBE blockLength 0 2 16 Length of the root level of the message without counting
any repeating groups or variable-length fields. Used for
template ID 2 2 11 The identifier of a DescriptionKey/EoC in a message
schema.
numGroups 8 2 0
Application ConflationID 0 8 - Represents the conflation number and is stamped with
the UNIX timestamp of each new conflation.
DecryptionKey 8 variable - FIX SBE body to carry a 128 bits AES-128 description
key as binary data for Co-lo clients.
The field will be populated only for co-lo subscribers on
the multicast market data feed.
For NDFs this will be a dummy wrapper.
4.2.2.7 Encrypted Msg Wrapper

(octets) Value
Hdr - SOF message length 0 4 - Total message length. Can vary based on the content of
the message.
encodingType 4 2 Big-endian
Hdr - SBE blockLength 0 2 52 Length of the root level of the message without counting
any repeating groups or variable-length fields. Used for
numGroups 8 2 1 One repeating group will present in this message.
Application Nonce 0 16 Used to ensure security for a stream cipher.
EncryptionType 16 1 Defines the type of the encryption used.
Value Description
0 None (Unencrypted)
1 AES-128 Counter Mode
ConflationID 17 8 Defines the unique link to the decryption key. It is
stamped with the UNIX timestamp of each conflation.
EncryptedPayload 25 VAR Defines the encrypted message (Header + Application
Body) and can be either:
• Market Data Snapshot Full Refresh
• Market Data Snapshot Incremental Refresh
Appendix A Version History
Appendix A Version History

1.1 Overview, Premium IP Multicast Updated descriptions to reflect that market data sent via the Colo Multicast
Feed, Matching Cleared NDF IP Premium Feed will be unencrypted for Cleared NDF venue and will be
Venues, Message encoding and encrypted for other venues
decoding
1.1 Premium IP Multicast Feed Figure 1 was replaced with a new one to reflect behavior for NDF Venues
and other venues
1.1 Matching Cleared NDF Venues Figure 2 was updated to reflect the behavior of unecrypted and encrypted
market data
1.1 Message encoding and decoding Included Figure 3.1
1.1 Conflation Setup Included Figure 4.1
1.1 VWAP Explained the behavior of VWAP publication for trade amendments and
cancellations
1.1 Message Types for Session Included Topic and Context messages to the table
Messages:
1.1 Negotiation Response Included the two Reserve fields at the bottom of the Negotiation Response
message
1.1 Context Message Removed the layout of the Sequence message and replaced with the layout
of the new Context message being used in Colo Multicast Premium IP Feed
1.1 Topic Message Include the layout of the new Topic message being used in Colo Multicast
Premium IP Feed
1.1 Security Definition Included the new fields TimedOrderMinDuration, TimedOrderMaxDuration,
MinimumQuoteLife, MinIcebergOrderTipSize, MaxIcebergOrderTipSize to
the Security Definition message
Included the new repeating group IcebergTipDelayGrp with the new fields ID,
MinReplenishDelay and MaxReplenishDelay
1.1 Encrypted Msg Wrapper Values added to EncryptionType field
Offsets of the fields EncryptionType and VariableDataField corrected

Lseg FX Market Data Api Spec v1.3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lseg FX Market Data Api Spec v1.3

Uploaded by

Copyright:

Available Formats

LSEG FX

FX MARKET DATA API SPECIFICATION (FIX SBE VERSION 2 RELEASE CANDIDATE 2)

Document version 1.3

© LSEG 2023. All rights reserved.

About this document ......................................................................................................................................................................... 6

2.3 Standard TCP/IP Feed ...................................................................................................................................................... 16

2.4 Conflation Setup ................................................................................................................................................................ 18

3.2 High Availability and Disaster Recovery ............................................................................................................................ 21

3.3 Order Book Replenishment................................................................................................................................................ 22

4.2 Application Layer Messages .............................................................................................................................................. 33

Appendix A Version History .................................................................................................................................................... 56

About this document ......................................................................................................................................................................... 6

2.3 Standard TCP/IP Feed ...................................................................................................................................................... 16

2.4 Conflation Setup ................................................................................................................................................................ 18

3.2 High Availability and Disaster Recovery ............................................................................................................................ 21

3.3 Order Book Replenishment................................................................................................................................................ 22

4.2 Application Layer Messages .............................................................................................................................................. 33

Appendix A Version History .................................................................................................................................................... 56

About this document

FOR FURTHER INFORMATION

Version Section Description

Version Section Description

Chapter 1 Market Data API Overview

1.2 SUPPORTED XML SCHEMAS

Schema File / Version Comment

lseg-fx-market-data-api-v1.2-schema-xml v1.0.xml Identical in content to the latest schema.

Chapter 2 System Architecture

Subscribers may subscribe to screened or unscreened market data.

2.2 PREMIUM IP MULTICAST FEED

2.2.1 Matching Cleared NDF Venues

2.2.2 All other Venues

Figure 1: Connectivity Model for Premium IP Multicast Feed

2.2.3 Message encoding and decoding

0 (Unencrypted) or 1 (AES-128 Counter

Figure 3: Counter (CTR) mode Decryption

2.2.3.1 IGMP configuration

2.2.4 Security Definition Feed

2.2.5 Order Book, Security Status and Statistics Feed

Figure 4: Colo Premium Multicast Feed Connectivity Overview

2.2.6 Sequencing and Recovery

Figure 5: Tracking Sequenced flows with Context and Topic Messages

2.3 STANDARD TCP/IP FEED

2.3.1 Security Definition Feed

2.3.2 Order Book and Statistics feed

2.4 CONFLATION SETUP

Figure 7: TCP/IP Feed Connectivity Overview

Chapter 3 Service Description

3.1 MARKET DATA DISSEMINATION SPECIFICS

3.1.1 Order Book Dissemination

3.1.2 Statistics Calculation and Dissemination

User Type LTP VWAP

Standard TCP/IP subscribers

3.1.3 Security Status Dissemination

3.2 HIGH AVAILABILITY AND DISASTER RECOVERY

3.2.1 Point-to-Point (TCP/IP) Market Data Subscribers

3.2.2 Multicast (UDP) Market Data Subscribers

3.3 ORDER BOOK REPLENISHMENT

3.4 SCHEMA BACKWARD COMPATIBILITY

Chapter 4 Message Formats

Header Field Offset Length Data Type

Header Field Offset Length Data Type

4.1 SESSION LAYER MESSAGES

4.1.1 Message Types for Session Messages: