DTCC GTR Otc Lite

DTCC Product Management GTR OTC Lite User Guide
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
DTCC GTR OTC Lite User Copyright 2010-2013 by DTCC Deriv/SERV LLC Page 1 of 68
Guide v0.6
1. Overview ............................................................................................................................................... 7
1.1 Introduction .................................................................................................................................. 7
1.2 GTR Document Portal ................................................................................................................... 7
1.3 Global Processing Overview ........................................................................................................ 10
1.3.1 File Input ............................................................................................................................. 10
1.4 GTR Connectivity ......................................................................................................................... 10
1.4.1 Data Center Access and Security......................................................................................... 11
1.5 GTR Entitlements ........................................................................................................................ 11
1.5.1 Web GUI Entitlement .......................................................................................................... 11
1.5.2 Secure FTP Entitlement ....................................................................................................... 12
1.6 GTR Sign on Process .................................................................................................................... 13
2. Trade submission ................................................................................................................................ 14
2.1 GTR Upload Process .................................................................................................................... 14
2.2 OTC Lite Cross Asset Messaging .............................................................................................. 16
2.2.1 OTC Lite Message Template ............................................................................................ 16
2.2.2 Valuation and Collateral Reporting ..................................................................................... 16
2.2.3 GTR CSV File Footer Message ............................................................................................. 16
2.3 GTR Batch Cut-off Requirements ................................................................................................ 18
2.4 Message Usage ........................................................................................................................... 18
2.4.1 Reporting a New Trade ....................................................................................................... 18
2.4.2 Reporting a Post Trade Event.............................................................................................. 19
2.4.3 Reporting a Trade Exit ......................................................................................................... 19
2.5 Lifecycle Event Reporting ............................................................................................................ 20
2.5.1 Correcting Life Cycle Events ................................................................................................ 20
The following table summarizes the events supported by the GTR. .................................................. 22
2.6 Message Workflows .................................................................................................................... 23
2.6.1 DIAGRAM 1 ......................................................................................................................... 24
2.6.2 DIAGRAM 2 ......................................................................................................................... 25
2.6.3 DIAGRAM 3 ......................................................................................................................... 26
Guide v0.6
2.6.4 DIAGRAM 4 ......................................................................................................................... 27

2.6.5 DIAGRAM 5 ......................................................................................................................... 28
2.6.6 DIAGRAM 6 ......................................................................................................................... 29
3. Message Validation ............................................................................................................................. 30
3.1 Validation Stages......................................................................................................................... 30
3.2 Business validation...................................................................................................................... 30
3.3 ESMA Regulatory validation ........................................................................................................ 30
3.4 Response Messages .................................................................................................................... 31
3.4.1 CSV-Batch Download Report (Spreadsheet Download Report).......................................... 31
3.5 End-of-Day Warning Report ........................................................................................................ 31
3.5.1 Generation Rules................................................................................................................. 32
4. Dual-sided reporting ........................................................................................................................... 33
4.1 Introduction ................................................................................................................................ 33
4.2 Identifying reporting model ........................................................................................................ 34
4.2.1 Independent reporting rules ............................................................................................... 34
4.2.2 Full Delegation reporting rules ........................................................................................... 34
4.2.3 Delegated Reporting Functionality Matrix.......................................................................... 36
5. Trade Identification............................................................................................................................. 37
5.1 Introduction of UTI & Principles applied by the GTR for OTC Lite........................................... 37
5.2 Upstream workflow .................................................................................................................... 38
5.3 UTI Lock ....................................................................................................................................... 38
5.3.1 UTI Lock Exceptions: ........................................................................................................... 39
6. Inter-TR Reconciliation........................................................................................................................ 40
6.1 Trade Pairing ............................................................................................................................... 40
6.2 Trade Matching ........................................................................................................................... 41
6.2.1 Fields and Rules................................................................................................................... 41
7. Participant Reporting .......................................................................................................................... 46
7.1 Downloading Reports off the Portal ........................................................................................... 46
7.2 Reports available for all Asset Classes ........................................................................................ 47
7.2.1 ACK/NACK ........................................................................................................................... 48
Guide v0.6
7.2.2 Warning Report ................................................................................................................... 49

7.2.3 GTR ESMA OTC Position Report .......................................................................................... 51
7.2.4 GTR ESMA OTC Activity Report ........................................................................................... 55
7.2.5 ESMA Match Status Report ................................................................................................. 56
7.2.6 ESMA UTI Conflict or Pair LEI Break Report ........................................................................ 58
8. Appendix A Useful Links ................................................................................................................... 59
8.1 Regulatory Background ............................................................................................................... 59
8.1.1 ESMA Final Draft Technical Standards ................................................................................ 59
8.1.2 Summary of the ESMA Technical Standards ....................................................................... 59
8.1.3 EMIR vs. DFA Comparison ................................................................................................... 59
8.1.4 ESMA Questions and Answers ............................................................................................ 59
8.1.5 ISDAs Guidance on Price Notation ..................................................................................... 59
8.2 Business Requirements Document ............................................................................................. 59
8.3 CSV Upload Template ................................................................................................................. 59
8.4 OTC Lite Presentations and Videos ............................................................................................. 60
8.5 ISDA Taxonomy ........................................................................................................................... 60
8.6 International sFTP Transmission Guide v1.0 ............................................................................... 60
8.7 Contact List for OTC Lite ............................................................................................................. 60
9. Appendix B Frequently Asked Questions (FAQs) ............................................................................. 61
9.1 What is the geographic and jurisdictional scope of OTC Lite?.................................................... 61
9.2 Who is able to use the OTC Lite service? .................................................................................... 61
9.3 Is it possible to send multiple files in one day as in one file per trade? ..................................... 62
9.4 Which Optional fields need to be filled out? ............................................................................ 62
9.5 Does the field Trade Party 2 need to be filled out when a party is submitting under
independent delegation? ........................................................................................................................ 63
9.6 How can I submit structured or exotic products? ...................................................................... 63
9.7 What is DTCCs system operating schedule? .............................................................................. 63
10. Appendix C DTCC Best Practice for Uploading ............................................................................. 64
10.1 Cross Asset Guidance .................................................................................................................. 64
10.2 Technical Guidance ..................................................................................................................... 65
Guide v0.6
10.3 Valid Values ................................................................................................................................. 65

10.4 Interest Rates .............................................................................................................................. 66
10.5 Commodities ............................................................................................................................... 66
10.6 Foreign Exchange ........................................................................................................................ 67
Revision History
Version Date Revision
V0.1 October 30, 2013 Initial Draft
V0.2 November 30, Revisions
2013 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 2.2.1 GTR CSV File Footer Message
Added 2.5.1 Correcting Life Cycle Events
Updated 3.5 EOD Warning Report
Added 6 Inter-TR Reconciliation (Includes Trade Pairing and Trade
Matching)
Updated 7.2.2 with Warning Error Codes
Added 7.2.5 ESMA Match Status Report
Added 7.2.6 ESMA UTI Conflict or Pair LEI Break Report
Added 8.1.4 ESMA Q&A Link
Added 8.1.5 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 1.5.1 Web GUI Entitlement
Updated 2.4 Message Usage
Updated 3.3 ESMA Regulatory Validation
Updated 4.2.3 Delegated Reporting Functionality Matrix
Updated 5 Trade Identification
Updated 5.2 Upstream Workflow
Updated 7.2.2 Warning Report
Updated 7.2.3 GTR ESMA OTC Position Report
Updated 7.2.5 ESMA Match Status Report
Updated 7.2.6 ESMA UTI Conflict or Pair Break Report
Updated 8.7 Contact List for OTC Lite
Guide v0.6
Guide v0.6
1. Overview
1.1 Introduction
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.2 GTR 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.
http://dtcc.com/data-and-repository-services/global-trade-repository/gtr-europe/client-center.aspx
Please reach out to your relationship manager to retrieve login information.
Guide v0.6
Guide v0.6
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.
Guide v0.6
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.
1.3.1 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
Guide v0.6
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.
1.4.1.1 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.
1.5 GTR Entitlements
1.5.1 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 firms access
coordinator to assign access rights for the web GUI to users within their firm.
Participant and regulator roles are defined in the GTR.
Guide v0.6
1.5.1.1 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.
1.5.1.2 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.
1.5.2 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 DTCCs
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.
Guide v0.6
1.6 GTR Sign on Process

