User Guide - Supplement - The Depository Trust & …/media/Files/Downloads/Data-and-Repository-Service… · Please consult your internal legal & compliance de partments for ... 4

User Guide

OTC Lite Service – Field by Field Description v1.0

All material in this document is considered DTCC Confidential and is copyright © 2013

DTCC

Page 1 of 32

User Guide - Supplement

Initiative:

Global Trade Repository European Markets Infrastructure Regulation (“EMIR”) Requirements

OTC Lite Service - Field by Field Description

Date: 23 December 2013 Version: v1 Status: Draft

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.

User Guide



DTCC

Page 2 of 32

Document Revision History

Date By Version Description

23 December Peter Garratt 1.0 First publication of field by field description

User Guide



DTCC

Page 3 of 32

Table of Contents 1 OTC LITE FIELD BY FIELD DESCRIPTION ...................................................................................4

1.1 OVERVIEW AND INTRODUCTION ................................................................................................4 1.2 GTR CONTROL FIELDS ............................................................................................................5 1.3 EMIR RTS FIELDS.................................................................................................................9 1.4 GTR CONTROL & EMIR RTS FIELDS........................................................................................ 28

DTCC Product Management Project Plan & Requirements



DTCC

Page 4 of 32

1 OTC Lite Field by Field Description

1.1 Overview and Introduction Objective of this supplement is to describe the purpose and use of each field within the OTC Lite message template. Note: This is not considered legal advice. Please consult your internal legal & compliance departments for compliance related questions. This should be read together with the following artifacts: OTC Lite message template (version published on the document portal) OTC Lite User Guide (version published on the document portal) EMIR Draft technical standards (Final Report) – Draft technical standards under the Regulation (EU) No 648/2012 of the

European Parliament and of the Council of 4 July 2012 on OTC Derivatives, CCPs and Trade Repositories (published on ESMA’s website)

ESMA Questions and Answers – Implementation of the Regulation (EU) No 648/2012 on OTC derivatives, central counterparties and trade repositories (EMIR) (published on ESMA’s website)

Validation principles (further explained in the user guide): Required field – must be populated for the message to be accepted by the GTR Optional field – can be left blank and the GTR will accept the message. However, please note that some fields as indicated are

EMIR required fields and should be populated to be in full compliance with EMIR reporting Conditional field – certain fields become required based on some optional fields being populated

Field overview: 1.2 GTR Control fields – These fields are not mandated by regulation but many of these fields are Required as indicated in the template in order for the GTR to process the message. 1.3 EMIR RTS fields – These fields are highlighted in the template (column J) and indicate the reference within the EMIR draft technical standards to the Annex of required fields and the related field reference number in Table 1 – Counterparty Data or Table 2 – Common Data.




DTCC

Page 5 of 32

1.4 GTR Control Fields & EMIR RTS fields – These fields are used to identify further information that has been submitted in a field identified as a specific EMIR RTS field

1.2 GTR Control Fields GTR OTC Lite Field #

GTR Field Name Description Purpose

1 Comment If populated with an * the entire line is treated as comment

Utilize an asterisk (*) in this field if you want to note the entire row of data in your CSV file is a comment. The comment rows in any file will be ignored and not be processed by the GTR.

2 Version An indication of the version of the message specification under which this submission has been constructed.

The GTR will support one version of the OTC Lite message template in production but in the event significant changes are required to support other regulations using the OTC Lite template then Version allows the GTR the flexibility to support more than one message template while firms upgrade (this is not envisaged in the medium term).

3 Message Type Indicates the type of inbound message to the GTR

Describes the message being reported to the GTR and invokes the necessary validation based on the message template.

4 Action Describes the type of GTR action required - New or Cancel

Describes the action that the GTR should take on the message being reported. Position message types only support an Action of "New" at the time of this publication.

5 Transaction Type Type of Transaction - Trade, Exit, Backload, PositionCancel

Describes the GTR transaction type supported for each message reported. "Trade" will be used most often and represents the reporting of New transactions and post trade lifecycle events "Backload" can be used to identify historical trades that are still open as at reporting start date "Exit" will be used to indicate to the GTR that a position has either fully terminated, novated, been exercised or merely needs to be removed for reporting purposes "PositionCancel" should be used to remove or cancel the position UTI from the trade repository




DTCC

Page 6 of 32

GTR OTC Lite Field #


(including any previously reported lifecycle events in the UTI). This transaction type should only be used when a UTI has been reported in error

8 Primary Asset Class An indication of which of the 5 major asset classes the data falls under

Describes the classification of the product on which the position is being reported into the primary asset-class of "Credit", "InterestRate", "ForeignExchange", "Equity" or "Commodity"

9 Data Submitter Message ID The submitting firm must enter a string value per message (row within the CSV submission) that they create for tracking submissions. DTCC will repeat this value on outbound messaging and reports but not utilize it for any other purpose (Should be unique per message)

This is a unique value per message in each CSV file. This does not need to be unique across CSV files

10 As of Date/Time On a Position message this field indicates the time that this view of the position is in effect. Position Exit will be processed when received as of the time received.

All positions reported on an UTI, including lifecycle events that result in a restatement of the position during a day, this field is used by the submitter to order the position messages with the latest position message representing the end of day state of the trade. The As of date component can be on the same day as the submission even if the timestamp is later than the submission but you cannot have a future dated As of Date.




DTCC

Page 7 of 32



11 Event ID Party 1 A unique identifier used to identify lifecycle events submitted by Party 1 or where full delegation applies the Party 1 would submit this since it will form part of the common data. For example if 5 partial terminations exist for a specific UTI and submitted on a POSITION message, each one must have a unique EID. This will allow identification of an event.

Not used in OTC Lite - may be used in the future to identify specific lifecycle events reported for Trade Party 1

12 Event ID Party 2 A unique identifier that will be submitted for all applicable lifecycle events by Party 2

Not used in OTC Lite - may be used in the future to identify specific lifecycle events reported for Trade Party 2 (under the full delegation reporting model)

13 Additional Repository 1 Prefix Identifies the value in "Additional Repository 1 Value" when populated (refer to message template for values supported)

14 Additional Repository 1 Value If UTI has been reported to another Repository, the LEI value or alternative ID value of the other repository (or relevant identifier if known)

An Optional field that may be used in the future to identify where the other side of the trade report has been made in the instance that both sides of the UTI do not report to the GTR

15 Reporting Obligation Party 1 Used to enumerate one or more jurisdictions where the trade is reportable.

Identifies the jurisdiction under which Party 1 to the trade is reporting

16 Reporting Obligation Party 2 Used to enumerate one or more jurisdictions where the trade is reportable.

Identifies the jurisdiction under which Party 2 to the trade is reporting (where Party 2 is being reported for as well as Party 1 - see "Submitted For Value" = "Both")

37 Submitted For Prefix Identifies the value in "Submitted For Value" when populated with a specific identifier for Trade Party 1 (refer to message template for values supported)

38 Submitted For Value Indicates the LEI (or valid DTCC participant ID) of the party for which the submission is being made on behalf of, or "BOTH" if submitted as a dual sided message. If not populated then defaults to "Data Submitter" field value

