User manual. Transaction reporting Release 1.1

Transcription

1 User manual Release 1.1 1

2 Table of content 1 Introduction Purpose of this document Change history Related Documents Releases Regulatory Reporting Hub Member Section High level process overview of transaction reporting Graphical User Interface (GUI) Access to the GUI Supported browsers Menu Dashboard Header Selection bar Reporting performance File uploads Timeline Footer Assisted Reporting Dashboard File Upload via GUI Transaction/Position/Valuation/Collateral Portfolio Update Detail View Overview Manual Transaction/Position/Valuation/Collateral Portfolio Update Entry via GUI Transaction/position modification Transaction version history Transaction/position cancellation Reference data enrichment via Internal Party ID Transaction/record search Transaction/record error search Customer- and User Settings (incl. Filters) User Settings Customer Settings Reports/Business Intelligence Transaction Volume Report Reporting Efficiency Report File Interface General Important Concepts

3 5.2.1 Timestamps Trade Date Regulation selection Uniqueness of a transaction Action Type Rejection versus error versus warning Transactions/positions/valuations/collaterals File Transfer Validations and response files Initial validations and initial response file Validations on repeatable fields Further validations and subsequent response file Further Response Files Trade Status Report NCA/TR feedback file MiFIR Data extract APA/ARM reconciliation end of day file INTC & complex trade reconciliation end of day file REGIS-TR reconciliation file Repeatable fields Stepwise upload of reference data Step 1: Provision of Party Reference Details Step 2: Uplod of transaction data Reference data enrichment APA Enrichment of OTC Post-Trade Indicator for Transaction Reporting DBG Enrichment/Reconciliation Assisted Reporting Test Available Instrument Data Simulation of NCA Feedback ( Mock-up ) Hotline and system operating hours Glossary Abbreviations Index of Tables Index of Figures Appendix File Upload via sftp

4 1 Introduction 1.1 Purpose of this document The Transaction Reporting User Manual is part of a core set of documents made available to customers. Its purpose is to: Give a functional overview of the Regulatory Reporting solution for Transaction Reporting Explain the structure and content of the application Familiarise Users with the Transaction Reporting solution and its features 1.2 Change history Date Change Reorganisation of document into GUI and interface sections - Addition of detailed description of upload and response process Main scope of Transaction Reporting Release Determination of the file transfer time to the NCA for MIFID II - Interface to REGIS-TR - EMIR II relevant reporting features Update of fields for DBG Enrichment, chapter Update of NCA/TR status values, chapter Update of Trade Date, chapter Update of Aggregated Validation Status table, chapter Related Documents The following further documentation is available in the download area of our website Document User Manual Regulatory Reporting Hub Member Section User Manual for Central Coordinators Regulatory Reporting Hub Member Section Transaction Reporting User Manual 1.1 Transaction Reporting Release Notes 1.1 Transaction Reporting Upload Specification 1.1 Transaction Reporting Upload Specification (Delta) 1.1 Transaction Reporting XML Guide 1.1 Transaction Reporting XML Guide (Delta) 1.1 Transaction Reporting XML Upload XSD 1.1 Transaction Reporting XML Responses XSD Releases The following table shows an overview of recent and next releases (detailed release notes are available on our website): 4

5 Release Date Scope summary Sep Revised EMIR - Copy of NCA outbound file Nov Audit trail tab in GUI - Full NCA feedback - APA and DBG enrichment - Art. 58 Commodity Position Reporting 5

6 2 Regulatory Reporting Hub Member Section In order to use the services of the Regulatory Reporting Hub a technical connection as well as certain access rights need to be set up, which are maintained within the Regulatory Reporting Hub Member Section. The Regulatory Reporting Hub Member Section is user-specific and only available to a closed group. During client onboarding a so called Central Coordinator will be set up as the initial user for the client company and will be authorized to access and self-manage the administration support services for the Regulatory Reporting Hub. To successfully register, the following six steps must be performed: Start the registration Enter user data Selection of services Activation Validation Approval by the Central Coordinator Details of the registration process are described in the User Manual Regulatory Reporting Hub Member Section as well as in the User Manual for Central Coordinators Regulatory Reporting Hub Member Section. Both User Manuals are accessible within the download area of the Regulatory Reporting Hub website Figure 1 - Regulatory Reporting Hub Member Section website 6

7 3 High level process overview of transaction reporting The following graphic provides an overview of the planned transaction reporting process chain offered by the solution: Figure 2 - Deutsche Börse's Transaction Reporting Offering The transaction data sent by the user to the RRH are validated and enriched. After a successful validation the reporting records are produced and sent to the NCA/the trade repository. 7

8 4 Graphical User Interface (GUI) 4.1 Access to the GUI The basic requirement to access the solution is an internet connection, a supported browser and a valid User certificate. A detailed overview of the onboarding requirements can be found in the User Manual Regulatory Reporting Hub Member Section as well as in the User Manual for Central Coordinators Regulatory Reporting Hub Member Section. Navigate to the following URL to access the Regulatory Reporting Hub: When accessing the site you will be prompted to enter your password. This password equals the password of your Member Section account which you have used to create your certificate. Figure 3 - RRH Sign-in-Screen In the Regulatory Reporting Hub, you will find the icon to launch the Transaction Reporting application under the Solutions section: Figure 4 - Access to Transaction Reporting 8

9 You can also access the transaction management section of the Regulatory Reporting Hub directly by using the following link: Supported browsers The Regulatory Reporting Hub GUI is tested with the following browsers, although it may work with other browsers as well: Supported browsers Google Chrome (version 48 or newer) Mozilla Firefox (version 44 / 38 ESR or newer) Internet Explorer (version 11 or newer) Safari (version 9 or newer) Table 1 - Supported Browsers 4.3 Menu The drop-down menu will become visible by a left-mouse-click on the icon on the top left corner of the screen: Figure 5 - Menu The regulation-specific Transaction/position entry section will only be displayed in case a single regulation has been selected in the regulation drop-down. The menu items are described in the following chapters. 9

10 4.4 Dashboard When accessing the solution, the user is directed to the dashboard. The dashboard gives a general overview of the current reporting status and enables the user to navigate through the various functions of the solution. Header Selection bar Reporting Performance File Uploads Footer Figure 6 - Transaction Reporting Dashboard In general, the dashboard serves as an overview of all operative data and allows the user to easily access the main functions. The dashboard consists of the tiles Deadline (today or tomorrow), Overdue, File Uploads and Timeline and will be individually configurable within the user settings. With a left-mouse-click on a chart within the reporting performance area or on a file within the upload file area, the user gets access to more detailed views or tables that enable quick analyses or editing of erroneous or incomplete transaction records Header The header shows the logged-in user and allows users to switch between the subscribed regulation reporting services. Figure 7 - Header Clicking on 8. next to the user name will open the user- and customer settings sub-menu shown in Figure 10

11 Figure 8 - User-/Customer settings access Details on the User-/ and Customer Settings Maintenance are described in Chapter 4.9 Customer- and User Settings (incl. Filters) Selection bar At the top of the screen there is a selection bar, which provides the function drop-down menu and the following drop-down filters: All Regulations, All Accounts, All Business Units and No Assisted reporting. The refresh button next to the filter activates the changes. Figure 9 - Selection bar Regulation Filter Within the drop-down filter All regulations, the user can navigate to the respective regulation module, e.g. EMIR, MiFIR. Figure 10 - Content of Sub-menu All regulations 11

12 Account Filter Clicking on All accounts within the header will open the sub tabs Main account and Sub accounts. The user can select each sub tab and receives an overview about all transaction data ( All Accounts ) or of only selected Accounts. If the customer has no sub-accounts, only Main Account is displayed. Figure 11 - All Accounts Furthermore, the reporting can be filtered according to certain Business Units and customers, for which assisted reporting is performed: Figure 12 - All Business Units Figure 13 - Assisted reporting customers If the account selection is Main and the Business Unit selection is All, then for customers who are Full/Partial Assistance Submitter (i.e. a reporting provider), the Full/Partial Assistance Submitter section of the assisted reporting drop-down is displayed and for customers who are a Full/Partial Assistance Customer, the Full/Partial Assistance Customer section of the drop-down is displayed. Otherwise, only No assisted reporting is selected in the assisted reporting drop-down. 12

13 4.4.3 Reporting performance The Reporting performance area allows the user to track reporting performance and progress. The area consists of the tiles Deadline (today or tomorrow) and Overdue, each with the ring charts Record validation, Transfer to NCA/TR and Acknowledgement by NCA/TR. Detailed description of the ring charts functionality is provided in Chapter 4.4 Dashboard. Figure 14 - Client Reporting Performance Deadline (today or tomorrow) In this display only records where the due date/time is >= current day at 0.00 am (local user time zone) with life-cycle status final are counted. Record Validation Ring Chart This ring chart shows for each validation status value the number of records with that status value if there is at least one record. Records with Transaction Data Upload Status = rejected are not reflected in the ring chart. The cut-off time of the related NCA (including its holiday calendar) to which the record should be submitted is taken as time component for the due date calculation. The Record validation status can show the following values: Record validation status valid, deadline today pending, deadline today warning, deadline today error, deadline today valid, deadline tomorrow pending, deadline tomorrow Aggregated Validation and Enrichment status valid valid but pending or "open" warning or warning but pending invalid valid valid but pending or "open" Due date & time due date/time >= current date 00:00 UTC AND due date/time < current date +1 00:00 UTC due date/time >= current date 00:00 UTC AND due date/time < current date +1 00:00 UTC due date/time >= current date 00:00 UTC AND due date/time < current date +1 00:00 UTC due date/time >= current date 00:00 UTC AND due date/time < current date +1 00:00 UTC due date/time >= current date :00 UTC due date/time >= current date :00 UTC 13

14 Record validation status warning, deadline tomorrow error, deadline tomorrow Aggregated Validation and Enrichment status warning or warning but pending invalid Due date & time due date/time >= current date :00 UTC due date/time >= current date :00 UTC Table 2 - Record Validation Ring Chart possible values Transfer to NCA/TR Ring Chart This ring chart shows the number of records for each of the transfer status values below if there is at least one record. The Transfer to NCA/TR status can show the following values: Transfer to NCA/TR NCA/TR status status Due date & time n/a transferred waiting n/a sent or receipt confirmed or file rejected or accepted or accepted with warning(s) or rejected or ref. data check outstanding or ref. data rejected open Table 3 - Transfer to NCA/TR Ring Chart possible values due date/time >= current date 00:00 UTC due date/time >= current date 00:00 UTC due date/time >= current date 00:00 UTC Acknowledgement by NCA/TR Ring Chart This ring chart shows the number of records for each of the below acknowledgement by NCA/TR status values if there is at least one record. The Acknowledgement by NCA/TR status can show the following values: Acknowledgement by NCA/TR status Due date & time NCA/TR status n/a n/a (any) valid, deadline today accepted or accepted with warning(s) due date/time >= current date 00:00 UTC AND due date/time < current date +1 00:00 UTC Valid, deadline accepted or accepted with tomorrow warning(s) due date/time >= current date :00 UTC Rejected, deadline today file rejected or rejected or ref. data rejected due date/time >= current date 00:00 UTC AND due date/time < current date +1 00:00 UTC Rejected, deadline file rejected or rejected or tomorrow ref. data rejected due date/time >= current date :00 UTC waiting instrument data, deadline today ref. data check outstanding due date/time >= current date 00:00 UTC AND due date/time < current date +1 00:00 UTC waiting instrument ref. data check outstanding data, deadline due date/time >= current date :00 UTC tomorrow waiting for feedback, deadline today sent or receipt confirmed due date/time >= current date 00:00 UTC AND due date/time < current date +1 00:00 UTC 14

15 Acknowledgement by NCA/TR status waiting for feedback, deadline tomorrow NCA/TR status sent or receipt confirmed Table 4 - Acknowledgement by NCA/TR Ring Chart possible values Due date & time due date/time >= current date :00 UTC Overdue In the Overdue display only records where the due date/time is < current day at 0.00 am (local user time zone) with life-cycle status final are counted. Record Validation Ring Chart The ring chart for overdue in record validation is the same as for Deadline (today or tomorrow) except that only records sent before the current date are counted. The Record validation status can show the following values: Record validation status Aggregated Validation and Enrichment status Due date & time valid valid pending valid but pending or "open" warning warning or warning but pending error invalid Table 5 - Record Validation Ring Chart possible values due date/time < current date 00:00 UTC due date/time < current date 00:00 UTC due date/time < current date 00:00 UTC due date/time < current date 00:00 UTC Transfer to NCA/TR Ring Chart This ring chart shows the number of records for each of the below transfer status values where there is at least one record. Only records sent before the current day with life cycle status final are counted. The Transfer to NCA/TR Ring Chart status can show the following values: Transfer to NCA/TR NCA/TR status Due date & time status transferred waiting sent or receipt confirmed or file rejected or accepted with warning(s) or rejected or ref. data check outstanding or ref. data rejected open Table 6 - Transfer to NCA/TR Ring Chart possible values Acknowledgement by NCA/TR Ring Chart due date/time < current date 00:00 UTC due date/time < current date 00:00 UTC This ring chart shows the number of records for each of the below acknowledgement by NCA/TR status values where there is at least one record. Only records sent on the current day with life cycle status final are counted. The Acknowledgement by NCA/TR Ring Chart can show the following values: Acknowledgement by NCA/TR NCA/TR status status Due date valid with warning(s) accepted with warning(s) due date/time < current date 00:00 UTC rejected file rejected or rejected or ref. data rejected due date/time < current date 00:00 UTC waiting instrument data ref. data check outstanding due date/time < current date 00:00 UTC 15

