thomson reuters matching api · thomson reuters matching api document ... reuters has made a...

THOMSON REUTERS MATCHING API

Document Version 1.0.17 Date of issue: 29 June 2011

CLIENT SITE DEPLOYMENT GUIDE

Legal Information

© Thomson Reuters 2011. All Rights Reserved.

Thomson Reuters, 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. Thomson Reuters, 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 Thomson Reuters and may not be reproduced, disclosed, or used in whole or part without the express written permission of Thomson Reuters.

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 Thomson Reuters as set out in the contract existing between us.

Matching API - Client Site Deployment Guide of 24 Document Version 1.0.17

Contents

Contents About this document .............................................................................................................4

Intended readership................................................................................................................................. 4

In this document ...................................................................................................................................... 4

Glossary................................................................................................................................................... 4

Feedback................................................................................................................................................. 4

Chapter 1 Introduction .....................................................................................................5

Chapter 2 Matching API connectivity overview .............................................................6

2.1 General Requirements for RFA/FIX Client Applications.................................................6

2.2 Connectivity requirements specific to RFA client applications .......................................6

2.3 Connectivity requirements specific to FIX client applications.........................................7

2.4 Connectivity requirements for Prime Broker Sites..........................................................7

Chapter 3 Topologies .......................................................................................................8

3.1 New Matching API only deployment ...............................................................................8

3.2 Client Site with Matching APIs........................................................................................9

3.3 Hybrid Client Site ..........................................................................................................10

Chapter 4 Service IP Addressing and use....................................................................11

4.1 Service Delivery ............................................................................................................11

4.2 Connecting to the Matching FIX Gateway ....................................................................13

4.3 Connecting to the Matching Point to Point Servers (P2PS) .........................................15

4.4 Example MAPI Application IP Addressing Requirements ............................................16

Chapter 5 ASA5510 Firewall Deployment.....................................................................18

5.1 Firewall Choices............................................................................................................18

5.2 Rules and Configuration ...............................................................................................18

5.3 ASA5510 Resiliency Arrangements..............................................................................20


About this document

About this document

Intended readership

Thomson Reuters internal support staff planning or installing systems or client network and infrastructure personnel using and implementing the Thomson Reuters Matching API product.

In this document

This document describes network configuration options to support the Matching API product that uses FIX and RFA interfaces into Thomson Reuters Matching.

Glossary

Term Definition

AQ Auto Quote

CNET Client network, i.e. the client’s own infrastructure

DNS Domain Name System

DR Disaster recovery

FIX Financial Information eXchange Protocol. Protocol for trading partners to communicate order related messages electronically.

FQDN Fully Qualified Domain Name

IDN Integrated Data Network. Reuters network for delivery of information products.

MFG Matching FIX Gateway

MPLS Multi-Protocol Label Switching

PB Prime Broker

PBC Prime Broker Client

RFA Reuters Foundation API (RFA)

TLAN Transactions LAN

Feedback

For more information please contact your Thomson Reuters Account Manager or current Transactions Business contact.


Chapter 1 Introduction

Chapter 1 Introduction

As part of our going commitment towards providing a world-leading FX Matching service Thomson Reuters has made a significant investment into its Thomson Reuters Matching service. The Thomson Reuters New Matching Program (NMP) delivers an enhanced Matching system that is high performing, scalable and extensible. The first phase of the NMP successfully upgraded the core Matching host on September 19th 2010. The second phase delivers a completely new set of Matching API solutions. Later phases will introduce a new Matching user interface for spot traders as well as functional enhancements to the Matching service.

The Matching APIs will replace our current Auto Quote API and consist of two interfaces, namely the Reuters Foundation API (RFA) and the Matching FIX interface. The RFA interface is used for price discovery and the Matching FIX interface is used for order entry, cancelation and post trade processing.

The Financial Information eXchange (FIX) Protocol is a widely used industry standard for order entry and post trade management. For further details you can register at http://www.fixprotocol.org/ and review the Thomson Reuters FIX messaging proposal which has been approved by FIX Protocol, Ltd. as part of their v5.0 SP2 EP100 release http://www.fixprotocol.org/specifications/EP100.


http://www.fixprotocol.org/