The below screenshots depict how to login to OTC Lite.
1. Go to https://gtr.eu.dtcc.com
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.
Guide v0.6
2. Trade submission
2.1 GTR Upload Process

The below screenshots depict how to manually upload CSV files into the system.
1. Go to: http://dtcc.com/data-and-repository-services/global-trade-repository/gtr-europe/client-
center/client-center.aspx?gated=customers
Contact GTR_Onboarding@dtcc.com 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.
Guide v0.6
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 firms 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
Guide v0.6
2.2 OTC Lite Cross Asset Messaging

The following message types are supported by the OTC Lite service for all asset classes.
Message Type Description

Position 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)
Valuation* Used to report the current valuation (market value) of the trade. The valuation is submitted on a
daily basis for the reportable trades.
Collateral Used to report portfolios of collateral that can be linked to individual transactions.
Valuation*
*Have a compliance date of August 11th 2014
2.2.1 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 scenarios 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
2.2.2 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.
2.2.3 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
Guide v0.6
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-END00054321
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.
00054321 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
*DTC0-END00000004
By way of example, when preparing your sFTP file the following format should be followed:
DataTrak Header
Application Header
*Comment Line
*DTC0-END00000004
DataTrak Trailer
Guide v0.6
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 Lifecycle ESMA

Type Event Action
All Any* New PositionCancel N/A Error
*Any refers to any message type and transaction type where Cancel applies
2.4.1 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
Guide v0.6
* 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
2.4.2 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 Action Transaction Lifecycle Event ESMA Action

Type Type
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.
2.4.3 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
Guide v0.6
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 trades 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.
2.5.1 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
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
Guide v0.6
Guide v0.6
The following table summarizes the events supported by the GTR.

Business Event Lifecycle Event
Trade
New Trade New
Amendment Amendment
Backload Backload
Compression
Termination (for all asset class)
PartialTermination (Credit)
Termination resulting from compression
(with compressed flag indicator true)
Amendment (Rates and Commodity)
(with compressed flag indicator true)
Exercise (Full)~ Exercise
Exercise (Partial) PartialExercise (FX)
Increase
Increase
Amendment (Rates)
Novation
Novation Full (Stepping out & remaining parties)~
Termination (Rates)
Novation
Novation Partial (Stepping out & remaining parties)
Termination (Rates)
Novation-Trade
Novation (Stepping in & remaining parties)
NovationTrade
PartialTermination (Credit)
Termination Full~
Termination
PartialTermination (Credit and FX)
Termination Partial
Termination (Rates, Equity, Commodity)
Valuation Update N/A
Cancel
Global Cancel (Withdrawing the trade)
Error
Exit or AutoExit Exit
Corporate Action CorporateAction (Equity)
Fee Amendment Amendment
Termination
Credit Event Exit
Modify
Cancel
Error
Guide v0.6
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 1 4 6
Full Delegation 3 2 5
Guide v0.6
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. 1
4. Party A submits a Position message to GTR on its own behalf. Party A Party B
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.
2,3 2,3
7. Party A sends a Valuation message
8. GTR sends an ACK to Party A Middleware 6,12,14
9. Party A sends a Collateral message
10. GTR sends an ACK back to Party A 5,11,13
6,8,10 4,7,9
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
TR
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)
Guide v0.6
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. Party A Party B
2. Parties send the trade to the middleware platform. 6
3. The middleware generates UTI and acknowledges trade with UTI.
4. Party A submits Position message to TR on behalf of both parties 2,3 2,3
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
5,9,11,13 7 7
8. Party A submits Position message indicating Amendment to the GTR Middleware 15,17
9. GTR sends an ACK back to Party A
10. Party A sends a Valuation message 4,8,10,12 14,16
11. GTR sends an ACK to Party A
12. Party A sends a Collateral message
14. Party B sends a Valuation message
TR
16. Party B sends a Collateral message
17. GTR sends an ACK back to Party B
Guide v0.6
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
6. Party A sends Collateral and Valuation message to GTR
7. GTR sends an ACK message back to Party A
1
Party A Party B
2, 4, 6
3, 5, 7
TR
Guide v0.6
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.
5. Party B sends Position message to TR on behalf of itself.
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
Guide v0.6
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.
5. Party A reports Valuation message and Collateral message on ongoing basis.
6. Party B reports Valuation message and Collateral message on ongoing basis.
1, 2 1, 2
Party A Execution Platform Party B
3, 4, 5 6
TR
Guide v0.6
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
2, 3 2, 3
Middleware
7 Trade Y
7 Trade Z
6, 8
4, 10 5, 11
9 Trade Y
TR CCP
9 Trade Z
Guide v0.6
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 GTR Business

GTR Core Validation
Validation Validation
Permission, UTI lock,

Is CSV valid? Are fields e.g. Does the post-trade
transaction & action type
formatted correctly? CCY = the position CCY?
consistency validation.
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
Guide v0.6
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.
3.4.1 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 Description

This status indicates that the GTR Core validation, GTR business validations
ACCEPT 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
REJECT 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 partys responsibility to ensure that they are
fully compliant for reporting to ESMA.
Guide v0.6
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-days warning report generation will be validated
for any exceptions and reported in the subsequent days 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
Guide v0.6
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 UTIs 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 its 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.
Guide v0.6
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.
4.2.1 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.
4.2.2 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
Guide v0.6
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:
Submitted Submitted Delegation Commo Trade Party 1 Trade Party 2

Scenario
By For Model n fields fields
Independent
Bank A Bank A Independent Y Y N
Reporting
Independent
Client B Client B Independent Y Y N
Reporting
Independent
Third Party Bank A Independent Y Y N
Reporting
Independent
Third Party Client B Independent Y Y N
Reporting
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
4.2.2.1 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 Party2s trade would be incomplete for EMIR reporting and warning on the Warning report would
be provided.
Guide v0.6
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.
OTC Lite
Resp. per
Scenario Common CP1 CP2
party
Counterparty 1 X
Independent
1
Reporting
Counterparty 2 X
Counterparty 1
2 Full Delegation
Counterparty 2 X X X
X in a red box: indicates that the GTR does not permit this message submission for the scenario
Guide v0.6
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
Guide v0.6
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
Guide v0.6
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
5.3.1 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
Guide v0.6
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 counterpartys 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 Trade Pairing Status Description

Exempt The position will not require pairing as the Counterparty Region is non-EEA.
N/A The positions will not require pairing as the Reporting Obligation does not include ESMA.
Unpaired Pairing has either yet to be attempted or that no pair has been located thus far.
Unpairable The position does meet the ESMA reconciliation criteria but does not have mandatory
fields required for the Pairing process (such as UTI and LEIs).
Paired The Position has been successfully paired either within the GTR or with another TR.
Pairing Error When a position has had external Pairing attempted but more than one TR has responded
with the same positions details.
Pair LEI Break When a position pair has been found where the UTI and one LEI match but the other LEI
does not match.
Guide v0.6
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 participants confirmation matching processes.
Trade Match Status Trade Match Status Description