16 waiting for feedback sent or receipt confirmed due date/time < current date 00:00 UTC Table 7 - Acknowledgement by NCA/TR Ring Chart possible values File uploads The file upload tile will only be available to users whose access is not limited to certain business units. Only files with sender ID corresponding to one of the selected accounts/subaccounts, or in case of assisted reporting one of the selected assisted reporting submitters/customers is shown. The file status and number of valid, invalid and rejected transaction records reflect the import results at the time of the file upload. Figure 15 - File upload / Validation on-going Figure 16 - File upload / Validation complete Timeline This chart shows the accumulated number of transactions loaded during the current and the previous business day (according to the holiday calendar of the NCA which the main account reports to) for the currently applied filters (regulation, account/sub-account, business unit, assisted reporting submitter/provider). 16

17 Figure 17 - Timeline Transaction load Footer This Footer area allows the user to switch on/off the visibility of the dashboard widgets Deadline (today or tomorrow), Overdue, File Uploads, and Timeline. By default, all widgets are made visible and have the prefix minus - included. In contrast, hidden widgets are preceded by a plus sign +. In case of the Assisted Reporting dashboard, the Footer will be shown on the left vertical axis. Figure 18 - Footer Figure 19 - Reporting Performance Area Assisted Reporting Dashboard Clients (Assisted reporting submitter) can access the dashboard via drop-down menu > Assisted Reporting Dashboard. The Assisted Reporting Dashboard looks as follows: 17

18 Figure 20 - Fully Assisted Reporting Dashboard The dashboard contains the same information for Clients as well as for Client s Clients (provided the user is a full assistance submitter and/or full assistance customer and has the necessary user rights, described in Chapter 3 Regulatory Reporting Hub Member Section. For Full Assistance Submitters (i.e. Clients of the Regulatory Reporting Hub), it displays the complete reporting overview of all the Clients Clients for which they provide reporting. For Full Assistance Customers (Client s Clients), an aggregate overview of all reporting across all Reporting Providers is displayed. The All Account / All Business Unit Filter only allows Main Account / All Business Units combination in this dashboard, since no sub-account or business unit structure is allowed in the context of Assisted Reporting. The dashboard is only visible to the user, if he selects under the All Account filter menu the Main Account and under the All Business Unit filter menu All Business Units. Furthermore, the user selects under All Full Assistance Customers menu All Full Assistance Customers or a specific assistance customer). If not, the GUI will hide respective tiles to the user). 18

19 Figure 21 - All Accounts Filter Figure 22 - All Business Units Filter Figure 23 - All Full Assistance Customers Filter The Assisted Reporting Filter has either All Assistance Submitters or All Assistance Customers (as shown under Figure 24) as default and does not provide the option No Assisted Reporting. 4.5 File Upload via GUI The file upload functionality in the GUI enables the user to manually upload CSV and XML files (unzipped) with the relevant data of reportable transactions. The required file format is described in Chapter 5 File 19

20 Interface. For manually uploaded files the user can choose any file name since the system will then produce a system generated filename. To manually import a transaction file, open the mega drop-down menu and choose File upload to open the file upload view. Click on the Select files button to browse and upload a CSV or XML file which should be saved in Windows/DOS format. In this context, it is important to note that in case of XML files, the user needs to validate the file against the corresponding XML Schema Definition (XSD) before any submission. Otherwise the XML file upload will be rejected with the error Invalid file structure. Once the user uploads a file, the GUI executes the file format check regarding authorisation of sender (LEI and user specific upload rights) and file format (see Transaction Reporting Upload Specification 1.1 and Transaction Reporting XML Guide 1.1). With successful file format validation, the file status is set to "upload by GUI" followed by the status pending load record and the file is ready for retrieval by the database where all further validations are executed. The RRH database checks every 5 minutes whether new files have been uploaded for processing. After processing all validations within the database a feedback for the uploaded file is provided within the recent uploads table. The record status is set to accepted, the number of Valid, Erroneous or Rejected records are shown. Known limitation with Release 1.1: The File upload via front-end (GUI) is limited to 1 MB per file (approx. 1,000 records). Figure 24 - File upload view In case of erroneous records, the user can navigate to the error search by clicking on the number of erroneous records. In case of rejected records, the user has to click on the number of rejected records that leads to show the Rejected table, which provides information why a single record has been rejected. 20

21 Figure 25 - Rejection table Please note that when looking at the rejection/error list from the file upload table the original validation status of the transactions as when the file was loaded are shown irrespective of later corrections of these transactions.to see the current status of the transactions use the dashboard or transaction search. 4.6 Transaction/Position/Valuation/Collateral Portfolio Update Detail View Overview With Release 1.1 the transaction/position/valutation/collateral portfolio update detail view is available for EMIR regulation and shows all relevant fields of a single transaction. It can be accessed via transaction/position/collateral portfolio error search for EMIR and via transaction error search for MiFIR or via dashboard diagrams/file upload tables by clicking on a selected transaction row or via the menu by choosing new transaction/record entry for EMIR and MiFIR. The window is structured into tabs, structuring the manual transaction/record entry into the following categories: Processing (e.g. Trade date, Customer transaction ID, Source System, ) Custom (9 custom fields with up to 50 characters, no format restrictions. Clients can individually define the GUI-fields of the user-configurable fields; described in section ) Delegation (e.g. EMIR Delegated Reporting) Counterparty (e.g. Counterparty 1/Counterparty 2 details) Transaction (e.g. Termination Date, Settlement Date, Quantity ) Instrument (e.g. Contract Type, Asset Class, ) Other Valuation Collateral 21

22 4.6.2 Manual Transaction/Position/Valuation/Collateral Portfolio Update Entry via GUI New transaction/record entry for EMIR and MiFIR To start the transaction/record entry process, left-click on the key function icon to open the mega drop-down menu and choose New transaction/record entry and select the applicable entry tab New EMIR transaction, New EMIR position or New EMIR collateral portfolio update. For MiFIR the user selects New transaction/record entry. Figure 26 - New record entry view with EMIR specific selection possibility Figure 27 - New Record entry view with MiFIR specific selection possibility The new transaction/record entry view (Figure 28) opens and is ready to be filled with the transaction details for EMIR and MiFIR. At the start of the transaction view, the cursor is on the second field of the tab Processing, the report level is automatically set to Transaction for EMIR. 22

