regulatory reporting hub trading venue reporting · reporting hub rights for the member section...

Regulatory Reporting Hub

Trading Venue Reporting

November 2017

AGENDA

Deutsche Börse Group 1

1 Introduction

2 Member Section

3 Connectivity

4 Workflow

5 Live-Demo of RRH

MiFIR puts trading venues in charge of transaction reporting of

non-EEA members and institutions not subject to MiFIR


The transaction reporting obligation for non-MiFIR firms stems from MiFIR, article 26 (5)*. Therefore, for entities, which

are not subject to this regulation, the operator of a trading venue is responsible for the transaction reporting of financial

instruments traded on its platform.

Eurex and Frankfurt Stock Exchange (FSE, incl. Börse Frankfurt Zertifikate AG) hence request their participants, that are

not subject to MiFIR, to provide transaction report-relevant information to the respective trading venue.

Regulatory requirements

* Regulation EU No 600/2014

** Directive EU 2014/65/EU

The trading venues request their participants to submit the following information for transaction reporting:

Participant reference data

Participant reference data such as Legal Entity identification codes (LEIs) of participants, National IDs of the traders of the

respective member firms, algorithm certificates and short codes shall be submitted in the Member Section in accordance

with the deadlines in Section 1 of the Eurex Circular 040/17 and the FSE circular 60/17.

Transaction data

There are 65 data fields in the transaction report as set out in Annex I of Commission Delegated Regulation (EU)

2017/590 [former RTS 22]. While most of the fields can be populated using the transaction data of the respective trading

systems, the information for some fields (standard case nine) needs to be added by the participant.

Transaction Reporting Scope


Trading venues require their participants to connect to the

Regulatory Reporting Hub operated by DBAG‘s reporting ARM

Eurex and FSE require all participant not subject to MiFIR, to connect to Deutsche Boerse’s Regulatory Reporting Hub

(RRH) for the submission of transaction-related information.

Please note, that the establishment of the required reporting infrastructure and the timely provision of the required

information will become a membership requirement as of 3 January 2018.

Trading venues requirements

The member loads the provided daily extract into its own system and adds the missing data to each transaction (except

for cancel records). Afterwards, the complete transactions are sent back to the RRH in the usual MiFIR inbound file format

(CSV or XML). This is the standard process.

The member provides all transaction data except for the GDB exchange data in the usual MiFIR inbound file format. The

RRH adds the missing data (“exchange data enrichment”).

Participants’ options of reporting

Member X

T7 TES

Member A(non-MiFIR entity)

2.

Transaction

data delivery

8. RRH

transfers valid

transaction

report to BaFin

9. Feedback

from BaFin

1. Order/ trade flow

RRHEurex

/

Xetra

3. RRH sends Eurex Daily

Extract file at the end of Day

T via SFTP

4. Member A submits MiFIR

inbound file before 15:00 on

T+1

6. RRH sends Member A feedback

file

7. RRH

sends Eurex

Completenes

s Reports of

all non-MiFIR

members

5. RRH uploads the inbound

files and performs validation

checks.

BaFin

Process flow of transaction reporting of non-EEA members and

institutions not subject to MiFIR

AGENDA


1 Introduction

2 Member Section

3 Connectivity

4 Workflow

5 Live-Demo of RRH

The RRH user setup is done in the Member Section


member.regulatoryreportinghub.com

Several steps have to be completed in order to access the

Regulatory Reporting Hub

Setup User for Member Section

Maintain RRH User Rights

Create Certificate

Access Platform using Certificate

and Member Section Password


To create users the standard workflows of the Member Section

are being used


Users can be created using the

Create User function in the User

Administration or the Self-

Registration feature

Existing Member Section users

can be used as well

The users require Regulatory

Reporting Hub rights for the

Member Section with RRH user

being the minimal requirement

RRH Admin rights are required to

administer the services

The Regulatory Reporting Hub Administration is used to set

access rights for the RRH GUI (1/2)


The Regulatory Reporting Hub Administration is used to set

access rights for the RRH GUI (2/2)


Click on relevant RRH Service

Choose user tobe maintained

Set user rightsand restrictions

The last step to get access to the hub is to create a certificate


To create a certificate the Certificate Generator

has to be used

JAVA 1.7 or above is required to launch the

generator

Once the certificate is installed the Regulatory Reporting Hub

can be accessed


Production: www.regulatoryreportinghub.comSimulation: simu.regulatoryreportinghub.com

AGENDA


1 Introduction

2 Member Section

3 Connectivity

4 Workflow

5 Live-Demo of RRH

SFTP connectivity

Requirements

• No specific hardware requirements

• WinSCP (version 5.1.4) or TurboFTP (version 6.30)

PuTTYKey Generator

• Windows: PUTTY Key Generator (PuTTYGen)

• Download from PuTTYdownload page (PuTTYGenSite) and install

• Ensure you have a text editor available (eg Notepad ++)


Documentation available : ‘Onboarding guide_How to connect via sFTP’

SFTP key generation – 1

Open PuTTYGen, select SSH-2 RSA for type of key, use ‘2048’ for ‘Number of bits in generated

key’



Click ‘Generate’ and move the mouse for randomness



Put a suitable comment into ‘Key comment’ field, and a ‘Key Passphrase’. You can use this

without a passphrase but it is not recommended



• Save the keys

• Private: LEIEntity.ppk

• Example: 549300298FD7AS4PPU21.ppk

• Public Key: LEIEntity.pub

• Example: 549300298FD7AS4PPU21.pub

• Save your private key in a safe place. The public key should be sent to

the RRH team ([email protected])


Connecting to the RRH

Site Name: Client provided

