GTR OTC Lite User Guide

Transcription

1 DTCC GTR OTC Lite User Guide April 2014 The European Securities and Markets Authority (the "ESMA") have not approved or otherwise sanctioned the information contained in this document. The EMIR business requirements detailed herein represent the DTCC GTR proposed implementation of trade reporting to enable firms to comply with EMIR. Readers should not infer approval by ESMA of the content of this document. This document should be read together with the business requirements for OTC Lite Copyright by DTCC Deriv/SERV LLC Page 1 of 68

2 1. Overview Introduction... 7 GTR Document Portal... 7 Global Processing Overview File Input GTR Connectivity Data Center Access and Security GTR Entitlements Web GUI Entitlement Secure FTP Entitlement GTR Sign on Process Trade submission GTR Upload Process OTC Lite Cross Asset Messaging OTC Lite Message Template Valuation and Collateral Reporting GTR CSV File Footer Message GTR Batch Cut-off Requirements Message Usage Reporting a New Trade Reporting a Post Trade Event Reporting a Trade Exit Lifecycle Event Reporting Correcting Life Cycle Events The following table summarizes the events supported by the GTR Message Workflows DIAGRAM DIAGRAM DIAGRAM Copyright by DTCC Deriv/SERV LLC Page 2 of 68

3 DIAGRAM DIAGRAM DIAGRAM Message Validation Validation Stages Business validation ESMA Regulatory validation Response Messages CSV-Batch Download Report (Spreadsheet Download Report) End-of-Day Warning Report Generation Rules Dual-sided reporting Introduction Identifying reporting model Independent reporting rules Full Delegation reporting rules Delegated Reporting Functionality Matrix Trade Identification Introduction of UTI & Principles applied by the GTR for OTC Lite Upstream workflow UTI Lock UTI Lock Exceptions: Inter-TR Reconciliation Trade Pairing Trade Matching Fields and Rules Participant Reporting Downloading Reports off the Portal Reports available for all Asset Classes ACK/NACK Copyright by DTCC Deriv/SERV LLC Page 3 of 68

4 Warning Report GTR ESMA OTC Position Report GTR ESMA OTC Activity Report ESMA Match Status Report ESMA UTI Conflict or Pair LEI Break Report Appendix A Useful Links Regulatory Background ESMA Final Draft Technical Standards Summary of the ESMA Technical Standards EMIR vs. DFA Comparison ESMA Questions and Answers ISDA s Guidance on Price Notation Business Requirements Document CSV Upload Template OTC Lite Presentations and Videos ISDA Taxonomy International sftp Transmission Guide v Contact List for OTC Lite Appendix B Frequently Asked Questions (FAQs) What is the geographic and jurisdictional scope of OTC Lite? Who is able to use the OTC Lite service? Is it possible to send multiple files in one day as in one file per trade? Which Optional fields need to be filled out? Does the field Trade Party 2 need to be filled out when a party is submitting under independent delegation? How can I submit structured or exotic products? What is DTCC s system operating schedule? Appendix C DTCC Best Practice for Uploading Cross Asset Guidance Technical Guidance Copyright by DTCC Deriv/SERV LLC Page 4 of 68

5 Valid Values Interest Rates Commodities Foreign Exchange Revision History Version Date Revision V0.1 October 30, 2013 Initial Draft V0.2 November 30, 2013 Revisions New Screenshots V0.3 December 11, 2013 Revised Position Report Table V0.4 December 12, 2013 Revised Q and A section V0.5 January 14, 2014 Updated 2.1 GTR Upload Process with new screen shots Added GTR CSV File Footer Message Added Correcting Life Cycle Events Updated 3.5 EOD Warning Report Added 6 Inter-TR Reconciliation (Includes Trade Pairing and Trade Matching) Updated with Warning Error Codes Added ESMA Match Status Report Added ESMA UTI Conflict or Pair LEI Break Report Added ESMA Q&A Link Added ISDA Guidance on Price Notation Added 8.6 International sftp Transmission Guide v1.0 Added additional Q&As in Section 8 Added 10 DTCC Best Practice for Uploading V0.6 March 17, 2014 Updated Web GUI Entitlement Updated 2.4 Message Usage Updated 3.3 ESMA Regulatory Validation Updated Delegated Reporting Functionality Matrix Updated 5 Trade Identification Updated 5.2 Upstream Workflow Updated Warning Report Updated GTR ESMA OTC Position Report Updated ESMA Match Status Report Updated ESMA UTI Conflict or Pair Break Report Updated 8.7 Contact List for OTC Lite Copyright by DTCC Deriv/SERV LLC Page 5 of 68

6 Copyright by DTCC Deriv/SERV LLC Page 6 of 68

7 1. Overview 1.1Introduction DTCC's cross-asset Global Trade Repository (GTR) provides the industry with a central point of communication and storage for OTC derivatives in the Credit, Equities, Rates, Commodities and FX asset classes and EMIR reportable exchange traded derivatives (ETD). GTR accepts all trades from any trading entity worldwide (or its agents) for all global transactions that are reportable to regulators. To supplement the GTR offering the OTC Lite service will be an additional reporting service allowing firms to report their OTC derivatives transactions that are reportable under European Market Infrastructure Regulation ( EMIR ) to the GTR. The solution allows for reporting of positions, trade events and valuation data on each position and collateral valuation data. The service is single jurisdiction and is therefore only appropriate to report trades to ESMA. All OTC derivative transactions for all asset classes can be reported using the single message template. Under EMIR each counterparty of the transaction is required to report the trade or one party may delegate the reporting responsibility to the other trade counterparty or a third party. The OTC Lite service offers independent submissions (report for only one trade counterparty) or full delegation (report for both trade counterparties). This will be explained further in this user guide. 1.2GTR Document Portal Additional useful information can be found on the GTR document portal and may be referred to in this user guide. The GTR document portal houses the latest business and technical documents that are designed to help users understand the requirements of the system. The document portal is divided into seven sections which are described below. Please reach out to your relationship manager to retrieve login information. Copyright by DTCC Deriv/SERV LLC Page 7 of 68

8 Copyright by DTCC Deriv/SERV LLC Page 8 of 68

9 The GTR Release Notes dropdown contains weekly release notes detailing the code changes that have been made and will be made in the UAT and Production environments. Additionally, a section called Release Notes provides information relating to GTR scheduled down times. The Product Training and Support dropdown contains functional description documents, business FAQs and best practices for using the GTR. This section is subdivided into asset classes and each document is categorized according to its asset class relevance. The Business Requirement Documentation dropdown contains documents that describe the requirements met by the GTR. The UAT Documentation dropdown contains documents that pertain to the current UATs in flight. The Supported - Spreadsheet and Messaging Specs dropdown contains the message templates and other technical documents describing the GTR functionality currently supported in the UAT and Production environments. The Future - Spreadsheet and Messaging Specs dropdown contains the message templates and other technical documents describing functionality that is under development and is not yet in the UAT or Production environments. Documents in this section are either under discussion in the DTCC working groups or are planned for migration into the UAT or Production environment. The Global Repository On-Boarding section contains GTR onboarding documentation. The Connectivity section contains guides describing the methods available for connecting to GTR. Copyright by DTCC Deriv/SERV LLC Page 9 of 68