http://www.fixprotocol.org/specifications/EP100

Chapter 2 Matching API connectivity overview


We start by showing, in Figure 1, a high level logical architecture diagram of the Thomson Reuters Matching API service.

Su

bsc

rib

er T

rust

ed

Net

wo

rkT

HO

MS

ON

RE

UT

ER

S

Figure 1: Thomson Reuters Matching API logical architecture

2.1 General Requirements for RFA/FIX Client Applications

All FIX and RFA client applications are developed and managed by the client, not by Thomson Reuters. As such, client applications are deployed on the client’s LAN.

All FIX Order entry traffic originates from the client’s LAN and is routed into the TLAN via a Thomson Reuters firewall.

Subscriber applications connect to two services, a FIX gateway to support FIX protocol message workflows and a Point to Point server (P2PS) to provide market data to the RFA Market Data Feed Direct (MDFD) consumer.

2.2 Connectivity requirements specific to RFA client applications

In lieu of planned future FQDN support clients will be provided with 4 IP addresses. These addresses are for the purposes below:

One pair (2) for ‘A’ and ‘B’ connections to P2PSs located within their assigned primary regional distribution site.

Another pair (2) for accessing the ‘A’ and ‘B’ P2SPs located at their designated secondary site.

In the event of a primary site failure scenario, clients will be required to manually re-point their RFA applications accordingly.



For day one, (prior to the deployment of the P2PS on the TLAN), clients will only be permitted to deploy a maximum of 2 RFA client applications per client site.

2.3 Connectivity requirements specific to FIX client applications

In lieu of planned future FQDN support clients will be provided with 4 ip address used to access the live Matching FIX Gateway (MFG) in each service condition. The IP address is that of a firewall located within a Thomson Reuters regional data centre. The firewall effectively acts as a proxy for all FIX connections originating from the client site to the Thomson Reuters global data centre where the live MFG is deployed and running.

These addresses are for the purposes below:

Two for routing their FIX connections to the live and DR MFG from their assigned primary regional site.

Two for routing their FIX connections to the live and DR MFG from their assigned secondary regional site.

In the event of a primary site failure scenario, clients are required to manually re-point their FIX applications accordingly from Live to DR.

Note: Under normal operating conditions (non DR scenarios) clients will be unable to establish connections to servers located within the Thomson Reuters DR site.

FIX clients may optionally utilise one TLAN for RFA/FIX connectivity (e.g. mini-TLAN) and another for credit purposes, both sites can trade into Matching under same Matching Site Id (Credit Code). This concept is explained in greater detail below.

2.4 Connectivity requirements for Prime Broker Sites

Connectivity requirements for Prime Broker (PB) sites are the same as standard subscriber sites with the exception of the features highlighted below.

Prime brokers have a unique requirement to login a Special Ticket User (STU). STUs are used for the processing of post trade messages generated from their Prime Broker Clients (PBCs). Prime Brokers may login their STUs from a:

Matching Keystation

Custom built FIX based post trade application

FIX2TOF adaptor developed by Thomson Reuters.

The following connectivity requirements apply to all STU deployment types:

Any FIX STU’s, including the FIX2TOF Adaptor developed and licensed by Thomson Reuters, must be deployed on the client LAN.

FIX STUs connect via the Thomson Reuters firewall to the MFG to receive notifications and Trade Capture Reports (TCRs).

Connectivity requirements to the MFG are identical to that of any other FIX application.


Chapter 3 Topologies


In this section we describe the supported topologies used in the Matching API service. Please liaise with you local Thomson Reuters Technical account manager who will be able to advise on the best approach to suit your business.

3.1 New Matching API only deployment

In the first topology option we show a typical arrangement for deployment of the Matching API. In this example a Matching subscriber wishes to deploy the Thomson Reuters Matching APIs at a remote location from their primary trading site. Within the remote site the client does not have any requirement to manually execute trades, administer credit or manage payment instructions. This deployment option will typically be used by Prime Broker Clients (PBCs) but is also available to standard subscribers. The reduced footprint client site configuration is often referred to as a Mini-TLAN configuration and is shown in Figure 2.

Figure 2: Mini-TLAN with RFA and FIX