Identifies who the report is being made for. This can be either Trade Party 1 or Both ("Both" should be populated in the instance where Trade Party 1 does not have a reporting obligation under ESMA but is reporting on behalf of Trade Party 2)




DTCC

Page 8 of 32



39 Reporting Delegation Model To identify the reporting model under which this data is being submitted

Identify the reporting delegation model being used to make the report. Independent - Submitter reporting both counterparty data and common data on behalf of Trade Party 1 Full - One party reporting both counterparty data and common data for both Trade parties on the report

44 Execution Agent Party 1 Prefix Identifies the value in "Execution Agent Party 1 Value" when populated (refer to message template for values supported)

45 Execution Agent Party 1 Value LEI of execution agent (Asset Manager) related to party 1

Identifies the Asset Manager that is entitled to view the specific UTI reported by Trade Party 1

46 Execution Agent Party 2 Prefix Identifies the value in "Execution Agent Party 2 Value" when populated (refer to message template for values supported)

47 Execution Agent Party 2 Value LEI of execution agent (Asset Manager) related to party 2

Identifies the Asset Manager that is entitled to view the specific UTI reported by Trade Party 2

58 Party Region Identifies whether Trade Party 1 is domiciled in the EEA or outside the EEA

89 Prior UTI Prefix (repeatable) Identification of a Prefix or Namespace associated with each prior UTI Value to make the each value unique

The Prior UTI Prefix & Value field is used when you would like to maintain an audit trail with a previously reported UTI that has been "Exit"ed, example, where a UTI was reported and subsequently you identify the UTI is incorrect and Exit the original position and submit the new position on the new UTI but populate these fields with the previous UTI

90 Prior UTI Value (repeatable) Indicates the prior UTI Value's related to the position

See "Prior UTI Prefix"

92 Internal Trade reference This is an optional field and can be used to indicate the internal trade reference of the party who submitted the common data

This can be used to report to the GTR an internal trade reference of the trade as represented in your own books and records. This is not reported to regulators but can be used for audit trail purposes.




DTCC

Page 9 of 32



117 Lifecycle event Effective Date Effective Date of the Lifecycle event that resulted in a change in the position. This is Optional at present

Although not specifically mandated by EMIR, this field can be used to populate the effective date of each post trade event that is reported on the position (in some asset-classes this is also known as the "Agreement Date")

147 Placeholder Placeholder field in template No data should be reported in this field (spare field that may be used in the future)

156 Trade Link ID Link ID to link any two trades reported with different UTI's

This field is specifically to enable firms to link two UTI's that are reported separately , example, an FX Swap can be made up of two FX Forwards. The industry has agreed that these are reported as separate UTI's. The "Trade Link ID" can be populated with an identifier that can be used for audit trail purposes to link to two FX Forwards. This field is not reported to regulators at present.

1.3 EMIR RTS Fields



7 UTI Value A Unique Trade ID agreed at the European level, which is provided by the reporting counterparty. If there is no unique trade ID in place, a unique code should be generated and agreed with the other counterparty.

EMIR field = Trade ID and will be a combination of the Prefix + Value to represent the Trade ID. This is unique for each trade and should be agreed by the counterparties prior to reporting or use the agreed industry methodology of UTI creation and sharing (see ISDA website for the UTI whitepaper)

18 Trade Party 1 Value LEI (interim a valid SDO account id) of the first party to the trade

EMIR field = Counterparty ID. Identifies the Trade Party 1 on the trade and should be represented with the LEI of Trade Party 1 but other values are accepted

20 Trade Party 2 Value LEI (interim a valid SDO account id) of the second party to the trade Where Prefix is Freeformattext the actual corporate name of the counterparty should be reported in this field

EMIR field = ID of the other counterparty. Identifies the Trade Party 2 or the counterparty on the trade and should be represented with the LEI of Trade Party 2 but other values are accepted




DTCC

Page 10 of 32



21 Trade Party 1 Domicile Domicile information for Trade Party 1 explicitly provided here

EMIR field = Domicile of the counterparty. Details the information of the registered office, consisting of full address, city and country of the reporting counterparty (Trade Party 1)

22 Trade Party 2 Domicile Domicile information for Trade Party 2 explicitly provided here

Required where reporting for both counterparties. EMIR field = Domicile of the counterparty. Details the information of the registered office , consisting of full address, city and country of the reporting counterparty (Trade Party 2)

25 Trade Party 1 Corporate Sector Corporate sector for Trade Party 1 can be explicitly provided here.

EMIR field = Corporate sector of the counterparty. Describes the nature of the reporting counterparties (Trade Party 1) companies activities and EMIR allows an enumerated list of values (see message template). This field can be left blank where the Trade Party 1 is a non-financial entity under EMIR

26 Trade Party 2 Corporate Sector Corporate sector for Trade Party 2 can be explicitly provided here

Applicable where reporting for both counterparties. EMIR field = Corporate sector of the counterparty. Describes the nature of the reporting counterparties (Trade Party 2) companies activities and EMIR allows an enumerated list of values (see message template). This field can be left blank where the Trade Party 2 is a non-financial entity under EMIR.

27 Trade Party 1 Financial Entity Jurisdiction EMIR - Indicate if the reporting counterparty is a financial counterparty in accordance with Article 2(8,9) of Regulation (EU) No 648/2012.

EMIR field = Financial or non-financial nature of the counterparty. Where Trade Party 1 is a Financial entity as per EMIR rules then this field is applicable and should be populated with ESMA

28 Trade Party 1 Non-financial Entity Jurisdiction EMIR - Indicate if the reporting counterparty is a non- financial counterparty in accordance with Article 2(8,9) of Regulation (EU) No 648/2012.

EMIR field = Financial or non-financial nature of the counterparty. Where Trade Party 1 is a Non-Financial entity as per EMIR rules then this field is applicable and should be populated with ESMA




DTCC

Page 11 of 32



29 Trade Party 2 Financial Entity Jurisdiction EMIR - Indicate if the reporting counterparty (Trade party 2) is a financial or non-financial counterparty in accordance with Article 2(8,9) of Regulation (EU) No 648/2012.

Required where reporting for both counterparties. EMIR field = Financial or non-financial nature of the counterparty. Where Trade Party 2 is a Financial entity as per EMIR rules then this field is applicable and should be populated with ESMA

30 Trade Party 2 Non-financial Entity Jurisdiction EMIR - Indicate if the reporting counterparty (Trade party 2) is a financial or non-financial counterparty in accordance with Article 2(8,9) of Regulation (EU) No 648/2012.

Required where reporting for both counterparties. EMIR field = Financial or non-financial nature of the counterparty. Where Trade Party 2 is a Non-Financial entity as per EMIR rules then this field is applicable and should be populated with ESMA

32 Broker Id Party 1 Value Indicates the broker for Trade Party 1 if applicable

EMIR field = Broker ID. Where Trade Party 1 uses a broker who acts as an intermediary then populate the identification of the broker using either LEI, pre-LEI, SwiftBIC or in the case of an individual a client code

