Transaction Reporting Service: EMIR

Transcription

1 Transaction Reporting Service: EMIR Service Manual January 2014 Version 1.0

2 Contents Indice 1.0 Revision History Introduction Scope References Trade Reporting in EMIR directive and European legislation Service Description Functional specifications Reporting Procedure Fields format Validation data process Appendix Appendix 2 19

3 1.0 Revision History Date Version Description Author 8 Jan Transaction Reporting Service to EMIR, English Version first draft Borsa Italiana 4

4 2.0 Introduction Following the introduction of a new regulation, EMIR 1 which will enter into force on 12 th February 2014 (UE No 648/2012 of the European Parliament and of the Council of 4 July 2012 on OTC derivatives, central counterparties and trade repositories) all financial transactions executed on OTC and ETD (Exchange Trade Derivatives) contracts must be reported to ESMA 2 certified Trade Repositories. The Regulation introduces provisions to improve transparency and reduce the risk on the derivatives markets. The service described in this document is offered by Borsa Italiana to its clients in order to facilitate mandatory transactions and reporting duties, introduced by the EMIR regulation. Information contained in the present document might be changed according to competent authorities final approvals. 2.1 Scope This document describes the functional and technical features of the service. 1 European Market Infrastructures Regulation Regulation (EU) 648/2012 of the European Parliament and Council on OTC derivatives, central counterparties and trade repositories also referred to as the Regulation 2 ESMA is a European Union independent financial regulatory institution, that works in the field of securities legislation and regulation to improve the functioning of financial markets in Europe, strengthening investor protection and cooperation between national competent authorities 5

5 2.2 References - ESMA doc.pdf - EMIR Reporting Field List release xlsx - UnaVista EMIR Reporting Technical Specifications.pdf - UnaVistaTradeRepository_QuickGuide.pdf 6

6 3.0 Trade Reporting in EMIR directive and European legislation EMIR European Union regulation completes the already in force MIFID directive, which specifies new obligations for ETD and OTC derivatives. EMIR rules outline regulatory framework for derivatives ETD and OTC contracts addressed to all involved stakeholders, central counterparties, financial counterparties and clearing members. Furthermore, EMIR establishes Trade Repositories, a system designated to collect and store all derivatives ETD and OTC contracts life cycle data. Borsa Italiana service will use UnaVista EMIR Trade Repository to collect, validate and reconcile all the operations regarding ETD and OTC on all the asset classes. Borsa Italiana TRS service allows to send ETD and OTC transactions to the trade repository, errors management, thanks to automatically syntactic checks, and the dispatch of the data compliant with legislation to UnaVista. 7

7 4.0 Service Description The TRS service is placed between client and Trade Repository and according to ESMA definitions it will be acting as a Third Party. The client maintains data ownership and reporting responsibility. Transaction reporting must take place via file upload, this file must use one of the formats listed below and the layout defined by UNAVISTA described in EMIR Reporting Field List release xlsx contained in the package available at The service will allow clients to perform the following actions: - Manual transaction entry via GUI - Bulk Transactions upload from file via GUI - Exceptions management and upload of corrected transactions - File upload via SFTP - Consultation of transaction reports for 5 days after submission - Historical data consultation - Data export on.csv file Supported formats are: - csv - ascii - xml The transaction must be sent by the end of the next trading day following the trade (that is by T+1 23:59:59 ) Trades reporting syntactic validity is checked before being transmitted to Unavista central Trade Repository. 8

8 Unavista will then validate and perform a reconciliation process by T+2. For each phase, Trade Repository will send response files to TRS. These files will be available to clients for consultation, error management and reporting. (see 4.2) Clients are also required to report the position and lifecycle records until the expiration of the financial instruments or until the position is closed. TRS also offers a data enrichment service, starting from the reference data provided by the user during the service subscription (described in Appendix 1). In addition, for ETD derivatives contracts on instruments cleared by CCG, the data will be used by Transaction Reporting to retrieve from the Borsa Italiana database all the information regarding contracts, positions and lifecycle stages in order to fill out the files correctly to be sent to Unavista hence reducing the manual data entry needed by clients. All validations, exception management and reporting resubmission will be managed by Transaction Reporting. For ETD transactions, cleared by CC&G, automatic generation will be configurable, clients will be able to specify if they want to use this service or if they prefer to personally send ETD transactions on CC&G guaranteed markets. Regardless of this choice, transactions sent by clients, once syntactic checks are passed, will be sent to UnaVista Trade Repository in any case. Regarding OTC and ETD derivatives contracts which are not cleared by CC&G, reporting enrichment concerns only static reference data provided by client when the contract is concluded (see form in Appendix 1). This service also offers the opportunity to clients to delegate the Common Data (data regarding the reported transaction) reporting to the counterparty of the trade, starting from univocal ID (called UTI3) and transaction reference Data. 3 Unique Trade Identifier 9