Site address: 194.36.239.249

Port: 24

Initial local directory: client test folder location

User ID: LEI


File structure - RRH


AGENDA


1 Introduction

2 Member Section

3 Connectivity

4 Workflow

5 Live-Demo of RRH

Overview of workflow


Xetra/Eurex extract


At the end of each trading day, the RRH informs each third country member about all

transactions it has executed at the GDB trading venues throughout the day and that need to be

reported under MiFIR (on behalf of the venue) via the daily Xetra/Eurex extracts (one extract

per trading system: Xetra Classic, Xetra T7, Eurex T7). The member has to provide the

unknown details (see slide 27) for these transactions to the RRH on the next business day until

15:00 CET.

The format of the extracts (CSV or XML) already corresponds with the inbound format of the

RRH, i.e. when sending the file back to the RRH only the file name needs to be adapted to the

RRH standards (see RRH documentation).

Sample file review (daily extract)


Aggregated client account (INTC)

When a member is aggregating orders (Client ID equals AGGR) and acting in “any other

capacity” or “matched principal basis”, the daily extract will contain a line where the buyer or

seller field (7 or 16) will be populated with INTC. Where there is a transfer into the aggregate

client account there should be corresponding transfers out (2-n, depending on the number of

clients within the INTC) of the aggregate client account within the same business day so that

the aggregate client account is flat. Those additional transaction reports have to be created by

the third country firm as the trading venue is no information about those transactions.

The following rules should be taken into account when creating the additional reports:

• The fields Customer transaction ID (PD002) and Transaction reference number (TR001)

should contain unique values which differs from any other transaction report

• When INTC was the buyer in transfer into the aggregated client account then INTC should

be the seller in the additional reports and vice versa

• The field Trading venue transaction identification code (TR005) should be empty

• The field Venue (TR006) should be populated with “XOFF”


Fields overview

The member has to populate the following fields

• Buyer or seller identification code

• Not relevant for prop business

• CP013/CP014 and CP024/CP025 in RRH inbound specification

Field 7 (buyer details) or 16 (seller details) in case of INTC accounts or in

case of PNAL-transactions

• Name, surname, DOB, decision maker code, decision maker name/surname

• Decision maker only if applicable

• Not relevant for prop business

Field 9-15 (buyer details) or 18-24 (seller details) – only if the buyer (field 7) or

seller (field 16) is a natural person

• OD14 in RRH inbound specification

• Not relevant for Eurex transactions

• Possible values: SESH, SSEX, SELL, UNDI

Field 62 (Short Selling Indicator) – only applicable for shares and sovereign debt

and only if the member (or one of its clients) is the seller


• Only relevant for commodity instruments

• True (Y) or False (N)

Field 64 (Commodity Derivative Indicator) – only for commodity

derivatives


Fields overview

The member may correct the content of the following fields

• Identifier, internal to the reporting firm to identify all the reports related to the same execution of a combination of financial instruments in accordance with Article 12.

• TR024 in RRH inbound specification

Field 40 (Complex Trade Component ID) – the member may

use its own strategy identifier

• Person or algorithm in firm responsible for investment decision


Field 57 (Investment Decision within Firm + ID Type)


Field 58 (Country of the Branch responsible for the Person making

the Investment Decision)

• OD011 in inbound specificationField 59 (Execution within Firm + ID Type)

• OD012 in RRH inbound specificationField 60 (Country of the Branch

supervising the Person responsible for the Execution)


Fields overview

The member should not modify the content of the following key fields

• Field is necessary to match the records provided by the RRH (daily extract) and the records provided by the member (inbound file)

• PD001 in RRH inbound specificationField Trade Date

• Field is necessary to match the records provided by the RRH (daily extract) and the records provided by the member (inbound file)

• PD002 in RRH inbound specification

Field Customer Transaction ID

• The Action Type (“N” > New, “R” > Correction, “C” > Cancel) determines how to report the transaction records to BaFin

• PD003 in RRH inbound specificationAction Type

• Field is part of unique key when reporting to the NCA

• TR001 in RRH inbound specification

Transaction Reference Number

• Field is part of unique key when reporting to the NCA

• CP002 in RRH inbound specificationExecuting Entity


Fields overview

The following fields can be helpful

• Fields contain the order numbers assigned by the exchange (field 1) and by the member (field 2)

• UF001/UF002 in RRH inbound specification

Customer configurable field 1+2

• Field contains the value „Buyer“ in case the buyer details have to be completed by the member (see slide 27)

• UF003 in RRH inbound specification

Customer configurable field 3

• Field contains the value „Seller“ in case the seller details have to be completed by the member (see slide 27)



• Field contains the value „Commodity derivative indicator“ in case the Commodities derivative indicator has to be completed by the member (see slide 27)



• Field contains the value „Short selling indicator“ in case the Short selling indicator has to be completed by the member (see slide 27)




Completeness Report

• The first section lists all transactions of the T-1 daily extract for which the member did not provide transaction data to the RRH.

Missing Transactions

• The second section lists all additional transaction records that were received today from the member but that are not listed in the T-1 daily extract.

Extra Transactions


- One report per GDB trading system

- Comprises two sections

Client ‘to do’ list + timelines

End of trading day

•Client retrieves daily extract csv/xml file from SFTP site

Client populates or corrects

relevant fields

Rename file according to RRH file requirements

3pm CET T+1

•Ensure file is uploaded to the RRH SFTP site


AGENDA


1 Introduction

2 Member Section

3 Connectivity

4 Workflow

5 Live-Demo of RRH

Regulatory Services

[email protected]

Contact

regulatory reporting hub trading venue reporting · reporting hub rights for the member section...

Documents