RTS 28 Process Notes

Summary
The requirement of the system is to produce output reports covering all Kyte trades in the format
required for RTS 28, and also to produce a machine-readable version for publication to the Kyte
website

The application loads trade details from various Kyte trading systems using components
implementing a common interface. Trade Information from these systems is stored in a single
database table in a common format, with one record per trade. Clients from all source systems are
mapped to the common Kyte Client ID.

SQL Server Reporting Services reports are used to generate the output reports that can be exported
as PDF or XML for publishing on website as per the RTS 28 requirements. It is at the report that the
data is filtered so that only trades for “Professional Clients” are included in the standard report.

The initial code was initially laid out on the assumption that it might be run at regular intervals
throughout the year rather than as a one-off process, but initially it is being run manually from visual
studio, one component at a time (see main process).

Visual Studio Solution

Source code is in Kyte Bitbucket

Project: Reporting
Repository: Rts28
VS Solution: Kyte.Reporting.Rts28.sln

You will need to add the “Microsoft Reporting Services Projects” extension from the Visual Studio
Marketplace to open this solution
Database
The database project uses DBUP for deployment. Please run start-migrations from the package
manager console on the database project to deploy/update the database.

Project: Kyte.Reporting.Rts28.DatabaseDeployment
Configuration file: appsettings.json

Main Process
The entry point process is hosted in a .NET Framework 4.7.1 console application, with the rest of the
code written in .net core 2.0. The host application has no logical function but does contain the main
settings file for the process.

Project: Kyte.Reporting.Rts28.ProcessHost
Configuration file: appsettings.json

The logical process runs from a .net core project, where dependency injection is used to register and
run all the component services (IProcessService) for loading trade data and writing to the
database.

Project: Kyte.Reporting.Rts28.Process
File: Rts28Process.cs

If you need enable and disable any components you can do so by commenting out sections in the DI
configuration.

The main process also triggers an update to the calendar table in the database so that the report is
able to use the number of business days in it’s calculation.

Input Components
The purpose of the import components is to query a source system, map the trades returned to a
common MarketOrder object, which is then stored (Inserted or Updated) in the common RTS28
database. Some of the input components need additional static reference data in order to map the
details into the MarketOrder object.

Each component loads its own LastProcessed and LatestTimestamp from the Source table in the
RTS28 database. This is used to determine which date range of trades to pull. These fields were
intended to be updated on completion of the process, so that the application could be run
periodically and it would load the next set of trades. However, for now this functionality has been
deliberately left out to enable easy manual running of the process in Visual Studio multiple times
over the same period. You will need to manually set the LatestTimestamp to be correct for the
period of data you want to load.

Bondia
RTS 28 Classifications
• Debit Instruments – Bonds
Source
This component queries the Bondia database directly to load trade details. Trades are mapped into
common MarketOrder objects. As these trades are not executed on an order book the client from
each Buy\Sell leg is recorded as both Client and Venue.

Additional Reference Data

The mapper makes a call to the ClientAPI to load in Bondia Client IDs mapped to KYTE#ID

Cash Equity – SSEOMS

RTS 28 Classifications
• Equities - Tick size liquidity bands 1 and 2
• Equities - Tick size liquidity bands 3 and 4
• Equities - Tick size liquidity bands 5 and 6

Source
This component is currently configured to pull data from a special dedicated SSEOMS database. This
is because the only full source for 2017 trade data was the B1 daily files. The SSEOMS database is
populated by a process that loads in data from a full years’ worth of SSEOMS B1 sources file. Note:
This could be replaced with a source direct from JUPITER for future years

Project: Reporting
Repository: SseomsB1Database
VS Solution: Kyte.Reporting.SseomsB1Database.sln

The query of SSEOMS data loads “Route to Street” messages, as these represent the MarketOrder
requirement of the RTS 28 Spec.

Additional Reference Data