23 Figure 28 - New EMIR transaction/record entry view Figure 29 New MiFIR transaction/record entry view Except some pre-populated fields like trade date, all fields are empty. The system determines all mandatory fields based on the selected regulation (see red box above). While entering values in the respective fields, each input value is validated in terms of field format, with immediate feedback to the user. Text fields entered in upper/lower case are converted to upper case. The drop-down combo boxes (e.g. for ISIN, etc.) display the name next to the ID in the suggestions and clear the name when leaving the field. The user has to provide or generate a customer transaction ID (by pressing the Generate TRN ID button, red box which cannot be changed once the transaction has been saved. Once the user presses the Submit button all mandatory field checks are performed and feedback is provided. Register tabs with errors are marked red, the life-cycle status and aggregate validation status are updated at the top row. If there are still errors on the transaction the user is asked if a new version of the transaction should be saved before correcting the errors. 23

24 Additional information regarding the fields can be found within Transaction Reporting Upload Specification 1.1 and Transaction Reporting XML Guide 1.1 which can be downloaded under Manuals /Transaction Reporting Upload Specification from the support-area of The User can manually enter EMIR positions under the newly introduced transaction/record entry tab New EMIR positions. The User clicks under tab record entry the tab New EMIR positions and the entry window (Figure 31) opens. Figure 30 - New EMIR position tab 24

25 Figure 31 - New EMIR position entry screen The User can manually enter EMIR collaterals under the newly introduced transaction/record entry tab New EMIR collateral portfolio. The User clicks under tab record entry the tab New EMIR collateral portfolio and the entry window (Figure 32) opens. 25

26 Figure 32 - New EMIR collateral portfolio update tab Figure 33 - New collateral portfolio update entry screen 26

27 Draft Version The user also has the possibility to save a draft version for later finalisation by pressing the Save as draft button.the Record is then marked with in the upper left corner, life cycle Draft (upper right) and the version number appears at the bottom. Only new transactions/positions/collateral portfolio updates or transactions/positions/collateral portfolio updates in draft can be saved as draft. Valuations and collateral updates messages can not be saved in draft. Figure 34 - Transaction, saved as draft Copy Transaction Besides, the user has the possibility to enter a new transaction by copying an existing transaction, overwriting the respective fields, specifying a new record ID and saving the transaction record by pressing the Submit button Reset If the user wants to reset all entries he made for a transaction record, he can press the Reset button on the left bottom side of the transaction detail view. If the user presses the button, the system will ask whether the user is sure to reset all fields to the original values. If the user confirms, then for a new transaction the system will clear all fields, apply the pre-population of fields for a new transaction display the changes and put the cursor in the first field. For an existing transaction, the system reloads the recent status from the database, displays it and puts the cursor in the first field Entry of repeatable fields The user can enter multiple instances of repeatable fields. A group of repeatable fields has a + button on the right side within the transaction input screen in the RRH-GUI. 27

28 Figure 35 - Example for "+" button within transaction input screen By clicking on the + button the following pop-up window opens. Figure 36 - Popup window behind "+" button The pop-up window has a functionality for adding, updating and deleting of information. Each row, once added, is editable right-sided under the row details. By clicking on each row, the value of that row is loaded into the row details. 28

29 Figure 37 - Row details The user can add, update or delete a data set, described as following: How to add a data set: The user enters the appropriate fields within the pop-up window and click the add-button. The data will be added and saved. How to update a data set: The user clicks with left-mouse-click on one of the rows, for which the update needs to be done. The value of that row is loaded into the row details. The user amends the data and clicks afterwards the updatebutton. The data set is updated and saved. How to delete a data set: The user clicks with left-mouse-click on one of the rows, for which the deletion needs to be done. The value of that row is loaded into the row details. The user enters the delete-button and the row is deleted. How to close a data set: The user clicks on the close-button. The pop-up is closed and the user is immediately back-directed to the record detail view. It is important to know that all unsaved changes are lost Transaction/position modification After saving a transaction/position or when viewing a searched transaction/position the user can change fields and save the modifications by pressing the Correct button in case he has the necessary access rights. 29

30 Figure 38 - Correction button Transaction version history The version history can be found at the bottom of the single transaction view. The current version is the default and shows also the name of the user who created this version. Older versions can be accessed through a drop-down menu. Figure 39 - Version history and Drop Down Menue The user can compare current and former versions side by side. Fields with changes are highlighted. 30

31 Figure 40 - Side by side comparison Transaction/position cancellation The cancellation function allows the user to manually cancel transaction/position records. After clicking on the Cancel button located on the detailed record view and confirming the cancellation in the popup dialog box, the record is cancelled. Preconditions for a cancellation are that the user is set up with the relevant cancel rights via user Interface and that he has not changed any fields on the transaction since opening the detail view or the last save. Figure 41 - Transaction detailed view / Cancellation button The system creates a new version of the transaction with action type C - Cancel, sets the life cycle status to Final, the aggregated validation to Valid and initiates the asynchronous processing of the 31

32 cancellation. Figure 42 - Transaction detail view / Successful Cancellation Reference data enrichment via Internal Party ID For the MiFIR regulation to avoid having to reenter buyer/seller or decision maker details several times customers can upload reference data (see file interface chapter) which is then referenced via an Internal Party ID. Once the relevant reference data has been uploaded the client only needs to enter the Internal_Party_ID. To do so, the respective ID code type must be set to Internal_Party_ID and the Internal_Party_ID value has to be entered in the respective ID code field. Figure 43 - Example 1: Selection of Internal Party ID as Buyer ID code field type; field value provided by RRH client 32

33 Figure 44 - Example 2: Selection of Internal Party ID as "Investment decision within firm" field type; field value provided by client After the entry of the internal party ID the related detail fields will be filled. Figure 45 - Enrichments based on Internal Party ID 4.7 Transaction/record search The Transaction/position Search function allows the user to search for transactions/positions matching specific user-defined criteria. Beside default filter criteria, the user is able to add additional (via Add criteria menu) or remove filters (via Remove criteria menu) and to save these for future use. Furthermore, Release 1.1 additionally offers the EMIR specific functionality of transaction/record searching for transactions/positions, valuations and collaterals. 33

34 After entering filter criteria and clicking on show results, a list with corresponding transactions/positions will be displayed. It shows the total amount of transactions corresponding to the set filters of the search criteria. The corresponding filters and search criteria are shown at the top of the list and can be further edited or hidden. Every search is limited to a date range of max. 1 week. Exception: When solely searching for a regulation specific key (Transaction Reference Number for MiFIR) no restrictions regarding date range are made. To search for specific transactions, left-click on the key function icon of the functions menu to open the mega drop-down menu and choose transaction search within the Search tab. The transaction search view provides the user with a range of filter functions: Default search criteria Configurable search criteria A wildcard search option is available User-defined search criteria additionally to the displayed criteria Within the transaction search, the user is also able to add or remove filter criteria and save them under save criteria. Figure 46 - MiFIR transaction search view / Additional filter criteria drop-down By clicking on show results, a list with transactions corresponding to the set filters or the search criteria are displayed. The corresponding filters and search criteria are shown at the top of the list and can be further edited or hidden. The transactions in the list can be sorted by any criteria. Columns can be sorted by clicking on their header. By pressing the Show results button, a further drop down menu allows the user to add or remove columns. The results (all columns) can also be exported to CSV and downloaded by pressing the icon. 34

35 Figure 47 - Search table view Within the result table view the user will also find the records status aggregated validation status in the first column, NCA/TR status and NCA/TR reconciliation status in the last two columns of the record (Figure 39). Figure 48 - MiFIR result list view / Columns with status information Clicking on a single transaction within the result table view (see red box above) allows the user to switch to the transaction s detailed view: 35

36 Figure 49 - MiFIR detailed view single transaction The User can search for more than one value within a search criterion by clicking the tick boxes of the individual values. Figure 50 - MiFIR transaction search for multiple values Furthermore, the User can search under EMIR for transactions, valuation updates, collaterals and collateral portfolio updates. The behaviour of the EMIR search tabs is working in the same way as already described for the MiFIR transaction search tabs. To start the EMIR transaction/record search process, left-click on the key function icon to open the mega drop-down menu and choose Record search and select the appropriate search tab EMIR transaction/position search. 36

37 Figure 51 - EMIR transaction/position search tab The EMIR transaction/position search window opens and the User can search/filter for individual criteria. Figure 52 - EMIR transaction/position search screen To start the EMIR valuation update search process, left-click on the key function icon to open the mega drop-down menu and choose Record search and select the applicable entry tab EMIR valuation update search. 37

38 Figure 53 - EMIR valuation update search tab The EMIR valuation update search window opens and the User can search/filter for individual criteria. Figure 54 - EMIR valuation update search screen To start the EMIR collateral update search process, left-click on the key function icon to open the mega drop-down menu and choose Record search and select the applicable entry tab EMIR collateral update search. 38

39 Figure 55 - EMIR collateral update search tab The EMIR collateral update search window opens and the User can search/filter for individual criteria. Figure 56 - EMIR collateral update search To start the EMIR collateral portfolio update search process, left-click on the key function icon to open the mega drop-down menu and choose Record search and select the applicable entry tab EMIR collateral portfolio update search. 39

40 Figure 57 - EMIR collateral portfolio update search tab The EMIR collateral portfolio update search window opens and the User can search/filter for individual criteria. Figure 58 - EMIR collateral portfolio update search sreen 4.8 Transaction/record error search In the course of data processing, the system applies validation rules which check: the file structure against the given standard for the respective file type the formats (e.g. date formats), value ranges (e.g. ISO currency codes) and mandatory fields (per product / transaction type) of the transaction records 40

41 field dependencies Identified deviations from the validation rules are reflected as rejections/errors/warnings. The Error search function allows the user to search for rejections/errors/warnings matching specific userdefined criteria. Beside default filter criteria, the user is able to add or remove additional filters and to save these for future use. With Release 1.1 the error search function is extended with the EMIR specific error update searches for transactions/positions, valuations, collaterals and collateral portfolios. Figure 59 - "MiFIR error search" button Known limitations: CSV export file of record search window contains minimal deviations regarding the order of fields. Omitting Trade Date in search criteria may have significant impact on the performance. These limitations will be stabled with a future release. How to handle errors / work with error search The error search is accessed by left-clicking on the key function icon of the functions menu and choosing the Error search in the mega drop-down menu. Analogous to the transaction search view, the error search view provides the user with a range of filter functions. Beside the shown default search criteria, the user is able to add or remove further search criteria and save his filter changes for later usage (button Save filter at bottom right). He is also able to reset his filter set to default search criteria by pressing the Reset filter criteria button (bottom right). Furthermore, saved filters are displayed with the latest being displayed on top. The wildcard search * substituting a transaction reference number displays all erroneous transaction records. 41

42 Figure 60 - MiFIR error search view / Wildcard search By clicking on show results, a list with the erroneous transactions corresponding to the set filters or the error search criteria will be displayed. Figure 61 - MiFIR error search result table / Link to detailed entry per transaction By clicking on an erroneous record within the search result table, the user switches to the transaction s detailed view and can perform the needed corrections. The tab Invalid provides a descriptive overview about detected warnings and errors. Additionally, the category tab(s) covering the erroneous field(s) is/are marked with red text as shown in the Figure below. 42

43 Figure 62 - MiFIR transaction detail view / Invalid tab - Summary of found errors By clicking on the respective category tab, the user can recognize the red marked field(s) that should be added or corrected. (see Figure 54) Figure 63 - MiFIR transaction detail view / Tab with errors - field entries By entering the correct values and pressing the Correct button the user fixes the erroneous field(s). The invalid tab has disappeared and the aggregated validation status of the new record version is set to valid. Furthermore, the User can search under regulation EMIR for transaction/position errors, valuation update errors, collateral update errors and collateral portfolio update errors. The behaviour of the EMIR error search tabs is working in the same way as already described for the MiFIR transaction error search tabs. 43

44 To start the EMIR transaction/record error search process, left-click on the key function icon to open the mega drop-down menu and choose Error search and select the appropriate search tab EMIR transaction/position error search, EMIR valuation update error search, EMIR collateral update error search or EMIR collateral portfolio update error search. Figure 64 - EMIR transaction/position error search tab The EMIR transaction/position error search window opens and the User can search/filter for individual criteria. Figure 65 - EMIR transaction/position error search screen To start the EMIR valuation update error search process, left-click on the key function icon to open the mega drop-down menu and choose Error search and select the appropriate search tab EMIR valuation update error search. 44

45 Figure 66 - EMIR valuation update error search tab The EMIR valuation error search window opens and the User can search/filter for individual criteria. Figure 67 - EMIR valuation update error search screen To start the EMIR collateral update error search process, left-click on the key function icon to open the mega drop-down menu and choose Error search and select the appropriate search tab EMIR collateral update error search. 45

46 Figure 68 - EMIR collateral update error search tab The EMIR collateral update error search window opens and the User can search/filter for individual criteria. Figure 69 - EMIR collateral update error search 46

47 To start the EMIR collateral portfolio update error search process, left-click on the key function icon to open the mega drop-down menu and choose Error search and select the appropriate search tab EMIR collateral portfolio update error search. Figure 70 - EMIR collateral portfolio update error search tab The EMIR transaction/position error search window opens and the User can search/filter for individual criteria. Figure 71 - EMIR collateral portfolio update error search screen 47

48 4.9 Customer- and User Settings (incl. Filters) The customer and user-settings can be accessed via the Header by clicking on the name. icon next to the user Figure 72 - User-/Customer settings access User Settings By clicking on the respective option, the user settings screen opens, in which certain preferences with regards to Format, Alerting and other Default criteria can be set. Figure 73 - User Settings View Formats: Language The user can set a default language for his personal access to user interface. Currently only English is available. In a later Release, the user will be able to switch to German. Currency Enables the user to set a default currency for Business Intelligence (BI) reports which will be presented in the user Interface. The current value is set to EUR - Euro and there is no effect if the user selects other values. Future possible values of this field are for example US Dollar, British Pound Sterling and Swiss Franc. 48

49 Time zone The user is able to select the time zone to be used in the user interface. The default value is CET. Date format The user is able to choose the date format to be used. The default format is dd.mm.yyyy. Time format The user can select the time format to be used. The default value is hh.mm.ss. Number decimal separator This is currently not applicable and set to Comma. Number grouping separator This is currently not applicable and set to Dot Alerting: The user must determine if and when she/he wants to receive alert mails. Currently this item is not applicable and will be available in a later Release Default criteria: The user can use default search criteria for the transaction/ error search but is also able to define own search filters. To create a transaction search filter (the same for error search filter) the user needs to follow the following steps: Click on the dashboard menu and select MiFIR transaction search. Choose or delete the criteria to be included in the filter by clicking on Add criteria or Remove criteria Enter a filter name and press Save to save the filter to be used later Figure 74 - Creation of a Transaction Search Filter named "MyFilter1" To use this filter, switch to the Customer settings again and select it instead of Default Filter. 49

50 Figure 75 - Filter selection Note that currently the saved filter cannot be changed. The user can only delete a filter and save it again under the same name. Dashboard: This allows the customer to activate the checkbox warning if he wants warnings displayed across all tiles of the dashboard. If warnings are switched off, any warning is counted as valid. This applies to all ring charts of the dashboard. Once the user has pressed the save button the refresh button of the browser or next to the filter activates the changes Customer Settings Configurable Fields There are nine user-configurable fields available within the inbound interface for transaction reporting (and the GUI). The fields are setup with up to 50 characters. Clients can individually define the GUI-fields of the user-configurable fields. All these fields will included in response files and can be used for individual analysis. The client can customize the fields (e.g. rename the field description) under Customer settings under tab Configurable fields. However, renaming will only be reflected within the GUI, but not within the xml/ csv file structures. Figure 76 - Access to Tab "Customer Settings" 50

51 Figure 77 - Configuration of "Configurable fields" Once the client finishes the maintenance of the Customer definable fields the Save-button has to be clicked. The customized and renamed client fields (in above mentioned example Max Mustermann ) are visible and selectable via filter criteria under Transaction search screen and in the transaction entry: Figure 78 - Result: New transaction entry view / Tab "Custom" with configurable fields Simulation database reset function Clients have the possibility to clear all of their entries for each regulation in the simulation environment by simply pushing the Simulation database reset button within the GUI. To process the simulation database reset the user right-click on personal settings of the functions menu to choose under customer settings the simulation database reset function. 51

52 Figure 79 - Simulation database reset function The user can process the reset of the simulation database by ticking the box Confirm deletion and clicking the button yes. Upon successful processing of the reset the message Database reset was successful appears. Furthermore, the user can leave the simulation database reset-function without processing by pressing the button no. Figure 80 - Simulation database reset button Stepwise Upload (Reference Data upload via GUI for MiFIR) For MiFIR customers can upload reference data for buyer/seller/decision maker details as a separate reference data file (see file interface chapter). Similarly to a transaction file this reference data file can also be uploaded via the GUI. The stepwise upload screen has two sections: The upper section is a file upload section of transaction data and the lower section is a reference data display section. The following picture shows the layout of the screen. 52

53 Figure 81 - Section File Upload: Stepwise Upload data, accessible via Customer Settings menu The file upload for the stepwise upload data works in the same way as the main file upload with respect to the file selection, cancel option during upload, progress bar, feedback on upload success, results-shown-per page, scrollbar, page-change. As shown in the picture above: Below the Select Files button is the filter. Behind this filter is a File Upload Status Table Stepwise Upload Data accessible, showing the following columns: Figure 82 - File Upload Status Table Stepwise Upload Data The table is sorted by upload time. This table can be sorted by all columns Unusual patterns This functionality will be available in a future release 4.10 Reports/Business Intelligence Within the mega drop down menu the user will find some business intelligence reports. The business intelligence reports allow the analysis of reporting flows and benchmark comparisons against static values. Known limitation with Release 1.1: Core reports will be available with a later release. Until PDF reports are introduced it is recommended to clients to use screen-shots for print-outs. 53

54 Transaction Volume Report This report shows data on the status of MiFIR records as they are reported to the hub, processed and submitted to the NCAs and corresponding responses received. The following types of data are shown in the report: Records with Action Type N (new) submitted to the hub Records with Action Type R (correction) submitted to the hub Records with Action Type C (cancellation) submitted to the hub Records where a warning was raised by the hub Records where an error was raised by the hub Records submitted to the NCA (per NCA) Records accepted by the NCA (per NCA) Records rejected by the NCA (per NCA) Records related to further NCA/TR feedback statuses (per NCA) For each type of data, the total count of records that were recorded in the 24-hour period of that particular day is displayed. Data are shown for a specific date range as multiple lines on a line chart. Figure 83 - Transaction volume report The customer can filter data on a specified date range (from, to dates) or by selecting a predefined date range (week, month, quarter, year) Reporting Efficiency Report This report shows the perceived efficiency of the clients reporting on the platform based on the number of warnings and errors identified by the RRH and the number of rejections from the NCA compared to a number of benchmark figures. Currently all benchmark values are fixed values but will be configurable in the future based on anonymised peer data The report only considers records with Action Type N (new) and R (correction) as sum. Cancellations are neglected. As with the transaction volume report, the customer can filter data on date ranges and print or download the reporting efficiency report. 54

55 Figure 84 - Reporting efficiency report 55

56 5 File Interface 5.1 General Users can submit transaction data files via GUI or a SFTP client. While this chapter describes how files can be uploaded via SFTP it also describes the required file structure, validations and response files which are also relevant for files uploaded via GUI. 5.2 Important Concepts Timestamps Timestamps in the RRH are in UTC format. UTC time is based on Greenwich Mean Time (the time zone of London without observing daylight savings time). Therefore, please note that during daylight savings time in Central Europe, e.g. 10:00 UTC time is 12:00 in Frankfurt. As part of the file name, the timestamp is in the format YYYYMMDDThhmmsssss, e.g T up to the precision of milliseconds. See sheet File Name Conv. in the Transaction Reporting Upload Specification. Inside the file header the sending timestamp has the format YYYY-MM-DDTHH:MM:SSZ, i.e. to the precision of seconds, e.g T08:05:00Z. This sending timestamp equals the version timestamp of your transactions. Field TR 007 Trade Time (see sheet Field List (T+P) in Transaction Reporting Upload Specification ) has to be sent to the level of microseconds and either with or without a time zone e.g. 10:00: Z or 12:00: Z+02: Trade Date The Trade Date (PD001) is part of the unique key except for Report Level K. In case of transactions and positions, the Trade Time (TR007) is also provided by the customer (except for Cancel and Termination). Both values are provided in UTC date/time format (e.g :00+2 or equivalently :00Z) but have always to be stored in UTC date/time (i.e :00Z). This may lead to the following situations (for trade times around midnight or time zones with large UTC time offsets): The customer submits a New transaction with e.g. Trade Date/Time :59:59+01:00. The Reporting Hub converts these values into Trade Date = and Trade Time = 23:59:59. Thus, the date is part of the unique key. Same situation as above. Now, the customer wants to correct the Trade Time and submits a Correction with Trade Date/Time :59:59+01:00. The platform checks whether a previous record version exists, but cannot find the New record version because of different unique keys (Trade Date of the new version is ) except for the unlikely case that another (completely different) record exists with the same unique key. Since for Action Type Cancel or Terminate the Trade Time is not required, the trade date must be provided according to UTC, i.e. in the above example Please note that due to system limitations a single upload file may only contain up to 750 different Trade Dates. Therefore if you need to update over three years of history you need to provide multiple files. 56

57 5.2.3 Regulation selection Currently customers can send transaction files for either MiFIR or EMIR. This has to be specified in the file name (see sheet File Name Conv. in the Transaction Reporting Upload Specification ), file header for CSV (see sheet Header + Footer Inbound CSV ) and in each transaction record with the Y/N-flags PD007 MiFIR reporting flag and PD008 EMIR reporting flag. There are some common fields for the regulations but most fields are different and since the concept of a transaction differs between EMIR and MiFIR we recommend to report transactions separately for each regulation Uniqueness of a transaction In the RRH a transaction is uniquely identified by the combination of the fields Sender ID (LEI as per the certificate used of the party transferring the file via sftp), PD001 Trade Date and PD002 Customer Transaction ID (see sheet Field List (T+P) in Transaction Reporting Upload Specification ). These fields are used to clearly identify a reporting record, for searching, modification/cancel and to avoid duplicate reporting. The Customer Transaction ID is independent of the unique transaction numbers of the respective regulation, i.e. Transaction Reference Number (MiFIR) or Unique Trade Identifier (EMIR). You are free to use the same number or different numbers. If a user has sent a new transaction for one regulation and sends another new transaction with the same trade date and customer transaction ID for another regulation, then the system accepts this. If common fields are different then the system sends a warning. If the user sends a correction or modification for one regulation and this affects fields also relevant for other regulations reported for this transaction, then the system sends a warning. If the user sends a cancellation or termination of a transaction for only one regulation, the other regulation records for this transaction will not be affected. In the course of the transaction data upload process, transaction data delivered by the user will be split into regulation-specific data records. Subsequently, these data records will be validated and enriched independently from each other Action Type When sending a transaction, the user has to indicate Field PD003 Action Type. It can have the following values: N: New New transaction for the respective regulations R: Correction Correction of a previous incorrect transaction report M: Modification Modification of the contract between the counterparties (only allowed for EMIR reporting) C: Cancel Cancellation of transaction reported in error T: Termination (Early) Termination of a contract before the original maturity date (only allowed for EMIR reporting) Since the MiFIR regulation only foresees New or Cancel, for MiFIR the RRH translates a Correction into Cancel of the original transaction report and a New transaction report Rejection versus error versus warning The result of a validation can result in a rejection, an error or a warning. 57

58 In case of a file rejection, the complete file is not processed and no transaction made it into the RRH. In case of the rejection of a single record, only this record is not processed. You will be able to see it in the reject table in the GUI but it is not available as a transaction In all reject cases, once you have corrected the file/transaction on your side you have to resend it again with Action Type New if the transaction didn t already exist on the RRH. Errors can only occur on record level, not on file level. In case of an error, the transaction is imported into the RRH but it cannot be transferred to the corresponding TR/NCA since it violates regulatory requirements. The Aggregated Validation Status (see Trade Status Report below) of the record is invalid. Also warnings can only occur on record level. A warning is a feedback that there may be an issue with the transaction report but it does not keep it from being reported to the TR/NCA. The Aggregated Validation Status of the record is set to warning or warning but pending Transactions/positions/valuations/collaterals Besides transactions, some regulations additionally comprise the reporting of positions, valuations and collateral data. In case of MiFIR, only transactions have to be reported, EMIR and FinfraG also encompass position and valuation reporting. Collateral reporting has to be taken into account in case of EMIR. Six report levels have to be distinguished as shown in the following table. Only one report level is allowed per file. Report level Description Relevant for Provided via Unique key T P V C K R Transaction record Position record Valuation record (transaction or position based) Collateral record (transaction or position based) Collateral record (portfolio based) Party record (containing party details for stepwise upload) MiFIR, EMIR, FinfraG EMIR, FinfraG EMIR, FinfraG EMIR EMIR MiFIR GUI or Inbound file type "T" GUI or Inbound file type "P" GUI or Inbound file type "V" GUI or Inbound file type "C" GUI or Inbound file type "K" Inbound file type R Sender ID + Trade Date + Customer Transaction ID + Regulation Sender ID + Trade Date + Customer Transaction ID + Regulation Sender ID + Trade Date + Customer Transaction ID + Regulation + Valuation Date Sender ID + Trade Date + Customer Transaction ID + Regulation + Valuation Date CP1 ID Type + CP1 ID + Collateral Portfolio Code 1 + Regulation + Valuation Date Executing Entity Identification Code Type + Executing Entity Identification Code + Internal Party ID Table 8 - Report Levels Transactions and positions are provided in separate inbound files (report level T and P ). Valuation data is either linked to a transaction or to a position. Collateral data may be linked to a transaction or position but can also be linked to a collateral portfolio. Accordingly, the customer may either attach valuation data to the related transaction/position record or provide the data in a separate valuation file (file type V ). The same holds for collateral data which is related to a transaction or position (file type C ). Portfolio based collateral has to be provided separately (file type K ). Please note that for each new valuation day, you have to send a valuation/collateral record as Action Type N (New) since the valuation date is part of the unique key. Also for a position, each new day has a new trade date and you therefore have to use Action Type N (New) to send the new position of the current day. Uploaded customer transaction and position records are split into regulation-specific transaction and position records and stored in regulation-specific tables, possibly together with attached valuation and 58

59 collateral information. Records of type V, C and K are also split into regulation-specific records and will be stored in separate (regulation-specific) valuation/collateral tables. 5.3 File Transfer Files uploaded by users need to follow a file naming convention and predefined format as specified in the Transaction Reporting Upload Specification and for XML files as well the Transaction Reporting XML Guide and Transaction Reporting XML Upload XSD. The customer has to put his file via sftp into his IN folder, see In addition, the following preconditions need to be met: Inbound files need to be generated in csv or xml formats (.xml and.csv ). Capital letters are also accepted (e.g..xml and.csv ). Files have to be in zipped format. (This does not apply to upload via GUI). Inside each zip archive only one file is allowed. The file name of the zip archive and its included inbound file must be identical (upper and lowercase extensions should be taken into account). The maximum file size for uploads is 400 MB (zipped). The maximum line length in a CSV file is 10,000 bytes. The number of files uploaded should not exceed 50 files per day. 5.4 Validations and response files Any validation performed by the RRH will lead to a response file. In the following the different validations and its corresponding response files are described. The RRH provides response files always as both XML and CSV file types Initial validations and initial response file The initial validations on file level are all the validations which can be performed directly on arrival of a file on the RRH. Consequently, the response file relates 1:1 to the file sent and its complete content. Rejections of a file or a record are only possible at the initial validations. The initial response file is described in the sheet Response in the Transaction Reporting Upload Specification and in the Transaction Reporting XML Guide. The initial response file contains all relevant information regarding input file records (valid, erroneous and reason for erroneous, rejected and reason for rejections). The response file header contains the Import and validation result, indicating whether the inbound file has been accepted or rejected and indicating whether record warnings and/or errors occurred. The response file name corresponds to the original inbound file but ends with "RESP. The timestamp included is equal to the timestamp submitted by the customer. The Customer Transaction ID, Regulation and Trade date but also the regulation specific Transaction Reference Number or UTI identify individual records within the response. In case of warnings/errors of an accepted file, related details will be provided within the response file body for each affected customer record and regulation. File name examples: SIM_529900G3SW56SHYNPR95_ T160728_MIXXXXXXT_RESP.XML_ZIP SIM_529900G3SW56SHYNPR95_ T160728_MIXXXXXXT_RESP.CSV_ZIP 59

60 File checks leading to a rejection Once a file has arrived in the IN folder, the system performs the following initial file checks: Check if sender has the authorisation to send the related file (LEI, regulation and services ordered) Check if file format equals CSV or XML Check if file name format agrees with file naming conventions (see sheet File Name Conv. in the Transaction Reporting Upload Specification ) For XML files check if the file structure conforms to the XSD Check if general file structure (header, content, footer) corresponds to the given standard for the respective file type (see sheets Header + Footer CSV, Header XML ) You can find a more detailed description of these checks if you filter the sheet Validations (T+P) and for EMIR/Finfrag also Validations (V+C+K) for any rows with file reject in the column E/W. For XML files the check for mandatory fields and for correct field formats is already performed with the validation against the XSD. All the mandatory fields listed in the sheet Field List (T+P) for transactions/positions and Field List (V+C+K) for valutions/collateral reports must be populated for the respective action type as shown in the column Mandatory fields (ref. Action type), otherwise the file will be rejected and the user will get the error code File rejected - File structure not valid in the response file. If the submitted file does not meet the requirements, it will be rejected and none of its contents will be imported CSV file record checks for technically mandatory fields/field format leading to rejections For CSV files RRH checks the technically mandatory fields and field format on record level and each violation will lead to a rejection of the record. You can find a more detailed description of these checks if you filter the sheet Validations (T+P) and for EMIR/Finfrag also Validations (V+C+K) for any rows with Error (reject record) in the column E/W. Technically Mandatory field checks: In case of CSV upload the technically mandatory fields are: Customer Transaction ID Action Type Trade Date At least one flag specifying the reported Regulation set to Y Regulation specific fields (e.g. for MiFIR the executing entity id, for EMIR Counterparty 1) If technically mandatory fields of a record within a CSV file are not provided or do not meet the format, the response file will show the error message Mandatory field not populated for each missing field. In case no regulation is selected, an error message such as No regulation selected for that record will be provided in the rejection table. In the GUI a rejection table will be created within the file uploads tile. Field format check: It is checked whether values meet the format requirements for the respective field. Length Integer Decimal Type Allowed values (e.g. trade date in the future or Executing entity identification code type <> LEI ) In case of CSV upload, if the field format checks failed, the customer will get the message error Field format invalid in the rejection table. 60

61 Further record checks leading to rejections Check regulation(s) vs. services ordered by customer: Check if the customer has ordered the respective regulation(s) In case of a regulation mismatch, an error message Regulation <set name of regulation> has not been ordered will be shown within the rejection table. The further processing for this transaction record is continued for all matching regulations ordered by the user. Action Type Check against Customer Transaction ID: Customer transaction ID for new transaction record (Action Type New ) already exists for the trade date, selected regulation(s) and customer An error message Wrong action type, Customer Transaction ID already exists will be provided within Rejection table. Action type of the record is Correction, Modification, Cancel or Termination but there is no existing customer transaction ID for that trade date and selected regulation(s) An error message Wrong action type, Customer Transaction ID does not exist will be provided within Rejection table. Action type of the record is Correction, Modification, Cancel or Termination and Customer transaction ID sent by the customer already exists for the trade date and selected regulation(s) and customer. Action type of the most recent version is Cancel or Termination An error message Status of Customer Transaction ID is Cancelled will be provided within Rejection table. Action type of the record is Modification or Termination but selected regulation equals MiFIR An error message Action type not allowed for MiFIR transactions will be provided within Rejection table. Check if a newer version of the record exists: A previous version of the same record (i.e. same customer transaction ID and regulation(s)) already exists and the sending time of the existing record is more recent than the sending time of the record to be processed. An error message A newer version of the record exists will be provided within Rejection table Further field checks leading to errors/warnings If all fields of a record are in correct format the record is stored in the database in its respective regulationspecific transaction table. In the next step the system will validate field content, reference data and regulation-specific validations. In contrast to the checks above, these validations result in records which are valid, contain warnings, or are erroneous. At this stage, records have to be corrected by submitting corrections instead of records with action type New. You can find a more detailed description of these checks if you filter the sheet Validations (T+P) and for EMIR/Finfrag also Validations (V+C+K) for any rows without reject in the column E/W. Field Content Validation: Record fields are checked against the validation rules described in the sheet Validations, filter column Type by Field Content The validation result can be valid, warning or erroneous. Reference Data Validation: Record fields are checked against the validation rules described in the sheet Validations, filter column Type by Reference Data 61

62 The validation result can be valid, warning or erroneous. Regulation-Specific Validation (MiFIR): Record fields of MiFIR records are checked against the validation rules defined by ESMA, in the sheet Validations, filter column Type by MiFIR Specific The validation result can be valid, warning or erroneous. In case of any discrepancies related to one of these validations, warnings or errors are created and feedback will be provided to the customer with details. Repeatable Fields Validation: Validations on repeatable fields Validation on repeatable fields apply to each value individually. Some repeatable fields are grouped together and validation rules exist to ensure that the number of field values is the same for each field being part of the group. In these cases, the first value of field 1 belongs to the first value of field 2 and so on (e.g. Buyer first name and Buyer surname and Buyer Birthdate ). If one or more values supplied in a repeatable field do not pass the defined validations the entire field is marked as such. Please refer also to Chapter APA/ARM reconciliation end of day file. The structure of the APA/ARM reconciliation end of day file is described in the sheet APA vs. ARM recon (eod) in the Transaction Reporting Upload Specification and in the Transaction Reporting XML Guide Further validations and subsequent response file The subsequent validations are validations which cannot happen directly on arrival of a file since the data against which the transactions are validated is not yet available on RRH, which will only be the case for DBG Enrichment/Reconciliation (see chapter 5.9). It can also happen for transactions entered via GUI where the duplicate check for the same MiFIR transaction reference number or the same EMIR UTI + Counterparty 1 + Counterparty 2 fails or where any warnings are created. All other errors are already directly provided in the GUI. Consequently, the response file just contains any records where an error/warning occurred during the subsequent validations. Rejections cannot occur in the subsequent validations. In contrast to the initial response, this feedback is not on file level, but on record level and it is sent every 30 minutes if a user has entered a transaction on the GUI which leads to an error/warning or if data from one of the DBG trading venues has arrived for enrichment/reconciliation and the customer had sent any transactions which result in an error/warning during the enrichment/reconciliation. The structure of the subsequent response file is the same as the Initial Reponse file and is also described in the sheet Response in the Transaction Reporting Upload Specification and in the Transaction Reporting XML Guide. Within the subsequent response file the Customer Transaction ID, Regulation and Trade date but also the regulation specific Transaction Reference Number or UTI identify individual records. Warnings or errors which had already been supplied in the Initial Response file will not be supplied again. The response file name does not include any regulation file type (e.g. MIXXXXXXT). The time stamp included is in UTC followed by "RESP. File name examples: SIM _529900G3SW56SHYNPR95_ T110434_RESP.XML_ZIP SIM_529900G3SW56SHYNPR95_ T110434_RESP.CSV_ZIP 62

63 5.5 Further Response Files Trade Status Report The structure of the trade status report file is described in the sheet Trade Status Report in the Transaction Reporting Upload Specification and in the Transaction Reporting XML Guide. The purpose of this file is to inform the customer about the most recent status updates on record level including Life cycle, Validation, Aggregated Validation and Reconciliation status. This file is provided every 30 minutes for all records where a status change happened. All the reported status values are listed in field trade status details within the corresponding XML body part and in the respective status fields in CSV. This file can also be used to identify the time once the reporting obligation was fulfilled: If you rely on the time when the data has arrived from the RRH at the NCA or TR, take Last Update Time where NCA/TR status is sent. If you want to take the time where the NCA or Trade Repository has confirmed receipt/acceptance, take Last Update Time where NCA/TR status is receipt confirmed, accepted, accepted with warnings, partially accepted or ref. data check outstanding. This file is regulation-independent and therefore the name of the trade status report does not contain any regulation file type. The time stamp included is in UTC followed by "STAT. File name examples: SIM_529900G3SW56SHYNPR95_ T110434_STAT.CSV_ZIP SIM_529900G3SW56SHYNPR95_ T110434_STAT.XML_ZIP The following table shows the different status fields and their possible values: Record Status [short name for User Interface] (affected regulations / entities / action types) Life Cycle Status [Life cycle status] (all / all / all) Validation and Enrichment Statuses Transaction Data Upload Status [Data upload status] (all / all / all) Immediate Validations Status [Immediate valid status] (all / all / N, R, M) Status Values draft waiting for foureyes approval final accepted rejected open n/a ok prelim ok warning* prelim warning error* Comment The record is in draft mode and will not be further processed until the customer approves it (only used for manually created GUI records). Record waits for 4-eyes approval (this feature is not implemented yet). This value is assigned to customer-approved GUI records as well as records, which were successfully uploaded via file transfer. No rejection. At least one customer data upload check raised an error (storage in reject table). This is not possible for manually entered GUI records. Set when the customer record is stored for the first time (provided the Immediate Validation checks apply, otherwise n/a ). a) Record Mode (PD016) equals draft b) Record Mode equals backreporting Task completed. No warnings or errors were detected. Set by GUI if all Immediate Validations carried out by the GUI were ok. At least one check with warning(s) but no check with error(s). Set by GUI. Analogue to warning but only related to those Immediate Validations carried out by the GUI. At least one check with error(s). 63

64 Record Status [short name for User Interface] (affected regulations / entities / action types) Trade Report Match Status [Trade report match status] (MiFIR / T / N, R) Exchange Data Match Status [Exchange data match status] (currently only MiFIR / T / N, R) In StatistiX, this status goes under the technical name Exchange Data Validation/Enrichment Status. Assisted Reporting Match Status [Assisted reporting match status] (MiFIR / T / N, R, C) In StatistiX, this status goes under the technical name Delegation Data Merge Status. Post-Enrichment Validation Status [Post enrichment status] (currently only MiFIR / T / N, R) Status Values prelim error open n/a ok warning open n/a waiting for data ok warning error open n/a waiting for data paired merged merged with errors error open n/a ok warning error Comment Set by GUI. Analogue to error but only related to those Immediate Validations carried out by the GUI. Set when APA enrichment is not applicable but APA recon is outstanding. Trade Report Enrichment and Validation do not apply (e.g. client did not book one of the subservices, no Trade Report ID is provided). APA enrichment and/or recon successfully completed without warnings. The status will switch from ok to warning if the enrichment was successful but the recon detected a mismatch for a non-enriched field. a) APA recon: APA trade not found (and APA enrichment did not apply). b) APA recon: APA trade found but at least one field mismatch. Set when Exchange Data Validation is outstanding. Exchange Data Enrichment and Validation do not apply (e.g. client did not book one of the services, transaction was not traded on Xetra, Eurex or Eurex Bonds). DBG exchange data not yet available for the transaction. Exchange Data Enrichment or Validation successfully completed without warnings. Only used for Exchange Data Validation: a) DBG data available for Venue & Trade Date but transaction not found. b) Validation executed, at least one field mismatch. Only used for Exchange Data Enrichment with time delay: DBG data available for Venue & Trade Date but transaction not found. Set when the customer record is stored for the first time (provided Assisted Reporting Data Merge applies, otherwise n/a ). Assisted Reporting Data Merge does not apply (e.g. client did not book the service). Partial assistance partner record (PAS or PAC) is not yet available. a) This is an interim status which is used in case the PAS and PAC records could be matched but one of the records is either erroneous or Exchange Data Enrichment is still outstanding. b) In case of data merge, the old PAC record version gets this status. New PAC record version has been successfully enriched with PAS data. At least one mismatch between PAS and PAC field values for a field that needs to be enriched but has already been populated by the PAC. Duplicate check failed. Pairing ID is already used by another record. Set when the customer record is stored for the first time (provided the task is applicable, otherwise n/a ). Post-Enrichment Validation does not apply. That is, no enrichment with DBG exchange data or with data of a Partial Assistance Submitter takes place. These statuses reflect the post-enrichment validation results (reference data checks & regulation-specific checks; see IFS, sheet Errors and Validations (T+P) ). Aggregated Validation and Enrichment Status 64