10 1.3 Global Processing Overview The OTC Lite service will only be accommodated in the EU datacenter ( EUDC ). This means that sftp and web-upload will need to be directed to the EUDC for processing. Firms can either connect directly to the EUDC or use their existing connectivity to the USDC but with the exception that any files sent via sftp will be routed to the EUDC based on the GTR Product ID assigned. The diagrams below indicate the connectivity options for the full GTR. Please note that the CSV files received via sftp for OTC Lite will follow the dedicated EU connectivity only File Input Submissions of CSV files via FTP or Web Upload will be to the GTR Product ID for file submissions. CDTS will retrieve the file from the file system and based on the GTR Product ID will send the file to the EUDC for processing. 1.4 GTR Connectivity Participants subscribing to the OTC Lite service can submit OTC trade information via the following channels: Web GUI, using CSV (comma separated values) file upload SFTP, using CSV files Copyright by DTCC Deriv/SERV LLC Page 10 of 68

11 1.4.1 Data Center Access and Security Access to the EUDC is separate and distinct from the others and will be provided by a new URL. For users to access the EUDC URL, they will need a new Global Login ID which is a separate and distinct log in ID from the existing Web ID. All existing users, who wish to gain access to Global URLs, will require a second Global Login ID in addition to their current Web ID. Existing Web IDs will not be able to access the Global URLs, likewise the Global Login IDs will not be able to log into the US URL. These existing users will need to request access to a new Global Login ID from their Super Access Coordinator (SAC). The SAC will be able to provide new Global Login IDs to their users. Global IDs will follow the current Web ID format Restrictions SAC CRS can only be accessed through the US URL. Existing and New SAC functionality will continue to be supported from the US URL. Global Login ID Cannot be permissioned as a SAC or AC as both functions are only accessible through the US URL. UAT Existing and New users will have to log into the EU URL to access UAT GTR Entitlements Web GUI Entitlement The GTR web system is accessed via links to the common DTCC Customer Portal. All new users are issued with login IDs and passwords in order to log-in to the Global Trade Repository system. Separate regional portals are available via each data center to access the GTR web system. Separate sign-on and passwords are required for accessing each portal. Each user login ID is associated with a GTR Entity/Participant Grouping code (O-Code), a four character code used to identify the organization of the user. A participant will receive separate O-Codes for different services provided. In addition, position reports are created at the O-Code level; therefore all entities grouped under the same set of O-Codes will show up on the same position report. Existing DTCC participants are able to utilize their existing login IDs and passwords to access the GTR Submission and Reporting system; however each participant should have one of the above roles defined for their existing login IDs, along with the mapping for their new Entity/Participant Grouping Code (O- Code). Currently Firms that are setup in DTCC have two or more access coordinators who can setup users for DTCC web products within their firm. The GTR system is configured to allow each firm s access coordinator to assign access rights for the web GUI to users within their firm. Participant and regulator roles are defined in the GTR. Copyright by DTCC Deriv/SERV LLC Page 11 of 68

12 Participant Participants are able to submit data to GTR by uploading CSV files for their authorized Entity through the submission portlet. The portlet is available on the GTR Dashboard. Participants can view the status of their uploaded batches through reports that can be downloaded as spreadsheets. This applies to CSV submissions uploaded via Web GUI or Secure FTP. Only OTC Lite submissions will be indicated on these batch reports (also known as the ACK or NACK batch output report) Participants are able to view reports applicable to the entities for which they have been authorized. All trades submitted in the OTC Lite service in the EUDC will be included on the participant reports generated at that data center Regulator Regulators are able to view reports in the GTR reporting portlet. Reports are available per asset class on the GTR Dashboard. Regulators are able to view reports based on the authorized Entity, the Regulator Type and Regulator Mapping setup in SDO. Only those trades marked as having reporting obligations will be included on the appropriate regulator reports. For example, all open trades in the EUDC will be included in the participant reports generated in EUDC but only those trades with a reporting obligation of ESMA will be included in the regulator reports generated in the EUDC Secure FTP Entitlement The participants who submit trade information into GTR will be given Secure FTP entitlement for the CSV submission. The way to submit through Secure FTP is through DATATRAK and AutoRoute which are DTCC s proprietary file input and output management subsystems. They enable DTCC and its participants to securely and reliably automate the exchange of files over a network link. DTCC supports these services over their proprietary SMART network, as well as the SWIFT and BT Radianz networks. For more information on DATATRAK and AutoRoute go to the GTR Clients Center (outline in section 1.2) and select Connectivity in the dropdown to retrieve the documentation. Copyright by DTCC Deriv/SERV LLC Page 12 of 68

13 1.6 GTR Sign on Process The below screenshots depict how to login to OTC Lite. 1. Go to 2. Here you are prompted for your user ID and password. Type your user ID and password and click Login 3. Select OTC Lite from the DTCC Portal Menu. It will look similar to the below link for the Global Trade Repository. Copyright by DTCC Deriv/SERV LLC Page 13 of 68

14 2. Trade submission 2.1 GTR Upload Process The below screenshots depict how to manually upload CSV files into the system. 1. Go to: Contact for login details. 2. Once you are logged in, select Supported - Spreadsheets and Messaging Specs. All message templates in Production are available under Supported - Spreadsheets and Messaging Specs. All message templates that are in UAT are available in Future - Spreadsheets and Messaging Specs. Copyright by DTCC Deriv/SERV LLC Page 14 of 68

15 3. Click the spreadsheet that you want to download (e.g. OTC Lite Upload Spreadsheet). 4. Log on to the portal to access OTC Lite. Select Participant in the dropdown. Enter your Participant Code and then select your O-Code in the dropdown. 5. The dashboard shows your firm s latest list of batch submissions to the GTR. Click Upload. The Upload page appears. 6. Click Upload and then use the navigation tools provided to locate and select the spreadsheet file that you want to upload. 7. Click Upload Copyright by DTCC Deriv/SERV LLC Page 15 of 68

16 2.2 OTC Lite Cross Asset Messaging The following message types are supported by the OTC Lite service for all asset classes. Message Type Position Valuation* Description Used either to report the point-in-time view of the trade state or to report the trade opening. The point-in-time view of the trade state may include any trade detail changes or updates to the trade. (This message type is similar to the main GTR service which supports a Snapshot ) Used to report the current valuation (market value) of the trade. The valuation is submitted on a daily basis for the reportable trades. Collateral Valuation* Used to report portfolios of collateral that can be linked to individual transactions. *Have a compliance date of August 11 th OTC Lite Message Template The message template is designed to enable full compliance with the EMIR requirements and as such contains fields that are specified in the EMIR RTS. In addition to these fields there are a set of control fields that are applicable for all message submission to the GTR in order for the GTR to process the messages correctly. The template is a simple CSV format and contains 28 control fields (most of these are required on each message) and 128 EMIR specific fields (including fields related to trade party 2 to enable delegated reporting). Each message type supported can be submitted on the same template and where the field is N/A or Optional it can be left blank (comma-separated) and the GTR will accept the message. Important to note: It is the reporting parties responsibility to ensure that all EMIR specific Required fields have been populated accurately and completely. The GTR mandates many of the fields as required but there are a number of common data fields (mostly trade economic fields) that are Optional on the message template. The reporting party has until end of T+1 UTC to report the trade to a registered trade repository (TR) under the EMIR rules. However, here may be certain scenario s that some of the data is not available. As soon as the data is available the reporting party must update their trade record in the GTR. Each EMIR field has been indicated in the message template and should be populated if available/applicable Valuation and Collateral Reporting Compliance for the valuation and collateral reporting will be 180 days post reporting start date. The description and details for valuation and collateral reports will be included at a later stage GTR CSV File Footer Message Each CSV file must contain a footer message. The file footer (trailer) contains information needed by GTR to process the CSV file correctly. The below footer message must be included in all csv submission Copyright by DTCC Deriv/SERV LLC Page 16 of 68

