regulatory reporting hub trading venue reporting...deutsche börse group 3 trading venues require...
TRANSCRIPT
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
Deutsche Börse Group 2
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
Deutsche Börse Group 3
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
Deutsche Börse Group 5
1 Introduction
2 Member Section
3 Connectivity
4 Workflow
5 Live-Demo of RRH
The RRH user setup is done in the Member Section
Deutsche Börse Group 6
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
Deutsche Börse Group 7
To create users the standard workflows of the Member Section
are being used
Deutsche Börse Group 8
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)
Deutsche Börse Group 9
The Regulatory Reporting Hub Administration is used to set
access rights for the RRH GUI (2/2)
Deutsche Börse Group 10
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
Deutsche Börse Group 11
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
Deutsche Börse Group 12
Production: www.regulatoryreportinghub.comSimulation: simu.regulatoryreportinghub.com
AGENDA
Deutsche Börse Group 13
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 ++)
Deutsche Börse Group 14
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’
Deutsche Börse Group 15
SFTP key generation – 2
Click ‘Generate’ and move the mouse for randomness
Deutsche Börse Group 16
SFTP key generation – 3
Put a suitable comment into ‘Key comment’ field, and a ‘Key Passphrase’. You can use this
without a passphrase but it is not recommended
Deutsche Börse Group 17
SFTP key generation – 4
Deutsche Börse Group 18
SFTP key generation – 5
• 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])
Deutsche Börse Group 19
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
Deutsche Börse Group 20
File structure - RRH
Deutsche Börse Group 21
AGENDA
Deutsche Börse Group 22
1 Introduction
2 Member Section
3 Connectivity
4 Workflow
5 Live-Demo of RRH
Overview of workflow
Deutsche Börse Group 23
Xetra/Eurex extract
Deutsche Börse Group 24
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)
Deutsche Börse Group 25
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”
Deutsche Börse Group 26
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
• OD14 in RRH inbound specification
• Only relevant for commodity instruments
• True (Y) or False (N)
Field 64 (Commodity Derivative Indicator) – only for commodity
derivatives
Deutsche Börse Group 27
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
• OD008 in RRH inbound specification
Field 57 (Investment Decision within Firm + ID Type)
• OD009 in RRH inbound specification
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)
Deutsche Börse Group 28
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
Deutsche Börse Group 29
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)
• UF004 in RRH inbound specification
Customer configurable field 4
• Field contains the value „Commodity derivative indicator“ in case the Commodities derivative indicator has to be completed by the member (see slide 27)
• UF005 in RRH inbound specification
Customer configurable field 5
• Field contains the value „Short selling indicator“ in case the Short selling indicator has to be completed by the member (see slide 27)
• UF006 in RRH inbound specification
Customer configurable field 6
Deutsche Börse Group 30
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
Deutsche Börse Group 31
- 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
Deutsche Börse Group 32
AGENDA
Deutsche Börse Group 33
1 Introduction
2 Member Section
3 Connectivity
4 Workflow
5 Live-Demo of RRH