65 Record Status [short name for User Interface] (affected regulations / entities / action types) Aggregated Validation Status [Aggregated validation status] (all / all / all) This status is updated each time one of the above-mentioned validation or enrichment statuses changes. Status Values open valid valid but pending warning warning but pending invalid Comment See Error! Reference source not found. NCA/TR Delivery and Feedback Status NCA/TR Status [NCA/TR status] (all / all / all) open n/a sent receipt confirmed file rejected accepted accepted with warnings partially accepted rejected ref. data check outstanding ref. data rejected Set when the customer record is stored for the first time. a) Record Mode (PD016) equals draft b) Set in case Record Mode equals check draft or in case of erroneous records or in case no new data would be reported after completion of all validation and enrichment tasks. c) Set in case of back-reported records. d) For further usage, see above (bullet point Further remarks to NCA/TR Status ). The record has been sent to the corresponding NCA/TR. The submission process has been completed. In case of Reporting Destination = No transfer to NCA, this status value indicates the transfer of the outbound file copy to the customer. Only relevant for MiFIR: The transaction has been received by the NCA and waits for validation. The outbound file has been rejected by the NCA/TR due to an invalid file structure. The record has been accepted by the NCA/TR. Only relevant for MiFIR, but not used according to ESMA s Technical Reporting Instructions (July 2017). MiFIR/EMIR: Some but not all related outbound records have been accepted by the NCA(REGIS-TR (the other ones were rejected e.g. a cancel and a new for a correct under MiFIR or a combined modification and valuation under EMIR). The record has been rejected by the NCA/TR. Only relevant for MiFIR: Processing of transaction by NCA is pending due to missing instrument reference data. Only relevant for MiFIR, but not used according to ESMA s Technical Reporting Instructions (July 2017). Reconciliation Statuses (not assigned to each record version but assigned to the record as a whole) This status is not used momentarily. Currently it is always set to n/a. NCA/TR Reconciliation Status [NCA/TR reconciliation status] (EMIR, MiFIR / T, P / affects all record versions) open n/a matched matching error matched with warning(s) duplicate error no pairing Set when the customer record is stored for the first time. Not relevant for the record (e.g. record has been cancelled without ever being successfully sent to NCA/TR). Record successfully validated. NCA/TR record found on RRH platform but at least one field mismatch. DBG record has not been found in transaction database of the reporting destination (NCA/TR). 65

66 Record Status [short name for User Interface] (affected regulations / entities / action types) Status Values no pairing NCA/TR record not found on platform open n/a Comment NCA/TR record not found on RRH platform. Set when the customer record is stored for the first time. Not relevant for the record. This status is not used momentarily. Currently it is always set to n/a. Sender/ARM Reconciliation Status [Sender/ARM recon. status] (MiFIR / T / affects all record versions) matched matching error matched with warning(s) duplicate error no pairing no pairing customer record not found on platform DBG data record has not been found in the transaction database of the Sender/ARM. * Warnings/errors can occur due to old reference data; as soon as reference data were updated, repeat the check, some warnings/errors may vanish, the status may change (error -> warning, error -> ok, warning -> ok). Table 9 - Status fields with their possible values The following table shows how the Aggregated Validation Status is derived: Aggregated Validation Status Life Cycle Status Transaction Data Upload Status Immediate Val. Status Trade Report Match Status Exch. Data Match Status Assisted Rep. Match Status Post Enr. Val. Status draft OR waiting 4-eyes appr. "open" "valid" "valid but pending" "warning" "warning but pending" final final final final final final - "accepted" "accepted" "accepted" "accepted" "accepted" - all statuses = "open" all statuses in ("n/a", "ok", "merged") Immediate Validations Status = prelim ok OR all statuses <> ("warning", prelim warning, "error", prelim error, merged with errors) AND at least one status in ("open", "waiting for data", "paired") AND NOT all statuses = open all statuses in ("n/a", "ok", "warning", "merged") AND at least one status = "warning" Immediate Validations Status = prelim warning OR all statuses <> ("prelim error", error, merged with errors ) AND at least one status = warning AND at least one status in ("open", "prelim ok, waiting for data", "paired") "invalid" at least one other status in ("error", prelim error, merged with errors ) 66

67 Table 10 - Deriving of aggregated validation status The following diagram shows the possible status changes: 67

68 Customer uploads record via file transfer (SFTP or GUI) Customer enters record via GUI RRH accepts transaction Entered via GUI ( save as draft ) Entered via GUI (as final record) Life cycle status Immediate Val. Status Final Open Reject Table (no status) Life cycle status Immediate Val. Status Draft Open Life cycle status Immediate Val. Status Final Open Aggregated Val. Status Valid but pending Aggregated Val. Status Open Aggregated Val. Status Valid but pending Customer has to correct and resend record RRH performs Immediate Validation Checks All Immediate Checks are ok At least one Immediate Check raised a warning At least one Immediate Check raised an error Immediate Val. Status Prelim OK Immediate Val. Status Prelim Warning Immediate Val. Status Prelim Error Trade Report Match Status Open Trade Report Match Status Open Trade Report Match Status Open Exchange Data Match Status Open Exchange Data Match Status Open Exchange Data Match Status Open Aggregated Val. Status Valid but pending Aggregated Val. Status Warning but pending Aggregated Val. Status Invalid RRH performs Validation checks Validation Checks and/or Immediate Validation checks raised warning Validation Checks and/or Immediate Validation checks raised warning Validation Checks and/or Immediate Validation raised Error Immediate Val. Status OK Immediate Val. Status Warning Immediate Val. Status Error Trade Report Match Status N/A or OK Trade Report Match Status N/A or OK Trade Report Match Status N/A or OK Exchange Data Match Status N/A or OK Exchange Data Match Status N/A or OK Exchange Data Match Status N/A or OK Aggregated Val. Status Valid Aggregated Val. Status Warning Aggregated Val. Status Invalid Trade Report / Exchange Data Validation booked by the customer Trade Report / Exchange Data Validation NOT booked by the customer Customer has to send a Correction or Cancel/New Trade Report / Exchange Data Validation is ok Trade Report / Exchange Data Validation has at least one warning Trade Report Match Status OK Trade Report Match Status Warning Exchange Data Match Status OK Exchange Data Match Status Warning Record ready for NCA Record sent to NCA Immediate Val. Status OK / Warning Immediate Val. Status OK / Warning Trade Report Match Status N/A or OK Trade Report Match Status N/A or OK Exchange Data Match Status N/A or OK Exchange Data Match Status N/A or OK Aggregated Val. Status Valid / Warning Aggregated Val. Status Valid / Warning NCA/TR Status Open NCA/TR Status Sent NCA provides feedback File was rejected by NCA File was accepted by the NCA NCA/TR Status File rejected NCA/TR Status Receipt confirmed Record rejected by the NCA OR reference data after 7 days still not available Check deferred due tooutstanding reference data Record accepted by the NCA Record accepted with warnings by the NCA NCA/TR Status Rejected NCA/TR Status Ref. Data Check out. NCA/TR Status Accepted NCA/TR Status Accepted with warnings RRH investigates error and corrects it Figure 85 - Status Overview 68

69 5.5.2 NCA/TR feedback file The structure of the NCA/TR feedback file is described in the sheet NCA_TR feedback in the Transaction Reporting Upload Specification and in the Transaction Reporting XML Guide. The NCA/TR status in that file is described in the previous section Trade Status Report. As currently no outbound interface functionality to NCAs is available for the Regulatory Reporting Hub, this type of responses is supplied by the RRH as a simulation (see Error! Reference source not found. Error! Re ference source not found.). They will be generated only if records submitted to RRH contain the specific values put in the comment field PD010. The responses are on record level, featuring the same NCA/TR status as defined in the Trade Status Report and the specific feedback from the NCA/TR for records with errors. The file name does not contain any regulation file type (e.g. MIXXXXXXT). The time stamp included is in UTC followed by "NCATRRESP. The response header includes NCA/TR RESPONSE (resp. NCA/TR Response ) in case of CSV (resp. XML). The response in case XML (resp. CSV) contains the field errordetails (resp. NCA/TR-ERROR-DESCRIPTION ) which describes the NCA message generated for the corresponding records depending on the value of the comment field and the NCA/TR status. However, accepted records are excluded from the body report. File name examples: SIM _529900G3SW56SHYNPR95_ T110434_NCATRRESP.CSV_ZIP SIM _529900G3SW56SHYNPR95_ T110434_NCATRRESP.XML_ZIP MiFIR Data extract The structure of the MiFIR Data Extract file is described in the sheet MiFIR Data Extract (eod) in the Transaction Reporting Upload Specification and in the Transaction Reporting XML Guide. This response only applies to MiFIR reporting and is time (end-of-day) triggered, and depicts all MiFIR transaction records successfully submitted to the RRH for one reporting day. Its purpose is to allow the RRH customer to reconcile their transactions with what the ARM has received. The file name of this report features the environment it is sent from, the receiver id (i.e. the ID of the sender that submitted the records to the RRH), the timestamp of the response in UTC. In addition, it does not contain any regulation file type and includes " MIDATEXTR. The file header contains the total number of records included in the file. File name examples: SIM_529900G3SW56SHYNPR95_ T120025_MIDATEXTR.CSV_ZIP SIM_529900G3SW56SHYNPR95_ T120025_MIDATEXTR.XML_ZIP APA/ARM reconciliation end of day file The structure of the APA/ARM reconciliation end of day file is described in the sheet APA vs. ARM recon (eod) in the Transaction Reporting Upload Specification and in the Transaction Reporting XML Guide. The purpose of the file is to provide the results of the APA/ARM reconciliation, especially to show any APA OTC trade reports for which no corresponding ARM transaction has been reported INTC & complex trade reconciliation end of day file The structure of the INTC & ComplexTrade Reconciliation file is described in the sheet INTC & ComplexTrade Recon (eod) in the Transaction Reporting Upload Specification and in the Transaction Reporting XML Guide. 69

70 The purpose of this report is to check strategy trade reporting and reporting of allocated trades. In MiFIR the individual legs which compose a strategy trade must be reported with the same complex trade component id. This report checks that for every individual complex trade component ID there are at least two legs. In addition if a reporting party can use INTC as buyer or seller if they book for example one trade against the market and later allocate parts of it to several clients. The report validates that within each trade date, and product the total of buys versus sells against INTC is zero at the end of the day REGIS-TR reconciliation file The structure of the REGIS-TR Reconciliation file is described in the sheet REGIS-TR Recon Report in the Transaction Reporting Upload Specification and in the Transaction Reporting XML Guide. The purpose of this file is to provide the results of the reconciliation of an RRH customer EMIR or FinFraG transaction reports against the reports of its counterparty. This reconciliation happens at the trade repository REGIS-TR. 5.6 Repeatable fields Release 1.1 offers the functionality to enter multiple values into repeatable fields for one transaction/position per field. Some of these fields are grouped together in repeatable groups. Other fields are individual repeatable fields (i.e. not part of a group). Multiple values are entered into individual repeatable fields, into groups of repeatable fields or chosen from a drop-down menu. Groups of repeatable fields have values that belong together (e.g. for buyer details: First name Max belongs to surname Mustermann ). Repeatable fields can be identified in the sheet Field List in the Transaction Reporting Upload Specification under column Q Repeatable fields with identifier R (for repeatable fields without predefined set of allowed values) and M (for fields with a predefined set of allowed values of which more than one can be provided). The maximum number of occurrences per field is defined in the corresponding field description. The column Length displays the maximum length per value in brackets. For CSV submission, multiple values are reported in one field, separated by commas (in case of a combination of repeatable fields ( R ) with multiple values ( M ), separation shall be done by comma per repeat, and by slash per combined multiple value). For XML submission, repeatable fields ( R ) can have multiple occurrences, fields with multiple values ( M ) however occur only once and the values are entered in one string separated by comma. Please note that for EMIR the separator of multiple values within a field is sometimes also - as per the field description. 5.7 Stepwise upload of reference data The code type Internal Party ID was introduced within the RRH to allow an enrichment of MiFIR buyer/seller/decision maker details within transactions (e.g. surname, last name, date of birth, etc.) based on a reference data table that has been provided before the upload of the transactions. To use this functionality, two steps have to be performed: First, the static party master data mappings between the Internal Party ID and the associated fields have to be uploaded and stored within the Regulatory Reporting Hub database (Party Reference Details) Second, the transaction data can be uploaded with using Internal_Party_ID as ID Code type for a buyer/seller/decision maker where the remaining data shall be enriched from the reference data. 70

71 5.7.1 Step 1: Provision of Party Reference Details The format of the fields within the reference data file is described in the sheet Field List (R) in the Transaction Reporting Upload Specification and in the Transaction Reporting XML Guide. The Customer will provide the enrichment data by submitting a reference data file (CSV or XML) via SFTP or via GUI file upload in the customer settings menu. Party records will be either accepted or rejected. No warnings are raised for party records (e.g. if buyer age > 100 years). New submission of a Party Reference File will replace an old version, i.e. no deltas will be determined. Hence, the customer is required to send the entire set of party reference details in case he would like to update only a subset. Consequently, if user s party reference record with an active record key (Executing Entity + Internal_Party_ID) is re-submitted, then this is considered as an update of the corresponding party information. In this case, a new record version is created. If a party reference file upload contains no longer a currently active record key, then this reference will be deactivated (for the related Executing Entity). The following table shows the fields that need to be provided within the party reference details: Field Name Field Content Example Executing Entity Identification Currently always LEI LEI Code Type Executing Entity Identification The party record is used for the NHR9CT3VBSOE58 Code enrichments of transactions having this Executing Entity (LEI) Internal Party ID Internal Party ID 4711 Code Type Code Value, e.g. LEI WJ4G2TV3T3G74 Country of the branch ISO 3166 Country Code, DE irrelevant for Decision Maker First Name Only relevant for Buyer, Seller, Max Decision Maker Surname Only relevant for Buyer, Seller, Mustermann Decision Maker Date of Birth Only relevant for Buyer, Seller, Decision Maker Table 11 - Data to be provided for party reference details Step 2: Uplod of transaction data For the following fields the customer has to use Internal_Party_ID as code type and provide his own Internal Party ID in the corresponding ID field. Table 12 - Fields where Internal Party ID can be entered 71

72 5.7.3 Reference data enrichment The Internal_Party_ID is the mapping criterion for identifying and mapping the allocated static party master data to enrich the appropriate below mentioned transaction data fields: Figure 86 - Field list, for which no necessity exists to provide remaining data Please note: It is important that the user provides the file-upload of the static party master data first otherwise the enrichment can t be performed. Also, the enrichment will always be based on the last available file of the party reference details. 5.8 APA Enrichment of OTC Post-Trade Indicator for Transaction Reporting Short description: Customers, who subscribed to the APA and ARM service, can instruct DBG to enrich their ARM transactions with APA data. With Release 1.2 the following transaction reporting field can be enriched: OTC Post-Trade Indicator (field 63 of Transaction Report; RTS 22, Annex I) Instrument identification code (ISIN, field 41 of Transaction Report; RTS 22, Annex I) The enrichment is also possible if the APA trade is not published, either by using the No-Publication Flag or because no publication obligation exists. Preconditions: The client has booked the MiFID II OTC post trade reporting service and the subservice "Return OTC Post Trade Indicator" The client has booked the MiFIR transaction reporting service and the subservice "Enrichment with APA trade details" The APA trade (whose data are used for enrichment) must be submitted to Deutsche Börse prior to the corresponding ARM transaction. The APA trade report and corresponding ARM transaction report use the same APA trade identifier (see below). 72

73 The OTC Post-Trade Indicator to be enriched on the ARM transaction report has been left empty by the client. Step 1: Client submits the APA trade (OTC Trade Reporting) The client submits the APA trade (FIX message) with or without an FpML message (see preconditions). The following APA fields must be populated in order to use the APA trade for the enrichment of the corresponding ARM transaction: o FirmTradeID (FIX tag 1041), o TrdRegTimestamp (FIX tag 769), o PartyID Executing Firm (FIX tag 448), The fields are used for the trade matching with Transaction Reporting. OTC Post-Trade Indicator: o o o Thirteen Trade Flags on the APA side determine the OTC Post-Trade Indicator (see Appendix). The ten flags BENC, ACTX, CANC, AMND, SDIV, RPRI, DUPL, TNCP, TPAC and XFPH are provided by the client to OTC Trade Reporting. Deutsche Börse determines the remaining three flags LRGS, ILQD and SIZE internally (the derivation is based on a certain set of reference data). Step 2: Client submits the ARM transaction (Transaction Reporting) Afterwards, the client submits the ARM transaction. The client has to provide the corresponding APA trade identifier (in field PD014 Trade Report ID) in the ARM transaction recrord in order to use the enrichment service. The venue (field TR006) provided in the ARM transaction record must state XXXX or XOFF to indicate an OTC trade Transaction Reporting will try to locate the APA trade in the related database table. o o Matching criteria: The APA trade can be identified via Trade Report ID (PD014), Trade Date (PD001), Executing Entity Identification Code (CP002). These fields correspond to the following fields on the APA side: FirmTradeID, Date component of TrdRegTimestamps, PartyID Executing Firm. An enrichment is possible if the APA trade is found. Otherwise, the ARM transaction is rejected. The actual enrichment is conducted if all preconditions are met, the corresponding APA trade is found, and the fields to be enriched (OD015 OTC Post-Trade Indicator) are not already populated by the client: o The corresponding APA Trade Flags that are active are collected and converted to match the requirements of the ARM record; the field is populated accordingly. The enrichment is part of the Customer Data Upload process, i.e. the client receives feedback shortly after submission of the inbound file: o o o o The Initial Customer Response File informs about enrichment errors (rejections). The Trade Status Report includes the Trade Report Match Status. This status equals ok in case the enrichment was successful. In addition, the Audit Trail tracks the enrichment process on field level. The hub transfers successfully validated and enriched transaction data to the corresponding NCA (an XML report in accordance with ISO 20022). The transfer time is configurable by the client. A copy of this report is provided to the client. The APA enrichments are visible in this report. 73

74 In order to use the enrichment service, the customer may need to submit APA trades, which are not necessary to meet his/her APA reporting obligations. These extra trades are charged like ordinary APA trades. 74

75 Figure 87 - Appendix, corresponding fields - OTC Trade Reporting / Transaction Reporting 75

76 5.9 DBG Enrichment/Reconciliation This will be available with release 1.2 for MiFIR transaction reporting of trading members who execute transactions on one of the following Deutsche Börse Group s trading venues: MIC code/venue id Trading venue System FRAA Börse Frankfurt Regulated Market Xetra Classic FRAB Börse Frankfurt Open Market Xetra Classic XETA Xetra Regulated Market Xetra T7 XETB Xetra Open Market Xetra T7 XEUR Eurex Eurex T7, Eurex Trade Entry Services XEUB Eurex Bonds Xetra Classic Table 13 - Deutsche Börse Group's trading venues To enrich MiFIR transactions upon upload with data from one of Deutsche Börse Group s exchanges or reconcile them, the following conditions have to be met: The customer has booked the service for the respective trading venue The field venue is filled with the MIC code of the trading venue The field Trade report id is filled with the unique number of the transaction on the venue as per below The customer leaves the fields to be enriched empty since even with enrichment values provided by the customer will not be overwritten. The fields applicable for DBG Enrichment are marked with an E in the column AA Applicable for GDB enrichment / recon (T+1) in the sheet Field List (T+P) of the Transaction Reporting Upload Specification Xetra Classic inkl. Eurex Bonds (MICs: FRAA, FRAB, XEUB) ISIN (12 characters) + TradeId (10 digits) + TradeIdSuffixNo (10 digits) These fields are available in e.g. the Xetra Trade Notification or the report TC810 Daily Trade Confirmation. See Xetra Member section -> Documentation -> Xetra > Interfaces -> Enhanced Transaction Solution -> Interface Specification -> Chapter Message Layout Reference -> Trade Notification or Xetra Member section -> Documentation -> Xetra > Technical -> XML Report Reference Manual -> Chapter «TC810 Daily Trade Confirmation» Xetra T7 (MICs: XETA, XETB) SecurityID (20 digits) + TradeId (10 digits) These fields are available in the Trade Notification. For documentation see -> Technology -> T7 trading architecture -> System documentation -> Release 6.0 -> Trading Interfaces -> T7 Enhanced Trading Interface Cash Message Reference -> Chapter 10.2 Trade Notification or T7 FIX Gateway FIX 4.2 and 4.4 Manual -> Chapter 6.8 Application Messages: Trade Capture 76

77 Eurex T7 inkl. TES (MIC: XEUR) SecurityID (20 digits) + ProductId (4 characters) + MDOriginType (1 digit) + TradeId (10 digits) + SideTradeId (10 digits) MDOriginType only contains the values 1 (TES) or 0 (non-tes) For documentation see -> Technology -> T7 Trading Architecture -> System Documentation -> Release 6.0 -> Trading Interfaces -> T7 Enhanced Trading Interface - Derivatives Message Reference -> Chapter 11.2 Trade Notification Or T7 FIX Gateway FIX 4.2 and 4.4 Manual -> Chapter 6.8 Application Messages: Trade Capture The equivalent field names in Eurex C7/CB012 are: SecurityID (20 digits) + ProductId (4 characters) + MDOriginType (1 digit) + origtrdmatchid (10 digits) + origtradeid (10 digits) SecurityID is not available in CB012 but has to be searched in the T7 Reference Data File (RDF) based on ProductId, Maturity Date, and for options also strike price and put/call identifier. MDOriginType also has to be derived 1 (TES) or 0 (non-tes). TrnTyp in CB012 can be used for this: 000 und 010 are non-tes, 040 and 042 are TES. The equivalent names in Eurex C7 FIXML are: SecurityID (20 digits to be searched from T7 RDF via Symbol, maturity date and for options strike price and put/call identifier) Product ID = Sym/Symbol (Fix tag 55) MDOriginType = if TrdTyp/TrdType (Fix tag 828) = 0, then 0 (non-tes) else 1 (TES) origtrdmatchid = MtchID/TrdMatchID (Fix tag 880) origtradeid = SideTradeID (Fix tag 1506) For documentation see -> Technology -> Eurex Clearing s C7 -> System Documentation -> Release 4.0 -> Eurex Clearing Interfaces -> C7 - Eurex Clearing FIXML Interface Specification - Volume 3: Transaction & Position Confirmation -> Chapter 3.2 Transaction Confirmation Or -> Eurex Reports -> Eurex XML Reports - Reference Manual -> Chapter CB012 Account Statement 6 Assisted Reporting Clients of the Regulatory Reporting Hub ( Clients ) can provide Assisted Reporting to multiple Customers (i.e. their own clients/ Clients of Client ), i.e. they act as Assisted reporting submitter to their Assisted reporting customer(s). The Assisted reporting submitter sends complete reporting records for its Assisted reporting Customers to the Regulatory Reporting Hub, which will after validation pass on the records to the appropriate NCA. 77

78 Figure 88 - Fully Assisted Reporting The Client (Assisted Reporting Submitter) has access to the GUI with read and change rights to the transactions of the Client s Client (Executing Entity/Assisted Reporting Customer). Responses will be sent back to the Client who can submit changes on behalf of Client s Client. If Client s Clients are additionally setup as registered RRH customers with a contract with DBAG, they can have either read-only or correct/cancel/read rights, depending on the settings. However it is not necessary that Client s Client are set up as customers of the Regulatory Reporting Hub. Submitters can initiate the set-up of third parties as their Assisted reporting customers when setting up their contract with the Regulatory Reporting Hub or choose to also report for third parties not setup on the RRH. Assisted Reporting Customers can have multiple Assisted Reporting Providers reporting on their behalf. Details of the registration-/rights access-process are available in the order form and in the User Manual - Regulatory Reporting Hub Member Section as well as in the User Manual for Central Coordinators Regulatory Reporting Hub Member Section, which is accessible within the download area of our website 7 Test 7.1 Available Instrument Data There are still no ESMA Instrument data available with Release 1.1. Therefore, simulated ESMA Instruments of 1.2 Million ISIN-Codes have been created and are available for download. This represents a cross section from MiFID I, XETRA, EUREX and Clearstream, which should cover most instruments listed in EEA (European Economic Area). Using one of the created 1.2 Million ISIN-Codes for testing-purposes avoids the manually entering of additional instrument data information under each transaction within the RRH. 7.2 Simulation of NCA Feedback ( Mock-up ) Currently no outbound interface functionality to NCAs is available for the Regulatory Reporting Hub. It is expected that NCAs will only make their interface for testing available in Q3/2017. Clients can simulate the behaviour of the RRH on basis of testing-data close to reality. The ESMA- Mock-up data (called Release 1.1 modelled regulatory reference data ) are available for download under Manuals /Transaction Reporting Upload Specification from the support-area of 78

79 To allow Release users to start testing the complete message flow, specific use cases have been set up to simulate the reporting to the NCA and the related response from the NCA within the dashboard ring charts NCA transfer status and NCA acknowledgement status and in the transaction detail view status register tab as well as in respond message files. The following table shows what feedback will be provided at subsequent mock NCA batch runs after a transaction is loaded/updated in the RRH based on specific contents within the CSV/XML- field Comment xlsx Tab field list field PD010). In the first batch (15 min after successful validation of uploaded file) the RRH sends data to the NCA, gets first feedback (receipt confirmed) from the NCA in the second batch (simulated with a 15 min delay), then a first validation response file from NCA (i.e. accepted with warning(s)) in the third batch and a potential result from a reference data check in the fourth batch (i.e. ref. data rejected). 79