17 to the GTR whether web upload or sftp. There are additional headers and trailers required in your sftp submissions but this footer is also required. The format of the message is as follows: *OCOD-ENDnnnnnnnn Example: *DTC0-END GTR Footer GTR Value Length (Trailer) Field Constant1 * (This is constant) 1 Originator This is the 4 character ORIGINATOR ID that is assigned to your 4 account as part of the GTR on-boarding process. DTC0 is used in our example above Constant2 -END (This is constant) 4 Record Count This is the count of records in the file excluding comment lines. 8 This must be left padded with zeroes are used in our example above. Sample File (example for information purposes only) The below example includes a file consisting of 4 lines with data. The comment line and file footer are not included in record count. Please also note the file footer is one value. *Comment Line,Data,Data,Data,Data,Data,Data,Data,Data,Data,Data,Data,Data,Data,Data,Data,Data *DTC0-END By way of example, when preparing your sftp file the following format should be followed: DataTrak Header Application Header *Comment Line,Data,Data,Data,Data,Data,Data,Data,Data,Data,Data,Data,Data,Data,Data,Data,Data *DTC0-END DataTrak Trailer Copyright by DTCC Deriv/SERV LLC Page 17 of 68

18 2.3 GTR Batch Cut-off Requirements Transactions reported under EMIR must be reported to a trade repository no later than T+1 following the conclusion, modification or termination of the trade. Across all asset classes, the cut-off for batch reporting in the EUDC is 23:45 Coordinated Universal Time (UTC). Five batch reporting cycles run each week and will be scheduled at the following times. Business Day EUDC Submission Cut-off EUDC Batch Run Monday 23:45 UTC Monday 00:00 UTC Tuesday Tuesday 23:45 UTC Tuesday 00:00 UTC Wednesday Wednesday 23:45 UTC Wednesday 00:00 UTC Thursday Thursday 23:45 UTC Thursday 00:00 UTC Friday Friday 23:45 UTC Friday 00:00 UTC Saturday 2.4 Message Usage The following section details how to report a new trade, report a post trade event and report a trade exit. The Trade Event column defines the business event that has occurred. The Message Type, Action, Transaction Type and Lifecycle Event columns refer to the fields you would submit on an inbound message. ESMA Action refers to how the message will be reported to ESMA. The OTC Lite message template can be used to report Interest Rate, Credit, Foreign Exchange, Equities and Commodity OTC derivative transactions. The tables below are applicable for all asset-classes unless indicated. Inbound Transaction type field value of PositionCancel will always be reported as Error to ESMA. Asset Class Message Type Action Transaction Type Lifecycle Event ESMA Action All Any* New PositionCancel N/A Error *Any refers to any message type and transaction type where Cancel applies Reporting a New Trade The following message type, activity type and transaction type combinations can be used to report a new trade. Trade Event* Message Action Transaction Type** Lifecycle Event ESMA Type Action New Trade Position New Trade Trade or New New Backload Position New Backload or Trade N/A or New Backload Novation Trade (a New Trade as Position New Trade Novation- New a result of a novation) Trade Copyright by DTCC Deriv/SERV LLC Page 18 of 68

19 * Allocated, Cleared and Unallocated Block trades will be reported under New Trade ** Multiple Transaction Types are giving users the ability to decide what is best depending on their system flow Reporting a Post Trade Event The following message type, activity type and transaction type combinations can be used to report post trade events. Trade Event Message Type Action Transaction Type Lifecycle Event ESMA Action Amendment Position New Trade Amendment New Modification Position New Trade Modify Modify Increase Position New Trade Increase New Partial Novation Position New Trade Novation Cancel Termination Position New Trade Termination Cancel Partial Termination (FX and Position New Trade PartialTermination Cancel Credits only) Fee Amendment Position New Trade Amendment New Compression* (original Position New Trade Compression Compression trade part-terminated) Succession (Credit only) Position New Trade CreditEvent New Credit Event (Credit only) Position New Trade CreditEvent New Partial Exercise (FX only) Position New Trade PartialExercise Cancel Exercise Position New Trade Exercise Cancel Corporate Action Position New Trade CorporateAction New *The new trade/s as a result of the compression event should have the field Compression marked as true Reporting a Trade Exit The following message type, activity type and transaction type combinations can be used to remove an existing trade. Trade Event Message Action Transaction Lifecycle Event ESMA Action Type Type Full Termination Position New Exit or Trade Termination Cancel Full Novation Position New Exit or Trade Novation Cancel Compression (original Position New Exit Compression Compression trade terminated) Exercise Position New Exit Exercise Cancel Partial Exercise Position New Exit or Trade Partial Exercise Cancel (FX Only) Exit Position New Exit Exit Cancel Position Cancel Position New PositionCancel N/A Error Copyright by DTCC Deriv/SERV LLC Page 19 of 68

20 Please note that a Position Cancel will remove the position as if it never existed. The UTI can be re-used if not locked by any other submission from the other counterparty. An Exit message is when a trade is no longer a live position (there is no need to submit an Exit when a trade matures). In addition, when a life cycle event occurs that will lead to an Exit message, submitting only an Exit message will be sufficient for reporting purposes. 2.5 Lifecycle Event Reporting EMIR regulations require reporting on the individual lifecycle events that occur throughout the lifetime of a derivative contract. Life-cycle events are changes to the originally agreed trade details which occur during a trade s lifetime. For trades that fall under EMIR it is necessary to provide reporting not only for end-of-day state of trades, but a substantiation of that end-of-day trade state in the form of an event log of specific changes that have occurred since the prior end-of-day, including the reason for these changes. This can be achieved by the reporting of a series of interim trade state position snapshots Correcting Life Cycle Events For certain OTC products, there can be many lifecycle events. There may be a time when a party submits a lifecycle event erroneously. There the below table was created to show how to correct a lifecycle event that was submitted incorrectly. First set of files sent to GTR: File Event Lifecycle Trade Notional As of Date Time Comment No. Event Field Amount 1 New Purchase Trade 10M 10M 01-May-2014 T09:00 Logging in position 1 Partial Unwind Termination 2M 8M 01-May-2014 T14:00 Termination 1 2 Partial Unwind Termination 2M 6M 02-May-2014 T10:00 Termination 2 3 Partial Unwind Termination 2M 4M 03-May-2014 T10:02 Termination 3 Termination 1 in File 1 needs to be cancelled: File Event Lifecycle Trade Notional As of Date Time Comment No. Event Field Amount 4 Error 8M 01-May-2014 T14:00 Telling DTCC the 1st partial unwind should be cancelled 5 Modify 8M 02-May-2014 T10:00 Bringing the remaining notional back to 8M as the 1st unwind is cancelled 6 Modify 6M 03-May-2014 T10:02 Bringing the remaining notional back to 6M as the 1st unwind is cancelled 7 6M Current Time To make sure the latest position is updated Copyright by DTCC Deriv/SERV LLC Page 20 of 68

21 Copyright by DTCC Deriv/SERV LLC Page 21 of 68

22 Business Event New Trade Amendment Backload The following table summarizes the events supported by the GTR. Termination resulting from compression Exercise (Full)~ Exercise (Partial) Increase Novation Full (Stepping out & remaining parties)~ Novation Partial (Stepping out & remaining parties) Novation (Stepping in & remaining parties) Termination Full~ Termination Partial Valuation Update Global Cancel (Withdrawing the trade) Exit or AutoExit Corporate Action Fee Amendment Credit Event Lifecycle Event Trade New Amendment Backload Compression Termination (for all asset class) PartialTermination (Credit) (with compressed flag indicator true) Amendment (Rates and Commodity) (with compressed flag indicator true) Exercise PartialExercise (FX) Increase Amendment (Rates) Novation Termination (Rates) Novation Termination (Rates) Novation-Trade NovationTrade PartialTermination (Credit) Termination PartialTermination (Credit and FX) Termination (Rates, Equity, Commodity) N/A Cancel Error Exit CorporateAction (Equity) Amendment Termination Exit Modify Cancel Error Copyright by DTCC Deriv/SERV LLC Page 22 of 68