Exempt The position will not require matching as Counterparty Region is non-EEA.
N/A The position will not require matching as Reporting Obligation does not include ESMA.
Pending The position has not been paired yet or has been paired but the matching process is yet to
take place.
Cancel The position was previously eligible for matching but a cancellation or exit message has
been received.
Matched The position has been reconciled and the key category 1 and category 2 fields match
within the prescribed tolerance.
Unmatched1 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.
Unmatched2 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.
Unmatched 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.
6.2.1 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 Must be S if B and B if S
S = seller
Guide v0.6
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 1
1
6 Notional currency ISO 4217 Currency Code, 3 alphabetical digits. Must match 1
2
7 Deliverable ISO 4217 Currency Code, 3 alphabetical digits. May not match 3
Guide v0.6

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 10383 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 Apply tolerance check 1 2
xxxx,yyyyy.
13 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=Non- Should match 2
means confirmed, E=Electronically confirmed.
28 Clearing Y=Yes, N=No. Must match 2
obligation
Guide v0.6

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 An integer multiplier of a time period describing Cannot match 3
frequency how often the counterparties exchange
payments, e.g. 10D, 3M, 5Y.
37 Floating leg An integer multiplier of a time period describing Cannot match 3
payment how often the counterparties exchange
frequency payments, e.g. 10D, 3M, 5Y.
38 Floating leg reset An integer multiplier of a time period describing Cannot match 3
frequency how often the counterparties exchange
payments, e.g. 10D, 3M, 5Y.
39 Floating rate of The name of the floating rate index, e.g. 3M Cannot match 3
leg 1 Euribor.
40 Floating rate of The name of the floating rate index, e.g. 3M Cannot match 3
leg 2 Euribor.
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.
Tolerance check 1 will
be applied
43 Forward Up to 10 numerical digits in the format Must match 2
exchange rate xxxx,yyyyy.
Tolerance check 1 will
be applied
44 Exchange rate E.g. EUR/USD or USD/EUR. 2 X ISO 4217 Must match 2
basis Currency Code, 3 alphabetical digits separated
by a slash.
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
Guide v0.6

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 50-54 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 Apply tolerance check 2 2
xxxx,yyyyy.
58 Action type and 3
59 details of action
type
Guide v0.6
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
Guide v0.6
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.
No. Report Report Description
The ACK or NACK output report will be a real-time report

ACK/NACK Report
indicating status of each message submitted. ACK report will
1 /Spreadsheet Download Report
include all accepted messages and NACK report will include all
(Upload Status Report)
rejected messages.
The warning report highlights warnings of issues that may
2 Warning Report indicate the message is not compliant for regulator reporting
even if the GTR accepted the message.
Includes the latest Position for all open UTIs that are reported to
ESMA. The report will contain only the ESMA reportable fields
3 GTR ESMA OTC Position Report 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 UTIs that are reported to ESMA.
The report will contain only the ESMA reportable fields from
4 GTR ESMA OTC Activity Report
Counterparty Data (Table 1) and Common Data (Table 2). All
alleges will be included regardless of what service the UTI was
reported through.
Guide v0.6
No. Report Report Description
Reports of the pairing and match status by UTI. Any unmatched

5 ESMA Match Status Report
fields are listed.
UTI Conflict and Pair Break LEI List of all trades where the LEI pair submitted is different for each
6
Report trade submission for the same UTI.
7.2.1 ACK/NACK
The ACK or NACK Report (Spreadsheet download report) will include all Trade Repository submissions
successfully processed, or rejected for the CSV submissions done through Web GUI or Secure FTP.
Field list for the ACK output report:

No. Field Name Sample Data Description
1 Action New Action will indicate if the incoming message is 'New', 'Modify'
or 'Cancel'
2 Transaction Type Trade Transaction Type as defined in the upload template
3 Message Type Position Message Type on the submissions
4 UTI Prefix IssuerA Prefix for UTI
5 UTI Value UTI123 Unique Trade Identifier;
UTI Value of the Submission
6 Asset Class Equity The Primary Asset Class
7 Product ID Prefix 1 ISDA The First Product Identifier prefix
8 Product ID Value 1 Equity:Swap:Pri The First Product Identifier value
ceReturnBasicP
erformance:Sin
gleName
9 Product ID Prefix 2 The Second Product Identifier prefix
10 Product ID Value 2 The Second Product Identifier value
11 Execution Timestamp 2012-02- The time and date of execution of the transaction in
09T15:25:00Z Coordinated Universal Time (UTC).
(YYYY-MM-DDTHH:MM:SSZ)
12 Data Submitter Prefix LEI Submitting Party ID Prefix
13 Data Submitter Value 5678 Submitting Party ID Value

14 Trade Party 1 Prefix LEI The First Counterparty prefix
15 Trade Party 1 5678 The First Counterparty Value
Value
16 Trade Party 2 Prefix LEI The Second Counterparty prefix
17 Trade Party 2 3214 The Second Counterparty Value
Value
18 Transaction Reference 123456 EMIR Specific field
Number
19 Internal Trade Reference Adft56687 Internal Trade Reference Number of either party
20 Reporting Obligation ESMA Jurisdictions where trade is reportable
Party 1
Guide v0.6
21 Reporting Obligation ESMA Jurisdictions where trade is reportable

Party 2
22 Data Submitter Message CSV123 Reference provided by the submitting firm on each message
ID within the CSV file
23 Submission Date & Time 2012-03- Submission Date and Time in UTC format. This is the time the
27T11:25:00Z submission was received by GTR.
( YYYY-MM-DDTHH:MM:SSZ )
24 Status ACCEPTED The Status of the message in GTR.
The NACK output report will include all the data fields submitted in the CSV submission file AND will add
in front of each row 3 additional fields:
Submission Date & Time

Status
Error Code / Reason
7.2.2 Warning Report

The objective of the report will be to highlight the possible issues with a message if it is deemed not
compliant due to missing information in the existing submissions in the GTR (submissions accepted by
the GTR) e.g. reported on behalf of both parties but Trade Party 2 Domicile is blank. All positions on the
Warning Report will be reported to ESMA.
The Warning Report will be available to the trade parties of the submission if Submitted for Value =
Both.
Field List:
1 UTI Prefix XXX Identify a prefix for the UTI (placeholder)

2 UTI Value 123 UTI assigned to the submission
3 Primary Asset Class Equity Asset class for the submission
4 Product ID Prefix 1 ISDA Indicates the taxonomy of the product used (ISDA preferred)
5 Product ID Value 1 Equity:Swap:Pri Product Value as specified by ISDA taxonomy
ceReturnBasicP
erformance:Sin
gleName
6 Product ID Prefix 2
7 Product ID Value 2
8 Data Submitter Prefix LEI Prefix of identifier of party submitting the trade
9 Data Submitter Value 5678 Value of identifier of party submitting the trade
10 Submitted For Prefix LEI Prefix of identifier of party on behalf of which the submission
is made
11 Submitted For Value 5678 Value of identifier of party on behalf of which the submission
is made
Guide v0.6
12 Submission Date/Time 2012-03- When the submission to the GTR was processed
26T09:10:10Z
13 Trade Party 1 Prefix LEI Prefix of identifier for the first party named as a counterparty
on the trade
14 Trade Party 1 Value 5678 Prefix of identifier for the first party named as a counterparty
on the trade
15 Trade Party 1 Name Bank A Derived from Prefix/Value combination
16 Trade Party 1 Notional 100000 Notional reported by party 1
17 Trade Party 1 Notional USD Currency for the notional reported by party 1
Currency/Units
18 Trade Party 2 Prefix LEI Prefix of identifier for the second party named as a
counterparty on the trade
19 Trade Party 2 Value 3214 Prefix of identifier for the second party names as a
counterparty on the trade
20 Trade Party 2 Name Bank B Derived from Prefix/Value combination
21 Trade Party 2 Notional 100000 Notional reported by party 2
22 Trade Party 2 Notional USD Currency for the notional reported by party 2
Currency/Units
23 Transaction Reference 1323423 EMIR specific field
Number
24 Internal Trade Reference T98765
25 Data Submitter Message CSV789 Reference provided by the submitting firm on each message
ID within the CSV file
26 Warning Reason Code 12 Reason code for the warning
27 Warning Description Unknown Reason description for the warning
Counterparty
Below is a list of the warnings and their descriptions:

Error Code Error Description
OTLW1001 Reporting Obligation Party 2 is required when reporting on behalf of both counterparties
OTLW1002 Trade Party 2 Domicile is required when reporting on behalf of both counterparties
OTLW1003 Trading capacity Party 2 is required when reporting on behalf of both counterparties
OTLW1004 Buyer Value Party 2 is required when reporting on behalf of both counterparties
OTLW1005 Trade Party 2 Financial Entity Jurisdiction or Trade Party 2 Non-financial Entity Jurisdiction is required
when reporting on behalf of both counterparties
OTLW1006 MTM Currency Party 2 is required when reporting on behalf of both counterparties
OTLW1007 Valuation Datetime Party 2 is required when reporting on behalf of both counterparties
OTLW1008 Valuation Type Party 2 is required when reporting on behalf of both counterparties
OTLW1009 Trade Party 2 Corporate Sector is required when Trade Party 2 Financial Entity Jurisdiction is blank and
Trade Party 2 Non-financial Entity Jurisdiction is blank
OTLW1010 Trade Party 2 Corporate Sector is required when Trade Party 2 Financial Entity Jurisdiction is "ESMA"
OTLW1011 The Directly linked to commercial activity or treasury financing Party 2 is required to be populated if
Party 2 is a non-financial entity
OTLW1012 Clearing Broker Party 2 Value is required when the trade is cleared
OTLW1013 Beneficiary ID Party 2 Value is required for Trade Party 2 when reporting on behalf of both
counterparties and trading capacity is Agent
Guide v0.6
Error Code Error Description

OTLW1014 Clearing Threshold Party 2 is required when Trade Party 2 Non-financial Entity Jurisdiction is "ESMA"
OTLW1015 UTI is greater than 52 characters
OTLW1016 Counterparty Region is required for ESMA reporting (Trade with non-EEA counterparty)
OTLW1017 Clearing Broker Party 1 is required when the trade is cleared
OTLW1018 Settlement Currency is required for ESMA reporting
OTLW1019 Execution Venue Value is required for ESMA reporting
OTLW1020 Price Notation - Price is required for ESMA reporting
OTLW1021 Price Notation - Price Type is required for ESMA reporting
OTLW1022 Delivery type is required for ESMA reporting
OTLW1023 Execution Timestamp is required for ESMA reporting
OTLW1024 Effective Date is required field for ESMA reporting
OTLW1025 Date of Settlement is required for ESMA reporting
OTLW1026 Clearing Timestamp is required for ESMA reporting
OTLW1027 Clearing DCO Value is required for ESMA reporting
OTLW1028 Clearing Threshold Party 1 is required for ESMA reporting
OTLW1029 MTM Currency CCP is required
OTLW1030 Valuation Datetime CCP is required
OTLW1031 Valuation Type CCP is required
7.2.3 GTR ESMA OTC Position Report

The report will reflect all open positions for the participant that are open in the EU Trade Repository.
Those positions with a Reporting Obligation of ESMA are reported to ESMA. The format of the report
will indicate the ESMA fields and the data reported against each of those fields. All alleges will be
reflected on the report (where the participant has been named as a trade party to a UTI reported by
another counterparty). No additional information will be provided on the report.
The ESMA Position Report will include those trades where the report recipient is named as a
counterparty to the trade or is named as the execution agent.
Field List:
ESMA EMIR Field ESMA Table reference GTR FIELD MAPPING
Table #
1 Reporting timestamp Table 1 - Counterparty Data Derived
Trade Party 1 Prefix GTR Control field
Trade Party 1 Value GTR Control field
2 Counterparty ID Table 1 - Counterparty Data Trade Party 1 Prefix,
Trade Party 1 Value
4 Name of the counterparty Table 1 - Counterparty Data Derived or Provided - Name of Trade Party 1
Trade Party 1 Prefix GTR Control field
Trade Party 1 Value GTR Control field
3 ID of the other Counterparty Table 1 - Counterparty Data Trade Party 2 Prefix,
Trade Party 2 Value
4b Name of the other counterparty Table 1 - Counterparty Data Derived or Provided - Name of Trade Party 2
Trade Party 1 Branch Location GTR Control field
Guide v0.6

Table #
Trade Party 2 Branch Location GTR Control field
5 Domicile of the counterparty Table 1 - Counterparty Data Trade Party 1 Domicile
6 Corporate sector of the counterparty Table 1 - Counterparty Data Trade Party 1 Corporate Sector
7 Financial or non-financial nature of Table 1 - Counterparty Data Trade Party 1 Financial Entity Jurisdiction,
the counterparty Trade Party 1 Non-financial Entity Jurisdiction
Broker Id Party 1 Prefix GTR Control field
Broker Id Party 2 Prefix GTR Control field
8 Broker ID Table 1 - Counterparty Data Broker Id Party 1 Prefix,
Broker Id Party 1 Value
Party 1 Reporting Obligation GTR Control field
Reporting Jurisdiction GTR Control field
Data Submitter Prefix GTR Control field
Data Submitter Value GTR Control field
9 Reporting entity ID Table 1 - Counterparty Data Data Submitter Prefix,
Data Submitter Value
Clearing Broker Party 1 Prefix GTR Control field
Clearing Broker Party 1 Value GTR Control field
10 Clearing member ID Table 1 - Counterparty Data Clearing Broker Party 1 Prefix,
Clearing Broker Party 1 Value,
Beneficiary ID Party 1 Prefix GTR Control field
Beneficiary ID Party 1 Value GTR Control field
11 Beneficiary ID Table 1 - Counterparty Data Beneficiary ID Party 1 Prefix,
Beneficiary ID Party 1 Value
Execution Agent Party 1 Prefix GTR Control field
Execution Agent Party 1 Value GTR Control field
12 Trading capacity Table 1 - Counterparty Data Trading capacity Party 1
13 Counterparty side Table 1 - Counterparty Data Buyer Prefix (Party 1), Buyer Value (Party 1)
14 Trade with non-EEA counterparty Table 1 - Counterparty Data Counterparty Region
15 Directly linked to commercial activity Table 1 - Counterparty Data Directly linked to commercial activity or
or treasury financing treasury financing Party 1
16 Clearing threshold Table 1 - Counterparty Data Clearing Threshold Party 1
17 Mark to market value of contract Table 1 - Counterparty Data MTM Value Party 1
MTM Value CCP
18 Currency of mark to market value of Table 1 - Counterparty Data MTM Currency party 1
the contract MTM Currency CCP
19 Valuation date Table 1 - Counterparty Data Valuation Datetime Party 1
Valuation Datetime CCP
20 Valuation time Table 1 - Counterparty Data Valuation Datetime Party 1
Valuation Datetime CCP
21 Valuation type Table 1 - Counterparty Data Valuation Type
Valuation Type CCP
22 Collateralisation Table 1 - Counterparty Data Collateralized Party 1
23 Collateral portfolio Table 1 - Counterparty Data Collateral portfolio code Party 1
24 Collateral portfolio code Table 1 - Counterparty Data Collateral portfolio code Party 1
25 Value of the collateral Table 1 - Counterparty Data Value of the collateral Party 1
26 Currency of the collateral value Table 1 - Counterparty Data Currency of the collateral value Party 1
Guide v0.6