34 Broker Id Party 2 Value Indicates the broker for Party 2 if applicable Applicable where reporting for both counterparties. EMIR field = Broker ID. Where Trade Party 2 uses a broker who acts as an intermediary then populate the identification of the broker using either LEI, pre-LEI, SwiftBIC or in the case of an individual a client code (this may be the same or different broker as Trade Party 1)

36 Data Submitter Value Identifies the party submitting the data. This could be a party to the trade, a CCP, or any legitimate agent for these primary parties

EMIR field = Reporting entity ID. Identifies the entity who is reporting the trade. This may be the same as Trade Party 1 or Trade Party 2 or a third party but must be a registered DTCC participant.

41 Clearing Broker Party 1 Value LEI of Clearing Broker / Futures Clearing Merchant for party 1 if applicable

EMIR field = Clearing member ID. Where the trade is cleared the Clearing Broker for Trade Party 1 must be identified.

43 Clearing Broker Party 2 Value LEI of Clearing Broker / Futures Clearing Merchant for party 2 if applicable

Applicable where reporting for both counterparties. EMIR field = Clearing member ID. Where the trade is cleared the Clearing Broker for Trade Party 2 must be identified.




DTCC

Page 12 of 32



49 Beneficiary ID Party 1 Value The value which combined with the prefix identifies the beneficiary party (e.g. LEI, DTCC ID)

EMIR field = Beneficiary ID. The party subject to the rights and obligations arising from the contract. Where the transaction is executed via a structure, such as a trust or fund, representing a number of beneficiaries, the beneficiary should be identified as that structure. If the beneficiary of the contract is not a counterparty to the contract, the reporting party (Trade Party 1) has to identify the beneficiary using either LEI, pre-LEI, SwiftBIC or in the case of an individual a client code. If the beneficiary is the same as Trade Party 1 then populate this field with the details of Trade Party 1.

51 Beneficiary ID Party 2 Value The value which combined with the prefix identifies the beneficiary party (e.g. LEI, DTCC ID)

Applicable where reporting for both counterparties. EMIR field = Beneficiary ID. The party subject to the rights and obligations arising from the contract. Where the transaction is executed via a structure, such as a trust or fund, representing a number of beneficiaries, the beneficiary should be identified as that structure. If the beneficiary of the contract is not a counterparty to the contract, the reporting party (Trade Party 2) has to identify the beneficiary using either LEI, pre-LEI, SwiftBIC or in the case of an individual a client code. If the beneficiary is the same as Trade Party 1 then populate this field with the details of Trade Party 2.

52 Trading capacity Party 1 Identifies whether Party 1 has concluded the contract as principal on own account (on own behalf or behalf of a client) or as agent for the account of and on behalf of a client.

EMIR field = Trading capacity. Identifies whether Trade Party 1 has concluded the contract as principal on own account (on own behalf or behalf of a client) or as agent for the account of and on behalf of a client.




DTCC

Page 13 of 32



53 Trading capacity Party 2 Identifies whether Party 2 has concluded the contract as principal on own account (on own behalf or behalf of a client) or as agent for the account of and on behalf of a client.

Required where reporting for both counterparties. EMIR field = Trading capacity. Identifies whether Trade Party 2 has concluded the contract as principal on own account (on own behalf or behalf of a client) or as agent for the account of and on behalf of a client.

55 Buyer Value (Party 1) The value which combined with the prefix identifies the buyer of the trade or position from perspective of trade party 1 (e.g. LEI, DTCC ID) Conditional: if "Leg 1 Payer" or " Leg 2 Payer" is populated then Optional, otherwise Required

EMIR field = Counterparty side. The GTR will derive the counterparty side when this field is populated. This must be populated from the perspective of Trade Party 1, example, Trade Party 1 is buying a call option from Trade Party 2 then this field will identify Trade Party 1 as the buyer. On certain Interest Rate and FX trades the buyer cannot be determined through industry best practice guidelines and therefore refer to fields named "Leg 1 Payer" and "Leg 2 Payer"

57 Buyer Value (Party 2) The value which combined with the prefix identifies the buyer of the trade or position from perspective of trade party 2 (e.g. LEI, DTCC ID) when the reporting party ("Data Submitter") is not a counterparty on the trade and is reporting on behalf of both counterparties ("Submitted for" = "Both")

Required where reporting for both counterparties. EMIR field = Counterparty side. The GTR will derive the counterparty side when this field is populated. This must be populated from the perspective of Trade Party 2, example, Trade Party 1 is buying a call option from Trade Party 2 then this field will identify Trade Party 1 as the buyer. This field, if populated, should always have the same value as Buyer Value (Party 1)

59 Counterparty Region For EMIR: Indication whether the other party is domiciled outside the EEA (European Economic Area).

EMIR field = Contract with non-EEA counterparty. Identifies whether the counterparty on the trade (Trade Party 2) is in the EEA (European Economic Area) or outside the EEA. Counterparty Region is required for ESMA reporting (Trade with non-EEA counterparty)




DTCC

Page 14 of 32



60 Directly linked to commercial activity or treasury financing Party 1

Information on whether the contract is objectively measurable as directly linked to the reporting counterparty's commercial or treasury financing activity, as referred to in Art. 10(3) of Regulation (EU) No 648/2012. This field shall be left blank in case the reporting counterparty is a financial counterparty, as referred to in Art. 2 (8) Regulation (EU) No 648/2012.

EMIR field = Directly linked to commercial activity or treasury financing. Information on whether the contract is objectively measurable as directly linked to the reporting counterparty's (Trade Party 1) commercial or treasury financing activity, as referred to in Art. 10(3) of Regulation (EU) No 648/2012. This field shall be left blank in case the reporting counterparty (Trade Party 1) is a financial counterparty, as referred to in Art. 2 (8) Regulation (EU) No 648/2012.

61 Directly linked to commercial activity or treasury financing Party 2

Information on whether the contract is objectively measurable as directly linked to the reporting counterparty's commercial or treasury financing activity, as referred to in Art. 10(3) of Regulation (EU) No 648/2012. This field shall be left blank in case the reporting counterparty is a financial counterparty, as referred to in Art. 2 (8) Regulation (EU) No 648/2012.

Applicable where reporting for both counterparties. EMIR field = Directly linked to commercial activity or treasury financing. Information on whether the contract is objectively measurable as directly linked to the reporting counterparty's (Trade Party 2) commercial or treasury financing activity, as referred to in Art. 10(3) of Regulation (EU) No 648/2012. This field shall be left blank in case the reporting counterparty (Trade Party 2) is a financial counterparty, as referred to in Art. 2 (8) Regulation (EU) No 648/2012. The Directly linked to commercial activity or treasury financing Party 2 is required to be populated if Party 2 is a non-financial entity.

62 MTM Value Party 1 Calculated MTM value EMIR field = Mark to market value of contract. Mark to market valuation of the contract, or mark to model valuation where applicable under Article 11(2) of Regulation (EC) No 648/2012. This is the valuation populated by Trade Party 1 for their side of the trade. If submitted for Party 1, CCP Values or Party 1 is required. If submitted for both, CCP Values required OR Party 1 and Party 2 required.