23 2.6 Message Workflows The message flows in the following section is based upon the following assumptions: Both parties to the trade are obligated to report under EMIR. There will be variations to each workflow in the cases where one party has no reporting obligation or an obligation to another jurisdiction. When a trade is executed on-facility, the facility will generate a UTI and advise both counterparties. When a trade is confirmed or affirmed using a middleware platform, the middleware will generate a UTI and advise both counterparties, or will arbitrate between counterparties and ensure agreed UTI is advised. When a trade is for clearing post bilateral execution the CCP will generate two new novated trades, report those trades under separate UTIs but link them with the original bilateral trade via the prior-uti field. When a trade is agreed to be cleared prior to execution, the CCP will generate and report two different UTIs A UTI is recommended field to be populated. However, when a UTI is not provided, the OTC Lite service will look for these values: o If submitted for value is 'BOTH', Then 'Transaction Reference Number' and 'Internal Trade reference' is required o If submitted for value is Party1, Then 'Transaction Reference Number' is required. o If submitted for value is Party2, Then 'Internal Trade reference' is required. If the UTI needs to be amended or corrected then the existing message needs to be exited ( Exit ) and a new position message submitted (indicate in the prior UTI field the previous UTI that was exited) Various parties (i.e. CCPs and other parties) will be able to submit on behalf of an entity but they will need to have access/permission to do so. When only Party A and Party B are involved, the submitting party will be the only party receiving ACK messages. The submitting party will always receive the ACK regardless of what role they play in the trade. If both CPs are participants in the GTR they will be able to retrieve their EOD reports which will indicate UTIs where they have been named as the counterparty (This is for OTC trades reported in the GTR). Bi-lateral On-facility Non-cleared Cleared Non-cleared Cleared Reporting Model Paper Confirm M/ware Conf/Aff M/ware Conf/Aff independent Full Delegation Copyright by DTCC Deriv/SERV LLC Page 23 of 68

24 2.6.1 DIAGRAM 1 Bilateral execution; affirmed in middleware; not cleared; Both parties report (no delegation) Note: The message template is a CSV only format and therefore if a middleware provider agrees to submit for one or both counterparties then the middleware provider must also adhere to the message format and submission methods described above. Flow Steps: 1. Party A & B bi-laterally agree trade. 2. Parties send the trade to the middleware platform. 3. The middleware generates UTI and confirms UTI with counterparties. 4. Party A submits a Position message to GTR on its own behalf. Party A 5. Party B submits a Position message to GTR on its own behalf. 6. The GTR sends an ACK back to Party A and Party B, respectively. 7. Party A sends a Valuation message 2,3 8. GTR sends an ACK to Party A 9. Party A sends a Collateral message 10. GTR sends an ACK back to Party A 11. Party B sends a Valuation message 12. GTR sends an ACK to Party B 13. Party B sends a Collateral message 14. GTR sends an ACK back to Party B 6,8,10 4,7,9 1 Middleware TR 2,3 5,11,13 Party B 6,12,14 In the above example if the middleware provider is able to submit the CSV file then the middleware provider could report the Position message for both in step 4 & 5 (and the middleware provider would receive the ACK instead of Party A and B from step 6) Copyright by DTCC Deriv/SERV LLC Page 24 of 68

25 2.6.2 DIAGRAM 2 Bilateral execution; affirmed in middleware; not cleared; Party A reports on behalf of both parties (full delegation) 1 Flow Steps: 1. Party A & B bi-laterally agree trade. 2. Parties send the trade to the middleware platform. 3. The middleware generates UTI and acknowledges trade with UTI. 4. Party A submits Position message to TR on behalf of both parties 5. The GTR sends an ACK back to Party A 6. Intra-day parties agree to amend the contract 7. Parties send the amends to middleware 8. Party A submits Position message indicating Amendment to the GTR 9. GTR sends an ACK back to Party A 10. Party A sends a Valuation message 11. GTR sends an ACK to Party A 12. Party A sends a Collateral message 13. GTR sends an ACK back to Party A 14. Party B sends a Valuation message 15. GTR sends an ACK to Party B 16. Party B sends a Collateral message 17. GTR sends an ACK back to Party B 5,9,11,13 Party A 7 2,3 6 Middleware TR 2,3 Party B 4,8,10,12 14, ,17 Copyright by DTCC Deriv/SERV LLC Page 25 of 68

26 2.6.3 DIAGRAM 3 Bi-lateral execution; paper confirmation; not cleared; One party reports all data (full delegation) Flow Steps: 1. Party A & B bi-laterally agree trade. 2. Party A sends a Position message to the GTR including common and counterparty specific data on behalf of both parties 3. The GTR sends an ACK back to Party A 4. Party A sends an EOD Position message recapping open positions including valuations 5. GTR sends an ACK back to Party A 6. Party A sends Collateral and Valuation message to GTR 7. GTR sends an ACK message back to Party A Party A 1 Party B 2, 4, 6 3, 5, 7 TR Copyright by DTCC Deriv/SERV LLC Page 26 of 68

27 2.6.4 DIAGRAM 4 On-Facility execution; not cleared; Both parties report (independent) Flow Steps: 1. Trade is booked on execution platform and is sent to Parties A & B. 2. Execution platform generates UTI and sends to Parties A & B. 3. Party A sends Position message to TR on behalf of itself. 4. GTR sends an ACK to Party A 5. Party B sends Position message to TR on behalf of itself. 6. GTR sends an ACK to Party B 7. Party A reports Valuation message and Collateral message on ongoing basis. 8. Party B reports Valuation message and Collateral message on ongoing basis. 1, 2 1, 2 Party A Execution Platform Party B 3, 4, 7 5, 6, 8 TR Copyright by DTCC Deriv/SERV LLC Page 27 of 68

28 2.6.5 DIAGRAM 5 On-Facility execution; not cleared; one party reports all data (full delegation) Flow Steps: 1. Trade is booked on execution platform and is sent to Parties A & B. 2. Execution platform generates UTI and sends to Parties A & B. 3. Party A sends Position message to TR on behalf of both parties. 4. GTR sends an ACK to Party A 5. Party A reports Valuation message and Collateral message on ongoing basis. 6. Party B reports Valuation message and Collateral message on ongoing basis. Party A 1, 2 1, 2 Execution Platform Party B 3, 4, 5 6 TR Copyright by DTCC Deriv/SERV LLC Page 28 of 68

29 2.6.6 DIAGRAM 6 On-Facility execution; cleared; Both counterparties report (independent); CCP reports the novated trades. Flow Steps: 1. Trade is booked on execution platform and is sent to Parties A & B with generated UTI. 2. Party A & Party B allege and affirm the trade on the middleware. 3. Middleware acknowledges trade with UTI back to Parties A & B. 4. Party A sends Position message to TR on behalf of itself. 5. Party B sends Position message to TR on behalf of itself. 6. Middleware sends trade to CCP for clearing 7. CCP novates bi-lateral trade into two trades with CCP facing each party and assigns UTI to each. 8. CCP acknowledges two new trades to middleware. 9. CCP sends Position message for two new trades to TR including reference to prior UTI (X) 10. Party A submits Position message to Exit original trade X 11. Party B submits Position message to Exit original trade X 1 1 Execution Facility Party A Party B 7 Trade Y 2, 3 2, 3 Middleware 7 Trade Z 4, 10 6, 8 5, 11 9 Trade Y TR CCP 9 Trade Z Copyright by DTCC Deriv/SERV LLC Page 29 of 68

