Contributing your data to Refinitiv

Gurpreet Bal
Platform Application Developer Platform Application Developer


In this article we will visit contributions and explore different mechanisms to contribute your data to Refinitiv. It is focused around the new Refinitiv Contribution Channel (RCC), which is a replacement for the legacy Market Link IP (MLIP) system.

Data Contribution is a means to send your pricing data to Refinitiv, from where it can fan out globally. Leading market participants, such as banks and brokers, use Refinitiv to publish and distribute their information to the community of financial professions, in order to advertise their prices to clients and prospects.

The Contributed Data is sent directly from the client to Refinitiv and not via a financial exchange. A client can contribute data either using a Desktop Product like:

  • Insertlink for Eikon
  • Eikon Excel

or by writing their own contribution applications using the Real-Time API SDK in C++ or Java.

In this article we will focus on latter - contribution of data using the API and the Refinitiv Contribution Channel. The reader must have an understanding of Real-Time SDK (formarly known as EMA), and be familiar with OMM Market Price data. You should also have a basic understanding of Refinitiv market data infrastructure components like ADS, ADH etc. The code snippets in this article are shown for Refinitiv Real-Time SDK - Java.

Contribution setups

There are two key options, through which an API developer can contribute data to Refinitiv head-end:

This option is to use and configure the Refinitiv's Real-Time Distribution formarly known as TREP, to take care of contribution specific connection and login details.

The option is suited for clients, who do not have an on-site Refinitiv's Real-Time Distribution System installation, and it utilizes an encrypted tunnel connection to connect to RCC servers.

The diagram below shows the complete data contribution and subscription cycle. The contributor applications on the bottom left quadrant connect through Refinitiv's Real-Time Distribution System (ADS and ADH), or a direct connection. The contributed data makes its way upstream to the Refinitiv's Real-Time Core, from where it can be distributed out to any data subscriber globally (shown on the right).

Contribution through Refinitiv's Real-Time Distribution System

The Refinitiv's Real-Time Distribution System (RTDS) can be configured to take care of contribution specific connection and login details. It entails configuring the Tunnel Stream Aggregator (TSA) in the ADH. Once RTDS configuration is complete, ADH takes care of the work required to connect to contribution head-end, and all an API application does is off-stream posting. The RTDS infrastructure connects to RCC through the delivery direct network, which is a private network between a client site and Refinitiv. The TSA adapter is already packaged with the ADH version 3.2, and needs to be configured.

Here is a sample TSA configuration for Advanced Distribution Hub (ADH):


hostname*adh*primeTopology : True

hostname*adh*routeList : trcc

hostname*adh*trcc.route*TRCC*Interactive*groupList : 1, 3, 4, 6

hostname*adh*trcc.route*TRCC*appServiceName : DDS_TRCE

hostname*adh*trcc.route*TRCC*commLinks : Interactive

hostname*adh*trcc.route*TRCC*dacsAttributes :

hostname*adh*trcc.route*TRCC*datastreamMonitor*interruptionDetection : False

hostname*adh*trcc.route*TRCC*datastreamMonitor*interruptionDuration : 4

hostname*adh*trcc.route*TRCC*datastreamMonitor*trafficWindow : 10

hostname*adh*trcc.route*TRCC*downloadCriteriaName :

hostname*adh*trcc.route*TRCC*hashIDs :

hostname*adh*trcc.route*TRCC*initialOpenLimit : 256

hostname*adh*trcc.route*TRCC*lockedDumpFile :

hostname*adh*trcc.route*TRCC*maxCache : 10000

hostname*adh*trcc.route*TRCC*primaryProvider : True

hostname*adh*trcc.route*TRCC*serverCost : 0

hostname*adh*trcc.route*TRCC*serverId : 287

hostname*adh*trcc.route*TRCC*serverPartitionList :

hostname*adh*trcc.route*TRCC*serverPartitionNegationList :

hostname*adh*trcc.route*TRCC*tunnelStream*numIpcOutputBuffers : 400

hostname*adh*trcc.route*TRCC*tunnelStream*userName :  ****