DTCC

Page 15 of 32



63 MTM Value Party 2 MTM value as generated by party 2 Applicable where reporting for both counterparties. EMIR field = Mark to market value of contract. Mark to market valuation of the contract, or mark to model valuation where applicable under Article 11(2) of Regulation (EC) No 648/2012. This is the valuation populated by Trade Party 2 for their side of the trade. If submitted for Party 2, CCP Values or Party 2 is required. If submitted for both, CCP Values required OR Party 1 and Party 2 required.

64 MTM Value CCP To distinguish when a counterparty is sending a CCP valuation as their counterparty valuation data

EMIR field = Mark to market value of contract. Mark to market valuation of the contract, or mark to model valuation where applicable under Article 11(2) of Regulation (EC) No 648/2012. This is the valuation populated provided by the CCP where a trade is cleared. It can be submitted by the reporting party (Trade Party 1) and will take precedence when populated.

65 MTM Currency Party 1 Native currency of the calculated MTM value EMIR field = Currency of the mark to market value of contract. Currency of the valuation populated by Trade Party 1.

66 MTM Currency Party 2 Currency in which the MTM value is reported by Party 2

Applicable where reporting for both counterparties. EMIR field = Currency of the mark to market value of contract. Currency of the valuation populated by Trade Party 2.

67 MTM Currency CCP Currency in which the MTM value is reported by CCP

EMIR field = Currency of the mark to market value of contract. Currency of the valuation populated in the "MTM Value CCP" field.

68 Valuation Datetime Party 1 Date and time of the valuation in UTC EMIR field = Valuation Date and Valuation Time. Identifies a timestamp for the valuation provided by Trade Party 1. This is a timestamp rather than two separate fields as described in the EMIR RTS. The UTC date/time format must be followed.




DTCC

Page 16 of 32



69 Valuation Datetime Party 2 Date time the valuation was generated by Party 2 in UTC

Applicable where reporting for both counterparties. EMIR field = Valuation Date and Valuation Time. Identifies a timestamp for the valuation provided by Trade Party 2. This is a timestamp rather than two separate fields as described in the EMIR RTS. The UTC date/time format must be followed.

70 Valuation Datetime CCP Date time the valuation was generated by CCP in UTC

EMIR field = Valuation Date and Valuation Time. Identifies a timestamp for the valuation populated in "MTM Value CCP". This is a timestamp rather than two separate fields as described in the EMIR RTS. The UTC date/time format must be followed.

71 Valuation Type Party 1 Reference model used by party 1 to calculate daily mark

EMIR field = Valuation type. Identifies whether the valuation provided by Trade Party 1 was performed mark to market or mark to model.

72 Valuation Type Party 2 Reference model used by party 2 to calculate daily mark

Applicable where reporting for both counterparties. EMIR field = Valuation type. Identifies whether the valuation provided by Trade Party 2 was performed mark to market or mark to model.

73 Valuation Type CCP Reference model used by CCP to calculate daily mark

EMIR field = Valuation type. Identifies whether the valuation populated in "MTM Value CCP" was performed mark to market or mark to model.

74 Collateralized Party 1 Indication of whether the contract is collateralized and how.

EMIR field = Collateralisation. Identifies whether the trade is collateralised and on what basis from Trade Party 1 perspective.

75 Collateralized Party 2 Indication of whether the contract is collateralized and how from trade party 2's perspective

Applicable where reporting for both counterparties. EMIR field = Collateralisation. Identifies whether the trade is collateralised and on what basis from Trade Party 2 perspective.

76 Collateral portfolio code Party 1 If collateral is reported on a portfolio basis, the portfolio should be identified by a unique code determined by the reporting counterparty.

EMIR field = Collateral portfolio code. If collateral is reported on a portfolio basis, the portfolio should be identified by a unique code determined by the reporting counterparty (Trade Party 1). The indication of a collateral




DTCC

Page 17 of 32



portfolio code indicates that the collateralisation was performed on a portfolio basis.

77 Collateral portfolio code Party 2 If collateral is reported on a portfolio basis, the portfolio should be identified by a unique code determined by Party 2.

Applicable where reporting for both counterparties. EMIR field = Collateral portfolio code. If collateral is reported on a portfolio basis, the portfolio should be identified by a unique code determined by the reporting counterparty (Trade Party 2). The indication of a collateral portfolio code indicates that the collateralisation was performed on a portfolio basis.

78 Value of the collateral Party 1 (repeatable values) Value of the collateral posted by Party 1 to the other counterparty. Where collateral is posted on a portfolio basis, this field should include the value of all collateral posted for the portfolio.

EMIR field = Value of the collateral. Value of the collateral posted by Trade Party 1 to the other counterparty. Where collateral is posted on a portfolio basis, this field should include the value of all collateral posted for the portfolio. This field will be made repeatable to include multiple values where the collateral is held in more than one currency.

79 Value of the collateral Party 2 (repeatable values) Value of the collateral posted by Party 2 to the other counterparty. Where collateral is posted on a portfolio basis, this field should include the value of all collateral posted for the portfolio.

Applicable where reporting for both counterparties. EMIR field = Value of the collateral. Value of the collateral posted by Trade Party 2 to the other counterparty. Where collateral is posted on a portfolio basis, this field should include the value of all collateral posted for the portfolio. This field will be made repeatable to include multiple values where the collateral is held in more than one currency.




DTCC

Page 18 of 32



80 Currency of the collateral value Party 1 (repeatable values) Specify the currency of the value of the collateral for Party 1 To accommodate the possible delegation of dual reporting to one party, the Counterparty Data fields are included in this specification twice; once for Party 1 and once for Party 2. Refer also to the Party 2 instance of this field when reporting for both parties.

EMIR field = Currency of the collateral value. Specify the currency of the value of the collateral for Trade Party 1. This field will be made repeatable to include multiple values where the collateral is held in more than one currency and each value should be associated with the values populated in "Value of the collateral Party 1" field.

81 Currency of the collateral value Party 2 (repeatable values) Specify the currency of the value of the collateral for Party 2

Applicable where reporting for both counterparties. EMIR field = Currency of the collateral value. Specify the currency of the value of the collateral for Trade Party 2. This field will be made repeatable to include multiple values where the collateral is held in more than one currency and each value should be associated with the values populated in "Value of the collateral Party 2" field.

82 Product ID Prefix 1 Indication of the taxonomy used EMIR field = Taxonomy used. Indicate what taxonomy is used to report the common data on the trade. The GTR supports the ISDA taxonomy and therefore the value "ISDA" would be populated in this field. The GTR will derive the interim taxonomy values to be reported to the regulators based on the ISDA taxonomy value populated in "Product ID Value 1" below.

83 Product ID Value 1 Specify the value of the taxonomy used EMIR field = Product ID 1. Indicate the relevant ISDA taxonomy value in this field. Until such time as there is an endorsed UPI for OTC derivatives, the GTR will derive the interim taxonomy values ("E") to be reported to the regulators based on the ISDA taxonomy value populated in this field (refer to message template for a full list of ISDA product taxonomy values supported)