30 3. Message Validation The existing GTR Message Validation subjects each message submitted to GTR to a set of validation steps. Failure to pass any of these checks results in a negative acknowledgment (NACK) message being returned to the submitter. Successful completion of all of these checks results in a positive acknowledgment (ACK) being returned to the submitter. 3.1 Validation Stages Schema Syntax Validation GTR Core Validation GTR Business Validation Is CSV valid? Are fields formatted correctly? Permission, UTI lock, transaction & action type consistency validation. e.g. Does the post-trade CCY = the position CCY? 3.2 Business validation The scope of the Business Validation will cover GTR Control Fields Other Mandatory jurisdictional Fields. That is, fields that are required for regulatory jurisdiction that are not GTR Control fields. Non-compliance with any steps will result in the rejection of the submission and the generation of a NACK. 3.3 ESMA Regulatory validation If a message has complied with the schema syntax validation, the GTR core validation and the business validation it will be accepted into the GTR. The submission will then be validated for the jurisdiction listed in Reporting Obligation Party 1 and Reporting Obligation Party 2. Non-compliance with regulatory validation which an obligation has been specified will result in the generation of a warning on the participant Warning Report. It should be noted that the message may be Copyright by DTCC Deriv/SERV LLC Page 30 of 68

31 accepted into the GTR even when a particular regulatory required field is not populated. The reason for this is that not all regulatory required fields are required for each scenario of reporting (in the case of delegated reporting) or where certain fields do not apply to the product being reported. Participants must review their Warning report and submit a Position message with all completed data to ensure the message is compliant with reporting to ESMA. (The Warning Report is provided each day with EOD reports) 3.4 Response Messages Notification messages (ACK or NACK reports) will be generated real-time in response to CSV file submissions CSV-Batch Download Report (Spreadsheet Download Report) Each CSV file submission will create a ACK or a NACK Report (Spreadsheet download report) or both (depending on the status of each message in the file) that includes all GTR submissions successfully processed, or rejected for the CSV submissions done through Web GUI or Secure FTP. This report is made available to the submitter automatically in the Spreadsheet Download tab on the Web GUI. Submission Status ACCEPT REJECT Description This status indicates that the GTR Core validation, GTR business validations as well as all the other mandatory fields have passed, indicating that the inbound submission was validated, verified and has been accepted in the GTR system. This status indicates that the GTR Core validation and GTR reduced business validations failed, indicating that the inbound submission was not as per the required validation and has been rejected by the GTR system. 3.5 End-of-Day Warning Report The EOD warning report contains trade level warnings where a specific trade failed the jurisdictional compliance requirement. The Position message regulatory field validations will be applied for validating the trade field compliance requirement. Warnings will be generated for all blank ESMA required fields. While the GTR might have a field as optional the field maybe an ESMA required field. It is the party s responsibility to ensure that they are fully compliant for reporting to ESMA. Copyright by DTCC Deriv/SERV LLC Page 31 of 68

32 3.5.1 Generation Rules Generated once a day during batch runs starting at 00:00midnight UTC in the EUDC. Any inbound submission received after prior-day s warning report generation will be validated for any exceptions and reported in the subsequent day s warning report. The report will contain only open outstanding warnings for that day It does not contain warnings on Position message that were corrected during the day. The existing GTR reporting portal has a facility to store prior 7 days of warning reports for reference. For the format of the Warning report see the Participant Report section below Copyright by DTCC Deriv/SERV LLC Page 32 of 68

33 4. Dual-sided reporting 4.1 Introduction IMPORTANT: IF REPORTING ON BEHALF OF BOTH OR ONE PARTY TO THE TRADE THEN ALL SUBSEQUENT MESSAGES ON THAT UTI MUST BE MADE TO THE SAME SERVICE ( OTC Lite or OTC Core ). The GTR cannot process UTI s that are partially submitted in a service. For example, if a Middleware uses OTC Core to submit on behalf of Party A and Party A is an OTC Lite user, the position message will be accepted by OTC Lite but will appear as a duplicate in the reports. The current GTR infrastructure supports the reporting of trade data by both sides to a transaction either directly, through delegated reporting or via approved 3rd party service providers. The submissions may be made independently by both sides to the trade, or via a central matching platform such as a confirmation service provider (as long as it s on a CSV file format as describe above). Under ESMA regulations both counterparties to any eligible trade have a reporting obligation. Furthermore the ESMA technical standards make a clear distinction between common data and counterparty data: Counterparty data the details relating to the counterparties to a contract.(annex Table 1 of the ESMA Technical Standards Document) Common data the details pertaining to the derivative contract concluded between the two counterparties. (Annex Table 2 of the ESMA Technical Standards Document) This data distinction, along with the obligation for both counterparties to report a trade gives rise to the following reporting scenarios and delegation models. Both counterparties may independently report both common and counterparty data One party may report both common and counterparty data for both parties (full delegated reporting model). o Under this model it is also possible for the other counterparty to supplement their counterparty data by submitting an independent report using the Position message (please note that the full Position message is required and the latest Position message submitted takes precedence of that side of the UTI) One or both counterparties may delegate reporting responsibility to one or more third parties On cleared trades the counterparties may delegate reporting to the CCP In all cases the counterparty/ccp remains responsible for ensuring that contracts are reported to the registered TR without duplication Fields have been added to the message template to accommodate for these reporting flows. Please note that if a counterparty (Party A) submits a message to OTC Core under the full delegated model and the other party (Party B) submits to OTC Lite independently using the same UTI this will create a dupe to regulators. Copyright by DTCC Deriv/SERV LLC Page 33 of 68

34 4.2 Identifying reporting model The GTR Control Fields Submitted For Prefix and Submitted For Value will identify whether the submission is on behalf of yourself, your counterparty or both parties. A field Reporting Delegation Model has been added to identify the reporting model applicable to each submission. Although not a required field, the Reporting Delegation Model has been included for future use. At present it does not influence processing options as they are based upon the value provided in the Submitted For Prefix and Submitted For Value fields. If submitting on behalf of one party this field must contain the value Independent. If submitting on behalf of both parties this field must contain the value Full. In the case of delegated submissions, GTR will ensure that the submitter has permission to provide data on behalf of the parties to the trade Independent reporting rules If Submitted For Prefix and Submitted For Value identify the submission as being on behalf of the submitter, i.e. Party 1 to the trade, the submission will be treated as an independent submission. In this scenario GTR will expect to receive counterparty data and common data submitted on behalf of only Party 1. The field Reporting Delegation Model must contain the value Independent or be left blank. The only Trade Party 2 data required under this report is the identification of the counterparty. All other Party 2 data contained in the submission it will be ignored, however the Party 1 data will be processed. Under this scenario the other party to the trade will report their data, if obligated, independently. This submission could be to GTR or could be to another TR Full Delegation reporting rules Party1 (or the third party to whom they have delegated reporting responsibility) submits all common data as well as Party1 and Party2 counterparty data. Note that under the full delegation model the reporting party can submit valuation and collateral valuation messages on behalf of either, or both, parties. Alternatively, each party can submit their own valuation and collateral valuation messages. If Submitted For Value identifies the submission as being on behalf of both parties then the submission is expected to contain Party 1 counterparty data, Party 2 counterparty data and common data. Under this scenario: The field Reporting Delegation Model must contain the value Full or be left blank. If some, or all, Party2 counterparty data attributes are NOT supplied, but the submission passes validation for acceptance into the GTR, the validations will generate a warning on the Warning Copyright by DTCC Deriv/SERV LLC Page 34 of 68