3.2 Client Site with Matching APIs

The following provides an example of a Matching subscriber who has completely migrated from AQ to RFA/FIX however they still have requirements to retain the Matching Keystations for the purpose of manual trading, payment instructions and credit management. This client site configuration is referred to as a Maxi-TLAN configuration and is depicted in Figure 3..

Standard Matching

TCSSMatching

C3

FX Matching Keystation

MPLS

TLAN Switch

TLAN Firewall Optional Subscriber Application

MDFD FIX Engine

THOMSON REUTERS MATCHING

FIX v5.0 SP2 EP100

(RFA market data) OMM via RSSL

Transactions LAN Client LAN

TCSSMatching

C3


Figure 3: Maxi-TLAN with RFA and FIX



3.3 Hybrid Client Site

The following provides an example of a Matching subscriber who, in the process of migrating to RFA/FIX, wishes to retain their Auto Quote applications during their migration period. This client site configuration is referred to as a hybrid Maxi-TLAN configuration.

In Figure 4 below the left Transactions LAN demonstrates the existing configuration found in an AutoQuote deployment with a firewall configuration supporting connectivity to/from the client LAN hosting the Matching API Application, etc.

Standard Matching

TCSSMatching

C3

MPLS

TLAN Switch

Optional Subscriber Application

MDFD FIX Engine

THOMSON REUTERS MATCHING

FIX v5.0 SP2 EP100

(RFA market data) OMM via RSSL

Transactions LAN Client LAN

TCSSMatching

C3


FX Matching Keystation FX Matching

KeystationAutoQuote

TLAN Firewall

Figure 4: Hybrid Maxi-TLAN Client Site with AQ and RFA/FIX


Chapter 4 Service IP Addressing and use


4.1 Service Delivery

On completion of certification a series of IP addresses will be released which will provide connectivity to the Production (London) and Disaster Recovery (Geneva) Matching service via primary distribution systems located in the following regions:

EMEA (London)

Americas (Nutley)

Asia Pacific (Singapore)

And to the Production (London) and Disaster Recovery (Geneva) Matching service via secondary distribution infrastructure in:

EMEA (Geneva)

Americas (Hauppauge)

Asia Pacific (Hong Kong)

To demonstrate this addressing and configuration we shall consider connectivity to Production and DR Matching over a primary EMEA (London) distribution and secondary EMEA (Geneva). Figure 5 describes the connectivity routes to the service (legend overleaf).

Figure 5: Connection routing to the Matching services in Production and DR



Thomson Reuters Controlled – Production Matching service to secondary distribution

Client Managed Targeting RFA – Normal service. Primary distribution for market data

Client Managed Targeting RFA – Primary distribution failure. Secondary distribution for market data

Thomson Reuters Controlled – Production Matching Service to primary distribution

Thomson Reuters Controlled – Matching Host failure state. DR service to primary distribution

Thomson Reuters Controlled – Matching Host failure state. DR service to secondary distribution

Client Managed Targeting FIX – Normal service. Production (or DR) deal management via primary distribution

Client Managed Targeting FIX – Primary distribution failure. Production (or DR) deal management via secondary distribution

Given the diagram on the previous page we can now consider FIX and RFA (MDFD) connectivity individually. The tables in the following sections describe the IP address ranges for each service conditions to demonstrate where a particular IP address is valid. Please refer to sections 2.2 and 2.3 in this document for further details on how your IP targets will be allocated.

Note: The assigned connectivity which is provided after certification of Matching API Application is subject to Rule 15.2 in the Matching Rule Book. This constrains the use of IP addresses in the tables below and only permits a Matching API Client to use the IP addressing supplied on completion of certification.



4.2 Connecting to the Matching FIX Gateway

The following table details the IP address ranges for FIX message routes shown in section 4.1. Here we consider all three primary and all three secondary distribution centres and their relation to the service/routing conditions.

As described in section 2.3; in the future when Thomson Reuters provided FQDNs are used to connect to the FIX proxy at the primary distribution site (or secondary in the event of a primary distribution site failure) a Matching Host DR state will automatically re point the FQDN to the DR Matching Host. This can be thought of as the green line to red line in the FIX path being switched on the FQDN association.