Table #
Primary Asset Class GTR Control field
Secondary Asset Class GTR Control field
Product ID Prefix GTR Control field
Product ID Value GTR Control field
1 Taxonomy used Table 2 - Common Data Product ID Prefix
2 Product ID 1 Table 2 - Common Data Product ID value 1
3 Product ID 2 Table 2 - Common Data Product ID Value 2
4 Underlying leg 1 Table 2 - Common Data Underlying Asset leg 1
4a Underlying leg 2 Table 2 - Common Data Underlying Asset leg 2
5 Notional currency 1 Table 2 - Common Data Notional Currency
6 Notional currency 2 Table 2 - Common Data Notional Currency
7 Deliverable currency 1 Table 2 - Common Data Settlement Currency
7a Deliverable currency 2 Table 2 - Common Data Settlement Currency
UTI Prefix GTR Control field
UTI Value GTR Control field
USI Prefix GTR Control field
USI Value GTR Control field
Trade Party 1 Transaction Id GTR Control field
8 Trade ID Table 2 - Common Data UTI Prefix, UTI Value
Prior UTI Prefix GTR Control field
Prior UTI Value GTR Control field
Trade Link ID GTR Control field
Exchange Traded Derivative GTR Control field
indicator
Execution Venue Prefix GTR Control field
10 Venue of execution Table 2 - Common Data Execution Venue Value
11 Compression Table 2 - Common Data Compression
12 Price / rate Table 2 - Common Data Price Notation - Price
13 Price notation Table 2 - Common Data Price Notation - Price Type
14 Notional amount leg 1 Table 2 - Common Data Notional Amount
14a Notional amount leg 2 Table 2 - Common Data Notional Amount
15 Price multiplier Table 2 - Common Data Price Multiplier
16 Quantity Table 2 - Common Data Quantity
17 Up-front payment Table 2 - Common Data Upfront payment
17a Up-front currency 1 Table 2 - Common Data Upfront payment CCY
17b Up-front payment 2 Table 2 - Common Data Upfront payment
17c Up-front currency 2 Table 2 - Common Data Upfront payment CCY
17d Up-front payment 3 Table 2 - Common Data Upfront payment
17e Up-front currency 3 Table 2 - Common Data Upfront payment CCY
17f Up-front payment 4 Table 2 - Common Data Upfront payment
17g Up-front currency 4 Table 2 - Common Data Upfront payment CCY
17h Up-front payment 5 Table 2 - Common Data Upfront payment
17i Up-front currency 5 Table 2 - Common Data Upfront payment CCY
17j Up-front payment 6 Table 2 - Common Data Upfront payment
17k Up-front currency 6 Table 2 - Common Data Upfront payment CCY
18 Delivery type Table 2 - Common Data Delivery type
Guide v0.6

Table #
19 Execution timestamp Table 2 - Common Data Execution Timestamp
20 Effective date leg 1 Table 2 - Common Data Effective date
20a Effective date leg 2 Table 2 - Common Data Effective date
21 Maturity date Table 2 - Common Data Scheduled Termination Date
22 Termination date Table 2 - Common Data Termination date
23 Settlement date 1 Table 2 - Common Data Date of Settlement
24 Master Agreement type Table 2 - Common Data Master Agreement type
25 Master Agreement version Table 2 - Common Data Master Agreement version
26 Confirmation timestamp Table 2 - Common Data Confirmation Date Time
27 Confirmation means Table 2 - Common Data Confirmation Type
28 Clearing obligation Table 2 - Common Data Mandatory Clearing Indicator
29 Cleared Table 2 - Common Data Cleared
30 Clearing timestamp Table 2 - Common Data Clearing Timestamp
Clearing DCO Prefix GTR Control Field
31 CCP ID Table 2 - Common Data Clearing DCO Prefix
Clearing DCO Value
32 Intragroup Table 2 - Common Data Intragroup
33 Fixed rate of leg 1 Table 2 - Common Data Fixed rate of leg 1
34 Fixed rate of leg 2 Table 2 - Common Data Fixed rate of leg 2
35 Fixed rate day count 1 Table 2 - Common Data Fixed rate day count
35b Fixed rate day count 2 Table 2 - Common Data Fixed rate day count
36 Fixed leg payment frequency 1 Table 2 - Common Data Fixed leg payment frequency
36b Fixed leg payment frequency 2 Table 2 - Common Data Fixed leg payment frequency
37 Floating rate payment frequency 1 Table 2 - Common Data Floating rate payment frequency
37b Floating rate payment frequency 2 Table 2 - Common Data Floating rate payment frequency
38 Floating rate reset frequency 1 Table 2 - Common Data Floating rate reset frequency
38b Floating rate reset frequency 2 Table 2 - Common Data Floating rate reset frequency
39 Floating rate of leg 1 Table 2 - Common Data Floating rate of leg 1
39b Floating rate spread of leg 1 Table 2 - Common Data Floating rate spread of leg 1
40 Floating rate of leg 2 Table 2 - Common Data Floating rate of leg 2
40b Floating rate spread of leg 2 Table 2 - Common Data Floating rate spread of leg 2
40c Leg 1 Payer Table 2 - Common Data Leg 1 Payer
40d Leg 2 Payer Table 2 - Common Data Leg 2 Payer
41 Currency 2 Table 2 - Common Data Currency 2
42 Exchange rate 1 Table 2 - Common Data Exchange rate 1
43 Forward exchange rate Table 2 - Common Data Forward exchange rate
44 Exchange rate basis Table 2 - Common Data Exchange rate basis
45 Commodity base Table 2 - Common Data Commodity base
46 Commodity details Table 2 - Common Data Commodity details
47 Delivery point or zone Table 2 - Common Data Delivery point or zone
48 Interconnection Point Table 2 - Common Data Interconnection Point
49 Load type Table 2 - Common Data Load type
50 Delivery start date and time Table 2 - Common Data Delivery start date and time
51 Delivery end date and time Table 2 - Common Data Delivery end date and time
52 Contract capacity Table 2 - Common Data Contract capacity
53 Quantity Unit Table 2 - Common Data Quantity Unit
Guide v0.6

Table #
54 Price/time interval quantities Table 2 - Common Data Price/time interval quantities
55 Option type Table 2 - Common Data Option Type
56 Option style (exercise) Table 2 - Common Data Option Style
57 Strike price (cap/floor rate) Table 2 - Common Data Option Strike Price
Option Strike Price CCY
57b Option Strike Price Type Table 2 - Common Data Option Strike Price Type
57c Option Strike Price CCY Table 2 - Common Data Option Strike Price CCY
Lifecycle Event GTR Control Field
Lifecycle Event Effective Date GTR Control Field
58 Action type Table 2 - Common Data Lifecycle Event
Action
59 Details of action type Table 2 - Common Data Lifecycle Event
Action
Please note that the GTR Control Fields are used to derive the next Table 1 or Table 2 field but are not
included in regulatory reports.
7.2.4 GTR ESMA OTC Activity Report

The report will reflect all activity since the last report for the participant that has been reported to
ESMA. The format of the report will indicate the ESMA fields and the data reported against each of
those fields. It is in the exact same format and field list as the ESMA Position Report. All alleges will be
reflected on the report (where the participant has been named as a trade party to a UTI reported by
another counterparty).
The format of and fields contained in the ESMA Activity Report is the same as those contained in the
ESMA Position Report as described in the previous section.
The fields Lifecycle Event, Lifecycle Event Effective Date, Action type and Details of action type will be
included in the activity report but are blank in the position report.
Guide v0.6
7.2.5 ESMA Match Status Report

The new Matching Status report will provide participants with a breakdown of category 1 and category 2
differences to facilitate them investigating and resolving breaks. See above section on Inter-TR
reconciliation for definition of break category.
The Matching Status report will detail the list of unmatched fields but only the field name and not the
field content on either side of the position.
The report will contain the following fields:

UTI
Party 1 LEI
Part 2 LEI (or other identifier)
Trade Reconciliation Status
Unmatched fields
Party 1 Transaction ID
The unmatched field names will be displayed horizontally and semi-colon separated
UTI Party 1 LEI Party 2 LEI Party 1