35 report identifying missing attributes required under EMIR. The warning report will be available to the parties to the trade, if they are on-boarded as GTR participants. If a Party to the trade wants to update their side of the UTI (possible scenario would be to add further counterparty data) then that Party would be required to submit an Position message for itself (indicate under Submitted For Value) and comply with the validation on the Position message. o As mentioned above please note that all the Counterparty data and Common data must be submitted for that Party so that the UTI for their side of the trade is accurately represented in the GTR. Any common data that is not provided and had previously been submitted will be blank in the GTR. The below chart depicts the above rules: Scenario Submitted By Submitted For Delegation Model Commo n Trade Party 1 fields Trade Party 2 fields Independent Reporting Bank A Bank A Independent Y Y N Independent Reporting Client B Client B Independent Y Y N Independent Reporting Third Party Bank A Independent Y Y N Independent Reporting Third Party Client B Independent Y Y N Full Delegation Bank A Both Full Y Y Y Full Delegation Client B Both Full Y Y Y Full Delegation Third Party Both Full Y Y Y Only Identifier/region of CP will be processed all other information will not be processed if submitted Reporting limitation Submission of subsequent full position messages, either for life-cycle reporting or for end of day reporting, under the full delegation model and on behalf of both parties will overwrite previous submissions causing the Party2 data that was missing from the original submission to be removed. Once again Party2 s trade would be incomplete for EMIR reporting and warning on the Warning report would be provided. Copyright by DTCC Deriv/SERV LLC Page 35 of 68

36 4.2.3 Delegated Reporting Functionality Matrix The below chart shows expected behavior and not necessarily all potential ways a message can be reported. The matrix assumes Counterparty 2 is not permissioned to carry out delegated reporting and can only update its own data. Scenario Resp. per party OTC Lite Common CP1 CP2 1 Independent Reporting Counterparty 1 X Counterparty 2 X 2 Full Delegation Counterparty 1 Counterparty 2 X X X X in a red box: indicates that the GTR does not permit this message submission for the scenario Copyright by DTCC Deriv/SERV LLC Page 36 of 68