9 4.1 Functional specifications Borsa Italiana Transaction Reporting receives trades executed by members who have subscribed to the service, trades sent both individually and automatically are aggregated and consistency and completeness checks are performed before dispatching the files to UnaVista. All the operations reported during the whole trading day are accepted by the service and will be checked as described in 4.3, stored in the Database and then sent to UnaVista. All transactions accepted by TRS are sent UnaVista real time for any member. In the event of a file failing the checks, errors are notified to the clients with the wrong record sent through the agreed procedure (file, error message on the GUI, etc). One or more files will be sent to UnaVista via sftp for each members, the results will be managed by the service and notified to the connected TRS clients or to the interconnected active channels. As described in the legislation; contracts, positions and lifecycle must be reported by the end of the next working day after the contract day, that is by 23:59:59 (T+1). See fig.1. Nevertheless, Transaction Reporting service will accept contract reporting for any day (T+n). 10

10 Fig. 1 Information transmission schedule 11

11 4.1.1 Reporting Procedure Each user can insert their own reports during the trading day in one of the following ways: GUI, accessible via web server or via local client. Loading a file or manually inserting in a dedicated window File upload via sftp Loading via GUI a. Single contract manual upload. Some fields in the input window will be filled with the reference data provided (see Appendix 1). b. File upload. Each file can contain transactions from different days. Transaction reported both manually and via file upload, will be real time displayed on the client transaction window. 12

12 SFTP file upload Each trading day TRS service will be able to manage multiple files submission. File name must contain the company ID called LEI (Legal Entity Identifier) 4, file upload date and a progressive identification number <ReportingFirm>_<ReportingDate>_<Prog>.<Ext> <ReportingFirm>: reporting firm LEI code <ReportingDate>: file submission date. Date must be in YYYYMMDD format <Prog>: 3 digits progressive id starting from 001. Files whose id is less than or equal to the last received file will be ignored. Secure file transfer is available 24 hours 7 days a week. Reports sent Monday to Friday will be managed and sent to UnaVista real time, whilst ones sent Saturday and Sunday will be accepted and dispatched to UnaVista the next Monday. Clients will be requested to login with UserId and password provided during service subscription or via SSH using RSA public key exchange All uploaded files will be shown real time in client Files window and identified as FileSFTP under the Source column. 4 LEI must be requested within the date reporting duties will come into effect ( at the present moment is 12 February 2014) 13

13 4.1.2 Fields format This section describes the file format requested by UnaVista. A complete list of Fields format is available at the following link: (file EMIR Reporting Field List release xlsx ) Character File must contain only 8-bit ASCII (ISO ) characters. Alphanumeric field Alphanumeric fields marked as Alpha can contain only alphanumerical characters Numerical data Numerical data are indicated as Decimal. Field length also includes decimal digits. For example, length 30 (25,5) is 25 integer and 5 decimals. Delimiter is full stop (.). Date and Time All the data inserted in the file must have YYYYMMDD format. Time will have HH:MM:SS (24-hour-clock) format and time zone UTC. Files must have an header with the field name as specified by UnaVista: (file EMIR Reporting Field List release xlsx ) Please note that a sample file is available on the Borsa Italiana website. 14