Trade Reconciliation Status Unmatched Fields Transaction ID
ABC123 SAMPLE98765LEI7ABCD SAMPLE123LEI456ABCD Single-sided, unpaired, non EEA OUR123REF
ABC124 SAMPLE98765LEI7ABCD SAMPLE123LEI456ABCD Single-sided, unpaired, EEA OUR124REF
Notional Amount Leg
1 - 1; Notional
Currency 1 - 1;
Dual-sided, unmatched category Confirmation
ABC125 SAMPLE98765LEI7ABCD SAMPLE123LEI456ABCD 1 Timestamp - 2 OUR125REF
Dual-sided, unmatched category
ABC126 SAMPLE98765LEI7ABCD SAMPLE789LEI456EFGH 2 Effective Date - 2 OUR126REF
ABC127 SAMPLE98765LEI7ABCD SAMPLE789LEI456EFGH Dual-sided matched OUR127REF
Single-sided, paired, unmatched
ABC128 SAMPLE98765LEI7ABCD SAMPLE789LEI456EFGH category 1 Cleared - 1 OUR128REF
Exchange Rate - 2;
Single-sided, paired, unmatched Execution Timestamp -
ABC129 SAMPLE98765LEI7ABCD SAMPLE123LEI456ABCD category 2 2 OUR129REF
Single-sided, paired, match
ABC130 SAMPLE98765LEI7ABCD SAMPLE123LEI456ABCD pending OUR130REF
ABC131 SAMPLE98765LEI7ABCD SAMPLE789LEI456EFGH Single-sided, paired, matched OUR131REF
Guide v0.6
For reference, below are the Trade Reconciliation Status descriptions:
Trade Reconciliation Status Trade Reconciliation Status description

The trade is ESMA reportable but the other side of the trade is not ESMA reportable and
Single-sided, unpaired, non EEA therefore there is no reconciliation requirement.
The GTR has one side of the trade, knows that the other side is EEA based upon the value of the
Contract with non-EEA counterparty flag for Table 1 Counterparty Data being set to Y and
Single-sided, unpaired, EEA does not know which TR holds the other side of the trade is.
The GTR has both sides of the trade and category 1 fields do not match within the tolerances
Dual-sided, unmatched defined in Appendix A. The fields which do not match will be listed on the TR reconciliation
category 1 Differences Report.
The GTR has both sides of the trade and category 2 fields do not match within the tolerances
Dual-sided, unmatched defined in Appendix A. The fields which do not match will be listed on the TR reconciliation
category 2 Differences Report.
The GTR has both sides of the trade and all fields match within the tolerances defined in
Dual-sided matched Appendix A.
The GTR has one side of the trade and the details of the other side of the trade have been
obtained from the TR with the other side of the trade. The reconciliation has taken place and
Single-sided, paired, not all fields match within the tolerances defined in Appendix A. The fields which do not match
unmatched category 1 will be listed on the TR reconciliation Differences Report.
obtained from the TR with the other side of the trade. The reconciliation has taken place and
Single-sided, paired, not all fields match within the tolerances defined in Appendix A. The fields which do not match
unmatched category 2 will be listed on the TR reconciliation Differences Report.
Single-sided, paired, match obtained from the TR with the other side of the trade. Match processing has not taken place
pending yet.
obtained from the TR with the other side of the trade. The reconciliation has taken place and all
Single-sided, paired, matched fields match within the tolerances defined in Appendix A.
Guide v0.6
7.2.6 ESMA UTI Conflict or Pair LEI Break Report

This is a new report provided to a counterparty of the Transaction based on results of the Inter-TR
reconciliation. An additional report should also contain details of any UTI Conflicts or Pair Break LEIs
recorded to inform participants and submitters of specific problems.
So from the perspective of Party A running the UTI Conflict & Pair Break LEI Report they should see four
columns:
1. Column A = UTI
2. Column B = Party A LEI (as submitted by Party A)
3. Column C = Party B LEI (as submitted by Party A)
4. Column D = Error Code [UTI reported by other parties, UTI reported to GTR in error or
Mismatched LEI]

1 UTI ABC123
2 Party 1 LEI SAMPLE98765LEI7ABCD
3 Party 2 LEI SAMPLE123LEI456ABCD
4 Error Code UTI reported by other parties
"UTI reported by other parties error will occur when:

Party A vs. Party B reports UTI 123
Party C vs. Party D reports UTI 123
Mismatched LEI error will occur when:

Party A vs. Party B reports UTI 456
Party B vs. Party C reports UTI 456
Guide v0.6
8. Appendix A Useful Links

8.1 Regulatory Background
8.1.1 ESMA Final Draft Technical Standards
http://www.esma.europa.eu/system/files/2012-600_0.pdf
8.1.2 Summary of the ESMA Technical Standards

http://dtcc.com/~/media/Files/Downloads/Data-and-Repository-Services/GTR/GTR-
Europe/Summary_ESMA_Technical_Standards.ashx
8.1.3 EMIR vs. DFA Comparison

http://dtcc.com/~/media/Files/Downloads/Data-and-Repository-Services/GTR/GTR-
Europe/EMIRvDFA-QandA.ashx
8.1.4 ESMA Questions and Answers

http://www.esma.europa.eu/documents/overview/10?title=&doc_reference=&section=
All&doc_type=266&x=40&y=8
Note: Please ensure you download the latest EMIR Q&A
8.1.5 ISDAs Guidance on Price Notation

http://www2.isda.org/attachment/NTQxMA==/ISDA%20PN-
APN%20Approach%20Document%20v1.0%202013_03_15.xlsx
8.2 Business Requirements Document

Go to the Go to the GTR Clients Center (outline in section 1.2) and select Business
Requirement Documentation in the dropdown to retrieve the documentation.
8.3 CSV Upload Template

Go to the GTR Clients Center (outline in section 1.2) and select Supported Spreadsheets and
Messaging Specs in the dropdown to retrieve the documentation. If OTC Lite has not been
released into production yet, the template will be located under Future Spreadsheets and
Messaging Specs dropdown.
Guide v0.6
8.4 OTC Lite Presentations and Videos

https://event.on24.com/eventRegistration/EventLobbyServlet?target=registration.jsp&eventid=
700397&sessionid=1&key=6397B17393EE25A7AA48715C8C732BD9&sourcepage=register
https://event.on24.com/eventRegistration/EventLobbyServlet?target=registration.jsp&eventid=
712067&sessionid=1&key=60143008A0D90C7B22FF0E0CF2BC4E2A&sourcepage=register
8.5 ISDA Taxonomy

http://www2.isda.org/identifiers-and-otc-taxonomies/
8.6 International sFTP Transmission Guide v1.0

http://www.dtcc.com/~/media/Download-
Center/GTR/Connectivity/International_sFTP_Transmission_Guide_v1_0.ashx
8.7 Contact List for OTC Lite

1. OTC Lite UAT
otcliteuat@dtcc.com
2. OTC Lite Production

otclitesupport@dtcc.com
3. Onboarding
gtr_onboarding@dtcc.com
4. Counterparty Data Enrichment

crrs@dtcc.com
5. Connectivity Group
SAG-CON@dtcc.com
6. Customer Support Center

csc@dtcc.com
Guide v0.6
9. Appendix B Frequently Asked Questions (FAQs)

9.1 What is the geographic and jurisdictional scope of OTC Lite?
OTC Lite service covers OTC derivatives transactions that are reportable under European Market Infrastructure Regulation (EMIR) ONLY to the
GTR. Once the EC and ACER conclude with additional requirements, an update will be published to support those requirements.
9.2 Who is able to use the OTC Lite service?