Instrument (Ticker to ISIN) and Client (SSEOMS to KYTE#ID and LEI) Reference data is contained in
the dedicated SSEOMS database. This was particularly needed for 2017 data as the B1 didn’t include
much static in older trades. This reference data will need to be refreshed to include more recent
trades if the same process is used next time. Alternatively, the Client API could probably be used in
conjunction with JUPITER.

Equity Tick Sizes required to perform the Tick Size Classification bands, are downloaded by the
process directly from ESMA.

UBIX
RTS 28 Classifications
• Commodities Derivatives – Futures and Options admitted to trading on a trading venue
• Currency Derivatives – Futures and Options admitted to trading on a trading venue
• Equity Derivatives – Futures and Options admitted to trading on a trading venue
• Interest Rate Derivatives – Futures and Options admitted to trading on a trading venue

Source
This component queries trade details directly from the UBIX database. A dummy source library is
included for development/testing.
Additional Reference Data
The following files of static data were provided and contain a CFI Code which can be used to identify
the underlying derivative type from the source trades.

• FuturesRefData.txt – containing “CFI Code” and other instrument details keyed on ISIN
• OptionsRefData.txt – containing “CFI Code” and other instrument details keyed on ISIN

Updated data would be required for future processes

Brokerhub
RTS 28 Classifications
• Commodities Derivatives – Other commodities derivatives and emission allowances
derivatives
• Equity Derivatives – Swaps and other equity derivatives
• Interest Rate Derivatives – Swaps, forwards, and other interest rate derivatives
• Securities Financing

Source
The source is currently a custom version of the ms_middle_office MySQL database, without the
trade splitting by broker, and including the “Listed” field from the Brokerhub API. It uses only the EU
logons for Brokerhub API. The source code and schema for this custom database and loader
application has been supplied to Alexandre Fromage.

Additional Reference Data

Brokerhub doesn’t contain enough static data to be able to decide the underlying type of product
traded. Neither do the Client names in Brokerhub link to clients available in the Client API. Exports of
the lists of products and clients were produced and populated by the operations team to be used in
the process.

• BrokerhubClientsCompleted.csv
• BrokerhubProductsCompleted.csv

RBS
RTS 28 Classifications
• Currency Derivatives – Swaps, forwards, and other currency derivatives Equity Derivatives

Source
Trades are queried from the main ms_middle_office MySQL database from the rbs_fx_deal table.
The query excludes “Spot” trades where deal type is “FX” so includes Options and Forwards

Additional Reference Data

A list of the client codes that traded within the period was exported and given to middle office to
enrich with Kyte ID and LEI. This file is used as a source in the import

• RBSClients.csv
Core
Repository
When saving a list of MarketOrder objects the MarketOrderRepository uses a BulkMerge library to
automatically BCP the data to the SQL server in a Temp table, then MERGE the data to INSERT or
UPDATE (UPSERT) as required

The component used is a fork of an opensource component that has since become a commercial
component http://entityframework-extensions.net/

Hosted on https://github.com/garetharevans/SqlBulkTools

I previously copied a nuget package for this onto your network on the following path, so if you have
copied this into your internal nuget path you may want to update this document to have the correct
folder

\Development\ForGareth\SqlBulkTools.1.0.2.nupkg

Database
In order for the main output report to be able to filter by Regulatory Classification a Client table is
required in RTS 28 database.

Currently the Internal Kyte Client API doesn’t contain the regulatory classification for Clients. So for
the purposes of this report a table has been loaded with a snapshot of data exported from salesforce
that contains the classification. This data will need to be refreshed with any new process.

If the Client API is enriched to contain this classification then the process could be updated to
automatically refresh the client table.

SQL Server Reporting Services (SSRS) - Output Report

• RTS 28.rdl
This is the main output report for the RTS28 data. It structures the output as specified.
Filters default to the previous year, and Professional Clients only, however the user can
change the filters if required.
• RtsTransform.xsl
This xsl transform file is used by the RTS report when it is exported to XML. It cleans up the
XML outputted from the report, leaving it ready to publish on the website in a Machine-
Readable format.
• Missing Clients.rdl
This report lists any Clients found in the MarketOrder dataset that do not exist in the Client
table, highlighting any missing local static.

All files should be deployed to a report folder on the in house SSRS server, with permission so that
Compliance can run the reports directly in their browser.