Last Updated: June 2026
Important Note: RFA 8.x is fully supported as of now, however this is a legacy API, and we are not investing in this API. It will be EOL’d in the near future, but we don’t have a date yet.
When we decide to EOL this, customers will be provided with at least 2-years notice. So RFA 8.x should not be used for new projects. In the meantime we have new APIs that should suit your needs better. View the list of updated APIs on the right hand side panel.
Overview
Whilst LSEG offers several current APIs and SDKs for working with Real-Time streaming data - many of our users have a considerable deployment of applications developed using our legacy APIs.
For many if not most of these applications, the original developers have moved on and the maintenance of these applications is the responsibility of someone who may have never coded with the underlying API or SDK.
For these applications, there will come a time, where the current maintainers will be asked to rewrite/migrate these legacy API applications to a current Real-Time APIs. Based on my experience of working with our users, this is often a cause of considerable anxiety for the developer - particularly if they have never used the legacy APIs and are suddenly faced with the task of learning two APIs - the legacy one and the newer alternative.
However, I have usually found the developer does not need to learn the legacy API in much detail. When helping developers in this situation, I find the following is usually sufficient to enable them to understand the legacy application code enough to migrate it to the newer API.
- Initially, a high-level overview outlining the key features of the legacy API helps the developer put things into context and gain a reasonable understanding of what the application is doing.
- I then follow this up with a walkthrough of key code snippets of an example application or their own codebase - highlighting key items such as configuration, initialisation, item subscription and so on.
In this document, I will attempt to document step 1 of the above. Whilst much of this information can be gleaned from the API's existing documentation, the information below would typically be spread out across several sections and/or documents.
Where it makes sense/is deemed necessary I will also provide an additional set of Migration Notes e.g. 'RFA to EMA Migration Notes' which would include what I typically cover in step 2 (and more). Links to any such notes will be added in the right-hand sidebar.
RFA C++ / JAVA API
Introduction
Robust Foundation API (RFA) is a high-performance data-neutral, thread-aware API for the Consumption, Publishing and Contribution of real-time streaming data from/to a Real-Time Distribution System (RTDS - formerly known as TREP) and offers low latency, high throughput data delivery (when using the OMM interface).
The most recent versions of RFA use the Open Message Model (OMM) to allow rich hierarchical data types including full order book support.
As a Feature complete API, whilst RFA supports recent compilers/IDEs/Operating systems – it does not contain features available in our newer strategic APIs, such as Cloud connectivity or support for newer RTDS functionality.
Languages Supported
C++, Java (and .NET wrapper) versions are available
Features
Key features/functionality of RFA are summarised below
Configuration
Uses a Configuration database that can be populated
· programmatically
· from a flat-file
· from Windows Registry (C++ Windows version)
· from an XML file (Java version - using Java Preferences API)
Configuration classes allow the reading of config data to be used within an RFA application. Configuration values fall into two main categories
· API configuration – Transport and API level (e.g. connection type, hostname, threading, retry, queue)
· Application configuration – Application related (e.g. RIC codes, username, runtime parameters)
The RFA Java version supports the use of System and User trees for storing Common and User-specific config values respectively.
Event model
RFA uses an asynchronous event mechanism – which requires the developer to register and implement event-based clients to handle events. Depending on the version of RFA the type of events varies e.g.
For the OMM based interface, the developer processes event types including:
· Connection state
· Item – which encapsulates a message containing data, status and acknowledgements
· Command Errors – e.g. invalid command submitted
· API Logging
Data request and response
Using the OMM interface requires a slightly different process:
· Loading Configuration
· Create Event Queue
· Create Logger and register interest Logger events
· Create OMM Consumer
· Register Interest in Connection and Error events
· Load Dictionary
· Create and submit Login request message to the server
· Create and send data item request message to the server
· Processing incoming events listed above (under Event model)
Data and Transport Protocol
The strategic OMM interface supports the more efficient binary encoded Wire Format. Combined with the hierarchical container-based flexibility of OMM, this allows us to support richer content such as Full Depth Order books, Yield Curves and custom data models whilst delivering considerably greater throughput and lower latency.
Use cases
Commonly used to Stream or snap real-time data records, as well as Timeseries(TS1) data and ANSI pages. Also used for publishing Streaming real-time data, as well as Contributing data internally or externally.
Pros/Cons
Pros include:
· Lower level, message-based
· Improved Flexibility over Legacy APIs
· OMM interface can consume newer richer data content available such as Full-depth Order Books
· OMM interface can publish newer richer data content such as Yield Curves, Full Depth Order Books and other custom defined data models
· Improved Performance compared to Legacy APIs
Cons include:
· Requires deployed or managed RTDS infrastructure (TREP)
· Feature complete does not support more recent or future RTDS(TREP) functionality
· Cannot connect to Cloud-based data sources
· Cannot contribute to cloud-based Contributions Channel
This document should be read in conjunction with the linked Articles (see the upper right-hand side) - namely 'Choosing your Real-Time Streaming API' as well as any relevant Migration notes.