80 # Scenario description Comme nt field First batch after transaction update no error respo nse file NCA/ TR status in Trade status report Second batch after transaction update (simulated 15 min delay) no error response file NCA/TR status in Trade status report 01 Normal valid transaction - - Sent - Receipt confirmed 02 Normal valid correction - - Sent - Receipt confirmed 03 Normal valid cancellation - - Sent - Receipt confirmed 04- A 04- B 05- A 05- B Transaction cancelled before it was sent in NCA batch Cancellation of transaction cancelled before it was sent in NCA batch Transaction corrected before NCA batch, status of the original version of transaction Transaction corrected before NCA batch, status of the corrected version of transaction 06 Reportable instrument but only later on ESMA list (NCA 1 confirms instrument validation) Third batch after transaction update (simulated 15 min after second batch) Error in response file NCA/TR status in Trade status report Fourth batch after transaction update (simulated 15 min after third batch) Error in response file - Accepted Accepted Accepted n/a - n/a - n/a - n/a - - n/a - n/a - n/a - n/a - - n/a - n/a - n/a - n/a - - Sent - Receipt confirmed Test 01 - sent - Receipt confirmed - Accepted - - Warning: Waiting for instrument data ref. data check outstanding NCA/TR status in Trade status report - accepted 78

81 # Scenario description Comme nt field 07 Non-reportable instrument rejected by NCA after waiting period (NCA 1 rejects instrument validation) RRH initially issues a warning that the instrument is not reportable but nevertheless reports it. 09 Assumption: Invalid MIC code in field Venue not caught by RRH 10 File containing the transaction rejected by NCA 11- A Transaction already sent with this Transaction ID in two different batches (error in duplicate trade validation by RRH), status of the duplicate transaction First batch after transaction update no error respo nse file NCA/ TR status in Trade status report Second batch after transaction update (simulated 15 min delay) no error response file NCA/TR status in Trade status report Test 02 - sent - Receipt confirmed Test 04 - sent - Receipt confirmed Third batch after transaction update (simulated 15 min after second batch) Error in response file Warning: Waiting for instrument data Field TR006 Venue: Invalid segment MIC NCA/TR status in Trade status report ref. data check outstanding Fourth batch after transaction update (simulated 15 min after third batch) Error in response file Instrument not reportable Rejected - n/a Test 05 - sent - file rejected Test 06 - sent NCA Error: transaction reference already exists. Action Type New. Rejected NCA/TR status in Trade status report ref. data rejected 79