hostname*adh*trcc.route*TRCC*tunnelStream*userPassword : ****

hostname*adh*trcc.route*TRCC*updateRateThreshold : 200

hostname*adh*trcc.route*TRCC.enableTunnelStreamAggregation : True

hostname*adh*trcc.route*allowSuspectData : False

hostname*adh*trcc.route*applicationId : 256

hostname*adh*trcc.route*compressionType : 0

hostname*adh*trcc.route*encryptionProtocol : TLSv1.2

hostname*adh*trcc.route*hostList : **** 

hostname*adh*trcc.route*maxIncomingBytesPerSecond : 0

hostname*adh*trcc.route*maxIncomingMessagesPerSecond : 0

hostname*adh*trcc.route*minCompressionThreshold : 0

hostname*adh*trcc.route*numIpcInputBuffers : 10

hostname*adh*trcc.route*numIpcOutputBuffers : 400

hostname*adh*trcc.route*pingInterval : 2

hostname*adh*trcc.route*port : 443

hostname*adh*trcc.route*protocol : rssl

hostname*adh*trcc.route*proxyHost :

hostname*adh*trcc.route*proxyPort :

hostname*adh*trcc.route*recoveryInterval : 10

hostname*adh*trcc.route*routeEnabled : True

hostname*adh*trcc.route*rsslConnectionType : encrypted

hostname*adh*trcc.route*serviceList : TRCC

hostname*adh*trcc.route*singleOpen : True

hostname*adh*trcc.route*tcpNoDelay : False

hostname*adh*trcc.route*tcpRecvBufSize : 524288

hostname*adh*trcc.route*tcpSendBufSize : 64240

hostname*adh*trcc.route*useReactor : True

hostname*adh*trcc.route*userName : rmds

hostname*ads*admin*sharedMemorySize : 12000000

hostname*ads*bindAggStatsThread :

Here we configured the Service Name as RCC and provided the RCC login userName and userPassword. We also defined a route with name trcc and configured it with the server hostList and port. TSA adapter will use rssl protocol and encrypted rssl connection. All this configuration information is available from the Refinitiv Account Manager. It is not advisable to change the ADH configuration, if you are not familiar with the configuration procedures. Please consult your Market Data administrator for any questions regarding this.

When the ADH is restarted with this configuration, the log file entries show the status of tunnel stream aggregator:

            <torsrmds11.1.adh.serviceGenerator.trcc.route.TRCC: Debug: Thu May 17  07:00:11 2018>
Server (TRCC, 276) has been restarted on network.

<torsrmds11.1.adh.sourceSSLDistribution.sslDispatcher.trcc.route.DDS_TRCE: Info: Thu May 17 07:00:11 2018>
Server "TRCC" started for RSSL application "DDS_TRCE:10" on route "trcc". Tunnel stream is open.

<torsrmds11.1.adh.sourceSSLDistribution.sslDispatcher.trcc.route.DDS_TRCE: Info: Thu May 17 07:00:11 2018>
Tunnel stream is open with maxMsgSize = 614400; maxFragmentSize = 6144; flow control type = 1; Tunnel stream recv window size = 12288; Tunnel stream send window size = 750000; Tunnel stream authentication type = 1; Tunnel stream data integrity type = 1

Once this configuration is complete and the Contribution service RCC is available to the user, as shown in the Service-Up state in ADH console.

Now, an EMA application can be used to POST data to this service in RTDS. Following snippet of code is taken/modified from EMA consumer example series300\example341__MarketPrice__OffStreamPost, available in the SDK package. Complete RTDS contribution posting sample is attached here.

A successful login to RTDS, results in the Login-Refresh message.