If IP addresses are used instead of the FQDN the client must factor in the requirement to re point the FIX engine as required given the service conditions this is set out in Table 4.2:

Table 4.2 FIX Gateway Address Ranges

REGIONAL DISTRIBUTION CENTRE

FIX PROXY IP ADDRESS RANGE

SERVICE CONDITION FIX MESSAGE

ROUTES

PRIMARY DISTRIBUTIONS

EMEA (LONDON) AMERICAS (NUTLEY)

ASIA PACIFIC (SINGAPORE)

159.220.106.193 To 159.220.106.196

NORMAL OPERATION

Use MFG IP addresses at the primary distribution

site

SECONDARY DISTRIBUTIONS

EMEA (GENEVA)

AMERICAS (HAUPPAUGE) ASIA PACIFIC (HONG KONG)

159.220.106.225 To 159.220.106.228

DR MODE FOR PRIMARY DISTRIBUTION SITE

Transition from primary to secondary distribution site Use IP addresses at the

secondary distribution site


EMEA (LONDON) AMERICAS (NUTLEY)


159.220.106.197 To 159.220.106.200

DR MODE FOR MFG Matching Service transitions from normal operation to remote DR site Use secondary MFG IP addresses at the primary distribution site


EMEA (GENEVA) AMERICAS (HAUPPAUGE) ASIA PACIFIC (HONG KONG)

159.220.106.229 To 159.220.106.232

DR MODE FOR MFG AND PRIMARY DISTRIBUTION

SITE Matching Service transitions and distribution site transition from normal operation to remote DR site

Use secondary MFG IP addresses at the secondary

distribution site



Note: White background in the table denotes scenarios where the Matching Engines are running in the normal service mode. Grey background in the table denotes scenarios where the Matching Engines are running in a DR mode at a different location.

Example:

A client in the New York area wishing to configure network devices in preparation for use would be interested in the IP ranges for “Americas (Nutley)” and “Americas (Hauppauge)”



4.3 Connecting to the Matching Point to Point Servers (P2PS)

Table 4.2 details the IP address ranges for connections to Point to Point Servers (P2PS) described in section 4.1 and Figure 5 by the RFA MDFD. Here it can be seen that there are only two service conditions to be considered as opposed to four in relation to FIX. These are:

Primary Distribution site active

Secondary Distribution site active (primary failure)

Table 4.3 RFA P2PS Address Ranges

DISTRIBUTION CENTRE P2PS TARGET IP ADDRESS RANGE

SERVICE CONDITION ROUTE CONDITIONS

PRIMARY DISTRIBUTION

EMEA (LONDON)

159.220.106.201

To 159.220.106.212


AMERICAS (NUTLEY)


159.220.106.201

To 159.220.106.202

NORMAL

Primary distribution IP address range

OR

SECONDARY DISTRIBUTION

EMEA (GENEVA)

159.220.106.233

To 159.220.106.244


AMERICAS (HAUPPAUGE) ASIA PACIFIC (HONG KONG)

159.220.106.233

To 159.220.106.234

DR MODE FOR DISTRIBUTION SITE

Transition from primary

to secondary distribution site

Use P2PS IP addresses at the secondary distribution site

OR

Note: White background in the table denotes the scenario where the P2PS is running in a normal mode within the primary distribution site. Grey background in the table denotes a scenario where the P2PS is running in a DR configuration within a secondary distribution site



4.4 Example MAPI Application IP Addressing Requirements

Putting together the information from sections 4.1, 4.2 and 4.3 we can provide an example of the IP address that a MAPI application may be given as part of its deployment into production.

Table 4.4a demonstrates a typical list of IP addresses that might be released to you for one of your FIX sessions. The FIX client application must use the IP addresses provided below based on the service conditions previously outlined in section 4.2. The FIX session details which will include the FQDN, IP address, SenderCompId and User authentication details will be provided to you upon completion of your Matching API certification testing.

Similarly for RFA table 4.4b lists an example allocation of P2PS target IP address to be used by the RFA client application under the two distinct service conditions mentioned in section 4.3.

Table 4.4a Example allocated FIX target addressing

FIX Gateway Target IP Address Service Condition