DTCC

Page 19 of 32



84 Product ID Prefix 2 Indication of the taxonomy used EMIR field = Taxonomy used. Where the ISDA taxonomy value is populated in "Product ID Value 1" or an UPI is endorsed and populated in above fields then this field can be left blank. However, where the interim taxonomy is populated above i.e. "E" then this field must be populated with "E" and the field "Product ID Value 2" must be populated with the relevant EMIR prescribed value.

85 Product ID Value 2 Specify the second value of the taxonomy used

EMIR field = Product ID 2. Where the ISDA taxonomy value is populated in "Product ID Value 1" or an UPI is endorsed and populated in above fields then this field can be left blank. However, where the interim taxonomy is populated above i.e. "E" then this field must be populated with the relevant EMIR prescribed value (see the message template for a list of allowed values). Industry best practice for OTC's is to use the ISDA taxonomy as described above.

86 Underlying Asset (repeatable up to 2 times semi-colon separated)

The underlying asset, reference asset or reference obligation for payments of a party’s obligations under the reportable transaction. The underlying asset may be a reference price, index, obligation, physical commodity with delivery point, futures contract or any other instrument agreed to by the parties to a reportable transaction. (EMIR - The underlying shall be identified by using a unique identifier for this underlying. In case of baskets or indices, an indication for this basket or index shall be used where a unique identifier does not exist) Interest Rate Swap - underlying asset is populated for leg 1 and leg 2 (semi-colon separated)

EMIR field = Underlying. The underlying shall be identified by using a unique identifier for this underlying. In case of baskets or indices, an indication for this basket or index shall be used where a unique identifier does not exist. The GTR can accept more types of underlying assets described than EMIR allows therefore the GTR will only report a value in this field if one of the following values for the underlying is populated, ISIN, UPI, LEI or pre-LEI, Basket or Index. The identifier in this field is described in field 150 "Underlying Asset Identifier Type". Where a RED ID (Credit derivatives) or a RIC (Equity derivatives) is supplied and the GTR can derive the ISIN from the relevant static data supplied then the ISIN will be reported. Best practice is to provide the ISIN where possible. Industry consensus indicates that Rates (with the exception of Debt options on an underlying bond), FX and Commodity trades do not have




DTCC

Page 20 of 32



an appropriate underlying to populate in this field.

87 Notional Currency/Units (repeatable up to 2 times semi-colon separated)

An indication of the type of currency that the notional amount is in. : Repeating field - one per leg

EMIR field = Notional currency 1 and Notional currency 2. Describe the currency of the notional amount and where there are two legs of a trade (Rates in particular) populate for both legs. For FX populate one currency that describes the currency of the notional amount and the second currency is populated in field 127 "Currency 2". For Commodity trades populate the unit that describes the notional amount indicated.

88 Settlement Currency (repeatable up to 2 times semi-colon separated)

Currency of settlement. EMIR field = Deliverable currency. Indicate the delivery currency. Provide for both leg 1 and leg 2 where appropriate.

91 Transaction Reference Number Unique identification number of the transaction provided by the reporting entity or third party reporting on its behalf.

EMIR field = Transaction reference number. See the ESMA Q&A for a description of the expected value in this field. EMIR describes this as a unique identification number of the transaction provided by the reporting entity or third party reporting on its behalf.

94 Execution Venue Value An indication of the venue of execution of a reportable swap transaction.

EMIR field = Venue of execution. An indication of the venue of execution of a reportable swap transaction. For OTC derivatives this field should be populated with "XXXX".




DTCC

Page 21 of 32



95 Price Notation - Price The price, yield, spread or rate, depending on the type of product. The price should exclude commission and accrued interest, where applicable

EMIR field = Price / rate. The price of the OTC trade and should exclude commission and accrued interest, where applicable.

96 Price Notation - Price Type Describes how to interpret the quoted price EMIR field = Price notation. Describes the manner in which the price is expressed i.e. describes the value populated in field 95 "Price Notation - Price"

97 Notional Amount (repeatable up to 2 times semi-colon separated)

Original value of the contract (repeatable where more than one notional on a trade)

EMIR field = Notional amount. Original value of the contract and can be populated for leg 1 and leg 2 where applicable. The GTR requires this field to be updated with the resulting notional following each subsequent post trade event (lifecycle event).

98 Price Multiplier Number of units of the fin. Instrument which are contained in a trading lot; e.g. number of derivatives represented by one contract

EMIR field = Price Multiplier. Number of units of the financial instrument which are contained in a trading lot; e.g. number of derivatives represented by one contract. Price Multiplier must be provided. For FX, Rates, and Credit, trades a value of 1 should be submitted.

99 Quantity Number of contracts included in the report where more than one derivative contract is reported

EMIR field = Quantity. Number of contracts included in the report where more than one derivative contract is reported. The best practice is for most Rates, Credit and FX OTC derivative trades the value in this field will be 1. For Equities and Commodities populate the number of underlying shares or options or units traded in the contract.

100 Upfront payment (repeatable up to 6 times semi-colon separated)

Amount of any up-front payment the reporting counterparty made or received

EMIR field = Upfront payment. Amount of any up-front payment the reporting counterparty made or received and this field should be used to populate any premium amount.

102 Delivery type Indicates whether the contract is settled physically or in cash

EMIR field = Delivery type. Indicates whether the contract is settled physically or in cash or in some instances elected which would be populated as "O" (optional for counterparty)




DTCC

Page 22 of 32



103 Execution Timestamp The time and date of execution of the reportable swap transaction in Coordinated Universal Time (UTC). The time-stamp shall be displayed with two digits for each of the hour, minute and second.

EMIR field = Execution timestamp. The time and date of execution of the reportable swap transaction in Coordinated Universal Time (UTC).

104 Effective Date (repeatable up to 2 times semi-colon separated)

Effective Date of the Contract: the date when obligations under the contract come into effect

EMIR field = Effective date. Effective Date of the Contract: the date when obligations under the contract come into effect and can be identified for leg 1 and leg 2 where applicable. The best practice for Equities is to populate the Trade Date in this field as agreed by the industry. The field can also be used to populate an effective date in the future where the trade has a forward starting date.

105 Scheduled Termination Date Original date of expiry of the reported contracts (or Option Expiration Date if an option contract). An early termination shall not be reported in this field

EMIR field = Maturity Date. Original date of expiry of the reported contracts (or Option Expiration Date if an option contract). An early termination shall not be reported in this field

106 Termination Date Termination date of the reported contract. If not different from "Scheduled Termination Date" this field shall be left blank

EMIR field = Termination date. Termination date of the reported contract. If not different from "Scheduled Termination Date" this field shall be left blank.

107 Date of Settlement (repeatable up to 2 times semi-colon separated)

Date of settlement of the underlying. If more than one, further fields may be used (e.g. 23A, 23B, 23C…)