37 5. Trade Identification The ability to identify individual trades using a Unique Trade Identifier (UTI) is a key component of EMIR. In all cases the counterparties to a trade, including the CCP in the case of cleared trades, are responsible for ensuring that contracts are reported to a registered trade repository without duplication. This means that both parties, and their agents, must report each trade using a single agreed UTI. The EMIR technical standards do not specify any rules for the generation of the UTI nor any structure, other than that it should contain up to 52 alphanumeric digits. Due to industry demand, the OTC Lite service accepts the following special characters `~!@#$%^&*()_-+= \;:/. in the UTI. 5.1 Introduction of UTI & Principles applied by the GTR for OTC Lite The GTR will ease the pairing of trades and positions by adopting the following approach. 1. The UTI will be universal, with no enforced structure. Its format will be limited to 52 alphanumeric characters as well as the special characters mentioned above (see message template and although the message template supports a UTI Prefix of 40 characters and UTI Value of 200 characters the ESMA defined format should be adhered to in order to comply with the rules). a. Where a UTI Prefix and UTI Value combined exceeds 52 characters a warning on the Warning report will be indicated. 2. After a UTI is agreed, the counterparties are expected to submit the UTI to the GTR.. 3. After a UTI is assigned to a position the UTI value cannot subsequently be modified. 4. Once a UTI is assigned it should be used for any subsequent reference to the given trade. 5. If the UTI needs to be corrected or modified then the message needs to be cancelled (Exit or PositionCancel) and resubmitted with the correct UTI (the actual UTI cannot be modified for a previously reported position). The best practice is to Exit the previous submission and submit the new UTI on a new Position message (indicating the previous UTI in the Prior UTI Value field). 6. The uniqueness of a UTI will be determined based on the combined values of the UTI Prefix and the UTI Value Copyright by DTCC Deriv/SERV LLC Page 37 of 68

38 5.2 Upstream workflow This document defines the specific enhancements necessary to support compliance with EMIR regulations under the existing GTR single submission paradigm ( submit once, report many ). The industry best practices for UTI generation and exchange is not covered in this User Guide. While the upstream workflow necessary to integrate and submit data to the GTR is beyond the scope of this document the following core principles in relation to upstream UTI workflow are complementary to the core GTR trade identifier principles above and are included here for reference: 1. Wherever possible, submitting parties will exchange an UTI upstream of GTR reporting so that when both parties to a trade submit their side of the trade the UTI will be common. Depending upon the timescale for the industry to agree the upstream workflow it may be necessary to enforce the following preliminary rules until such time as a fully flexible solution can be implemented. 1. If the UTI is known this must be submitted to GTR otherwise submit an interim UTI and follow the process on correcting this once the UTI is known. 2. If the UTI is changed subsequently then an exit and re-submit must be used to create the trade with the agreed UTI in GTR a. When an UTI cannot be agreed prior to reporting an interim UTI can be submitted in the UTI field on the position message. When the final UTI is agreed the position would need to be exited and resubmitted with the Prior UTI indicating the value of the interim UTI originally submitted. 3. The UTI must be unique for the trade counterparty pair and asset-class. If the same UTI is submitted subsequently for another Primary Asset Class with the same trade counterparty pair it will be rejected. 5.3 UTI Lock 1. When the first New submission is made for the UTI ( Position or Valuation ), the system will perform the following validations. The below are the general rules when both parties on the trade are KNOWN Participant IDs to the GTR system. a. The system will check if the UTI submitted is unique across the OTC Lite service. If the UTI is NOT present in the service, the system will accept the UTI as valid. Once the UTI is accepted, the Trade Repository assigns the UTI to the Party, Counterparty, Message Type and Asset Class. b. The subsequent submissions for the same UTI cannot modify the Party ID and the Asset Class. The system will allow the modification of the Counterparty ID until the Counterparty submission is received. 2. Once the LOCK has been applied, even if the Party/Counterparty Cancel / Exit the previous records for a given UTI and submit New records for the same UTI with different Counterparty ID, the system will reject the message stating Invalid Submission UTI exists for another Copyright by DTCC Deriv/SERV LLC Page 38 of 68

39 Party/Counterparty. For a given UTI, the Party-Counterparty-Asset Class LOCK will remain the same throughout the lifetime of the OTC Lite service. 3. The LOCK will be applied for a UTI when the Trade has dual submissions submissions done for both the Party side and the Counterparty side. After the party and the counterparty records are received by the Trade Repository, the system will LOCK the UTI UTI Lock Exceptions: 1. The Trade Repository system will LOCK the UTI for a given Party-Counterparty-Asset Class. After submissions from both parties are received by the TR and the LOCK has been applied, the system will NOT allow the User to modify the Party ID, Counterparty ID or the Asset Class. Given below are the few exceptions to the UTI LOCK rules. a. The Trade Repository will allow the modification of Party ID and Counterparty ID if the modified Party ID/Counterparty ID belongs to the same Ultimate Parent. i. For a LOCKED UTI, the GTR system will allow the Participants to modify the Party ID/Counterparty ID, if the modification is within the same Ultimate Parent structure. ii. For example, if the Party ID is Bank A-NY belonging to Ultimate Parent ID Bank A. The TR will allow the Party/Counterparty to modify the Party ID to another Participant ID Bank A-Asia, belonging to the same Bank A Ultimate Parent ID. b. The Trade Repository will allow the submission of Party ID and Counterparty ID if the Party ID/Counterparty ID originally under a different Ultimate Parent/Parent structure got changed to a different Ultimate Parent/Parent Structure. This may happen in case of Firm Reorganization. i. For example, if the Party ID is Bank A-NY belonging to Ultimate Parent ID Bank A. The TR will allow the Party/Counterparty submission if Party ID Bank A-NY moved to another Ultimate Parent ID Bank ANew. c. If initially submitted as an internal or unknown id, you can modify to add an LEI Copyright by DTCC Deriv/SERV LLC Page 39 of 68

40 6. Inter-TR Reconciliation The dual sided reporting obligation that exists under ESMA, coupled with the choice of repository services available to market participants will result in situations where the two parties to a given trade have selected to use different trade repositories in order to discharge their reporting obligations. In the scenario where the GTR holds a single sided position which falls under the remit of the ESMA regulations, ESMA imposes an obligation on the TR to reconcile data with the other repository. An inter-tr interoperability solution has been proposed by a number of the companies, including DTCC, who have applied to become TRs. This proposal is to be reviewed with ESMA and will be fully documented in the Inter-TR Reconciliation and Interoperability BRD. 6.1 Trade Pairing Pairing can only take place where a UTI has been provided. If a UTI is not provided by the two counterparties to the trade, trade sides cannot be paired. Pairing can only take place with other TRs where both counterparties have been reported with an LEI or pre-lei. If the ID of the other counterparty has been populated with anything other than an LEI or pre- LEI, the report can never pair with the other counterparty s report, because they will have used an LEI or pre-lei in their Counterparty ID field. If the ID of the other counterparty is not populated with an LEI or pre-lei, TRs cannot pair and compare the trade. Where both sides of a trade are reported to GTR, pairing will be attempted using UTI, Counterparty ID and ID of the other counterparty regardless of the type of identifier used (i.e. this is not restricted to use of LEIs). The GTR will record the status of each position. The population of trade pairing status values is described in the following table. Trade Pairing Status Exempt N/A Unpaired Unpairable Paired Pairing Error Pair LEI Break Trade Pairing Status Description The position will not require pairing as the Counterparty Region is non-eea. The positions will not require pairing as the Reporting Obligation does not include ESMA. Pairing has either yet to be attempted or that no pair has been located thus far. The position does meet the ESMA reconciliation criteria but does not have mandatory fields required for the Pairing process (such as UTI and LEI s). The Position has been successfully paired either within the GTR or with another TR. When a position has had external Pairing attempted but more than one TR has responded with the same positions details. When a position pair has been found where the UTI and one LEI match but the other LEI does not match. Copyright by DTCC Deriv/SERV LLC Page 40 of 68

41 6.2 Trade Matching The GTR system receives Trade messages and maintains a Paired Status, a Paired Source and a Matched Status for all trades with a Trade Position. Once a trade has been paired a comparison of the two sides of the trade will take place and status of that comparison will be stored. The possible match status of each trade is described in the following table. The fields on which the comparison is based are listed later in this section. It should be noted that this matching process is not relevant to, nor in any way replaces, a participant s confirmation matching processes. Trade Match Status Exempt N/A Pending Cancel Matched Unmatched1 Unmatched2 Unmatched Trade Match Status Description The position will not require matching as Counterparty Region is non-eea. The position will not require matching as Reporting Obligation does not include ESMA. The position has not been paired yet or has been paired but the matching process is yet to take place. The position was previously eligible for matching but a cancellation or exit message has been received. The position has been reconciled and the key category 1 and category 2 fields match within the prescribed tolerance. The position has been reconciled and one or more category 1 fields do not match within the prescribed tolerance but all the category 2 fields do match within the prescribed tolerance. The position has been reconciled and one or more category 2 fields do not match within the prescribed tolerance but all the category 1 fields do match within the prescribed tolerance. The position has been reconciled and one or more category 1 fields do not match within the prescribed tolerance and one or more category 2 fields do not match within the prescribed tolerance Fields and Rules The following data fields are included in trade matching Table 1 Counterparty Data Note that field 8 Unique Trade Id is regarded as a common link between common data fields and counterparty data fields. Field Field Name ESMA Format Match / Tolerance Rule to other trade number 2 Counterparty Id LEI Must match id of the other counterparty 3 ID of the other counterparty LEI Must match id of the counterparty 13 Counterparty side B = buyer, or S = seller Must be S if B and B if S Copyright by DTCC Deriv/SERV LLC Page 41 of 68

42 Table 2 Common Data The fields in this table have been categorized as: 1. The field will be reconciled but if the field does not match for both trade submissions (within the specified tolerance) the trade will be excluded from the aggregated reports produced by the DTCC public reporting team 2. The field will be reconciled but even if the field does not match for both trade submissions (within the specified tolerance) the trade will still be included in the aggregated reports 3. It will not be practical to reconcile the field N/A The field is not applicable for reconciliation purposes In addition, the following tolerance check types will be used in comparison of some fields: 1. Amounts on trades to be compared must be within 1 percent difference. Compare the 1st amount and 2nd amount to be compared to establish the larger amount Subtract smaller amount from larger amount to give amount difference Divide amount difference by larger amount and multiply the result by 100 If the result is greater than 1, then the amounts do not match 2. Amounts on trades to be compared must match to the left of the decimal point. 3. Datetime on trades to be compared must match for the date part of the field. No. Name ESMA Format Match/ Tolerance Rule Category to other trade 1 Taxonomy used Identify the taxonomy used: Must match 1 U=Product Identifier [endorsed in Europe] I=ISIN/AII + CFI E=Interim taxonomy 2 Product id 1 For taxonomy = U: Product Identifier (UPI), to Must match 1 be defined For taxonomy = I: ISIN or AII, 12 digits alphanumerical code For taxonomy = E: Derivative class: CO=Commodity CR=Credit CU=Currency EQ=Equity IR=Interest Rate OT= Other 3 Product id 2 For taxonomy = U: Blank For taxonomy = I: CFI, Must match 1 6 characters alphabetical code For taxonomy = E: Derivative type: CD= Contracts for difference FR= Forward rate agreements FU= Futures FW=Forwards OP=Option SW=Swap OT= Other 4 Underlying ISIN (12 alphanumerical digits); LEI (20 Must match 2 alphanumerical digits); Interim entity identifier (20 alphanumerical digits); UPI (to be defined); B= Basket; I=Index. 5 Notional currency ISO 4217 Currency Code, 3 alphabetical digits. Must match Notional currency ISO 4217 Currency Code, 3 alphabetical digits. Must match Deliverable ISO 4217 Currency Code, 3 alphabetical digits. May not match 3 Copyright by DTCC Deriv/SERV LLC Page 42 of 68

43 No. Name ESMA Format Match/ Tolerance Rule Category to other trade currency 8 Trade id Up to 52 alphanumerical digits. Must match 1 9 Transaction An alphanumeric field up to 40 characters Will never match 3 reference number 10 Venue of ISO Market Identifier Code (MIC), 4 digits Should match 2 execution alphabetical. Where relevant, XOFF for listed derivatives that are traded off-exchange or XXXX for OTC derivatives. 11 Compression Y = if the contract results from compression; N= Should match 2 if the contract does not result from compression. 12 Price/rate Up to 20 numerical digits in the format xxxx,yyyyy. Apply tolerance check Price notation E.g. ISO 4217 Currency Code, 3 alphabetical Must match 2 digits, percentage. 14 Notional amount Up to 20 numerical digits in the format Apply tolerance check 2 1 xxxx,yyyyy. 15 Price multiplier Up to 10 numerical digits. Must match 1 16 Quantity Up to 10 numerical digits. Must match 1 17 Up-front payment Up to 10 numerical digits in the format Apply tolerance check 1 2 xxxx,yyyyy for payments made by the reporting counterparty and in the format xxxx,yyyyy for payments received by the reporting counterparty. 18 Delivery type C=Cash, P=Physical, O=Optional for Must match 2 counterparty. 19 Execution ISO 8601 date format / UTC time format. Apply tolerance check 3 2 timestamp for OTC. 20 Effective date ISO 8601 date format. Must match 2 21 Maturity date ISO 8601 date format. Must match 1 22 Termination date ISO 8601 date format. Must match 2 23 Date of ISO 8601 date format. Cannot match 3 settlement 24 Master Free Text, field of up to 50 characters, Cannot match 3 agreement type identifying the name of the Master Agreement used, if any. 25 Master Year, xxxx. Cannot match 3 agreement version 26 Confirmation ISO 8601 date format, UTC time format. Apply tolerance check 3 2 timestamp 27 Confirmation Y=Non-electronically confirmed, N=Nonconfirmed, Should match 2 means E=Electronically confirmed. 28 Clearing obligation Y=Yes, N=No. Must match 2 Copyright by DTCC Deriv/SERV LLC Page 43 of 68

44 No. Name ESMA Format Match/ Tolerance Rule Category to other trade 29 Cleared Y=Yes, N=No. Must match 1 30 Clearing ISO 8601 date format, UTC time format. Apply tolerance check 3 2 timestamp 31 CCP Legal Entity Identifier (LEI) (20 alphanumerical Must match 2 digits) or, if not available, interim entity identifier (20 alphanumerical digits) or, if not available, BIC (11 alphanumerical digits). 32 Intragroup Y=Yes, N=No. Should match 2 33 Fixed rate leg 1 Numerical digits in the format xxxx,yyyyy. Apply tolerance check 1 2 (tolerance tba) 34 Fixed rate leg 2 Numerical digits in the format xxxx,yyyyy. Apply tolerance check 1 2 (tolerance tba) 35 Fixed rate day Actual/365, 30B/360 or Other. Cannot match 3 count 36 Fixed leg payment frequency An integer multiplier of a time period describing how often the counterparties exchange payments, e.g. 10D, 3M, 5Y. Cannot match 3 37 Floating leg payment frequency 38 Floating leg reset frequency An integer multiplier of a time period describing how often the counterparties exchange payments, e.g. 10D, 3M, 5Y. An integer multiplier of a time period describing how often the counterparties exchange payments, e.g. 10D, 3M, 5Y. The name of the floating rate index, e.g. 3M Euribor. The name of the floating rate index, e.g. 3M Euribor. Cannot match 3 Cannot match 3 39 Floating rate of leg 1 Cannot match 3 40 Floating rate of Cannot match 3 leg 2 41 Currency 2 ISO 4217 Currency Code, 3 alphabetical digits. Must match 2 42 Exchange rate 1 Up to 10 numerical digits in the format Must match 2 xxxx,yyyyy. 43 Forward exchange rate 44 Exchange rate basis Up to 10 numerical digits in the format xxxx,yyyyy. E.g. EUR/USD or USD/EUR. 2 X ISO 4217 Currency Code, 3 alphabetical digits separated by a slash. Tolerance check 1 will be applied Must match Tolerance check 1 will be applied Must match 2 45 Commodity Base AG=Agricultural Should match 2 EN=Energy FR=Freights ME=Metals IN= Index EV= Environmental EX= Exotic 46 Commodity AG=Agricultural Should match 2 Copyright by DTCC Deriv/SERV LLC Page 44 of 68 2

45 No. Name ESMA Format Match/ Tolerance Rule Category to other trade Details EN=Energy FR=Freights ME=Metals IN= Index EV= Environmental EX= Exotic 47 Delivery Point or EIC code, 16 character alphanumeric code. Must match 2 zone (energy) 48 Interconnection Free text, field of up to 50 characters. Cannot match 3 point (energy) 49 Load Type Repeatable section of fields to identify Must match 2 (energy) the product delivery profile; BL=Base Load PL=Peak Load OP=Off-Peak BH= Block Hours OT=Other 50 Delivery start ISO 8601 date format. Must match 2 date time (energy) 51 Delivery end date ISO 8601 date format. Must match 2 time (energy) 52 Contract Capacity Free text, field of up to 50 characters. Cannot match 3 (energy) 53 Quantity Unit 10 numerical digits in the format xxxx,yyyyy. Apply tolerance check 1 1 (energy) 54 Price/time 10 numerical digits in the format xxxx,yyyyy. Apply tolerance check 1 2 interval quantities (energy) 55 Option type P=Put, C=Call. Must match 2 56 Option style A=American, B=Bermudan, E=European, Must match 2 S=Asian. 57 Strike price Up to 10 Numerical digits in the format xxxx,yyyyy. Apply tolerance check Action type and details of action type 3 Copyright by DTCC Deriv/SERV LLC Page 45 of 68

46 7. Participant Reporting The GTR reports as detailed below provide information on the status of submitted trades and full trade details. The OTC Lite service has a limited set of participant reports. If a participant has been fully onboarded via the manual onboarding process all reports are automatically generated and available for download via the GUI by default (If a participant has been onboarded via the internet onboarding process then the data in the ESMA Activity and Position report will be available via search and download only through the portal). Unless otherwise stated below, all reports are downloadable in CSV format via the Report Download function in the GTR System or via Secure FTP. The reports are automatically generated Monday to Friday starting midnight UTC in the EUDC and will be available on the web GUI for 7 Calendar Days. It should be noted that the GTR participants position reports reflect the current state of the trades reported by them, on their behalf or where they are the counterparty. They do not reflect aggregated positions across multiple trade states. All of our standard report headers contain both the business date for which the report was generated and also the actual date that the report ran. Having this information stated on all reporting output provides customers the information needed to enable them to ensure that they use the latest reports available. 7.1 Downloading Reports off the Portal The below screenshots will show how to download reports off the portal. Users will have to sign into the portal (Section 1.6) and then upload a CSV spreadsheet (Section 2.1) to be able to download reports. To access the ACK/NACK Reports 1. Once logged into the OTC Lite Portal, click on Download Copyright by DTCC Deriv/SERV LLC Page 46 of 68

47 2. Once the Download button is clicked, the screen below will open up with the latest ACK Reports 3. To retrieve the NACK Reports click on the OTC-NACK tab 4. Afterwards check off the reports to download and then hit the Download button to download a ZIP file 7.2 Reports available for all Asset Classes The following list of reports is produced by all of the asset classes. 1 No. Report Report Description ACK/NACK Report /Spreadsheet Download Report (Upload Status Report) 2 Warning Report 3 GTR ESMA OTC Position Report 4 GTR ESMA OTC Activity Report The ACK or NACK output report will be a real-time report indicating status of each message submitted. ACK report will include all accepted messages and NACK report will include all rejected messages. The warning report highlights warnings of issues that may indicate the message is not compliant for regulator reporting even if the GTR accepted the message. Includes the latest Position for all open UTI s that are reported to ESMA. The report will contain only the ESMA reportable fields from Counterparty Data (Table 1) and Common Data (Table 2). All alleges will be included regardless of what service the UTI was reported through. Includes all successfully processed submissions into the GTR since the last report generation for all UTI s that are reported to ESMA. The report will contain only the ESMA reportable fields from Counterparty Data (Table 1) and Common Data (Table 2). All alleges will be included regardless of what service the UTI was reported through. Copyright by DTCC Deriv/SERV LLC Page 47 of 68