14 4.2 Validation data process This chapter describes how the validation process works, from Transaction Reporting service pre acceptance ( fields format and length, headers etc) to the validation and reconciliation by UnaVista Checks performed by Transaction Reporting service are: 1. Instrument identification code check. Users can specify both the ISIN and the native market alphanumerical symbol. If this field is left empty or invalid data has been submitted, the system will display an error message and the report will be not dispatched to UnaVista 2. Syntactic and file length check as established by UnaVista. Following response.txt files will be returned to user containing reports outcomes: Initial validation file, will contain possible format inconsistency, fields correctness and file format. This check is performed real time by Transaction Reporting service before files are sent to UnaVista EMIR TR and will be identified by suffix TRSRes: Ex: <original file name>_trsres.txt Reponse file from UnaVista EMIR TR File further to delivery and first check. This file will be sent to clients in 20 minutes after it has been forwarded by TRS and is identified by suffix _UVRes ; Ex: <original file name>_uvres.txt Response file from Trade Repository following transaction recording. This file will be returned within 2 hours from the report being sent and will be identified by suffix _UVTR. 15

15 Ex: <original file name>_uvtr.txt All response files will contain the information below: - File handling timestamp (UnaVista will use UK Time) - Number of transactions sent - Number of invalid transactions - Position in the file of the transaction that has generated the error - Name of the field that has generated the error - Error code - Error code description - Field Value that has generated the error - Reporting Firm Id - Transaction Id (UTI) - Report Message Type (Trade, Position or Life Cycle) The values returned in the response files will be consistent with the ones sent in the initial report. Ex: in case the user doesn t fill a field, this will be returned empty. Intraday dispatching outcomes and pending status will be displayed in Files and Transactions window. 16

16 Further validation files will be sent back following the data matching process operated by the Trade Repository within 2 days of the report being sent (T+2). <original file name>_differences_yyyymmdd.txt <original file name>_resolved_yyyymmdd.txt <original file name>_summary by Lastupdated_yyyyMMdd.txt <original file name>_summary by Trade Date_yyyyMMdd.txt <original file name>_unmatched_yyyymmdd.txt 17

17 4.3 Appendix 1 TRS, in order to facilitate clients reporting activity on OTC and ETD not cleared by CC&G and decrease the amount of data requested for each operation, provides a data enrichment service using the Reference Data given by the member at service establishment. Data will be provided by filling out a dedicated form: Reporting Counterparty ID [CP2]: LEI code. Company Univocal Id Reporting Firm Corporate Name [CP4] company name Reporting Firm Registered Office [CP5] company registered address Reporting Firm Country Code of Branch [CP5A]: Company Country ISO code Reporting Firm Corporate Sector [CP6]: company business sector (ex. Bank, Insurance, investment bank, lending institution, etc) Reporting Firm Financial Status [CP7]: specifies if reporting counterparty is financial, not financial or other (ex. Clearing house) Moreover, clients who subscribe the service and report ETD contracts on instruments cleared by CC&G will be asked to provide the same data listed above. They will also be requested to specify if they prefer to report directly or use the transaction automatic generator feature. 18

18 4.4 Appendix 2 This paragraph describes in which way the Clearing system generates UTI and PUTI codes in order to identify uniquely trades and positions (for ETD reporting only). Further details are available in the Trade Repository Reporting document published on Cassa di Compensazione e Garanzia website ( under EMIR>Trade Repository area. UTI for ETD trades Field Name Length Description API field MIC-Code 10 Fixed value 000CGIT000 Participant Code 5 NotifyContract/Abicode Trade Date 8 Format YYYYMMDD NotifyContract/ContractDate Product ID 12 Isin Code NotifyContract/ISINCode Trade Number 12 NotifyContract/ContractNumber (*) Trade Indicator 1 B=Buy S=Sell (from the Participant perspective) Chain Indicator 1 C=Between CM and CCP T=Between Trading Member and Clearing Member NotifyContract/Side (*) through BCS it is possible to get the trade number (see table above) for each ETD trade (contract number). Using BCS, it is also possible to fetch the corresponding trade number assigned by the trading platform (SOLA). 19

19 UTI for positions related to ETD trades Field Name Length Description API field MIC-Code 10 Fixed value 000CGIT000 Position indicator 1 L=Long S=Short Depending on NotifyPositions/CurrentLong and NotifyPositions/CurrentShort Participant Code 5 NotifyPositions/Abicode Account 1 NotifyPositions /Accounttype SubAccount 4 NotifyPositions /SubAccount Product ID 12 Isin Code NotifyPositions /ISINCode 20