EMIR field = Date of Settlement. Date of settlement of the underlying and can be populated for leg 1 and leg 2. The best practice by asset class should be followed by populating one of the relevant values which indicates Rates should populate Payment Date (Unadjusted), Additional Payment payment date, Premium settlement date/Premium Payment Date, Cash settlement payment dates, Optional early termination adjusted cash settlement payment date, Settlement Date (unadjusted); Equities should populate Valuation Date, Option Valuation Date, Exotic Valuation Date, Digital Option Valuation Date, Premium Payment Date; Commodities should populate Fixed Leg Payment Dates, Floating Leg 1 Payment Dates, Floating Leg 2 Payment Dates, Option Exercise Payment Dates, Option




DTCC

Page 23 of 32



Premium Payment Date, Commodity Forward Average Price Leg Payment Dates, Physical Bullion Settlement Date, Exotic Premium Payment Date; Credit is not applicable

108 Cleared Indicates whether clearing has taken place. EMIR field = Cleared. If the trade is a cleared trade and has cleared then indicate "true" in this field. Otherwise populate false if the trade is not cleared.

109 Clearing Timestamp Timestamp of when the trade was cleared EMIR field = Clearing timestamp. If the trade has cleared then indicate the timestamp of when the trade was cleared.

111 Clearing DCO Value Indication if the trade will be cleared, and where. Valid values are the LEI (interim a valid SDO account id) of CCP if cleared and known at the time.

EMIR field = CCP ID. Identifies where the trade will be cleared. This should be the LEI of the CCP.

112 Intragroup Indicates whether the contract was entered into as an intra-group transaction, defined in Article 3 of Regulation (EU) No 648/2012.

EMIR field = Intragroup. Indicates whether the contract was entered into as an intra-group transaction, defined in Article 3 of Regulation (EU) No 648/2012. Populate this field with "true" if the trade is an intra-group trade or "false" if the trade is not an intra-group trade.

113 Option Type An indication of the type of option. EMIR field = Option type. An indication of the type of option. The only values ESMA will accept are "P" (put) or "C" (call).




DTCC

Page 24 of 32



114 Option Style Indicates type of option (European, American, etc.)

EMIR field = Option style (exercise). Indicates type of option and ESMA will accept European, American, Bermudan or Asian

115 Option Strike Price Strike price for the option (can be a price or a percentage but represented as a price, example, percentage of par = 101.25)

EMIR field = Strike price (cap/floor rate). Indicate the strike price of the option. For a cap or floor the strike price should be populated with a numeric number but represents a percentage. The description of what value is populated in this field "Option Strike Price" must be populated in either field 116 "Option Strike Price CCY" if this is a currency value or field 155 "Option Strike Price Type" if this represents a percentage in the case of a cap or floor or similar product.

118 Lifecycle Event Although the position snapshot will always hold the current position notional, there are cases where a position message submission is triggered as a result of an event on intra-day basis. This field should be populated with the event that triggered the position message if applicable.

EMIR field = Action Type / Details of Action Type. This field works together with field 4 "Action" and field 5 "Transaction Type" but must be populated with the relevant event description for each message submitted. (see the User Guide for further details on how the GTR interprets the values in these fields and reports them to ESMA as per the EMIR RTS)

119 Fixed rate of leg 1 (Interest Rates only) An indication of the fixed rate leg 1 used, if applicable.

EMIR field = Fixed rate of leg 1. An indication of the fixed rate leg 1 used, if applicable which would be the Fixed Rate (initial) - leg 1

120 Fixed rate of leg 2 (Interest Rates only) An indication of the fixed rate leg 2 used, if applicable.

EMIR field = Fixed rate of leg 2. An indication of the fixed rate leg 2 used, if applicable which would be the Fixed Rate (initial) - leg 2

121 Fixed rate day count (Interest Rates only) (repeatable up to 2 times semi-colon separated)

The actual number of days in the relevant fixed rate payer calculation period, if applicable. Repeated for leg 2

EMIR field = Fixed rate day count. The actual number of days in the relevant fixed rate payer calculation period, if applicable and can populate for leg 1 and leg 2.

122 Fixed leg payment frequency (Interest Rates only) (repeatable up to 2 times semi-colon separated)

Frequency of payments for the fixed rate leg, if applicable. Repeated for leg 2

EMIR field = Fixed leg payment frequency. Frequency of payments for the fixed rate leg, if applicable and can populate for leg 1 and leg 2.




DTCC

Page 25 of 32



123 Floating rate payment frequency (Interest Rates only) (repeatable up to 2 times semi-colon separated)

Frequency of payments for the floating rate leg, if applicable. Repeated for leg 2

EMIR field = Floating rate payment frequency. Frequency of payments for the floating rate leg, if applicable and can populate for leg 1 and leg 2.

124 Floating rate reset frequency (Interest Rates only) (repeatable up to 2 times semi-colon separated)

Frequency of floating rate leg resets, if applicable. Repeated for leg 2

EMIR field = Floating rate reset frequency. Frequency of floating rate leg resets, if applicable and can populate for leg 1 and leg 2.

125 Floating rate of leg 1 (Interest Rates only) (repeatable up to 2 times semi-colon separated)

An indication of the interest rates used which are reset at predetermined intervals by reference to a market reference rate, if applicable. Repeated for leg 2

EMIR field = Floating rate of leg 1. An indication of the interest rates used which are reset at predetermined intervals by reference to a market reference rate, if applicable. Best practice is to populate this with either Floating Rate Index - leg 1 or Floating Rate Spread (initial) - leg 1

126 Floating rate of leg 2 (Interest Rates only) (repeatable up to 2 times semi-colon separated)

An indication of the interest rates used which are reset at predetermined intervals by reference to a market reference rate, if applicable. Repeated for leg 2

EMIR field = Floating rate of leg 2. An indication of the interest rates used which are reset at predetermined intervals by reference to a market reference rate, if applicable. Best practice is to populate this with either Floating Rate Index - leg 2 or Floating Rate Spread (initial) - leg 2

127 Currency 2 (Foreign exchange only) The cross currency, if different from the currency of delivery.

EMIR field = Currency 2. The cross currency, if different from the currency of delivery. There are always two currencies in a quote basis, the second currency quoted, will always be Notional Currency 2, example EUR/USD = USD will be Notional Currency 2.

128 Exchange rate 1 (Foreign exchange only) The contractual rate of exchange of the currencies.

EMIR field = Exchange rate 1. The contractual rate of exchange of the currencies.

129 Forward exchange rate (Foreign exchange only) Forward exchange rate on value date. EMIR field = Forward exchange rate. The FX industry has deemed this field is not applicable for FX OTC derivatives. For FX Forwards this would be the same rate as field 128

130 Exchange rate basis (Foreign exchange only) Quote base for exchange rate. EMIR field = Exchange rate basis. Quote base for exchange rate, example EUR/USD

131 Commodity base (Commodities only - general) (repeatable up to 2 times semi-colon separated)

Indicates the type of commodity underlying the contract.

EMIR field = Commodity base. Indicates the type of commodity underlying the contract (see message template for supported values)




DTCC

Page 26 of 32