The below chart provides different scenarios of users using the service.
Reporting
Obligation Can User Onboard to
Scenarios CFTC JFSA MAS ASIC HKMA
: ESMA OTC Lite?
(EMIR)
Onboarded for one or all of the following
Scenario 1 Yes Yes Yes Yes Yes Yes Yes
already (jurisdiction level)
Credit, Credit, Credit, Credit, Credit,
Onboarded for all asset-classes for each Interest Interest Interest Interest Interest
jurisdiction but want to report to ESMA on Lite Rates, Rates, Rates, Rates, Rates,
Scenario 2 Yes Yes
template (Lite template can cater for all asset- Equity, FX, Equity, FX, Equity, FX, Equity, FX, Equity, FX,
classes) Commodit Commodit Commodit Commodit Commodit
y y y y y
Credit, Credit, Credit,
Onboarded for combination of asset-classes for Interest Credit, Interest Interest
Yes, no specific limit on
each jurisdiction but not all and want to report Rates, Interest Rates, Rates, FX, Interest
Scenario 3 Yes reporting any other
to ESMA on Lite template for remaining asset- Equity, FX, Rates, Equity, FX, Equity, FX, Rates
asset-class
class/es Commodit Equity, FX Commodit Commodit
y y y
Scenario 4 New user - European reporting obligation only No No No No No Yes Yes
Existing or New user wants to use Lite template
Scenario 5 No No No No No Yes No
for multi-jurisdictional reporting
Guide v0.6
Existing or New user - wants to split their

reporting within an asset-class for reporting No - reporting is
Scenario 6 purposes (i.e. some Rates products submitted Yes different, submission is
on OTC Core solution and others on OTC Lite different
service)
Existing or New user - no European reporting
Scenario 7 No No
obligation
Yes - search & download
Scenario 8 Middle Market onboarded through internet No No No No No Yes
only
Yes - but CSV upload
Scenario 9 Yes
Middleware provider reporting data only
Larger new user or user wants to report on Yes - submission &
Scenario
behalf of clients - full onboarding direct with Yes search & download
10
GTR Onboarding available
9.3 Is it possible to send multiple files in one day as in one file per trade?
It is possible to send several files for a same day through the use of a position message which will be required to report all lifecycle events. A
lifecycle event reason is added to the Position submission and the relevant details of the event. The latest Position message received will
represent the end of day position for that day and Multiple Position messages can be submitted on any particular day and these can be ordered
with As of Date/Time indicated on each message.
9.4 Which Optional fields need to be filled out?

The firms should look at the conditionality within each message type which is clearly represented as Required, Optional or Conditional.
Furthermore, they should look at the column called EMIR field (column J) to understand whether the field is an EMIR required field to ensure
they are fully compliant for reporting to ESMA.
Guide v0.6
9.5 Does the field Trade Party 2 need to be filled out when a party is
submitting under independent delegation?
The submitting party needs to submit at least the Trade Party 2 Prefix & Value (and Name of the
counterparty where SWIFTBIC, Internal or Freeformattext used as a Prefix). This is required on message
and by EMIR. The only other Party 2 field that is required by EMIR is Counterparty Region (to identify if
counterparty is an EEA or nonEEA counterparty) but the field is Optional on message but must be
provided to be fully compliant. The reason this is optional was feedback received from firms indicating
this is not always known at time of reporting. A warning on the Warning report will indicate where this
field is blank and the firm will need to submit the Position message to add the information when
available to be fully compliant.
9.6 How can I submit structured or exotic products?

The nature of structured & exotic products is that they are not standard and there may be no industry
agreed guidance on how to submit. The GTR provides the fields requested by ESMA and firms should
decide how to best populate them.
9.7 What is DTCCs system operating schedule?

DTCC processes data for reporting every day at cut-off times specified midnight Sunday to midnight
Friday. DTCC has a weekly maintenance period starting on Saturday 10pm EST to Sunday 6am EST.
During this time DTCC will queue messages received and process these afterwards.
Guide v0.6
10. Appendix C DTCC Best Practice for Uploading

The below is DTCCs best practice guidance for populating the upload templates. It is not intended to be
legal guidance on trade reporting. Please consult your internal legal and business teams to ensure
accurate and compliant reporting. In addition, firms should follow the OTC Lite Message Template on
acceptable field values.
10.1 Cross Asset Guidance

Participants should submit messages under the same UTI to ONLY one application (Core or OTC Lite). If
trade submissions on the same UTI is submitted to both Core and OTC Lite this can cause duplicative
reporting to the regulators.
Message Template Guidance
Report using ISDA OTC Taxonomy

Use ISDAs guidance on price notation
http://www2.isda.org/attachment/NTQxMA==/ISDA%20PN-
APN%20Approach%20Document%20v1.0%202013_03_15.xlsx
The field Underlying Asset does not apply to all FX and Commodity products. As well as most
Interest Rates products
Where available ISIN should be reported
The field Price Multiplier is only applicable for Equity products
Quantity will be 1 for Credit, Interest Rates, and FX products but will be the number of
contracts reported for Commodity and Equity products
Multiple Values will be sequenced and Paired for reporting (i.e.: Notional Amount = 110; 120;
130; Notional Currency = USD; GBP; EUR will be reported as 110 USD; 120 GBP; 130 EUR)
Values or text fields can contain symbols such as comma's (,) as long as the value or values are
within quote signs . Example: Beneficiary ID Party 1 Value is a text field therefore a valid value
may include a symbol but the submitted value will need to be in quotes to be accepted Fund A
LTD.
Enumerated values in Valid Value(s) column are case sensitive.
All dates must be submitted in an YYYY-MM-DD format. Date time fields are to submitted in
YYYY-MM-DDTHH:MM:SSZ and in UTC time.
DTCC does not provide a best practice for reporting exotic products as that is left at the
discretion of the firms
Reporting strategies should follow the confirmation record, if not electronically confirmed,
reporting will be left at the discretion of firms
Guide v0.6
Lifecycle Event Guidance
When reporting Notional Amount for a lifecycle event, the value should always be the resulting
position
o Below is an example:
UTI Lifecycle Event Notional Amount Notional Currency Notes

UTI123 Trade 1,000,000.00 EUR
UTI123 Increase 1,500,000.00 EUR Increase was for 500,000.00, user reports
outstanding notional
10.2 Technical Guidance

Rows that are not meant for processing should have a * notation in front of it
Footers need to be included in the last row in the following format: *<4 CHAR OCODE>-END<8
DIGIT # OF TRADE ROWS>
i.e.: *8TY6-END00000280
All upload files must be in CSV format
All enumerated values are case sensitive, TRUE and true is not the same in the system
Values or text fields can contain symbols such as comma's (,) as long as the value or values are
within quote signs .
For example: Beneficiary ID Party 1 Value is a text field therefore a valid value may
include a symbol but the submitted value will need to be in quotes to be accepted
Fund A, LTD.
All dates must be submitted in an YYYY-MM-DD format. Date time fields are to submitted in
YYYY-MM-DDTHH:MM:SSZ and in UTC time.
10.3 Valid Values

Although OTCLite does not allow FpML as an input format, below are scheme links of valid values that
are derived from the ISDA terminology, users may use the valid values in these links.
FpML Schemes
Day count fraction http://www.fpml.org/coding-scheme/day-count-fraction
Floating Rate Index http://www.fpml.org/coding-scheme/floating-rate-index
Price Quote Unites (Commodities) http://www.fpml.org/coding-scheme/price-quote-units
ISDA Product ID http://www.fpml.org/coding-scheme/product-taxonomy
Frequency
M = Month, D = Day, Y =Year, W= Week, T=Term
Users should populate frequency in the format of number + frequency (i.e.: 3M, 4Y, 3W, 1T)
Guide v0.6
10.4 Interest Rates