82 # Scenario description Comme nt field 11- B Cancellation of transaction already sent with this Transaction ID in two different batches (error in duplicate trade validation by RRH), status of the duplicate transaction 12 Warning by NCA for unlikely trade time Figure 89 - List Mock-NCA use cases First batch after transaction update no error respo nse file NCA/ TR status in Trade status report Second batch after transaction update (simulated 15 min delay) no error response file Test 07 - sent NCA Error: transaction does not exist. Action Type Cancel. NCA/TR status in Trade status report Test 08 - sent - Receipt confirmed Third batch after transaction update (simulated 15 min after second batch) Error in response file NCA/TR status in Trade status report Fourth batch after transaction update (simulated 15 min after third batch) Error in response file Rejected Warning: Trade time outside market trading hours accepted with warning(s) - - NCA/TR status in Trade status report 80

83 How to enter NCA-Mock use cases within a transaction record: To simulate the reporting to the NCA and the related response from the NCA for a specific scenario shown in the above list of Mock-NCA use cases, the user has to enter the related use case text in the comment field (Tab Processing ) when creating a new transaction via GUI. Figure 90 - NCA-Mock use case entry via GUI To enter a use case within a CSV or XML- file the related use case text has to be entered in the field Comment ( Transaction Reporting Upload Specification 1.0 and Transaction Reporting XML Guide 1.0) Figure 91 - NCA-Mock use case sample CSV-file 81

