This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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”
UTI Lock ....................................................................................................................................... 38 5.3
UTI Lock Exceptions: ........................................................................................................... 39 5.3.1
Version Date Revision V0.1 October 30, 2013 Initial Draft
V0.2 November 30, 2013
Revisions New Screenshots
V0.3 December 11, 2013 Revised Position Report Table
V0.4 December 12, 2013 Revised Q and A section
V0.5 January 14, 2014 Updated 2.1 GTR Upload Process with new screen shots Added 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
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.
GTR Document Portal 1.2
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.
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.
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.
Secure FTP Entitlement 1.5.2
The participants who submit trade information into GTR will be given Secure FTP entitlement for the CSV
submission.
The way to submit through Secure FTP is through DATATRAK and AutoRoute which are DTCC’s
proprietary file input and output management subsystems. They enable DTCC and its participants to
securely and reliably automate the exchange of files over a network link. DTCC supports these services
over their proprietary SMART network, as well as the SWIFT and BT Radianz networks.
For more information on DATATRAK and AutoRoute go to the GTR Clients’ Center (outline in section 1.2)
and select “Connectivity” in the dropdown to retrieve the documentation.
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 [email protected] 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
3. Click the spreadsheet that you want to download (e.g. OTC Lite Upload Spreadsheet).
4. Log on to the portal to access OTC Lite. Select Participant in the dropdown. Enter your Participant Code and then select your O-Code in the dropdown.
5. The dashboard shows your firm’s latest list of batch submissions to the GTR. Click Upload. The Upload page appears.
6. Click Upload and then use the navigation tools provided to locate and select the spreadsheet file that you want to upload.
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 Valuation*
Used to report portfolios of collateral that can be linked to individual transactions.
*Have a compliance date of August 11th 2014
“OTC Lite” Message Template 2.2.1
The message template is designed to enable full compliance with the EMIR requirements and as such contains fields that are specified in the EMIR RTS. In addition to these fields there are a set of control fields that are applicable for all message submission to the GTR in order for the GTR to process the messages correctly. The template is a simple CSV format and contains 28 control fields (most of these are required on each message) and 128 EMIR specific fields (including fields related to trade party 2 to enable delegated reporting). Each message type supported can be submitted on the same template and where the field is N/A or Optional it can be left blank (comma-separated) and the GTR will accept the message. Important to note: It is the reporting parties’ responsibility to ensure that all EMIR specific Required fields have been populated accurately and completely. The GTR mandates many of the fields as required but there are a number of common data fields (mostly trade economic fields) that are Optional on the message template. The reporting party has until end of T+1 UTC to report the trade to a registered trade repository (TR) under the EMIR rules. However, here may be certain scenario’s that some of the data is not available. As soon as the data is available the reporting party must update their trade record in the GTR. Each EMIR field has been indicated in the message template and should be populated if available/applicable
Valuation and Collateral Reporting 2.2.2
Compliance for the valuation and collateral reporting will be 180 days post reporting start date. The
description and details for valuation and collateral reports will be included at a later stage.
GTR CSV File Footer Message 2.2.3
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
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 (Trailer) Field
GTR Value Length
Constant1 * (This is constant) 1
Originator This is the 4 character ORIGINATOR ID that is assigned to your account as part of the GTR on-boarding process. DTC0 is used in our example above
4
Constant2 -END (This is constant) 4
Record Count This is the count of records in the file excluding comment lines. This must be left padded with zeroes. 00054321 are used in our example above.
8
Sample File (example for information purposes only)
The below example includes a file consisting of 4 lines with data. The comment line and file footer are
not included in record count. Please also note the file footer is one value.
*Comment Line ,Data,Data,Data,Data
,Data,Data,Data,Data
,Data,Data,Data,Data
,Data,Data,Data,Data
*DTC0-END00000004
By way of example, when preparing your sFTP file the following format should be followed:
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
Bilateral execution; affirmed in middleware; not cleared; Both parties report (no delegation)
Note: The message template is a CSV only format and therefore if a middleware provider agrees to submit for one or both counterparties then
the middleware provider must also adhere to the message format and submission methods described above.
Flow Steps: 1. Party A & B bi-laterally agree trade. 2. Parties send the trade to the middleware platform. 3. The middleware generates UTI and confirms UTI with counterparties. 4. Party A submits a Position message to GTR on its own behalf. 5. Party B submits a Position message to GTR on its own behalf. 6. The GTR sends an ACK back to Party A and Party B, respectively. 7. Party A sends a Valuation message 8. GTR sends an ACK to Party A 9. Party A sends a Collateral message 10. GTR sends an ACK back to Party A 11. Party B sends a Valuation message 12. GTR sends an ACK to Party B 13. Party B sends a Collateral message 14. GTR sends an ACK back to Party B
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)
Bilateral execution; affirmed in middleware; not cleared; Party A reports on behalf of both parties (full
delegation)
Flow Steps: 1. Party A & B bi-laterally agree trade. 2. Parties send the trade to the middleware platform. 3. The middleware generates UTI and acknowledges trade with UTI. 4. Party A submits Position message to TR on behalf of both parties 5. The GTR sends an ACK back to Party A 6. Intra-day parties agree to amend the contract 7. Parties send the amends to middleware 8. Party A submits Position message indicating Amendment to the GTR 9. GTR sends an ACK back to Party A 10. Party A sends a Valuation message 11. GTR sends an ACK to Party A 12. Party A sends a Collateral message 13. GTR sends an ACK back to Party A 14. Party B sends a Valuation message 15. GTR sends an ACK to Party B 16. Party B sends a Collateral message 17. GTR sends an ACK back to Party B
Bi-lateral execution; paper confirmation; not cleared; One party reports all data (full delegation)
Flow Steps: 1. Party A & B bi-laterally agree trade. 2. Party A sends a Position message to the GTR including common and counterparty specific data on behalf of both parties
3. The GTR sends an ACK back to Party A
4. Party A sends an EOD Position message recapping open positions including valuations
5. GTR sends an ACK back to Party A
6. Party A sends Collateral and Valuation message to GTR
On-Facility execution; not cleared; Both parties report (independent)
Flow Steps:
1. Trade is booked on execution platform and is sent to Parties A & B. 2. Execution platform generates UTI and sends to Parties A & B. 3. Party A sends Position message to TR on behalf of itself. 4. GTR sends an ACK to Party A
5. Party B sends Position message to TR on behalf of itself. 6. GTR sends an ACK to Party B 7. Party A reports Valuation message and Collateral message on ongoing basis. 8. Party B reports Valuation message and Collateral message on ongoing basis.
On-Facility execution; not cleared; one party reports all data (full delegation)
Flow Steps:
1. Trade is booked on execution platform and is sent to Parties A & B. 2. Execution platform generates UTI and sends to Parties A & B. 3. Party A sends Position message to TR on behalf of both parties. 4. GTR sends an ACK to Party A
5. Party A reports Valuation message and Collateral message on ongoing basis. 6. Party B reports Valuation message and Collateral message on ongoing basis.
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
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
ACCEPT
This status indicates that the GTR Core validation, GTR business validations as well as all the other mandatory fields have passed, indicating that the inbound submission was validated, verified and has been accepted in the GTR system.
REJECT This status indicates that the GTR Core validation and GTR reduced business validations failed, indicating that the inbound submission was not as per the required validation and has been rejected by the GTR system.
End-of-Day Warning Report 3.5
The EOD warning report contains trade level warnings where a specific trade failed the jurisdictional
compliance requirement. The Position message regulatory field validations will be applied for validating
the trade field compliance requirement.
Warnings will be generated for all blank ESMA required fields. While the GTR might have a field as
optional the field maybe an ESMA required field. It is the party’s responsibility to ensure that they are
IMPORTANT: IF REPORTING ON BEHALF OF BOTH OR ONE PARTY TO THE TRADE THEN ALL
SUBSEQUENT MESSAGES ON THAT UTI MUST BE MADE TO THE SAME SERVICE (“OTC Lite” or “OTC
Core”). The GTR cannot process UTI’s that are partially submitted in a service. For example, if a
Middleware uses “OTC Core” to submit on behalf of Party A and Party A is an “OTC Lite” user, the
position message will be accepted by OTC Lite but will appear as a duplicate in the reports.
The current GTR infrastructure supports the reporting of trade data by both sides to a transaction either
directly, through delegated reporting or via approved 3rd party service providers. The submissions may
be made independently by both sides to the trade, or via a central matching platform such as a
confirmation service provider (as long as it’s on a CSV file format as describe above).
Under ESMA regulations both counterparties to any eligible trade have a reporting obligation.
Furthermore the ESMA technical standards make a clear distinction between common data and
counterparty data:
Counterparty data – the details relating to the counterparties to a contract.(Annex Table 1 of the ESMA Technical Standards Document)
Common data – the details pertaining to the derivative contract concluded between the two counterparties. (Annex Table 2 of the ESMA Technical Standards Document)
This data distinction, along with the obligation for both counterparties to report a trade gives rise to the
following reporting scenarios and delegation models.
Both counterparties may independently report both common and counterparty data
One party may report both common and counterparty data for both parties (full delegated reporting model).
o Under this model it is also possible for the other counterparty to supplement their counterparty data by submitting an independent report using the Position message (please note that the full Position message is required and the latest Position message submitted takes precedence of that side of the UTI)
One or both counterparties may delegate reporting responsibility to one or more third parties
On cleared trades the counterparties may delegate reporting to the CCP
In all cases the counterparty/CCP remains responsible for ensuring that contracts are reported to the registered TR without duplication
Fields have been added to the message template to accommodate for these reporting flows.
Please note that if a counterparty (Party A) submits a message to OTC Core under the full delegated
model and the other party (Party B) submits to OTC Lite independently using the same UTI this will
The GTR Control Fields Submitted For Prefix and Submitted For Value will identify whether the
submission is on behalf of yourself, your counterparty or both parties. A field Reporting Delegation
Model has been added to identify the reporting model applicable to each submission. Although not a
required field, the Reporting Delegation Model has been included for future use. At present it does not
influence processing options as they are based upon the value provided in the Submitted For Prefix and
Submitted For Value fields.
If submitting on behalf of one party this field must contain the value “Independent”.
If submitting on behalf of both parties this field must contain the value “Full”.
In the case of delegated submissions, GTR will ensure that the submitter has permission to provide data
on behalf of the parties to the trade.
Independent reporting rules 4.2.1
If Submitted For Prefix and Submitted For Value identify the submission as being on behalf of the
submitter, i.e. Party 1 to the trade, the submission will be treated as an independent submission. In this
scenario
GTR will expect to receive counterparty data and common data submitted on behalf of only Party 1.
The field Reporting Delegation Model must contain the value Independent” or be left blank. The only Trade Party 2 data required under this report is the identification of the counterparty. All other
Party 2 data contained in the submission it will be ignored, however the Party 1 data will be processed.
Under this scenario the other party to the trade will report their data, if obligated, independently. This
submission could be to GTR or could be to another TR.
Full Delegation reporting rules 4.2.2
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
report identifying missing attributes required under EMIR. The warning report will be available to the parties to the trade, if they are on-boarded as GTR participants.
If a Party to the trade wants to update their side of the UTI (possible scenario would be to add further counterparty data) then that Party would be required to submit an Position message for itself (indicate under Submitted For Value) and comply with the validation on the Position message.
o As mentioned above please note that all the Counterparty data and Common data must be submitted for that Party so that the UTI for their side of the trade is accurately represented in the GTR. Any common data that is not provided and had previously been submitted will be blank in the GTR.
The below chart depicts the above rules:
Scenario Submitted
By Submitted
For Delegation
Model Commo
n Trade Party 1 fields
Trade Party 2 fields
Independent Reporting
Bank A Bank A Independent Y Y N
Independent Reporting
Client B Client B Independent Y Y N
Independent Reporting
Third Party Bank A Independent Y Y N
Independent Reporting
Third Party Client B Independent Y Y N
Full Delegation Bank A Both Full Y Y Y
Full Delegation Client B Both Full Y Y Y
Full Delegation Third Party Both Full Y Y Y
Only Identifier/region of CP will be processed all other information will not be processed if submitted
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 Party2’s trade would be incomplete for EMIR reporting and warning on the Warning report would
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.
UTI Lock 5.3
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
Party/Counterparty’. For a given UTI, the Party-Counterparty-Asset Class LOCK will remain the same throughout the lifetime of the “OTC Lite” service.
3. The LOCK will be applied for a UTI when the Trade has dual submissions – submissions done for both the Party side and the Counterparty side. After the party and the counterparty records are received by the Trade Repository, the system will LOCK the UTI
UTI Lock Exceptions: 5.3.1
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
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.
Trade Pairing 6.1Pairing can only take place where a UTI has been provided. If a UTI is not provided by the two
counterparties to the trade, trade sides cannot be paired.
Pairing can only take place with other TRs where both counterparties have been reported with an LEI or
pre-LEI. If the “ID of the other counterparty“ has been populated with anything other than an LEI or pre-
LEI, the report can never pair with the other counterparty’s report, because they will have used an LEI or
pre-LEI in their Counterparty ID field. If the “ID of the other counterparty” is not populated with an LEI
or pre-LEI, TRs cannot pair and compare the trade. Where both sides of a trade are reported to GTR,
pairing will be attempted using UTI, Counterparty ID and ID of the other counterparty regardless of the
type of identifier used (i.e. this is not restricted to use of LEIs).
The GTR will record the status of each position. The population of trade pairing status values is
described in the following table.
Trade Pairing Status 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 LEI’s).
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.
The GTR system receives Trade messages and maintains a Paired Status, a Paired Source and a Matched
Status for all trades with a Trade Position. Once a trade has been paired a comparison of the two sides
of the trade will take place and status of that comparison will be stored.
The possible match status of each trade is described in the following table. The fields on which the
comparison is based are listed later in this section. It should be noted that this matching process is not
relevant to, nor in any way replaces, a participant’s confirmation matching processes.
Trade Match Status 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.
Fields and Rules 6.2.1
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 number
Field Name ESMA Format Match / Tolerance Rule to other trade
2 Counterparty Id LEI Must match id of the other counterparty
3 ID of the other counterparty LEI Must match id of the counterparty
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 to other trade
Category
1 Taxonomy used Identify the taxonomy used: U=Product Identifier [endorsed in Europe] I=ISIN/AII + CFI E=Interim taxonomy
Must match 1
2 Product id 1 For taxonomy = U: Product Identifier (UPI), to 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
Must match 1
3 Product id 2 For taxonomy = U: Blank For taxonomy = I: CFI, 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
No. Name ESMA Format Match/ Tolerance Rule to other trade
Category
currency
8 Trade id Up to 52 alphanumerical digits. Must match 1
9 Transaction reference number
An alphanumeric field up to 40 characters Will never match 3
10 Venue of execution
ISO 10383 Market Identifier Code (MIC), 4 digits alphabetical. Where relevant, XOFF for listed derivatives that are traded off-exchange or XXXX for OTC derivatives.
Should match 2
11 Compression Y = if the contract results from compression; N= if the contract does not result from compression.
Should match 2
12 Price/rate Up to 20 numerical digits in the format xxxx,yyyyy.
Apply tolerance check 1 2
13 Price notation E.g. ISO 4217 Currency Code, 3 alphabetical digits, percentage.
Must match 2
14 Notional amount Up to 20 numerical digits in the format xxxx,yyyyy.
Apply tolerance check 2 1
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 xxxx,yyyyy for payments made by the reporting counterparty and in the format xxxx,yyyyy for payments received by the reporting counterparty.
Apply tolerance check 1 2
18 Delivery type C=Cash, P=Physical, O=Optional for counterparty.
Must match 2
19 Execution timestamp
ISO 8601 date format / UTC time format. Apply tolerance check 3 for OTC.
2
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 settlement
ISO 8601 date format. Cannot match 3
24 Master agreement type
Free Text, field of up to 50 characters, identifying the name of the Master Agreement used, if any.
Cannot match 3
25 Master agreement version
Year, xxxx. Cannot match 3
26 Confirmation timestamp
ISO 8601 date format, UTC time format. Apply tolerance check 3 2
CSV123 Reference provided by the submitting firm on each message within the CSV file
23 Submission Date & Time 2012-03-27T11:25:00Z
Submission Date and Time in UTC format. This is the time the 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
Warning Report 7.2.2
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: No. Field Name Sample Data Description
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:PriceReturnBasicPerformance:SingleName
Product Value as specified by ISDA taxonomy
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
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 Currency/Units
USD Currency for the notional reported by party 1
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 Currency/Units
USD Currency for the notional reported by party 2
23 Transaction Reference Number
1323423 EMIR specific field
24 Internal Trade Reference T98765
25 Data Submitter Message ID
CSV789 Reference provided by the submitting firm on each message within the CSV file
26 Warning Reason Code 12 Reason code for the warning
27 Warning Description Unknown Counterparty
Reason description for the warning
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
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.
GTR ESMA OTC Activity Report 7.2.4
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.
For reference, below are the Trade Reconciliation Status descriptions:
Trade Reconciliation Status Trade Reconciliation Status description
Single-sided, unpaired, non EEA The trade is ESMA reportable but the other side of the trade is not ESMA reportable and therefore there is no reconciliation requirement.
Single-sided, unpaired, EEA
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 does not know which TR holds the other side of the trade is.
Dual-sided, unmatched category 1
The GTR has both sides of the trade and category 1 fields do not match within the tolerances defined in Appendix A. The fields which do not match will be listed on the TR reconciliation Differences Report.
Dual-sided, unmatched category 2
The GTR has both sides of the trade and category 2 fields do not match within the tolerances defined in Appendix A. The fields which do not match will be listed on the TR reconciliation Differences Report.
Dual-sided matched The GTR has both sides of the trade and all fields match within the tolerances defined in Appendix A.
Single-sided, paired, unmatched category 1
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 not all fields match within the tolerances defined in Appendix A. The fields which do not match will be listed on the TR reconciliation Differences Report.
Single-sided, paired, unmatched category 2
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 not all fields match within the tolerances defined in Appendix A. The fields which do not match will be listed on the TR reconciliation Differences Report.
Single-sided, paired, match pending
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. Match processing has not taken place yet.
Single-sided, paired, matched
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 all fields match within the tolerances defined in Appendix A.
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 LEI’s
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”]
No. Field Name Sample Data Description
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:
Existing or New user - wants to split their reporting within an asset-class for reporting purposes (i.e. some Rates products submitted on OTC Core solution and others on OTC Lite service)
Yes No - reporting is different, submission is different
Scenario 7 Existing or New user - no European reporting obligation
No No
Scenario 8 Middle Market onboarded through internet No No No No No Yes Yes - search & download only
Scenario 9 Middleware provider reporting data
Yes Yes - but CSV upload only
Scenario 10
Larger new user or user wants to report on behalf of clients - full onboarding direct with GTR Onboarding
Yes Yes - submission & search & download available
Is it possible to send multiple files in one day as in one file per trade? 9.3
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.
Which ‘Optional’ fields need to be filled out? 9.4
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
10. Appendix C – DTCC Best Practice for Uploading The below is DTCC’s 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.
Cross Asset Guidance 10.1
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