159.220.106.193 NORMAL

Primary distribution IP addresses

159.220.106.225

DR Mode for Primary Distribution Site

Transition from primary to secondary distribution site Use IP addresses at the secondary distribution site

159.220.106.197

DR Mode for Matching FIX Gateway (MFG)

Matching Service transitions from normal operation to remote DR site

Use secondary MFG IP addresses at the primary distribution site

159.220.106.229

DR Mode for Matching FIX Gateway (MFG) and Primary Distribution Site

Use secondary MFG IP address at the secondary distribution

site

Note: White background in the table denotes scenarios where the Matching Engines are running in the normal service mode. Grey background in the table denotes scenarios where the Matching Engines are running in a DR mode at a different location.



Table 4.4b Example allocated RFA target addressing

P2PS Target IP Address Service Condition

159.220.106.201

159.220.106.202

NORMAL Primary distribution IP addresses

159.220.106.233

159.220.106.234

DR Mode for Primary Distribution Site Transition from primary to secondary distribution site Use P2PS IP addresses at the secondary distribution site

Note: White background in the table denotes the scenario where the P2PS is running in a normal mode within the primary distribution site. Grey background in the table denotes a scenario where the P2PS is running in a DR configuration within a secondary distribution site.


Chapter 5 ASA5510 Firewall Deployment.


5.1 Firewall Choices

The Matching API product requires access into matching via a Transaction LAN firewall to route the messaging to/from a client Matching API Application. The firewall(s) are intended to provide secure connectivity into the Matching Service fulfilling the security requirement to control/limit access to/from external services on the client LAN. Please refer to you sales point of contact for further information:

A dual configuration of the Cisco Secure Remote Access Firewall ASA 5510 provided by Thomson Reuters provides a resilient configuration. Please refer to you sales point of contact for further information.

5.2 Rules and Configuration

A predefined set of rules and configuration settings are implemented onto the chosen firewall deployment option. It is important that these firewall rules are maintained as they are implemented to not only protect the TLAN but to ensure correct and efficient message traffic routing to and from the Matching Host. This is as FIX and RFA traffic once inside the Matching Over IP (MOIP) circuit on the BT MPLS routing infrastructure is treated in the same manner as current Matching traffic.

In order for this to be achieved it is important that client connections are presented to BT as having come from a reserved TLAN address of X.X.X.3 or in some cases X.X.X.4.

The TLAN is therefore configured inside the firewall security and the Subscriber’s infrastructure is considered outside the TLAN firewall security. RFC1918 addressing must not be propagated as it may clash with the Client’s own addressing. Therefore there is a need to NAT the destination at the firewall.

Table 5.2 below describes the particular settings that the ASA5510 uses to correctly integrate into the BT MPLS Matching Over IP (MOIP) delivery circuit.

Table 5.2 Firewall configuration requirements.

Configuration item Setting Details

Open firewall port 60237 Non-SSL access to FIX Gateway.

Open firewall port 60238 SLL access to FIX Gateway.

Open firewall port 60239 Connection for RFA to P2PS.

Diagnostics/Logs Deny IP any log Has the effect of denying all other connections and logs this activity to file.

Network Address Translation

Translate MAPI service RFC1918 addresses to registered address space

A NAT to the 159.220.106.x Thomson Reuters registered addresses



Configuration item Setting Details

Connection/IP settings

TLAN side of firewall connects to:

xxx.xxx.xxx.3

xxx.xxx.xxx.4

Essential setting which allows firewall traffic entering the TLAN to be routed correctly. This is in line with the Matching Over IP (MOIP) service package on MPLS. The designated TLAN IP which replaces xxx.xxx.xxx will be provided by your Thomson Reuters Technical Account Manager after BT MPLS connection setup.


The Matching host servers are provided in the following registered network range: 159.220.106.192/26

Firewalls and routers on the client side should be configured correctly to connect this range. Note: Specific production connection addressing will be provided after completion of certification.


On TLAN switch the firewalls are connected to FASTETHERNET at: 1st firewall to Port 0/6 on first switch 2nd firewall to Port 0/6 on second switch Configuration on the TLAN switch is as below: interface FastEthernet0/6 description connect to 1st firewall switchport mode access switchport nonegotiate spanning-tree portfast