84 Then the file can be uploaded as usual via the File upload functionality: Figure 92 - NCA-Mock file upload 15 min after successful validation of the uploaded file the RRH simulates a first batch sending the data to the NCA. In the second batch (simulated with a 15 min delay after first batch), a first feedback (receipt confirmed) from the NCA is provided. A first validation response file from NCA (i.e. accepted with warning(s)) is provided in the third batch (further 15 min delay) and a potential result from a reference data check in the fourth batch (i.e. ref. data rejected). All response files are provided via SFTP: Figure 93 - Sample NCA-Mock response file - SFTP zipped The ring charts of the dashboard are also reflecting the changes of the respective status with each simulated batch: 82

85 Figure Ring chart sample reflecting the NCA-Mock flow 8 Hotline and system operating hours For technical queries related to the application and platform features please contact our customer technical support team. English and German speaking support is available from 08:00 to 18:00 CET from Monday to Friday excluding German bank holidays. We will use all reasonable efforts to respond within 24 hours. Telephone: (German) Telephone: (English) cts@deutsche-boerse.com 83

86 9 Glossary 9.1 Abbreviations Abbreviation APA ARM CFI Code CSV DBG EMIR FAC FAS FIX FpML GUI ID Description Approved Publication Arrangement Approved Reporting Mechanism Classification of Financial Instruments Code Comma Separated Values one of the file-formats supported by the Release Deutsche Börse Group European Markets Infrastructure Regulation - regulation designed to increase the stability of the over-the-counter (OTC) derivative markets throughout the EU states Full Assistance Customer Full Assistance Submitter Financial Information exchange Financial product Markup Language Graphical User Interface Identifier ISO International Organisation for Standardisation organisation introducing quality management systems standards to help organizations to ensure that they meet the needs of customers and other stakeholders while meeting statutory and regulatory requirements related to a product. LEI Legal Entity Identifier - A unique ID associated with a single legal entity; allows consistent identification of parties to financial transactions, facilitating a consistent and integrated view of exposures OTC Over-The-Counter MiFID II / MiFIR NCA RRH TR XML Table 14 - Glossary / Abbreviation Markets in Financial Instruments Directive / Regulation - law that provides harmonised regulation for investment services across the European Economic Area National Competent Authority Regulatory Reporting Hub Trade Repository Trade Repository or Swap Data Repository is an entity that centrally collects and maintains the records of over-the-counter (OTC) derivatives. These electronic platforms, acting as authoritative registries of key information regarding open OTC derivatives trades Extensible Markup Language 84