132 Commodity details (Commodities only - general) (repeatable up to 2 times semi-colon separated)

Details of the particular commodity beyond the "Commodity base"

EMIR field = Commodity details. Details of the particular commodity beyond the "Commodity base" (see message template for supported values)

133 Delivery point or zone (Commodities only - energy) (repeatable up to 2 times semi-colon separated)

Delivery points(s) of market area(s). EMIR field = Delivery point or zone. Delivery points(s) of market area(s) and the field allows for 2 values (mostly applicable to energy trades)

134 Interconnection Point (Commodities only - energy) Identification of the border(s) or border point(s) of a transportation contract.

EMIR field = Interconnection Point. Identification of the border(s) or border point(s) of a transportation contract (mostly applicable to energy trades)

135 Load type (Commodities only - energy) Repeatable section of EMIR fields 50-54 to identify the product delivery profile which correspond to the delivery periods of a day. (repeatable in line with GTR field # 136 - 140)

EMIR field = Load type. Repeatable section of EMIR fields 50-54 to identify the product delivery profile which correspond to the delivery periods of a day. (repeatable in line with GTR field # 136 - 140)

136 Delivery start date and time (Commodities only - energy) (repeatable up to 12 times semi-colon separated)

Start date and time of delivery. EMIR field = Delivery start date and time. Start date and time of delivery and the field allows for 12 values (mostly applicable to energy trades)

137 Delivery end date and time (Commodities only - energy) (repeatable up to 12 times semi-colon separated)

End date and time of delivery. EMIR field = Delivery end date and time. End date and time of delivery and the field allows for 12 values (mostly applicable to energy trades)

138 Contract capacity (Commodities only - energy) (repeatable up to 24 times semi-colon separated)

Quantity per delivery time interval. EMIR field = Contract capacity. Quantity per delivery time interval and the field allows for 24 values (mostly applicable to energy trades)

139 Quantity Unit (Commodities only - energy) (repeatable up to 2 times semi-colon separated)

Daily or hourly quantity in MWh or kWh/d which corresponds to the underlying commodity.

EMIR field = Quantity Unit. Daily or hourly quantity in MWh or kWh/d which corresponds to the underlying commodity and the field allows for 2 values (mostly applicable to energy trades)

140 Price/time interval quantities (Commodities only - energy) (repeatable up to 24 times semi-colon separated)

If applicable, price per time interval quantities.

EMIR field = Price/time interval quantities. If applicable, price per time interval quantities and the field allows for 24 values.




DTCC

Page 27 of 32



141 Clearing Threshold Party 1 Information on whether the reporting counterparty is above the clearing threshold as referred to in Art. 10(3) of Regulation (EU) No 648/2012. This field shall be left blank in case the reporting counterparty is a financial counterparty, as referred to in Art. 2 (8) Regulation (EU) No 648/2012.

EMIR field = Clearing threshold. Information on whether the reporting counterparty (Trade Party 1) is above the clearing threshold as referred to in Art. 10(3) of Regulation (EU) No 648/2012. This field shall be left blank in case the reporting counterparty (Trade Party 1) is a financial counterparty, as referred to in Art. 2 (8) Regulation (EU) No 648/2012. Indicate "true" if above the clearing threshold or "false" if below the clearing threshold.

142 Clearing Threshold Party 2 Information on whether the reporting counterparty is above the clearing threshold as referred to in Art. 10(3) of Regulation (EU) No 648/2012. This field shall be left blank in case the reporting counterparty is a financial counterparty, as referred to in Art. 2 (8) Regulation (EU) No 648/2012.

Applicable where reporting for both counterparties. EMIR field = Clearing threshold. Information on whether the reporting counterparty (Trade Party 2) is above the clearing threshold as referred to in Art. 10(3) of Regulation (EU) No 648/2012. This field shall be left blank in case the reporting counterparty (Trade Party 2) is a financial counterparty, as referred to in Art. 2 (8) Regulation (EU) No 648/2012. Indicate "true" if above the clearing threshold or "false" if below the clearing threshold. Clearing Threshold Party 2 is required when Trade Party 2 Non-financial Entity Jurisdiction is “ESMA.”

143 Compression Indication that the trade is a result of a compression

EMIR field = Compression. Indication that the trade is a result of a compression and therefore this field would be "true" if the UTI or trade was as a result of a compression event.

144 Confirmation Date Time Denotes the business date and time of the confirm

EMIR field = Confirmation timestamp. Denotes the business date and time of the confirm.

145 Confirmation Type Indication of whether the trade was confirmed electronically or otherwise

EMIR field = Confirmation means. Indication of whether the trade was confirmed electronically or otherwise (other values supported are NonElectronic and NotConfirmed)




DTCC

Page 28 of 32



146 Mandatory Clearing Indicator A list of jurisdictions where the product requires mandatory clearing. Allowable values: ESMA-Y, ESMA-N, ESMA-X. An entry of “ESMA-X” will be inputted until a list of mandatorily clearable products is published by ESMA.

EMIR field = Clearing Obligation. Once ESMA formulate a list of mandatory clearable products then if the trade is on such a product this field will indicate "ESMA”. (Refer to the ESMA website when this list is available).

151 Master Agreement type Reference to the name of the relevant master agreement, if used for the reported contract (e.g. ISDA Master Agreement, International Purchase and Sale Agreement, International Forex Master Agreement, European Master Agreement or any local Master Agreement)

EMIR field = Master Agreement type. Reference to the name of the relevant master agreement, if used for the reported contract (e.g. ISDA Master Agreement, International Purchase and Sale Agreement, International Forex Master Agreement, European Master Agreement or any local Master Agreement)

152 Master Agreement version Reference to the year of the master agreement version used for the reported trade, if applicable (e.g. 1992, 2002)

EMIR field = Master Agreement version. Reference to the year of the master agreement version used for the reported trade, if applicable (e.g. 1992, 2002)

1.4 GTR Control & EMIR RTS Fields



6 UTI Prefix Identification of a prefix or namespace associated with a UTI value to make the value unique

Industry best practice is to populate a Prefix in UTI Prefix that together with UTI Value will ensure uniqueness of the UTI (EMIR field = Trade ID). This field will be concatenated with "UTI Value" to form the Trade ID for EMIR reporting. (see industry best practice on UTI, ISDA website)




DTCC

Page 29 of 32



17 Trade Party 1 Prefix Prefix for the value provided in the "Trade Party 1 Value" field (ex. 'BIC') To accommodate the possible delegation of dual reporting to one party, the Counterparty Data fields are included in this specification twice; once for Party 1 and once for Party 2. Refer also to the Party 2 instance of this field when reporting for both parties.

Identifies the value populated in "Trade Party 1 Value". An LEI is the preferred identifier and ESMA has indicated that in their Q&A. The GTR allows other values where appropriate (see the message template for valid values)

19 Trade Party 2 Prefix Prefix for the value provided in the "Trade Party 2 Value" field (ex. 'BIC')

Identifies the value populated in "Trade Party 2 Value". An LEI is the preferred identifier and ESMA has indicated that in their Q&A. The GTR allows other values where appropriate (see the message template for valid values)

23 Trade Party 1 Branch Location In the case of a trade being entered into by the overseas branch of a legal entity this indicates the country of the branch. This field will cause regulatory reports to be created for the regulators in country identified, in addition to the prudential regulator of the legal entity.

This field is not strictly an EMIR required field however where a trade is executed by the branch of a legal entity identified in Trade Party 1 then the branch must be identified in this field by indicating the country code of the branch (2 digit ISO country code). This enables the GTR to report the trade to the relevant National Competent Authority (NCA) in whose jurisdiction the branch is authorised.

24 Trade Party 2 Branch Location In the case of a trade being entered into by the overseas branch of a legal entity this indicates the country of the branch. This field will cause regulatory reports to be created for the regulators in country identified, in addition to the prudential regulator of the legal entity.

This field is not strictly an EMIR required field however where a trade is executed by the branch of a legal entity identified in Trade Party 2 then the branch must be identified in this field by indicating the country code of the branch (2 digit ISO country code). This enables the GTR to report the trade to the relevant National Competent Authority (NCA) in whose jurisdiction the branch is authorised.

31 Broker Id Party 1 Prefix Prefix for the value provided in the "Broker Id Party 1 Value" field (ex. 'BIC')

Identifies the value populated in "Broker Id Party 1 Value". An LEI is the preferred identifier. The GTR allows other values where appropriate (see the message template for valid values)




DTCC

Page 30 of 32



33 Broker Id Party 2 Prefix Prefix for the value provided in the "Broker Id Party 2 Value" field (ex. 'BIC')

Identifies the value populated in "Broker Id Party 2 Value". An LEI is the preferred identifier. The GTR allows other values where appropriate (see the message template for valid values)

35 Data Submitter Prefix Prefix for the value provided in the "Data Submitter Value" field (ex. 'BIC')

Identifies the value populated in "Data Submitter Value". A DTCC ID is the preferred identifier as the GTR always needs to know the data submitter. A submitter must be onboarded to the GTR and have a valid DTCC participant ID as well as be permissioned to report on behalf of Trade party 1 or Both.

40 Clearing Broker Party 1 Prefix Prefix of Clearing Broker / Futures Clearing Merchant for party 1 if applicable

Identifies the value populated in "Clearing Broker Party 1 Value". An LEI is the preferred identifier. The GTR allows other values where appropriate (see the message template for valid values)

42 Clearing Broker Party 2 Prefix Prefix of Clearing Broker / Futures Clearing Merchant for party 2 if applicable

Identifies the value populated in "Clearing Broker Party 2 Value". An LEI is the preferred identifier. The GTR allows other values where appropriate (see the message template for valid values)

48 Beneficiary ID Party 1 Prefix The prefix for the value provided in the Beneficiary ID Party 1 Value field

Identifies the value populated in "Beneficiary ID Party 1 Value". An LEI is the preferred identifier. The GTR allows other values where appropriate (see the message template for valid values)

50 Beneficiary ID Party 2 Prefix The prefix for the value provided in the Beneficiary ID Party 2 Value field

Identifies the value populated in "Beneficiary ID Party 2 Value". An LEI is the preferred identifier. The GTR allows other values where appropriate (see the message template for valid values)

54 Buyer Prefix (Party 1) Prefix for the value in the Buyer Value (Party 1) field

Identifies the value populated in "Buyer Value (Party 1)". An LEI is the preferred identifier. The GTR allows other values where appropriate (see the message template for valid values)




DTCC

Page 31 of 32



56 Buyer Prefix (Party 2) Prefix for the value in the Buyer Value (Party 2) field

Identifies the value populated in "Buyer Value (Party 2)". An LEI is the preferred identifier. The GTR allows other values where appropriate (see the message template for valid values)

93 Execution Venue Prefix Prefix for the value provided in the "Execution Venue Value" field (ex. 'MIC')

Identifies the value populated in "Execution Venue Value". An LEI is the preferred identifier. The GTR allows other values where appropriate (see the message template for valid values). For OTC derivatives this field is not applicable when the value populated in "Execution Venue Value" is "XXXX"

101 Upfront payment CCY (repeatable up to 6 times semi-colon separated)

Conditional where Upfront Payment is populated

Identifies the currency/ies of the value/s populated in "Upfront payment" using a valid ISO currency code

110 Clearing DCO Prefix Prefix for the value provided in the "Clearing DCO Value" field (ex. 'BIC'). Required when "Clearing DCO Value" field contains an LEI (or interim code)

Identifies the value populated in "Clearing DCO Value". An LEI is the preferred identifier. The GTR allows other values where appropriate (see the message template for valid values).

116 Option Strike Price CCY Currency of Strike price for the Option Identifies the currency of the value populated in "Option Strike Price" using a valid ISO currency code. When "Option Strike Price" is populated then either "Option Strike Price CCY" or "Option Strike Price Type" is required.

148 Name of Trade Party 1 Indicate the name of the counterparty. If Trade Party 1 has been identified with an LEI, DTCC participant ID, CICI or AVID (AVOX ID) then the trade repository can derive the name of the counterparty. However, any other identifier used will need to be supplemented with the name of the counterparty in this field

This field must be populated when Trade Party 1 has been identified by using either a SwiftBIC, EIC, "Internal" or "Freeformattext" value.

149 Name of Trade Party 2 Indicate the name of the counterparty. If Trade Party 2 has been identified with an LEI, DTCC participant ID, CICI or AVID (AVOX ID) then the trade repository can derive the name of the counterparty. However, any other identifier used will need to be supplemented with the name of the counterparty in this field

This field must be populated when Trade Party 2 has been identified by using either a SwiftBIC, EIC, "Internal" or "Freeformattext" value.




DTCC

Page 32 of 32



150 Underlying Asset Identifier Type (repeatable 2 times) The prefix to identify the value indicated in "Underlying Asset" which could be an LEI, ISIN, Interim Entity Identifier, UPI or indicate the underlying asset is basket or index

Identifies the type of value populated in "Underlying Asset"

153 Leg 1 Payer Interest Rate trade only - Identification of the payer of leg 1

This field must be populated when "Buyer Value (Party 1)" is blank. The field should indicate which trade party is the leg 1 payer. Valid values are "Trade Party 1" or "Trade Party 2"

154 Leg 2 Payer Interest Rate trade only - Identification of the payer of leg 2

This field must be populated when "Buyer Value (Party 1)" is blank. The field should indicate which trade party is the leg 2 payer. Valid values are "Trade Party 1" or "Trade Party 2"

155 Option Strike Price Type Where the Option Strike Price is a percentage of par then use this field to populate the type

Identifies the type of the value populated in "Option Strike Price" when this is not a currency, example, percentage (when referring to a cap or floor). When "Option Strike Price" is populated then either "Option Strike Price CCY" or "Option Strike Price Type" is required.

Documents

User Guide - Supplement - The Depository Trust & …/media/Files/Downloads/Data-and-Repository-Service… · Please consult your internal legal & compliance de partments for ... 4