public void onRefreshMsg(RefreshMsg refreshMsg, OmmConsumerEvent event) {

    if(refreshMsg.domainType() == EmaRdm.MMT_LOGIN && 

    refreshMsg.state().streamState() == OmmState.StreamState.OPEN && 

    refreshMsg.state().dataState() == OmmState.DataState.OK ) {

        // login successful, save variables

        _postStreamID = refreshMsg.streamId();

        _ommConsumer = (OmmConsumer) event.closure();

        _streamHandle = event.handle();

        // start posting



The method postMessage which populates and sends the contribution fields is as follows:


public void postMessage() {

// update the contributed fields

FieldList nestedFieldList = EmaFactory.createFieldList();

nestedFieldList.add(EmaFactory.createFieldEntry().real(22, _bid++, OmmReal.MagnitudeType.EXPONENT_NEG_1));

nestedFieldList.add(EmaFactory.createFieldEntry().real(25, _ask++, OmmReal.MagnitudeType.EXPONENT_NEG_1));


// create an update message for our item

UpdateMsg nestedUpdateMsg = EmaFactory.createUpdateMsg()





// create a post message, and embed the update

PostMsg postMsg = EmaFactory.createPostMsg()








// send to realtime distribution system

_ommConsumer.submit(postMsg, _streamHandle);


This posted data will automatically be forwarded to RCC and thus contributed to Refinitiv. The output from this EMA sample shows a successful login to ADS, followed by initial contribution upon login-refresh and multiple contributions upon receiving an acknowledgment:

            Jul 03, 2018 2:33:27 PM com.thomsonreuters.ema.access.ChannelCallbackClient reactorChannelEventCallback
INFO: loggerMsg
ClientName: ChannelCallbackClient
Severity: Info
Text: Received ChannelUp event on channel Channel
Instance Name EmaConsumer_1
Component Version ads3.2.1.L1.linux.tis.rrg 64-bit

----- Refresh message ----
domain="Login Domain"
state="Open / Ok / None / 'Login accepted by host ***.'"
itemGroup="00 00"
Attrib dataType="ElementList"
ElementEntry name="AllowSuspectData" dataType="UInt" value="1"
ElementEntry name="ApplicationId" dataType="Ascii" value="256"
ElementEntry name="ApplicationName" dataType="Ascii" value="ADS"
ElementEntry name="Position" dataType="Ascii" value=""
ElementEntry name="ProvidePermissionExpressions" dataType="UInt" value="1"
ElementEntry name="ProvidePermissionProfile" dataType="UInt" value="0"
ElementEntry name="SingleOpen" dataType="UInt" value="1"
ElementEntry name="SupportEnhancedSymbolList" dataType="UInt" value="1"
ElementEntry name="SupportOMMPost" dataType="UInt" value="1"
ElementEntry name="SupportPauseResume" dataType="UInt" value="0"
ElementEntry name="SupportStandby" dataType="UInt" value="0"
ElementEntry name="SupportBatchRequests" dataType="UInt" value="7"
ElementEntry name="SupportViewRequests" dataType="UInt" value="1"
ElementEntry name="SupportOptimizedPauseResume" dataType="UInt" value="0"

System refresh, starting posting...
----- Ack message ----
domain="MarketPrice Domain"

Continue posting...
----- Ack message ----
domain="MarketPrice Domain"

Contribution without Real-Time Distribution System

When using the API to contribute without using the RTDS infrastructure, the application also has to deal with additional complexity of connecting and establishing an encrypted tunnel to one of the RCC servers in the cloud. This is more suited for clients, who do not have an on-site RTDS installation. These customers will have the option to connect to RCC through either Internet or Delivery Direct network.

To contribute directly to RCC, an EMA application undertakes following three steps:

  1. Establish an encrypted Tunnelstream connection to one of the RCC hosts. For production applications, it is recommended to establish two simultaneous connections, to two different servers.
  2. Upon establishing the tunnel stream, send the login request.
  3. Once the login is accepted, the application is ready to start contributing on the login substream.

An application should only contribute to a single stream at any given time. The second stream is for redundancy purposes, and should only be used if there are issues with the first one. Once the encrypted connection is established, the process of posting data for contribution is quite similar to the code snippet shown earlier.

The EMA sample: series400\example440__System__TunnelStream which ships with the SDK distribution, forms the basis of establishing the encrypted tunnel. Please refer to EMA Java Contributions tutorial and EMA C++ Contributions tutorial, to view the step by step process, and complete code sample to build and run a contribution app.


Refinitiv Real-Time SDK