87 9.2 Index of Tables TABLE 1 - SUPPORTED BROWSERS... 9 TABLE 2 - RECORD VALIDATION RING CHART POSSIBLE VALUES TABLE 3 - TRANSFER TO NCA/TR RING CHART POSSIBLE VALUES TABLE 4 - ACKNOWLEDGEMENT BY NCA/TR RING CHART POSSIBLE VALUES TABLE 5 - RECORD VALIDATION RING CHART POSSIBLE VALUES TABLE 6 - TRANSFER TO NCA/TR RING CHART POSSIBLE VALUES TABLE 7 - ACKNOWLEDGEMENT BY NCA/TR RING CHART POSSIBLE VALUES TABLE 8 - REPORT LEVELS TABLE 9 - STATUS FIELDS WITH THEIR POSSIBLE VALUES TABLE 10 - DERIVING OF AGGREGATED VALIDATION STATUS TABLE 11 - DATA TO BE PROVIDED FOR PARTY REFERENCE DETAILS TABLE 12 - FIELDS WHERE INTERNAL PARTY ID CAN BE ENTERED TABLE 13 - DEUTSCHE BÖRSE GROUP'S TRADING VENUES TABLE 14 - GLOSSARY / ABBREVIATION Index of Figures FIGURE 1 - REGULATORY REPORTING HUB MEMBER SECTION WEBSITE... 6 FIGURE 2 - DEUTSCHE BÖRSE'S TRANSACTION REPORTING OFFERING... 7 FIGURE 3 - RRH SIGN-IN-SCREEN... 8 FIGURE 4 - ACCESS TO TRANSACTION REPORTING... 8 FIGURE 5 - MENU... 9 FIGURE 6 - TRANSACTION REPORTING DASHBOARD FIGURE 7 - HEADER FIGURE 8 - USER-/CUSTOMER SETTINGS ACCESS FIGURE 9 - SELECTION BAR FIGURE 10 - CONTENT OF SUB-MENU ALL REGULATIONS FIGURE 11 - ALL ACCOUNTS FIGURE 12 - ALL BUSINESS UNITS FIGURE 13 - ASSISTED REPORTING CUSTOMERS FIGURE 14 - CLIENT REPORTING PERFORMANCE FIGURE 15 - FILE UPLOAD / VALIDATION ON-GOING FIGURE 16 - FILE UPLOAD / VALIDATION COMPLETE FIGURE 17 - TIMELINE TRANSACTION LOAD FIGURE 18 - FOOTER FIGURE 19 - REPORTING PERFORMANCE AREA FIGURE 20 - FULLY ASSISTED REPORTING DASHBOARD FIGURE 21 - ALL ACCOUNTS FILTER FIGURE 22 - ALL BUSINESS UNITS FILTER FIGURE 23 - ALL FULL ASSISTANCE CUSTOMERS FILTER FIGURE 24 - FILE UPLOAD VIEW FIGURE 25 - REJECTION TABLE FIGURE 26 - NEW RECORD ENTRY VIEW WITH EMIR SPECIFIC SELECTION POSSIBILITY FIGURE 27 - NEW RECORD ENTRY VIEW WITH MIFIR SPECIFIC SELECTION POSSIBILITY FIGURE 28 - NEW EMIR TRANSACTION/RECORD ENTRY VIEW FIGURE 29 NEW MIFIR TRANSACTION/RECORD ENTRY VIEW FIGURE 30 - NEW EMIR POSITION TAB FIGURE 31 - NEW EMIR POSITION ENTRY SCREEN FIGURE 32 - NEW EMIR COLLATERAL PORTFOLIO UPDATE TAB FIGURE 33 - NEW COLLATERAL PORTFOLIO UPDATE ENTRY SCREEN

88 FIGURE 34 - TRANSACTION, SAVED AS DRAFT FIGURE 35 - EXAMPLE FOR "+" BUTTON WITHIN TRANSACTION INPUT SCREEN FIGURE 36 - POPUP WINDOW BEHIND "+" BUTTON FIGURE 37 - ROW DETAILS FIGURE 38 - CORRECTION BUTTON FIGURE 39 - VERSION HISTORY AND DROP DOWN MENUE FIGURE 40 - SIDE BY SIDE COMPARISON FIGURE 41 - TRANSACTION DETAILED VIEW / CANCELLATION BUTTON FIGURE 42 - TRANSACTION DETAIL VIEW / SUCCESSFUL CANCELLATION FIGURE 43 - EXAMPLE 1: SELECTION OF INTERNAL PARTY ID AS BUYER ID CODE FIELD TYPE; FIELD VALUE PROVIDED BY RRH CLIENT FIGURE 44 - EXAMPLE 2: SELECTION OF INTERNAL PARTY ID AS "INVESTMENT DECISION WITHIN FIRM" FIELD TYPE; FIELD VALUE PROVIDED BY CLIENT FIGURE 45 - ENRICHMENTS BASED ON INTERNAL PARTY ID FIGURE 46 - MIFIR TRANSACTION SEARCH VIEW / ADDITIONAL FILTER CRITERIA DROP-DOWN FIGURE 47 - SEARCH TABLE VIEW FIGURE 48 - MIFIR RESULT LIST VIEW / COLUMNS WITH STATUS INFORMATION FIGURE 49 - MIFIR DETAILED VIEW SINGLE TRANSACTION FIGURE 50 - MIFIR TRANSACTION SEARCH FOR MULTIPLE VALUES FIGURE 51 - EMIR TRANSACTION/POSITION SEARCH TAB FIGURE 52 - EMIR TRANSACTION/POSITION SEARCH SCREEN FIGURE 53 - EMIR VALUATION UPDATE SEARCH TAB FIGURE 54 - EMIR VALUATION UPDATE SEARCH SCREEN FIGURE 55 - EMIR COLLATERAL UPDATE SEARCH TAB FIGURE 56 - EMIR COLLATERAL UPDATE SEARCH FIGURE 57 - EMIR COLLATERAL PORTFOLIO UPDATE SEARCH TAB FIGURE 58 - EMIR COLLATERAL PORTFOLIO UPDATE SEARCH SREEN FIGURE 59 - "MIFIR ERROR SEARCH" BUTTON FIGURE 60 - MIFIR ERROR SEARCH VIEW / WILDCARD SEARCH FIGURE 61 - MIFIR ERROR SEARCH RESULT TABLE / LINK TO DETAILED ENTRY PER TRANSACTION FIGURE 62 - MIFIR TRANSACTION DETAIL VIEW / INVALID TAB - SUMMARY OF FOUND ERRORS FIGURE 63 - MIFIR TRANSACTION DETAIL VIEW / TAB WITH ERRORS - FIELD ENTRIES FIGURE 64 - EMIR TRANSACTION/POSITION ERROR SEARCH TAB FIGURE 65 - EMIR TRANSACTION/POSITION ERROR SEARCH SCREEN FIGURE 66 - EMIR VALUATION UPDATE ERROR SEARCH TAB FIGURE 67 - EMIR VALUATION UPDATE ERROR SEARCH SCREEN FIGURE 68 - EMIR COLLATERAL UPDATE ERROR SEARCH TAB FIGURE 69 - EMIR COLLATERAL UPDATE ERROR SEARCH FIGURE 70 - EMIR COLLATERAL PORTFOLIO UPDATE ERROR SEARCH TAB FIGURE 71 - EMIR COLLATERAL PORTFOLIO UPDATE ERROR SEARCH SCREEN FIGURE 72 - USER-/CUSTOMER SETTINGS ACCESS FIGURE 73 - USER SETTINGS VIEW FIGURE 74 - CREATION OF A TRANSACTION SEARCH FILTER NAMED "MYFILTER1" FIGURE 75 - FILTER SELECTION FIGURE 76 - ACCESS TO TAB "CUSTOMER SETTINGS" FIGURE 77 - CONFIGURATION OF "CONFIGURABLE FIELDS" FIGURE 78 - RESULT: NEW TRANSACTION ENTRY VIEW / TAB "CUSTOM" WITH CONFIGURABLE FIELDS FIGURE 79 - SIMULATION DATABASE RESET FUNCTION FIGURE 80 - SIMULATION DATABASE RESET BUTTON FIGURE 81 - SECTION FILE UPLOAD: STEPWISE UPLOAD DATA, ACCESSIBLE VIA CUSTOMER SETTINGS MENU FIGURE 82 - FILE UPLOAD STATUS TABLE STEPWISE UPLOAD DATA FIGURE 83 - TRANSACTION VOLUME REPORT FIGURE 84 - REPORTING EFFICIENCY REPORT FIGURE 85 - STATUS OVERVIEW FIGURE 86 - FIELD LIST, FOR WHICH NO NECESSITY EXISTS TO PROVIDE REMAINING DATA FIGURE 87 - APPENDIX, CORRESPONDING FIELDS - OTC TRADE REPORTING / TRANSACTION REPORTING FIGURE 88 - FULLY ASSISTED REPORTING

89 FIGURE 89 - LIST MOCK-NCA USE CASES FIGURE 90 - NCA-MOCK USE CASE ENTRY VIA GUI FIGURE 91 - NCA-MOCK USE CASE SAMPLE CSV-FILE FIGURE 92 - NCA-MOCK FILE UPLOAD FIGURE 93 - SAMPLE NCA-MOCK RESPONSE FILE - SFTP ZIPPED FIGURE RING CHART SAMPLE REFLECTING THE NCA-MOCK FLOW FIGURE 95 - WINSCP - LOGIN DIALOG FIGURE 96 - WINSCP - FILE PROTOCOL FIGURE 97 - WINSCP - DIRECTORIES FIGURE 98 - WINSCP - CONTENT OF DEFAULT REMOTE DIRECTORY Appendix 10.1 File Upload via sftp The sftp (secure File Transfer Protocol) upload functionality enables the customer to automate the uploads to/downloads from the Regulatory Reporting Hub. SFTP is also integrated into many graphical tools that support public key authentication. To use sftp the user needs to be issued with a key pair, consisting of a public and a private key In this document, the WinSCP client is used for the demonstration, but other sftp clients such as TurboFTP and FileZilla can be used instead. Before uploading the user needs to know the following predefined login data: Host name: the user will have to provide the IP address of the sftp server. This address is set to Port number: this is the corresponding connection port, which should be equal to 24. User name: this must be equal to the LEI of the user. Private key file: a user has to specify the path to his/her private key. With these data, the user needs to execute the following steps: Start WinSCP and a Login Dialog will appear. 87

90 Figure 95 - WinSCP - Login Dialog Set the File Protocol to SFTP and enter the login data: Figure 96 - WinSCP - File Protocol Choose Directories under Environment and enter the location where the files to be uploaded are stored into the field Local directory. Then press Login to connect to the server. 88

91 Figure 97 - WinSCP - Directories If the connection was successful the user should see the content of his default remote directory as shown below on the right side. Figure 98 - WinSCP - Content of Default Remote Directory After connecting to the server users can upload files using Drag & Drop. This works as follows: First select the local files to be uploaded from the local directory then drag the selection and drop it on the remote directory panel of the server. The target remote directory should be the IN input folder. 89