Product Specific
Debt Option Strike Price type should be submitted as a percentage of par
Amortizing notionals and step schedules are to be reported as an update to the position. Users
report resulting notional, no lifecycle event reported, this is contract intrinsic
Floating rate will be the tenor + floating rate
Firms should populate the Leg 1/Leg 2 Payer
For cap floor, the Option Strike Price Type should be Cap:basis
Maturity of a FRA is the effective date
For example:
If the opening date is 2014-01-07 this would be considered the Execution
Timestamp
If the value date is 2014-03-19 this would be considered the Effective Date
If the maturity date 2014-06-18 this would be considered the Scheduled
Termination Date
Collar trades is a strategy trade and the client can either report the strategy as two different
trades (1 Cap and 1 Floor) with two different UTIs or the client can report this trade as an Exotic.
For submitting Rate Resets, the underlying rates will be matched as part of the Inter/Intra TR
process. Therefore, this should be agreed with your counterparty
Buyer determination
For option products the buyer of the option is considered the buyer
For products with a fixed rate, the fixed rate buyer is considered the buyer
For all other products there is no best practice defined
10.5 Commodities
Product Specific
Load Type is only applicable for Electric taxonomies
Delivery End and Start dates do not apply to Cash taxonomies
Delivery Point and Interconnection point only apply to Eng:Elec taxonomies
Price/Time field only applicable for Elec. Rates will be in sequence of hours (i.e.: 14;15;16 = Rate
for hour 1 =14, Rate for hour 2 =15, Rate for hour 3 =16)
Guide v0.6
10.6 Foreign Exchange

Product Specific
When reporting an FX swap, users should send in two submissions, one as an FX Spot and one as
an FX Forward with two distinct UTIs. The link ID field should be used to link these submissions.
Link IDs should be unique and shared
Users, can also report an FX Swap with two FX Spot trades or two FX Forward trades
For FX Forwards, the value in field Exchange rate 1 (Foreign exchange only) should be the same
as value in the Forward exchange rate (Foreign exchange only) field
Currency 1 for the quote basis should be populated in the Notional Currency/Units field
Currency 2 for the quote basis should be populated in the Currency 2 field
For FX Swaps, the Effective Date is the effective date of the Swap. For FX Forwards, the Effective
Date is the trade date.
NDFs typically settle on a different day then its maturity. All other products settle on maturity.
For NDFs there is no requirement to report the settlement fixing rate
Buyer determination
For option products the buyer of the option is considered the buyer
For non-option products there is no clear buyer and no best practice defined
Example of an FX Forward
Party 1 buys EUR 1,000 from Party 2 at .80 = 800 on 2014-06-20
*Below is a scaled down version of the samples in order to illustrate the above scenario. Please check the template
to ensure all required fields are submitted.
GTR Field Name Sample Value Notes

Version Lite1.0
Message Type Position
Action New
Transaction Type Trade
UTI Prefix UTIPREFIX
UTI Value TRANSACTID007
Primary Asset Class ForeignExchange
Product ID Prefix 1 ISDA
Product ID Value 1 ForeignExchange:Forward
Underlying Asset (repeatable up to 2
times semi-colon separated) N/A for FX
Notional Currency/Units (repeatable The first currency in the exchange rate quote basis should
up to 2 times semi-colon separated) EUR be must be populated (e.g. EUR/GBP)
Settlement Currency (repeatable up Only applicable to Non Deliverable Forwards and Non
to 2 times semi-colon separated) Deliverable Options. Otherwise, must be blank.
Price Notation - Price 0.8 As per the best practice here
Guide v0.6
Price Notation - Price Type Rate

Notional 1 applies to the first currency in the "Notional
Notional Amount (repeatable up to 2 Currency/Units (repeatable up to 2 times semi-colon
times semi-colon separated) separated)" field, the second Notional Amount applies to
1000;800 the currency 2
Delivery type C
Execution Timestamp 2014-06-20T15:25:00Z
Effective Date (repeatable up to 2
times semi-colon separated) 2014-06-24 One date applicable
Scheduled Termination Date 2014-06-24
Date of Settlement (repeatable up to Applicable to Non Deliverable Options and Non Deliverable
2 times semi-colon separated) Forwards
Lifecycle Event New
For the Currency 2 (Foreign exchange only) field, the value
Currency 2 (Foreign exchange only) should always reflect the payer of the second currency
GBP expressed in the exchange rate quote basis
For Forwards, the Exchange rate 1 (Foreign exchange
Exchange rate 1 (Foreign exchange
only) field will be the same as the Forward exchange rate
only)
0.8 (Foreign exchange only) field
For Forwards, the Exchange rate 1 (Foreign exchange
Forward exchange rate (Foreign
only) field will be the same as the Forward exchange rate
exchange only)
0.8 (Foreign exchange only) field
Exchange rate basis (Foreign exchange only) will drive the
logic for populating:
Notional Currency/Units
Exchange rate basis (Foreign Notional Amount (repeatable up to 2 times semi-colon
exchange only) separated)
Currency 2 (Foreign exchange only)
Leg/Currency 1 Payer
EUR/GBP Leg/Currency 2 Payer
Leg/Currency 1 Payer field should relate to the Notional
Currency and Notional Amount 1. For FX, Leg 1 should
always reflect the payer of the first currency expressed in
Trade Party 1 the exchange rate quote basis
Leg/Currency 2 Payer field should relate to the Currency 2
and Notional Amount 2. For FX, Leg 2 should always reflect
the payer of the second currency expressed in the exchange
Trade Party 2 rate quote basis
Guide v0.6

DTCC GTR Otc Lite

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

DTCC GTR Otc Lite

Diunggah oleh

Hak Cipta:

Format Tersedia

DTCC Product Management GTR OTC Lite User Guide

DTCC GTR OTC Lite User Guide

2.6.4 DIAGRAM 4 ......................................................................................................................... 27

7.2.2 Warning Report ................................................................................................................... 49

10.3 Valid Values ................................................................................................................................. 65

1.2 GTR Document Portal

Please reach out to your relationship manager to retrieve login information.

The Global Repository On-Boarding section contains GTR onboarding documentation.

1.3 Global Processing Overview

1.3.1 File Input

1.4 GTR Connectivity

Web GUI, using CSV (comma separated values) file upload

1.4.1 Data Center Access and Security

1.5 GTR Entitlements

1.5.1 Web GUI Entitlement

Participant and regulator roles are defined in the GTR.

1.5.2 Secure FTP Entitlement

1.6 GTR Sign on Process

2.1 GTR Upload Process

Contact GTR_Onboarding@dtcc.com for login details.

2.2 OTC Lite Cross Asset Messaging

Message Type Description

2.2.1 OTC Lite Message Template

2.2.2 Valuation and Collateral Reporting

2.2.3 GTR CSV File Footer Message

The format of the message is as follows:

2.3 GTR Batch Cut-off Requirements

Business Day EUDC Submission Cut-off EUDC Batch Run

2.4 Message Usage

Asset Class Message Type Action Transaction Lifecycle ESMA

2.4.1 Reporting a New Trade

Trade Event* Message Action Transaction Type** Lifecycle Event ESMA

2.4.2 Reporting a Post Trade Event

Trade Event Message Action Transaction Lifecycle Event ESMA Action

2.4.3 Reporting a Trade Exit

Trade Event Message Action Transaction Lifecycle Event ESMA Action

2.5 Lifecycle Event Reporting

2.5.1 Correcting Life Cycle Events

First set of files sent to GTR:

Termination 1 in File 1 needs to be cancelled:

The following table summarizes the events supported by the GTR.

2.6 Message Workflows

3.1 Validation Stages

Schema Syntax GTR Business

Permission, UTI lock,

3.2 Business validation

GTR Control Fields

3.3 ESMA Regulatory validation

3.4 Response Messages

3.4.1 CSV-Batch Download Report (Spreadsheet Download Report)

Submission Status Description

3.5 End-of-Day Warning Report

3.5.1 Generation Rules

Counterparty data the details relating to the counterparties to a contract.(Annex Table 1 of

4.2 Identifying reporting model

4.2.1 Independent reporting rules

4.2.2 Full Delegation reporting rules

The below chart depicts the above rules:

Submitted Submitted Delegation Commo Trade Party 1 Trade Party 2

Only Identifier/region of CP will be processed all

4.2.2.1 Reporting limitation

4.2.3 Delegated Reporting Functionality Matrix

5.2 Upstream workflow