This port is configured as AUTO/AUTO. This is already setup on the switches and is shown for reference. Note:

Whilst the default is AUTO some clients require the port to be set to 100 Full duplex. A check is therefore required to verify the CNET interface port setting.



5.3 ASA5510 Resiliency Arrangements

The ASA5510 can be provided as a standalone or resilient pairing. On the firewall the Cisco Adaptive Security Device Manager (ASDM) software is used to configure the device as required by the Matching service. These configurations are made by Thomson Reuters prior to client handover.

In depth information regarding the Cisco device can be found on the Cisco website in the “Navigating the Cisco ASA 5500 Series Documentation” section at

http://www.cisco.com/en/US/docs/security/asa/roadmap/asaroadmap.html

For reference a schematic of the resilient Active/Standby failover arrangement is shown in Figures 6 and 7 overleaf where Figure 6 shows normal operation and Figure 7 a situation under failure.

This allows a Standby ASA to take over the functionality of a failed Active unit. When the active firewall fails it enters a Standby state leaving the Standby unit become Active. The Active firewall assumes the IP addresses and MAC addresses of the failed unit and begins passing traffic. The firewall that has become Standby takes the Standby IP addresses and MAC addresses.

Network devices see no change in the MAC to IP address pairing and as such there is no ARP entry change required or time out seen anywhere on the network. Therefore client systems new not attempt any other connections and continue via the default gateway which will have switched transparently.

Figure 6. Resilient Active/Standby ASA5510 pair – Normal running


http://www.cisco.com/en/US/docs/security/asa/roadmap/asaroadmap.html


Figure 7. Resilient Active/Standby ASA5510 pair – Switched running



5.4 Client Network Address Information Gathering

The ASA5510 forms the demarcation point of the Matching service into a client’s network infrastructure. In order to configure routing correctly between the Matching host and the client’s own Matching API Application the following pieces of IP information should be provided by the client.

Items 4 and 5 and options accompanying items 6, 7 and 8 are repeatable up to a value of 5 i.e. we are able to support up to 5 separate client IP ranges/network:

As per the note in Table 5.2 there is a requirement to check interface port setting. Whilst the default setting on the ASA device port is AUTO some clients require the port to be set to 100 Full duplex. A check is therefore required to verify the CNET interface port setting.

Item IP Parameter Notes Mandatory/Optional

1 Client Network Interface IP Address <CNET Interface IP Address>

This is the gateway the client will use for routing to the MAPI registered addresses.

Mandatory

2

Client Network Standby Interface IP Address <CNET Interface standby IP Address>

Required for configuration but not used for MAPI connections.

Mandatory

3 Client Network Subnet Mask <CNET Interface Subnet Mask>

The mask for items 1 and 2 Mandatory

4

Start of Client Application System IP Range <First FIX/RFA Client IP Range 1>

Beginning of IP range of client systems hosting the Matching API Application

Mandatory

5

End of Client Application System IP Range <Last FIX/RFA Client IP Range 1>

End of IP range of client systems hosting the Matching API Application

Mandatory

6 Network to route to

<FIX/RFA Client Network 1>

If routing is required for IP range defined in items 4 and 5

Optional

7

Subnet mask used in route

<FIX/RFA Client Network 1 Subnet Mask>

The mask for associated with item 6

Optional




Item IP Parameter Notes Mandatory/Optional

8 Gateway IP address for route

<CNET Gateway IP Address>

Gateway for route defined in item 6 and 7

Optional

© 2011 Thomson Reuters. All rights reserved. Republication or redistribution of Thomson Reuters content, including by framing or similar means, is prohibited without the prior written consent of Thomson Reuters. 'Thomson Reuters' and the Thomson Reuters logo are registered trademarks and trademarks of Thomson Reuters and its affiliated companies.

For more information

Send us a sales enquiry at financial.thomsonreuters.com/sales

Read more about our products at financial.thomsonreuters.com

Find out how to contact your local office financial.thomsonreuters.com/locations

Document Version 1.0.17 Date of issue: 29 June 2011

thomson reuters matching api · thomson reuters matching api document ... reuters has made a...

Documents