Regulatory Reporting Hub Trading Venue Reporting. November 2017

Transcription

1 Regulatory Reporting Hub Trading Venue Reporting November 2017

2 AGENDA Deutsche Börse Group 1 1 Introduction 2 Member Section 3 Connectivity 4 Workflow 5 Live-Demo of RRH

3 Deutsche Börse Group 2 MiFIR puts trading venues in charge of transaction reporting of non-eea members and institutions not subject to MiFIR Regulatory requirements 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. Transaction Reporting Scope 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. * Regulation EU No 600/2014 ** Directive EU 2014/65/EU

4 Deutsche Börse Group 3 Trading venues require their participants to connect to the Regulatory Reporting Hub operated by DBAG s reporting ARM Trading venues requirements 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 Participants options of reporting 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 ).

5 Process flow of transaction reporting of non-eea members and institutions not subject to MiFIR BaFin 6. RRH sends Member A feedback file 8. RRH transfers valid transaction report to BaFin 9. Feedback from BaFin Member X 1. Order/ trade flow T7 Member A (non-mifir entity) TES 4. Member A submits MiFIR inbound file before 15:00 on T+1 3. RRH sends Eurex Daily Extract file at the end of Day T via SFTP 5. RRH uploads the inbound files and performs validation checks. RRH 7. RRH sends Eurex Completenes s Reports of all non-mifir members Eurex / Xetra 2. Transaction data delivery

6 AGENDA Deutsche Börse Group 5 1 Introduction 2 Member Section 3 Connectivity 4 Workflow 5 Live-Demo of RRH

7 The RRH user setup is done in the Member Section Deutsche Börse Group 6 member.regulatoryreportinghub.com

8 Deutsche Börse Group 7 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

9 Deutsche Börse Group 8 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

10 Deutsche Börse Group 9 The Regulatory Reporting Hub Administration is used to set access rights for the RRH GUI (1/2)

11 Deutsche Börse Group 10 The Regulatory Reporting Hub Administration is used to set access rights for the RRH GUI (2/2) Click on relevant RRH Service Choose user to be maintained Set user rights and restrictions

12 Deutsche Börse Group 11 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

13 Deutsche Börse Group 12 Once the certificate is installed the Regulatory Reporting Hub can be accessed Production: Simulation: simu.regulatoryreportinghub.com

14 AGENDA Deutsche Börse Group 13 1 Introduction 2 Member Section 3 Connectivity 4 Workflow 5 Live-Demo of RRH

15 Deutsche Börse Group 14 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 PuTTY download page (PuTTYGen Site) and install Ensure you have a text editor available (eg Notepad ++) Documentation available : Onboarding guide_how to connect via sftp

16 Deutsche Börse Group 15 SFTP key generation 1 Open PuTTYGen, select SSH-2 RSA for type of key, use 2048 for Number of bits in generated key

17 Deutsche Börse Group 16 SFTP key generation 2 Click Generate and move the mouse for randomness

18 Deutsche Börse Group 17 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

19 SFTP key generation 4 Deutsche Börse Group 18

20 Deutsche Börse Group 19 SFTP key generation 5 Save the keys Private: LEIEntity.ppk Example: FD7AS4PPU21.ppk Public Key: LEIEntity.pub Example: FD7AS4PPU21.pub Save your private key in a safe place. The public key should be sent to the RRH team (regulatory.services@deutsche-boerse.com)

21 Deutsche Börse Group 20 Connecting to the RRH Site Name: Client provided Site address: Port: 24 Initial local directory: client test folder location User ID: LEI

22 File structure - RRH Deutsche Börse Group 21

23 AGENDA Deutsche Börse Group 22 1 Introduction 2 Member Section 3 Connectivity 4 Workflow 5 Live-Demo of RRH

24 Overview of workflow Deutsche Börse Group 23

25 Deutsche Börse Group 24 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).

26 Sample file review (daily extract) Deutsche Börse Group 25

27 Deutsche Börse Group 26 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

28 Fields overview The member has to populate the following fields Deutsche Börse Group 27 Field 7 (buyer details) or 16 (seller details) in case of INTC accounts or in case of PNAL-transactions Buyer or seller identification code Not relevant for prop business CP013/CP014 and CP024/CP025 in RRH inbound specification Field 9-15 (buyer details) or (seller details) only if the buyer (field 7) or seller (field 16) is a natural person Name, surname, DOB, decision maker code, decision maker name/surname Decision maker only if applicable Not relevant for prop business 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 Not relevant for Eurex transactions Possible values: SESH, SSEX, SELL, UNDI Field 64 (Commodity Derivative Indicator) only for commodity derivatives OD14 in RRH inbound specification Only relevant for commodity instruments True (Y) or False (N)

29 Deutsche Börse Group 28 Fields overview The member may correct the content of the following fields Field 40 (Complex Trade Component ID) the member may use its own strategy identifier 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 57 (Investment Decision within Firm + ID Type) Person or algorithm in firm responsible for investment decision OD008 in RRH inbound specification Field 58 (Country of the Branch responsible for the Person making the Investment Decision) OD009 in RRH inbound specification Field 59 (Execution within Firm + ID Type) OD011 in inbound specification Field 60 (Country of the Branch supervising the Person responsible for the Execution) OD012 in RRH inbound specification

30 Deutsche Börse Group 29 Fields overview The member should not modify the content of the following key fields Field Trade Date Field Customer Transaction ID 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 specification 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 Action Type Transaction Reference Number The Action Type ( N > New, R > Correction, C > Cancel) determines how to report the transaction records to BaFin PD003 in RRH inbound specification Field is part of unique key when reporting to the NCA TR001 in RRH inbound specification Executing Entity Field is part of unique key when reporting to the NCA CP002 in RRH inbound specification

31 Deutsche Börse Group 30 Fields overview The following fields can be helpful Customer configurable field 1+2 Customer configurable field 3 Customer configurable field 4 Customer configurable field 5 Customer configurable field 6 Fields contain the order numbers assigned by the exchange (field 1) and by the member (field 2) UF001/UF002 in RRH inbound specification 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 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 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 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

32 Deutsche Börse Group 31 Completeness Report - One report per GDB trading system - Comprises two sections Missing Transactions The first section lists all transactions of the T-1 daily extract for which the member did not provide transaction data to the RRH. Extra 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.

33 Deutsche Börse Group 32 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

34 AGENDA Deutsche Börse Group 33 1 Introduction 2 Member Section 3 Connectivity 4 Workflow 5 Live-Demo of RRH

35 Contact Regulatory Services