Guidelines for reporting under EMIR

23 October 2023
ESMA74-362-2281

Guidelines https://sherpa.esma.europa.eu/sites/ MKT/MDP/Groups/Forms/Group%20 MDP%20Document%20Set/docseth omepage.aspx?ID=1339&FolderCTI D=0x0120D52000F338AB8D4718AC 4980888518131BE828020300A279A C6D96CED64DAC96DA6F4F9AE96B &List=36f5f926-0ad5-4293-81ad0f20a20c29cf&RootFolder=%2Fsites %2FMKT%2FMDP%2FGroups%2FR TF%20Meeting%2020210506&RecSr c=%2Fsites%2FMKT%2FMDP%2FGr oups%2FRTF%20Meeting%2020210 506paper for reporting under EMIR

1
Table of Contents
Annex: Guidelines for reporting under EMIR ......................................................................... 6
1 Legislative references, abbreviations and definitions...................................................... 6
1 Scope............................................................................................................................. 9
2 Purpose.........................................................................................................................10
3 General Principles .........................................................................................................11
3.1 Transition to reporting under the RTS and ITS on reporting ...................................11
3.2 Determining the number of reportable derivatives ..................................................12
3.2.1 Reportable products........................................................................................12
3.2.2 Reporting obligation with regards to the parties involved in the trade ..............15
3.2.3 Reportability in specific scenarios....................................................................17
3.3 Intragroup exemption from reporting ......................................................................19
3.4 Allocation of responsibility for reporting ..................................................................24
3.4.1 General clarifications.......................................................................................24
3.4.2 FC trading with NFC........................................................................................25
3.4.3 CCP ................................................................................................................31
3.4.4 Funds (UCITS, AIF and IORP that, in accordance with national law, does not
have legal personality)...................................................................................................31
3.5 Delegation of reporting ...........................................................................................33
3.6 Reporting of lifecycle events...................................................................................35
3.6.1 Action types ....................................................................................................35
3.6.2 Action types and event types combinations.....................................................39
3.6.3 Lifecycle events and use of linking IDs (Prior UTI, PTRR ID, Subsequent position
UTI) 44
3.7 Reporting at position level ......................................................................................45
3.8 Reporting of on-venue derivatives..........................................................................49
3.9 Timely reporting of conclusion, modification and termination of a derivative...........54
3.9.1 Conclusion of a derivative ...............................................................................54
3.9.2 Modification or correction of a derivative .........................................................55
3.9.3 Reporting of margin and valuation updates .....................................................55
3.9.4 Termination of a derivative ..............................................................................56
3.10 Mapping business events to action types and levels ..............................................57

2
3.11 UTI generation .......................................................................................................65
3.12 Determining counterparty side................................................................................69
3.13 Identification of counterparties................................................................................71
3.14 Procedure when a counterparty undergoes a corporate action...............................73
3.15 Identification and classification of products.............................................................75
3.16 Identification of underlying......................................................................................76
3.17 Price, notional and quantity fields ...........................................................................77
3.18 Reporting of valuations...........................................................................................80
3.19 Reporting of margins..............................................................................................84
3.20 Identification of the trading venue...........................................................................90
3.21 Fields related to clearing ........................................................................................91
3.22 Fields related to confirmation .................................................................................92
3.23 Fields related to settlement ....................................................................................93
3.24 Reporting of regular payments ...............................................................................93
3.25 Reporting of other payments ..................................................................................94
3.26 Dates and timestamps fields ..................................................................................95
3.27 Reporting of derivatives on crypto-assets...............................................................96
3.28 Reporting of complex products...............................................................................97
3.29 Ensuring data quality by counterparties..................................................................99
4 Reporting per product type ..........................................................................................105
4.1 Reporting of IRS...................................................................................................105
4.2 Reporting of swaptions.........................................................................................107
4.2.1 Swaption on a fixed-to-floating IRS ...............................................................107
4.3 Reporting of other IR products .............................................................................112
4.4 Reporting of FX swaps and forwards....................................................................113
4.4.1 FX swaps (spot-forward and forward-forward)...............................................113
4.4.2 Compression of the near leg of the FX swap.................................................120
4.4.3 FX option.......................................................................................................129
4.4.4 Additional considerations on the reporting of currencies................................132
4.5 Reporting of NDFs................................................................................................132
4.5.1 NDF ..............................................................................................................132
4.6 Reporting of CFDs................................................................................................134
4.6.1 CFD ..............................................................................................................135
4.7 Reporting of equity derivatives .............................................................................137
4.7.1 Dividend swap...............................................................................................138

3
4.8 Reporting of credit derivatives ..............................................................................142
4.8.1 CDS ..............................................................................................................144
4.9 Reporting of commodity derivatives......................................................................148
4.9.1 Electricity future.............................................................................................149
5 EMIR Tables of fields ..................................................................................................151
5.1 Table 1 Counterparty data....................................................................................152
5.1.1 Cleared Option between FCs (ETD)..............................................................152
5.1.2 Cleared Option between FCs with voluntary delegation agreement (ETD) ....154
5.1.3 Non-Cleared Option between FCs.................................................................156
5.1.4 OTC Option between NFC - and FC..............................................................158
5.1.5 OTC Option between NFC - and NFC +........................................................159
5.1.6 OTC Contract type which requires the population of fields ‘Direction of Leg 1’ and
‘Direction of Leg 2’ between FCs.................................................................................161
5.2 Table 2 Common data..........................................................................................163
5.2.1 Reporting of action types at trade and position level......................................163
5.2.2 Other reportable details.................................................................................178
5.3 Table 3 Margin data .............................................................................................197
5.3.1 Reporting of margin update for a new uncollateralised derivative..................197
5.3.2 Reporting of margin for a new derivative collateralized at portfolio level........198
5.3.3 Reporting of margin update at an individual transaction level for an uncleared
derivative.....................................................................................................................201
6 Guidelines on derivatives data management ...............................................................204
6.1 Trade State Report...............................................................................................204
6.1.1 Introduction ...................................................................................................204
6.1.2 Treatment of event date ................................................................................205
6.1.3 Uniqueness of derivatives and special fields .................................................211
6.1.4 Treatment of action type ‘Revive’. .................................................................212
6.1.5 Reporting with action type ‘EROR‘ and ‘REVI’...............................................213
6.1.6 Inclusion in the TSR of schedule information.................................................214
6.1.7 Dead derivatives ...........................................................................................215
6.2 Reconciliation.......................................................................................................216
6.2.1 Scope of data subject to reconciliation ..........................................................216
6.2.2 Position-level vs trade-level reconciliation .....................................................216
6.2.3 Reconciliation of valuation.............................................................................218
6.2.4 Derivatives with two legs ...............................................................................218

4
6.2.5 Reconciliation of schedule information ..........................................................218
6.3 Data Quality feedback ..........................................................................................219
6.3.1 Rejection feedback........................................................................................219
6.3.2 Warnings feedback .......................................................................................224
6.3.3 Reconciliation feedback ................................................................................231
6.4 Data access .........................................................................................................235
6.4.1 Operational aspects ......................................................................................235
6.4.2 Template form for data access ......................................................................238
6.4.3 EMIR fields for data filtering ..........................................................................243

6
Annex: Guidelines for reporting under EMIR
1 Legislative references, abbreviations and definitions Legislative references EMIR Regulation (EU) 648/2012 of the European Parliament and Council on OTC derivatives, central counterparties and trade repositories - European Market Infrastructures Regulation1 SFTR Regulation (EU) 2015/2365 of the European Parliament and of the Council of 25 November 2015 on transparency of securities financing transactions and of reuse and amending Regulation (EU) No 648/2012 2 – Securities Financing Transactions Regulation RTS on reporting Commission Delegated Regulation (EU) No 2022/1855 of 10 June 2022 supplementing Regulation (EU) No 648/2012 of the European Parliament and of the Council on OTC derivatives, central counterparties and trade repositories with regard to regulatory technical standards specifying the minimum details of the data to be reported to trade repositories and the type of reports to be used3 ITS on reporting Commission Implementing Regulation (EU) No 2022/1860 of 10 June 2022 laying down implementing technical standards for the application of Regulation (EU) No 648/2012 of the European Parliament and of the Council on OTC derivatives, central counterparties and trade repositories, with regard to the standards, formats, frequency and methods and arrangements for reporting and repealing Implementing Regulation (EU) No 1247/20124 1 OJ L 201, 27.7.2012, p.1 2 OJ L 337, 23.12.2015, p.1 3 OJ L 262, 7.10.2022, p. 1 4 OJ L 262, 7.10.2022, p.68.

7
RTS on registration Commission Delegated Regulation (EU) No 150/2013 of 19 December 2012 supplementing Regulation (EU) No 648/2012 of the European Parliament and of the Council on OTC derivatives, central counterparties and trade repositories with regard to regulatory technical standards specifying the details of the application for registration as a trade repository, as amended by Commission Delegated Regulation (EU) 2019/362 of 13 December 2018 5 and by Commission Delegated Regulation (EU) 2022/18576 RTS on data quality Commission Delegated Regulation (EU) No 2022/1858 of 10 June 2022 supplementing Regulation (EU) No 648/2012 of the European Parliament and of the Council on OTC derivatives, central counterparties and trade repositories, with regard to regulatory technical standards specifying the procedures for the reconciliation of data between trade repositories and the procedures to be applied by the trade repository to verify the compliance by the reporting counterparty or submitting entity with the reporting requirements and to verify the completeness and correctness of the data reported7 RTS on data access Commission Delegated Regulation (EU) No 151/2013 of 19 December 2012 supplementing Regulation (EU) No 648/2012 of the European Parliament and of the Council on OTC derivatives, central counterparties and trade repositories, with regard to regulatory technical standards specifying the data to be published and made available by trade repositories and operational standards for aggregating, comparing and accessing the data, as amended by Commission Delegated Regulation (EU) 2017/1800 and by Commission Delegated Regulation (EU) 2019/361, as amended by the Commission Delegated Regulation (EU) 2022/18568 5 OJ L 52, 23.2.2013, p. 25 6 OJ L 262, 7.10.2022, p.41 7 OJ L 262, 7.10.2022, p.46. 8 OJ L 262, 7.10.2022, p.34.

8
RTS on organisation requirements
Commission Delegated Regulation (EU) 2017/565 of 25 April 2016 supplementing Directive 2014/65/EU of the European Parliament and of the Council as regards organisational requirements and operating conditions for investment firms and defined terms for the purposes of that Directive Abbreviations CFI code Classification of Financial Instruments code CM Clearing Member CCP Central Counterparty CP Consultation paper on Guidelines on Reporting under EMIR CP on RTS/ITS Consultation paper on the technical standards on reporting, data quality, data access and registration of TRs under EMIR REFIT9 FR on RTS/ITS Final report on the technical standards on reporting, data quality, data access and registration of TRs under EMIR REFIT10 CPMI Committee on Payments and Market Infrastructures EC European Commission ECB European Central Bank EEA European Economic Area ERR Entity responsible for reporting ESCB European System of Central Banks ESMA European Securities and Markets Authority 9 https://www.esma.europa.eu/sites/default/files/library/esma74-362- 47_cp_on_the_ts_on_reporting_data_quality_data_access_and_registration_of_trs_under_emir_refit.pdf 10 https://www.esma.europa.eu/sites/default/files/library/esma74-362- 824_fr_on_the_ts_on_reporting_data_quality_data_access_and_registration_of_trs_under_emir_refit_0.pdf

9
EU European Union
FIRDS Financial Instruments Reference Data System FSB Financial Stability Board IOSCO International Organisation of Securities Commissions ISIN International Securities Identification Number ISO International Organization for Standardization ITS Implementing Technical Standards LEI Legal entity identifier MIC Market identifier code NCA National Competent Authority OJ The Official Journal of the European Union OTC Over-the-counter Q&A Questions and Answers RSE Report submitting entity RTS Regulatory Technical Standards SWIFT Society for Worldwide Interbank Financial Telecommunication TR Trade repository UTI Unique Transaction Identifier XML Extensible Mark-up Language XSD XML Schema Definition 1 Scope Who?

These Guidelines will apply to financial and non-financial counterparties to
derivatives as defined in Articles 2(8) and 2(9) of EMIR, to trade repositories (TRs) as defined in Article 2(2) of EMIR and to competent authorities.

10
What?
2. These Guidelines will apply in relation to the derivatives reporting obligation as
stated in Article 9 of EMIR and the TRs’ obligations under Articles 78 and 81 of EMIR. When?
3. These Guidelines will apply from 29 April 2024.
2 Purpose
4. These Guidelines are based on Article 16(1) of ESMA’s Regulation. They fulfil
several purposes with regards to the harmonisation and standardisation of reporting under EMIR. This is key to ensure high quality of data necessary for the effective monitoring of the systemic risk. Furthermore, increased harmonisation and standardisation of reporting allows to contain the costs along the complete reporting chain - the counterparties that report the data, the TRs which put in place the procedures to verify the completeness and correctness of data, and the authorities, defined in Article 81(3) of EMIR which use data for supervisory and regulatory purposes. The Guidelines provide clarifications on the following aspects:
a. transition to reporting under the new rules, b. the number of reportable derivatives,
c. intragroup derivatives exemption from reporting,
d. delegation of reporting and allocation of responsibility for reporting, e. reporting logic and the population of reporting fields, f. reporting of different types of derivatives, g. ensuring data quality by the counterparties and the TRs, h. construction of the Trade State Report and reconciliation of derivatives by the TRs,
i. data access.

11
3 General Principles
3.1 Transition to reporting under the RTS and ITS on reporting
5. All the reports submitted by the counterparties to the TRs after the start of reporting
under the RTS and ITS on reporting will have to comply with the amended requirements. This applies to the reports of derivatives concluded after the reporting start date and to any modifications or terminations reported after that date, irrespective of when the derivative that is modified or terminated was concluded.
6. In general, any reportable lifecycle event will need to be reported in line with the
revised requirements.
7. In accordance with the Article 10(2) of the ITS on reporting, the counterparties
should update all their outstanding derivatives to conform with the revised reporting requirements within 180 calendar days of the reporting start date by submitting a report with event type ‘Update’, unless they have submitted a report with the action type ‘Modify’ or ‘Correct’ (correcting the details of the trade11) for such derivatives within this period (given that ‘Modify’ and ‘Correct’ will be full messages, thus reporting of a modification or a correction of the derivative will require provision of all relevant details of that derivative).
8. If the counterparty does not report within the 180-day transition period any
modification or any correction of the derivative, it should submit a report using combination of action type ‘Modify’ and event type ‘Update’, populating all the relevant details in accordance with the RTS and ITS on reporting.
9. Even if a counterparty reports daily collateral and valuation updates, but no
modification or correction was reported during transition period for a given derivative, the counterparty should update that derivative.
10. If the derivative matures or is terminated during the transition period, counterparties
do not need to send the report with event type ‘Update’ when no reportable modification took place.
11. All outstanding derivatives, both at a trade and at a position level, should be
updated. The derivatives at trade level that were included in a position are not outstanding and therefore should not be updated. Only the corresponding derivative at position level should be updated, to the extent it is outstanding on the reporting start date.
12. Terminated or matured trades should not be updated and re-reported. This is
without prejudice to sending reports such as modifications and corrections with regards to past events for terminated or matured trades, where relevant. 11 Action type ‘Correct’ will allow for correcting trade data or trade and valuation data or margin data. Only the report with action type ‘Correct’ related to trade data or trade and valuation data will ensure update of all relevant fields of a derivative. Valuation and margin data will be updated in any case by sending the daily valuation and margins reports (action types ‘Valuation’ and ‘Margin update’, respectively)

12
13. If a counterparty reopens a not-updated derivative with action type ‘Revive’, either
during the transition period or afterwards, it should provide all relevant details of the derivative as of the date of the revival, as in any other ‘Revive’ report.
14. The transition period does not impact in any way the obligation under Article 9 of
EMIR to report the relevant events by T+1. Therefore any conclusion, modification or termination of a derivative occurring after the reporting start date, should be reported accordingly by the end of the next working day (T+1), also if it occurs during the 6-month transition period.
15. During the transition period TRs should include all outstanding derivatives in the
reconciliation process, irrespective of whether they have been updated or not. The fields required under the RTS and ITS on reporting will be subject to reconciliation as specified in the Annex to the RTS on data quality. Fields that were reported in the past but are no longer required under the RTS and ITS on reporting will not be reconciled.
16. The counterparties should not create a new UTI for outstanding derivatives, even if
the original UTI is not fully compliant with the new format requirements under the RTS and ITS on reporting. This applies also to field 2.3 ‘Prior UTI’ and field 2.4 ‘Subsequent position UTI’.
17. In line with the EMIR validation rules TRs should not reject reports due to UTIs that
are not fully compliant with the new requirements for those derivatives that were concluded before the reporting start date of the RTS and ITS on reporting.
18. In case of transfer of data between TRs, prior to the data transfer TRs should
ensure that TR participants upgrade the outstanding derivatives that are subject to data transfer to the most up to date reporting requirement12 .
3.2 Determining the number of reportable derivatives
3.2.1 Reportable products
19. EMIR Article 9(1) states that “counterparties and CCPs shall ensure that the details
of any derivative contract they have concluded and of any modification or termination of the contract are reported to a trade repository […]”. A derivative contract or derivative is defined in EMIR Article 2(5) as a financial instrument as set out in points (4) to (10) of Section C of Annex I to MiFID. In the last few years several uncertainties have been raised with regards to the qualification of certain contracts as derivatives. This section aims to provide clarification to market participants taking into account the current state of the regulations. Currency derivatives 12 See Guideline 11 in the ESMA74-362-2351 Guidelines on transfer of data between Trade Repositories under EMIR and SFTR

13
20. MIFID RTS on organisational requirements for investment firms13 clarifies in Article
10 the characteristics of other derivative contracts relating to currencies which allows to differentiate between spot contracts that are not derivatives and forward contracts that are derivative contracts. In principle, and more particularly for major currency pairs, a FX contract is considered a derivative if the delivery is scheduled to be made at least 3 trading days after the execution of the contract, while under some circumstances this limit may be extended based on standard market practices. Based on the above elements, forward FX contracts are reportable under EMIR while spot FX contracts are not.
21. As an illustration a FX contract selling X EUR and purchasing Y USD traded on
Monday 4 January 2021 and settling on Thursday 7 January 2021 is a forward contract and reportable under EMIR. A similar FX contract traded on Monday 4 January 2021 and settling on Wednesday 6 January 2021 is a spot contract and not reportable under EMIR.
22. A FX contracts selling X EUR and purchasing Z ZAR traded on Monday 4 January
2021 and settling on Wednesday 6 January 2021, for which the transaction is carried out in order to purchase an equity traded on the JSE14 with a T+3 settlement cycle is not a derivative and thus not subject to reporting under EMIR based on the fact that when a FX contract is linked to the purchase of transferable securities or units of collective investment undertaking, it is considered as a derivative when the delivery is made after the delivery period of the market where the transferable securities or units in an undertaking for collective investment in transferable securities (UCITS) are traded or after 5 days, whichever is the shorter.
23. Furthermore, Article 10 provides that “a contract shall not be considered a spot
contract where, irrespective of its explicit terms, there is an understanding between the parties to the contract that delivery of the underlying is to be postponed and not to be performed within” the period referred to in the above paragraphs.
24. For swaps, at first cross currency swaps and FX swaps are to be distinguished.
Cross currency swaps are contracts that contain both an interest rate factor and a currency factor. They are considered as interest rate derivatives and should be reported as such under EMIR. FX swaps to the contrary only entail a FX factor (i.e. in general no interim payments occur). FX swap is a derivative composed of 2 legs, a near leg and a far leg. Regardless of whether the near leg is a spot or a forward, the FX swap should be reported as a single derivative rather than as a combination of derivatives. Further details on how these derivatives should be reported are contained in section 4.4. Derivatives on crypto-assets
25. Only derivatives on crypto-assets that fulfil the definition of ‘derivative’ or ‘derivative
contract’ under EMIR are expected to be reported.
13 Commission Delegated Regulation (EU) 2017/565 of 25 April 2016 supplementing Directive 2014/65/EU of the European Parliament and of the Council as regards organisational requirements and operating conditions for investment firms and defined terms for the purposes of that Directive (Text with EEA relevance) 14 Equity Market Risk Management | Johannesburg Stock Exchange (jse.co.za)

14
26. For the reporting of the details of derivatives, counterparties should rely on the
regulatory framework that is applicable. Therefore, if the derivative on a crypto-asset is considered as a financial instrument under MiFID, it should be reported in accordance with its features.
27. In case where a counterparty enters a derivative contract with a crypto-asset as the
underlying, it should populate the field 2.12 ’Derivative based on crypto-assets‘ with ’True’. Total return swaps, liquidity swaps or collateral swaps (in relation to SFTR)
28. Some obligations related to total return swaps (TRS) are included in SFTR, notably
in Chapter IV relating to Transparency towards investors. Nevertheless, TRS are derivatives and thus are reportable under EMIR and not under SFTR. The definition in Article 3(18) of SFTR clearly states that a TRS “means a derivative contract as defined in point (7) of Article 2 of Regulation (EU) No 648/2012 in which one counterparty transfers the total economic performance, including income from interest and fees, gains and losses from price movements, and credit losses, of a reference obligation to another counterparty.” It is to be noted that depending on the underlying, TRS are to be reported either as credit derivatives or as equity derivatives. Details on how these are to be reported can be found in sections 4.7 and 4.8.
29. Furthermore, Recital 7 of SFTR clarifies that some transactions that are commonly
referred to as liquidity swaps and collateral swaps, which do not fall under the definition of ’derivative contracts‘ under EMIR, are included in the scope of SFTR. These contracts are not reportable under EMIR. Complex contracts
30. In the case of contracts stemming from another contract (e.g. option on a future),
the first contract ceases to exist before giving rise to the second one which is materially different from the first one. The two contracts should be reported separately, i.e. the second one should only be reported once the first contract is terminated. Therefore, even though the two contracts are connected in the way they come into existence, they should be reported in two separate reports. In case where the resulting contract does not qualify as a ‘derivative’ or ‘derivative contract’ as defined in EMIR Article 2(5), the resulting contract should not be reported.
31. In the case where a derivative has two or more legs (e.g. a single derivative contract
representing a strategy that has the features of several contracts), all legs of the contract should be reported in one report, where the combination of fields allows for this. Otherwise, a report per leg should be submitted and those reports should be linked by using the same package identifier in field 2.6. Market transactions that do not fall under the definition of a derivative
32. The following transactions do not fall under the definition of a derivative under EMIR
and thus should not be reported under EMIR:

15 a. Financial instruments with embedded derivatives (e.g. convertible bonds): some financial instruments are issued with features that could be considered as derivatives embedded in the structure of the instrument itself. This is for instance the case of convertible bonds which according to Table 2.2 of Annex III of RTS 2017/583 “means an instrument consisting of a bond or a securitised debt instrument with an embedded derivative, such as an option to buy the underlying equity”. b. Structured finance products or structured products are defined in Article 2(1)(28) of MiFIR as “those securities created to securitise and transfer credit risk associated with a pool of financial assets entitling the security holder to receive regular payments that depend on the cash flow from the underlying assets”.
c. Securitised derivatives are defined in Table 4.1 of Annex of RTS 2017/583 as
“a transferable security as defined in Article 4(1)(44)(c) of Directive 2014/65/EU different from structured finance products”. These include at least:
• plain vanilla covered warrants;
• leverage certificates;
• exotic covered warrants;
• negotiable rights;
• investment certificates.
3.2.2 Reporting obligation with regards to the parties involved in the trade
33. Intragroup derivatives, not eligible for exemption, should be reported as any other
derivatives and the corresponding field 2.37 ’Intragroup‘ should be populated as ’True‘. However, Article 9(1) EMIR provides for an exemption of intragroup derivatives from the reporting obligation where the relevant conditions are met. In these cases, both counterparties should continue to report until the conditions for applying the exemption can be met and the exemption is granted (further clarifications on the exemption are provided in the section 3.3).
34. Derivatives within the same legal entity (e.g. between two desks or between two
branches of the same entity) should not be reported under EMIR as they do not involve two counterparties. The only exception is the situation in which a Clearing Member defaults and the CCP temporarily assumes both sides of the outstanding derivative contracts.
35. Similarly, non-EU subsidiaries of a group for which the parent undertaking is
established in the Union are not required to report their derivatives under EMIR. In the case of contracts between an EU counterparty and a non-EU counterparty, the EU counterparty will need to report such contracts.
36. EMIR requires counterparties and CCPs to report. CCPs are defined in EMIR
Article 2(1) and counterparties are defined either as FC if the entity falls under any
of the categories of financial counterparties defined in EMIR or as an NFC if it is an

16 undertaking established in the Union other than a CCP or a FC. The concept of an undertaking is not defined in EMIR. However, the European Commission provides in its FAQ15, question II.14 a rationale leading to the consideration that the “concept of undertaking is broader than that of 'companies or firms' and thus, is not restricted to entities with legal personality or with for-profit-making (Article 54 TFEU)”. It is worth noting that individuals not carrying out an economic activity are consequently not considered as undertakings and thus are not subject to the reporting obligation under EMIR.
37. As a consequence, if the activity performed by the entity with a charitable nature or
otherwise a non-profit profile falls under the definition of an economic activity that qualifies it as a charity or non-profit entity, it would be subject to the obligations applicable to non-financial counterparties for the derivatives concluded, including the reporting obligation.
38. With regards to investment funds (e.g. UCITS, AIF, unincorporated funds, IORP),
the counterparty to the derivative is generally the fund (or in case of umbrella funds, the sub-fund). When a fund manager executes a contract for different funds at the same time (e.g. block trade), it should immediately allocate the relevant part of that contract to the relevant funds and report accordingly. As a consequence, the counterparty ID should be the ID of the fund, not the ID of the fund manager. According to Articles 9(1b) to (1d) EMIR, the fund manager shall report the OTC derivatives on behalf of the funds. The ID of the fund manager should be included as the entity responsible for reporting and where it reports directly as the report submitting entity. It should be noted that in rare circumstances, the fund manager executes trades on its own account and not on behalf of the funds it manages. In such case the counterparty would be the fund manager.
39. Non-EU AIFs that are set up exclusively for the purpose of serving one or more
employee share purchase plans, or that are securitisation special purpose entities as referred to in point (g) of Article 2(3) of Directive 2011/61/EU, do not qualify either as FCs under Article 2 (8) nor as NFCs under Article 2(9). As such, these AIFs are not subject to the reporting obligation and therefore, they should not report derivatives under EMIR. However, if the other counterparty is subject to the reporting obligation under EMIR, that counterparty should report derivatives concluded with such non-EU AIFs.
40. More generally, with regards to funds and in particular when an AIFM is managing
AIFs domiciled in the Union and AIFs domiciled in third countries, fund manager should establish whether the AIF qualifies as a FC under EMIR Article 2(8). In case the AIF qualifies as a FC, the AIFM that is authorised or registered under AIFMD should ensure that the derivative details are reported.
41. Finally, some specific entities are out of scope of EMIR in general in accordance
with EMIR Article 1(4) such as the BIS, central banks or public bodies charged with or intervening in the management of the public debt for a given list of countries. However, with regard to Article 1(5) the reporting obligation is the only EMIR 15 emir-faqs-10072014_en.pdf (europa.eu).

17 obligation that applies to multilateral development banks, some public sector entities, the ESF and ESM.
42. Investment firms that provide investment services (such as execution of orders or
receipt and transmission of orders) without becoming a counterparty to a derivative by acting as principal do not have an obligation to report under EMIR. Nevertheless, in case the investment firm acts as an investment fund manager as described in paragraphs 1b, 1c or 1d of EMIR Article 9, then this investment firm becomes responsible and legally liable to report on behalf of the counterparty and to report its own LEI in the field 1.3 ‘Entity responsible for reporting’.
43. Similarly, when a management company provides the service of portfolio
management (as defined in Article 4(8) of MiFID) to a client, and, by doing so, enters into derivative contracts, the client should be considered as the counterparty to the derivative, except when the management company bears the risk of the derivative contract and therefore is considered as a counterparty. The management company can report to TRs on behalf of its clients without prejudice to the client’s liability for meeting the reporting obligation. In that situation, the ID of the management company should be provided as the report submitting entity ID.
44. When a broker is a counterparty to a derivative, it should report the derivative and
identify itself as a counterparty. In line with the RTS on reporting and more particularly with regard to the details to be reported in the field 1.15, the broker is then not required to report its LEI in the field ’Broker ID’ Otherwise, if a broker only acts as an intermediary for counterparty 1, the LEI of the broker should be reported in the ‘Broker ID’ field.
3.2.3 Reportability in specific scenarios
45. Reporting under EMIR is dual-sided, i.e. both counterparties to derivative contracts
are required to report if they fall under the scope of EMIR. As a consequence, for a derivative entered into by two counterparties subject to EMIR, the same derivative is expected to be reported twice, once on behalf of each counterparty, and the details of the reported derivative should be consistent across both reports.
46. Article 9(1e) stipulates that counterparties and CCPs should ensure that such
details are reported correctly and without duplication. Based on this requirement, counterparties or other entities responsible for reporting should put in place processes and controls in order to avoid the risk of duplicate reporting. This is particularly important (i) in the case of a change of TR (ensure that the reports are channelled to the right TR), (ii) in the case of a corporate event such as a merger or an acquisition (avoid reporting the same derivative on behalf of the wrong entity) or (iii) in the case of changes in delegation (ensure that only one delegated entity reports a derivative). In case a duplicate report is identified the counterparty should immediately take corrective actions with diligence in order to resolve the problem.
47. In the event of a novation, where a counterparty (being a CCP or another
counterparty) steps into a derivative and becomes a new counterparty to the derivative (this paragraph does not cover clearing events), the derivative should be reported with action type ‘New’ and event type ‘Step-in’ by both counterparties, i.e.

18 the new counterparty stepping-in as well as the counterparty that does not change. For the original report relating to the existing derivative, both counterparties should send a report with action type ‘Terminate’ and event type ‘Step-in’, populating the field 2.45 ’Early termination date’.
48. For block trades, there is a distinction necessary between (i) scenarios where the
block trade was concluded by an investment firm and then allocated to clients and (ii) those scenarios where the block trade was concluded by a fund manager without own reporting obligation and then allocated to individual funds.
49. In the first case the block trade should first be reported by the investment firm. The
investment firm should then report the allocations to the individual clients.
50. In the second case, block trades that are subsequently allocated to individual funds
on trade date are not required to be reported. In such cases, the counterparty to the derivative is the individual fund, therefore the allocations should be reported (a) specifying the relevant individual fund (on behalf of which the fund manager has entered into the block trade) as counterparty to the said trade and (b) specifying the allocation of the relevant part of the trade to the relevant individual fund. Any parts of a block trade that are not allocated on trade date should be reported with the fund manager as the counterparty. This reporting logic would only apply where the allocation post trade date is permitted by the applicable national legislation.
51. In case a collateral agreement allows the covering of exposures in transactions that
are not to be reported under EMIR, the collateral reported should be just the collateral that covers the exposure related to the derivatives reported under EMIR. If it is impossible to distinguish within a pool of collateral the amount which relates to derivatives reportable under EMIR from the amount which relates to other transactions, the collateral reported can reflect the actual collateral posted / received covering a wider set of transactions. As a consequence, in case none of the transactions covered by the report is reportable under EMIR, no collateral should be reported.
52. Regulation (EU) 2019/834 of the European Parliament and of the Council of 20 May
2019 amending Regulation (EU) No 648/2012 removed the backloading requirement from Article 9 of EMIR, therefore derivatives concluded before and no longer outstanding on 12 February 2014 are not subject to the reporting obligation.
53. Where no contracts are concluded, modified or terminated during several days, no
reports are expected apart from updates to valuations or collateral on outstanding derivatives, as required. As the obligation to report should be complied with by T+1 (T being the date of conclusion/modification/termination of the contract), there is no other need to send daily reports if there are no conclusion, modifications to the contract or termination.
54. Derivatives that are concluded and then netted or terminated for other reasons
during the same day, should be reported to TRs. In case of a termination during the same day, at least two reports should be sent: a report with action type ‘New’ and a second report with action type ‘Terminate’ and the relevant event type, unless the derivative is reported with action type ‘Position component’ in which case it will be

19 netted into the subsequent position (please refer to section 3.7 for position level reporting specificities).
55. With regards to cleared derivatives, the Article 2 of the RTS on reporting details
how trades that are cleared should be reported. As a consequence, if the derivative is not cleared on the same day by a CCP or if the derivative is concluded off venue, the derivative should first be reported in its original state and then, once it is cleared, the original derivative should be terminated with action type ‘Terminate’ and event type ‘Clearing’. The subsequent derivative should be reported with action type ‘New’ and event type ‘Clearing’ or, if relevant, with action type ‘Position Component’.
3.3 Intragroup exemption from reporting
56. The three-month period referred to in Article 9(1) EMIR, as amended by Regulation
2019/834, in which the authorities may disagree with the fulfilment of the above conditions, starts on the calendar day following receipt of the notification(s) by the relevant NCA(s).
57. The exemption should be valid from the date when the NCA(s) confirm(s) to the
counterparty(ies) that the conditions to use the exemption are satisfied, or if no decision is notified by the NCA(s), it will be valid from the end of the three-month non-objection period. If the conditions, referred to in the third sub-paragraph of
Article 9(1) EMIR, as amended by Regulation 2019/834, may be no longer fulfilled
due to a change in the counterparties characteristics, the counterparties need to inform the relevant NCA(s). Without prejudice to the existing exemption, the NCA(s) can object to the use of the exemption if the conditions are no longer met. From the point in time at which the NCA objects to the use of the exemption the exemption will not be valid.
58. It should be noted that the counterparties should report derivatives during the threemonth period unless the NCA(s) notify(ies) the counterparty(ies) that they agree
upon fulfilment of the conditions before the three-month period expires.
59. With regards to the reference to the ‘parent undertaking’ for the purpose of the
conditions for the exemption under Article 9(1) EMIR, as amended by Regulation 2019/834, it should be considered that:
a) the ultimate parent undertaking of the group16 relevant for the consolidation on a full basis is the parent undertaking for that purpose, and b) the centralised risk evaluation, measurements and control procedures should be applicable for the counterparties notifying the exemption from reporting. It is not 16 The European Commission has clarified that the exemption contained in Article 9(1) of EMIR does not cover intragroup transactions for which the parent undertaking is established in a third country, even if the transaction occurs between two counterparties which are both established in the EU. (see ESMA EMIR Q&A TR Answer 51 (m).)

20 necessary that they are established at the level of the whole group of the ultimate undertaking. The notion of ultimate parent undertaking under point a) here above is to be understood as the highest consolidating entity in the group.

21
60. Figure 1 illustrates the general case.

22
FIGURE 1: EXAMPLE OF A TWO-LAYER GROUP STRUCTURE
61. Some specific use cases are detailed in Figure 2, Figure 3, Figure 4 and Figure 5.
FIGURE 2: FULL CONSOLIDATION BY THE ULTIMATE PARENT UNDERTAKING
FIGURE 3: FULL CONSOLIDATION BY THE ULTIMATE PARENT UNDERTAKING WITH ANOTHER
ENTITY HAVING FINAL OWNERSHIP

23
FIGURE 4: FULL CONSOLIDATION BY THE ULTIMATE PARENT UNDERTAKING WITH AN
INTERMEDIATE PARENT
FIGURE 5: FULL CONSOLIDATION BY THE ULTIMATE PARENT UNDERTAKING WITH AN
INTERMEDIATE PARENT AND WITH ANOTHER ENTITY HAVING FINAL OWNERSHIP
62. Counterparties should submit their notifications to their respective NCAs (individual
notifications should be sent to each NCA where counterparties are located) in accordance with the procedures adopted by those NCAs in each Member State. If

24 this is acceptable for the respective NCA, the ultimate parent undertaking (as per paragraph 59 of these Guidelines) or the entity relevant for centralised risk evaluation, measurements and control procedures with regards to the counterparties for which the exemption is notified may provide a single notification identifying each entity of its group situated within that Member State for which exemption is requested. It is not necessary that the ultimate parent undertaking or the entity relevant for centralised risk evaluation, measurements and control procedures with regards to the counterparties for which the exemption is notified, is a counterparty to a derivative contract, neither that it is located in the Member State where it submits a notification.
63. When notifying of their intention to apply the exemption from the reporting obligation
in accordance with Article 9(1) EMIR, the notifying counterparty should state that it fulfils the conditions laid down in the third subparagraph of Article 9(1) EMIR and, if applicable, should indicate the other NCA(s) that have been notified with regards to the counterparty(ies) included in the notification. The NCA may ask for additional information and/or documents to assess the fulfilment of the conditions laid down in the third subparagraph of Article 9(1) EMIR.
64. Counterparties may notify their intention to apply an intragroup exemption even if
the counterparties have not yet concluded any derivatives and consequently apply the exemption unless one of the NCAs objects for derivatives concluded after the exemption has been granted. Nevertheless, the notification should only be submitted once all the conditions specified in third sub-paragraph of Article 9(1) of EMIR are fulfilled.
65. When counterparties of the same group established in at least two different Member
States notify their NCAs of their intention to apply a reporting exemption under
Article 9(1) EMIR, each NCA needs to consider whether the conditions laid down
in the third subparagraph of Article 9(1) are met. NCAs may disagree on the fulfilment of these conditions. Where one of the NCAs considers that the conditions are not fulfilled, it should notify the counterparty in its Member State as well as the other NCA(s) within the three-month period of the receipt of the notification and specify the reasons.
66. Where counterparties want to benefit from the exemption from reporting and once
they consider they have addressed the objection(s) raised by the objecting NCA(s), they should renotify accordingly of their intention to apply the reporting exemption under Article 9(1) EMIR.
67. A derivative contract between a financial counterparty (FC) and non-financial
counterparty (NFC) where:
a. the FC belongs to both a group of undertakings referred to in Article 3(1) or
Article 80(7) and (8) of Directive 2006/48/EC (CRD), and another group referred
to in Articles 1 and 2 of Directive 83/349/EEC, and b. the NFC merely belongs to the group under Articles 1 and 2 of Directive 83/349/EEC,

25
c. may be eligible for an intragroup exemption from reporting. Notably, in
accordance with the definition of ‘group’ in Article 2(16) EMIR, as amended by Regulation 2019/834, such a contract may be eligible for an intragroup reporting exemption if the NFC, while not consolidated under the CRD, is part of the same consolidated non-financial group as the FC.
68. For the avoidance of doubt, if counterparties notify their respective NCAs on
different dates, they should wait until the end of the later of the two three-month periods before relying on the exemption (provided neither NCA objected) or until all relevant NCAs agree on the fact that the conditions laid down in the third subparagraph of Article 9(1) EMIR are met. The reporting exemption for the derivative contracts concluded by the relevant counterparties is not valid, if one NCA has objected to it. Therefore, the derivatives concluded between the counterparties, that are included in the notification, should continue to be reported.
69. Once the reporting exemption is valid, the counterparties that benefit from the
exemption should send reports with action type ‘Error’ for all the derivatives referred to in paragraphs 2(a) and 2(b) of Article 2 of the ITS on reporting with the counterparties for which the reporting exemption is valid.
70. If the reporting exemption ceased to be valid due to a non-compliance with any of
the conditions referred to in the third sub-paragraph of Article 9(1) EMIR, the counterparties concerned should report the derivative contracts that have been concluded and have not been terminated by the counterparties nor matured on the date the exemption ceased to be valid using action type ‘New’ and event type ‘Trade’ and provide all the relevant details of those derivatives as they stand on the date when the exemption ceases to be valid, and report all subsequent lifecycle events as they occur. It is not necessary to report the lifecycle events to the derivative that occurred between the date of conclusion of that derivative and the date when the exemption ceased to be valid. If these derivatives were previously cancelled with action type ‘Error’ at the moment when the exemption was granted, the counterparties should report such derivatives with action type Revive. Also in this scenario, it is not necessary to report lifecycle events that occurred during the period when the exemption from reporting was valid.
3.4 Allocation of responsibility for reporting
3.4.1 General clarifications
71. In accordance with EMIR Article 9(1), counterparties and CCPs are required to
ensure that the details of any derivative that is reportable as described in the section
3.2 are reported to a TR. Therefore, unless an exemption applies or unless a
different party is responsible and legally liable for reporting pursuant to Article 9(1a) of EMIR, the reporting obligations apply to all counterparties and CCPs established in the Union as soon as they enter into a derivative contract. This means, that such a derivative should be reported no later than the working day following its conclusion, modification or termination.

26
3.4.2 FC trading with NFC
72. With regard to the provisions under Article 9(2) of the ITS on reporting, ESMA
considers that, in order to fulfil the respective requirements, NFC- and FC should agree on the way to exchange information in each of these cases. More particularly, with regard to Article 9(2)(a) of the ITS on reporting, those arrangements should allow the FC to have the information no later than T+1 after the conclusion or modification of a contract so that the FC can proceed to the timely reporting. This can be achieved e.g. by providing a list of predefined standard values to be used as default by the FC, unless specified otherwise by the NFC-. In any case the NFCremains responsible for providing the FC with correct details and the FC is responsible for using the information provided by the NFC-. As an example of predefined values, consider the case where an NFC- is entering into derivative contracts with a credit institution without the use of a broker, not clearing those contracts and entering into them only to hedge its commercial activity in the sense of EMIR Article 10(3). In this case, the NFC- could agree that the FC reports the below pre-defined values in the fields specified in Article 9(2) of the ITS on reporting, unless the NFC- specifically instructs the FC otherwise:
a. 1.15 ‘Broker ID’: blank. b. 1.16 ‘Clearing Member’: blank.
c. 1.20 ‘Directly linked to commercial activity or treasury financing’: ‘True’.
73. ESMA takes this opportunity to remind market participants that NFC- are not
required to report data on collateral, mark-to-market, or mark-to-model valuations of the contracts in accordance with Article 4 of the RTS on reporting. Nevertheless, should the FC report this information, it should be correct as of the respective collateral or valuation timestamp.
74. A particular situation is where a conclusion of a derivative has been reported or
should have been reported by the NFC- (either because it was executed before the provisions setting out the reporting responsibility became applicable on 18 June 2020 or because the NFC- opted-out at the time of the execution), and a modification or termination is to be reported under the provisions assigning the responsibility and legal liability to the FC. More particularly, this situation might happen during the transition period, thus under the principles explained in section
3.1 on the transition to the new reporting standards. ESMA considers as well that
the arrangements between the NFC- and the FC should take into account such situations in order to ensure the continuity of the reporting in terms of content, timeliness and adequacy. The counterparties should as well ensure that those contracts are not reported with duplication.
75. For any outstanding OTC derivatives where an FC and an NFC- report to two
different Trade Repositories at the moment the responsibility and legal liability are transferred, the outstanding OTC derivatives of the NFC- should be ported to the TR of the FC at that moment, unless the FC decides to become client of the TR of the NFC- and report the OTC derivatives concluded with the NFC- to that TR. Similarly, each time when NFC changes its status from NFC- to NFC+, and thus

27 the responsibility and legal liability is transferred to the NFC, the outstanding OTC derivatives concluded with the FC should be ported to the TR of the NFC, unless the NFC decides to become client of the TR of the FC and report the OTC derivatives concluded with the FC to that TR. Any such transfer of OTC derivatives between the TRs of any pair of FC-NFC should be performed following the Guidelines on transfer of data between Trade Repositories 17 (in particular, the derivatives subject to transfer should not be cancelled and re-reported by the counterparties, but rather transferred as specified in the Guidelines).
76. With regard to Article 9(2)(b) of the ITS on reporting, the fields 1.7 ‘Clearing
threshold of counterparty 1’ and 1.13 ‘Clearing threshold of counterparty 2’ are part of the reportable details. To the extent possible, the NFC- should inform the FC of an anticipated change in its status ahead of the date of the required annual calculation of its positions pursuant to the Article 10(1) of EMIR to avoid any disruption in the continuity of reporting. While the status of the NFC is known and primarily assessed by the NFC itself, the FC should collect the information on a regular basis in order to be able to perform its own reporting. When the FC becomes aware of a change from NFC+ to NFC- after the calculation date, it should submit the missing reports pertaining to the OTC derivatives that were concluded, modified or terminated after that date without undue delay. Such submissions should be done, upon having received from the NFC all relevant details (as per Article 9(2)(a) of the ITS on reporting) pertaining to these derivatives.
77. Similarly, the NFC should take all relevant steps in order to ensure that it is capable
to take over the reporting once it changes its status from NFC- to NFC+ in order to ensure continuity of the reporting in terms of content, timeliness and adequacy. This includes as well that the NFC should inform the FC as soon as possible and therefore, the NFC should ideally anticipate the change.
78. With regard to the Article 9(2)(c) of the ITS on reporting, NFCs are responsible for
ensuring that their LEI is renewed in a timely fashion. In order to avoid disruptions in the reporting and for the FC to avoid having to manage rejections by the TRs, ESMA considers that FC can e.g. timely liaise with the NFC- so that the latter renews its LEI. Nevertheless, if the NFC- has not timely renewed its LEI and therefore FC was not able to successfully report on behalf of NFC-, the FC should submit the missing reports without undue delay as soon as the LEI of the NFC- is renewed.
79. While the obligation to report OTC derivatives is no longer on the NFC-, ESMA
considers that it is of utmost importance that both counterparties, including the NFC-, are in possession of complete and up-to-date information about the details of the derivatives that have been reported to a TR. Therefore, ESMA considers that FCs can e.g. provide its NFC- counterparties on regular basis (e.g. monthly) with the information concerning the contracts that are outstanding at the TRs. Being able to compare its own records with the records of derivatives stored at the TRs on a regular basis would support the NFC- in fulfilling its other obligations as defined 17 https://www.esma.europa.eu/sites/default/files/library/esma74-362-2351_final_report_- _guidelines_on_data_transfer_between_trade_repositories_emir_sftr.pdf

28 under EMIR and more particularly to EMIR Article 9(2) “Counterparties shall keep a record of any derivative contract they have concluded and any modification for at least five years following the termination of the contract” or other relevant regulations as well as to be aware of the information that is available to the entities listed in EMIR Article 81(3) on their behalf.
80. For the avoidance of doubt, ESMA stresses again that all the aforementioned
clarifications apply only to OTC derivatives. Thus, for ETDs, i.e. any derivative contracts that do not qualify as OTC based on the definition of Article 2(7) of EMIR as amended by Article 32 of SFTR, the counterparty remains responsible and legally liable for reporting the details to a TR and the provisions related to the transfer of responsibility and legal liability do not apply. Counterparties cannot assume that all options and futures traded on venue are ETDs.
81. In very specific cases, external circumstances might lead to a change in the
allocation of responsibility for the reporting e.g.:
a. FC that was established in an EEA country will be established in a third country, b. Derivative contract changes from OTC to ETD or vice versa.
82. In such cases, ESMA considers that the allocation of responsibility depends on the
situation at each time a reporting requirement arises, e.g. for a derivative contract that is considered OTC until 30//11 and becomes an ETD as of the 1/12, the FC is responsible for reporting until 30/11 included while the NFC- will be become responsible and legally liable for reporting as from the 1/12. All other provisions of these guidelines will be applicable in accordance with the allocation of responsibility.
83. Another limitation is that the provisions on allocation of responsibility only apply
when the FC is established in the Union or where the conditions laid down in the fourth sub-paragraph of Article 9(1a) of EMIR are fulfilled.
84. Finally, counterparties should take into account the situation of the implementation
of the amendments to EMIR in EEA countries (Iceland, Liechtenstein and Norway). Until the amendments to EMIR are incorporated into the EEA agreement and transposed into the national laws of these countries, counterparties should carefully assess their obligations when trading with EEA counterparties and have arrangements in place to ensure that reports are made without duplication.

29
Table 2 - Population of the fields pertaining to counterparties, report submitting entity and entity
responsible for reporting
Scenario
Report submitting entity (field 1.2)
Entity responsible for reporting (field
1.3)
Counterparty
1 (field 1.4)
Counterparty
2 (field 1.9)
FC reporting on behalf of
NFC- in accordance with Article
9(1a)
Leg 1 FC LEI FC LEI FC LEI NFC- LEI
Leg 2 FC LEI FC LEI NFC- LEI FC LEI
FC reporting on behalf of
NFC- in accordance with Article
9(1a) and FC delegating to
RSE
Leg 1 RSE LEI FC LEI FC LEI NFC- LEI
Leg 2 RSE LEI FC LEI NFC- LEI FC LEI
NFC- opting out from FC reporting on their behalf in accordance with Article 9(1a) Leg 1 FC LEI FC LEI FC LEI NFC- LEI Leg 2 NFC- LEI NFC- LEI NFC- LEI FC LEI NFC- opting out from FC reporting on their behalf in accordance with Article 9(1a) FC delegating to RSE NFCdelegating to RSE2 Leg 1 RSE LEI FC LEI FC LEI NFC- LEI Leg 2 RSE2 LEI NFC- LEI NFC- LEI FC LEI Leg 1 FC LEI FC LEI FC LEI NFC+ LEI

30
Table 2 - Population of the fields pertaining to counterparties, report submitting entity and entity
responsible for reporting
Scenario
Report submitting entity (field 1.2)
Entity responsible for reporting (field
1.3)
Counterparty
1 (field 1.4)
Counterparty
2 (field 1.9)
NFC+ delegating to
FC
Leg 2 FC LEI NFC+ LEI NFC+ LEI FC LEI
NFC+ delegating to
FC and FC subdelegating to RSE
Leg 1 RSE LEI FC LEI FC LEI NFC+ LEI
Leg 2 RSE LEI NFC+ LEI NFC+ LEI FC LEI
NFC+ not delegating to
FC
Leg 1 FC LEI18 FC LEI FC LEI NFC+ LEI
Leg 2 NFC+ LEI19 NFC+ LEI NFC+ LEI FC LEI
Counterparty trading with a natural person not eligible for an LEI delegating to RSE Leg 1 RSE LEI CP 1 LEI CP 1 LEI Client code as specified in ITS on reporting for field 1.9 No Leg 2 reporting required The contract is an ETD (No other delegation in place20) Leg 1 FC LEI FC LEI FC LEI NFC- LEI Leg 2 NFC- LEI NFC- LEI NFC- LEI FC LEI Complex scenario with various events:
NFC + delegating the reporting to RSE.
NFC + becomes NFC- and decides to opt out from FC reporting on their behalf in accordance with
Article 9(1 a) but relies on RSE.
18 If the the FC relies on another entity to submit the reports on its behalf, the field should be populated with the LEI of that RSE. 19 If the the NFC+ relies on another entity to submit the reports on its behalf, the field should be populated with the LEI of that RSE. 20 In case a delegation to another RSE is made, the logic is the same as when the delegation takes place in case ofan NFCopting out from FC reporting in accordance with Article 9(1)(a).

31
Table 2 - Population of the fields pertaining to counterparties, report submitting entity and entity
responsible for reporting
Scenario
Report submitting entity (field 1.2)
Entity responsible for reporting (field
1.3)
Counterparty
1 (field 1.4)
Counterparty
2 (field 1.9)
NFC – decides to opt-in i.e. to stop delegating to RSE and to start relying on FC in accordance with
Article 9(1a).
The FC uses another TR than RSE.
NFC – is merged into another NFC (noted NFC*) that remains NFC-. NFC – becomes NFC+. In this scenario we focus only on the Leg reported on behalf of the NFC.

NFC+ delegating the reporting
to an RSE
RSE LEI NFC LEI NFC LEI FC LEI
NFC+ becomes NFC- but opts
out from FC reporting on their behalf under Article 9(1a) and decides to continue the delegation to an RSE NFC notifies FC ahead of the change of status based on the annual calculation. NFC notifies FC as well that it decides not to apply the transfer of responsibility and legal liability in accordance with Article 9(1a). The NFC continues to rely on its current process and delegates voluntarily to its RSE. RSE LEI NFC LEI NFC LEI FC LEI
NFC- opts in for reporting by FC
on their behalf under Article 9(1a)
Prior to the delegation, the NFC notifies the FC that it intends opt-in the regime foreseen under Article 9(1a) and to transfer the responsibility and legal liability for reporting to the FC in accordance with Article 9(1a) at least 10 days before the transfer of responsibility. The FC and the NFC put in place the arrangements required under Article 9(2) of the ITS on reporting. As a pre-condition to the actual transfer of responsibility, NFC initiates and performs the transfer of data from its RSE’s TR to the TR of the FC in accordance with the Guidelines on data transfer between TRs and with these Guidelines.

32
Table 2 - Population of the fields pertaining to counterparties, report submitting entity and entity
responsible for reporting
Scenario
Report submitting entity (field 1.2)
Entity responsible for reporting (field
1.3)
Counterparty
1 (field 1.4)
Counterparty
2 (field 1.9)
FC LEI FC LEI NFC LEI FC LEI
4. NFC- is merged into another
NFC- (noted NFC*)
FC or NFC- follow the process described in Article 8 of the ITS on reporting related to changes of LEI. Once the change is processed by the TR, the new LEI should be used. FC LEI FC LEI NFC* LEI FC LEI
5. NFC- becomes NFC+ NFC notifies FC ahead of the change of status based on the annual
calculation.
In accordance with the arrangements put in place between both counterparties and required under Article 9(2) of the ITS on reporting, the NFC notifies the FC of the change of status based on the annual calculation. If required under the arrangements, the FC or the NFC initiates and performs the transfer of data from its TR to the TR of the NFC in accordance with the Guidelines on data transfer between TRs and with these Guidelines. NFC* LEI NFC* LEI NFC * LEI FC LEI
3.4.3 CCP
85. With regards to CCPs, in EMIR CCPs are not considered as Financial
Counterparties under Article 2(8) of EMIR, therefore if an NFC- would enter directly in a derivative contract with a CCP, the CCP would not become responsible and legally liable for the reporting of the details of the derivative on behalf of the NFC-. In such cases, the obligation to comply with the reporting obligation remains with the NFC-.
3.4.4 Funds (UCITS, AIF and IORP that, in accordance with national law, does not
have legal personality)
86. Articles 9(1b), (1c) and (1d) introduce as well the allocation of responsibility for
reporting for funds towards their respective fund manager in certain circumstances. In these cases, it is considered that the fund managers have all relevant details available in their respective roles and that the compliance with the provisions on

33 allocation of responsibility for reporting can be ensured in accordance with the regulation.
87. As an illustration, please refer to the Table 3 below.
Table 3 – Population of the fields pertaining to counterparties, report submitting entity and entity
responsible for reporting
Scenario
Report submitting entity (field
1.2)
Entity responsible for reporting (field
1.3)
Counterparty
1(field 1.4)
Counterparty 2
(field 1.9)
Management company / AIFM
(IFM) reporting on behalf of the fund under
Article 9(1c)
Leg
1
LEI IFM LEI IFM LEI fund LEI CPT
Leg
2
LEI CPT LEI CPT LEI CPT LEI fund
Management
Company / AIFM
(IFM) reporting on behalf of the fund under
Article 9(1c) and
delegating to the
CPT
Leg
1
LEI CPT LEI IFM LEI fund LEI CPT
Leg
2
LEI CPT LEI CPT LEI CPT LEI fund
Management
Company / AIFM
(IFM) reporting on behalf of the fund under
Article 9(1c) and
delegating to a
RSE
Leg
1
LEI RSE LEI IFM LEI fund LEI CPT
Leg
2
LEI CPT LEI CPT LEI CPT LEI fund
88. In the particular case where a fund that qualifies as an FC enters into an OTC
derivative with an NFC-, the provision on allocation of responsibility for reporting in the Article 9(1) and the clarifications thereof in the related Guidelines under section
3.4.2 above apply for the OTC derivative from the side of the counterparty.
Therefore, in such a situation:
a. The fund manager is responsible and legally liable to report the OTC derivative on behalf of the fund;

34 b. The fund is responsible and legally liable to report the OTC derivative on behalf of the NFC-.
89. As an illustration, if an AIF (LEI AAAAAAAAAA1111111111) with an AIFM (LEI
AAAAAAAAAA2222222222) enters into an OTC derivative contract with an NFC- (LEI 123456789ABCDEFGHIJK), the counterparty related fields are to be populated as follows:
TABLE 4 – EXAMPLE OF FUND RESPONSIBLE TO REPORT THE DERIVATIVE ON BEHALF
OF THE NFCReport 1 of the derivative Report 2 of the derivative
1.3 Entity
Responsible for
Reporting
AIFM LEI:
AAAAAAAAAA2222222222
AIF LEI:
AAAAAAAAAA1111111111
1.4 Counterparty 1
(Reporting
Counterparty)
AIF LEI:
AAAAAAAAAA1111111111
NFC- LEI:
123456789ABCDEFGHIJK
1.9 Counterparty 2 NFC- LEI:
123456789ABCDEFGHIJK
AIF LEI:
AAAAAAAAAA1111111111
90. For the avoidance of doubt, ESMA stresses again that all the aforementioned
clarifications apply only to OTC derivatives. Thus, for ETDs, i.e. any derivative contracts that do not qualify as OTC based on the definition of Article 2(7) of EMIR as amended by Article 32 of SFTR, the counterparty remains responsible and legally liable for reporting the details to a TR and the provisions related to the transfer of responsibility and legal liability do not apply. Counterparties cannot assume that all options and futures traded on venue are ETDs.
3.5 Delegation of reporting
91. Besides the allocation of responsibility stemming from EMIR Article 9(1a)-(1d) and
covered by section 3.4, EMIR stipulates in Article 9(1f) that the counterparties and CCPs that are subject to the reporting obligation may delegate that reporting obligation, this includes any task (individually and separately) related to the reporting of data. In case of delegation of reporting, the delegating counterparty should provide the report submitting entity with all the details of the derivative contracts and it is responsible for ensuring that those details are correct. The processes and timelines should in case of delegation be the same as in the case of allocation of responsibility for reporting described in the section 3.4. Although at the technical level there are many similarities and common processing aspects between the allocation of responsibility and delegation of reporting, legally they are

35 different and independent reporting scenarios. It should also be mentioned that EU counterparties should carefully assess any risks that might be posed to their compliance with the reporting obligations in case of delegation of reporting to a nonEU report submitting entity.
92. RTS on reporting provides a specific data element, field 1.2 ‘Report submitting
entity ID’, which should be mandatorily populated and in case where the reporting counterparty or entity responsible for reporting has not delegated the submission of the report to a third party or to the other counterparty, the reporting counterparty or entity responsible for reporting will populate its own LEI. In the case when in the reporting of a derivative multiple entities are involved, i.e. the reporting is carried out by a chain of entities, field 1.2 should be populated with the LEI of the entity ultimately submitting the report to the TR. FR on RTS/ITS (in section 4.1.3) also clarifies that the RSEs should inform the reporting counterparties and ERRs about relevant reporting and data quality issues (including data submitted on its behalf, all the rejections, reconciliation breaks as well as other data quality issues pertaining to the relevant data) for which the information will not be provided by the TRs, especially if these reporting counterparties and ERRs are not participants or users of the TR. ESMA also clarified in the FR on RTS/ITS that responsibilities regarding the outstanding derivatives should be agreed by the parties and covered by the delegation agreement. Naturally the delegation agreement needs to cater for the point in time when it comes into effect and also for the point in time when it ceases to be effective. Responsibilities of the counterparties and RSEs with regards to data completeness and accuracy, e.g. update of LEI, and generally the responsibility for the content of reports remains in case of delegation always with the entity responsible for reporting. The delegating counterparty (subject to the reporting obligation) should provide the RSE with all the details of the derivative in a timely manner, and it is responsible for ensuring that those details are correct.
93. Delegation of reporting includes the following scenarios:
a. one counterparty delegates to the other counterparty; b. one counterparty delegates to a third party;
c. both counterparties delegate to a single third party;
d. both counterparties delegate to two different third parties.
94. In any of the scenarios above the principle of avoiding duplication and ensuring the
continuity of reporting should be followed.
95. ESMA encourages centralised reporting (i.e. by the venue on which a non-OTC
derivative has been concluded or by the CCP in which it is being cleared); however, this should be always a matter of agreement by the counterparties, based on delegation agreement. Whenever a third party is performing that function based on a delegation agreement (on behalf of one or both counterparties), it should ensure that all relevant data are duly and timely provided by the counterparties to fulfil the reporting obligation.
96. Further clarifications should be noted with regards to the delegation of tasks in case
a third party is used for reporting and any possible differences in criteria for

36 delegation depending on the home member state of the delegating entity. Firstly, the reporting counterparty, ERR or RSE can decide to delegate any task related to the reporting of data, including the generation of the UTI. Secondly, currently no specific rules on how the delegation should be performed are determined, however all EMIR provisions should be respected (timely and accurate reporting, etc.) and the counterparties should remain liable for the content of the reports and any misreporting by the third entities they rely upon. Legal documentation covering the delegation arrangement is recommended (e.g. written agreement between entity responsible for reporting and the report submitting entity, even if also subject to the requirement to report, such as the other counterparty or the CCP).
97. For example investment firms that provide only investment services (such as
execution of orders or receipt and transmission of orders) do not have any obligation to report under EMIR unless they become a counterparty to a derivative by acting as principal. However, nothing prevents counterparties to a derivative to use an investment firm (acting as a broker) as a third party for TR reporting.
98. In the case when a portfolio manager is involved, i.e. an entity to which the
execution of (a part of) the investment strategy of a counterparty is delegated, this portfolio manager should be identified (in the relevant field) only when that entity performs, de jure or de facto, one of the roles identified in the counterparty data of a derivative report, e.g. broker. Otherwise that entity should not be identified.
3.6 Reporting of lifecycle events
3.6.1 Action types
99. Counterparties should report the conclusion, modification and termination of a
derivative.
100. In case none of the details of the derivative, as expressed in the data fields,
have changed, the counterparties should not report again details of the derivative. The only exception is the update of the outstanding derivatives in the transition period as described in the section 3.1.
101. Furthermore, the counterparties that are required to report valuation and
collateral, i.e. FCs, NFC+ and CCPs, should report on a daily basis the details of valuation and collateral as they stand at the end of the day, for all their outstanding derivatives.
102. Counterparties should use action type ‘Modify’ to report modifications of the
details of a derivative, ‘Valuation’ to report changes in the value of a derivative and ‘Margin update’ to report modifications of the corresponding collateral.
103. Counterparties should ensure that action types ‘Modify’ and ‘Correct’ are used
correctly. In particular, ‘Modify’ should be used to report modifications to the terms or details of a previously reported derivative, including when counterparty provides additional information that previously was not available at the time of reporting. ‘Modify’ should not be used to report corrections of details of derivatives – only ‘Correct’ should be used for that purpose.

37
104. Similarly, in the case of collateral data, action type ‘Margin update’ should be
used to report the collateral for the first time as well as to report modifications of the collateral data, but not the corrections of the previously reported collateral details which should be made with action type ‘Correct’. A change in the collateral portfolio code should be reported with ‘Modify’ (to update the code for a given derivative in the portfolio) and ‘Margin update’ (when submitting the details of the collateral at portfolio level). However, if the change in the portfolio code information is made due to an initial error in reporting, such change should be reported with action type ‘Correct’.
105. In principle only one report per day, with action type ‘Margin update’ is expected.
However, if a counterparty identifies that it had submitted incorrect collateral data for a given day, it should submit a collateral report with action type ‘Correct’ for that day (specifying in the field ‘Event date’ and in the ‘Collateral timestamp’ the day for which the data are corrected).
106. Collateral at a single derivative level can be reported for the first time either as
part of the derivative report with action type ‘New’ or separately with action type
‘Margin update’. Collateral at portfolio level should be reported for the first time with action type ‘Margin update’. The new collateral is expected to be reported only when at least one derivative covered by that collateral was reported and not errored. Verification that collateral is not reported when no corresponding derivative was reported should be performed as part of the TRs’ validations. If a counterparty submits wrongly both derivatives and corresponding collateral, erroring the derivatives would result automatically in erroring the collateral as there would no longer be any corresponding derivatives.
107. In case a margin update report is submitted to a TR by a counterparty without
obligation to report collateral on a daily basis (but the corresponding derivatives are valid and should not be errored), that counterparty should not submit any further margin updates. Sequences of action types
108. In order to ensure logical coherence between different reports pertaining to the
same derivative, TRs’ validation rules cover i.a. the correct sequences of action types.
FIGURE 6: ALLOWABLE SEQUENCES OF ACTION TYPES

38
THE BLUE BOXES IN THE
109. Figure 6 chart specify the status of a derivative, while the allowable action types
are indicated on the arrows. For example, when a derivative is reported for a first time with the action type ‘New’, the status changes from ‘Not reported’ to ‘Outstanding’. If a counterparty reports subsequently ‘Error’ for that derivative, the status changes from ‘Outstanding’ to ‘Errored (non-outstanding)’. For a derivative that has such status, the only allowable action type is ‘Revive’ (the only action type on the arrows starting in the blue box with status ‘Errored (non-outstanding)’. If submitted - it would change the status of the derivative either back to ‘Outstanding’ or to ‘Terminated (non-outstanding)’, depending on the maturity/termination date of that derivative. All dependencies between action types and statuses of derivatives indicated in the chart should be read in this way.
110. All dependencies described in the chart apply to the reports of a given
counterparty. I.e. the reports sent by the other party to the trade do not impact allowable action types reported by the first counterparty. It applies in particular to action type ‘Error’, meaning that if one counterparty submitted ‘Error’ for a given UTI (and has not reported ‘Revive’ afterwards), only that counterparty will not be able to send further reports (other than ‘Revive’) for this UTI. In this way, if one counterparty reports ‘Error’ by mistake, it will not prevent the other counterparty from timely reporting relevant lifecycle events.
111. Action types ‘Modify’, ‘Correct’, ‘Margin update’ and ‘Valuation’ do not impact
the status of the derivative. They are allowed to be reported for terminated trades only in the case of late reporting but they cannot be used to change the status of the derivative to outstanding (e.g. by modifying the maturity date). Only the action type ‘Revive’ can be used to change the status of the derivative to outstanding.

39
112. Action type 'Revive' can be used to re-open derivatives cancelled (with action
type 'Error'), terminated by mistake (with action type 'Terminate') and to re-open derivatives that reached (incorrectly reported) maturity date. Furthermore, ‘Revive’ can be used after the action type ‘Position component’, if the latter was reported by mistake. In such case the revived derivative at the trade level will be perceived as outstanding, subject to the expiration date. If the counterparty reported new position or a modification of a position, it would need to be reverted separately (by erroring or modifying such position, respectively).
113. Counterparties, when reporting ‘Revive’ should provide all applicable details of
the contract as of the time of revival. However, counterparties should also submit any missing reports that should have been made while the derivative was temporarily non-outstanding. This includes reports with action type ‘Correct’ to correct any specific values in the report, except for when the only correction was to update the derivative to outstanding status (where such status can be inferred from the ‘Revive’ report itself).
114. Reaching the scheduled maturity date is not an EMIR reportable event by the
counterparties. No action type applies in this case, including but not limited to ‘Error’ and ‘Terminate’. Once a derivative reaches it maturity date, it is considered no longer outstanding. A derivative that is no longer outstanding and is reported late with action type ‘New’ after reaching its maturity date, will be considered nonoutstanding.
115. When a derivative is included in the position, the status of that derivative
changes to ‘Terminated (non-outstanding)’. Any subsequent lifecycle events must be reported at position level with a different UTI (the one of the position), and the correct sequencing of these reports for that position should also be validated. It is possible however to send a correction at trade level for a derivative that was reported with action type ‘Position component’, if some details of that derivative were incorrect.
116. The reports should be sent in a chronological sequence in which the events
occurred, in line with the requirements set out in the ITS on reporting. However, it is recognised that in the cases where an entity fails to report on time or becomes aware of the past submission of incorrect information, the entity should send the reports with past event dates thus breaking the chronological order.
117. If there is an error in a historic valuation submission, only the valuation for that
past date needs to be corrected and there is no need to rereport the correct valuations submitted after the incorrect valuation message. However, in the case where multiple ’Valuation’ messages had been incorrectly reported and corrections were required - the counterparty should submit a correction report for each day when incorrect valuation was submitted.
118. TRs should validate the correct sequences of action types taking into the
consideration the content of the field ‘Event date’. With regard to how the TRs should treat the reports with past event dates for the purpose of construction of the Trade State Report, more details are included in the section 6.1.

40
3.6.2 Action types and event types combinations
119. Counterparties should report, where applicable, the relevant event type, as
specified in the field 2.152 in the RTS on reporting.
120. The below table specifies the allowable combinations of action types and event
types, as well as sets out whether they apply at trade level, position level or both. The last column of the table indicates when a given action type can be reported without an event type.
Table 5 - Allowable action type-event type combinations
Event type
TRADE
STEP-IN
PTRR
EARLY TERMINATION
CLEARING
EXERCISE
ALLOCATION
CREDIT EVENT
INCLUSION IN POSITION
CORPORATE EVENT
UPDATE
No Event Type required
Action type
NEW T T,P T P T,P
MODIFY T,P T T,P P T,P T,P P
CORRECT T,P
TERMINATE T,P T T,P T T,P
ERROR T,P
REVIVE T,P
VALUATION T,P
MARGIN UPDATE T,P
POSITION
COMPONENT T
121. Table 6 clarifies the applicability of all allowed action type-event type
combinations as well as provides additional comments on the actual use cases where such combinations would be reported or, on the contrary, where they should not be used.
122. The comprehensive mapping between business events and action type-event
type combinations is provided in the section 3.10.
123. It should be noted that no event type is envisaged for porting. ESMA reiterates
that porting should be performed in line with the Guidelines on transfer of data

41 between TRs21. Action types ‘New’ and ‘Terminate’ should not be used for that purpose.
Table 6 - Applicability of action type – event type combinations
Action type Event type Applicability Comments New Trade When a derivative with a new UTI is created for the first time through trade and not because of another prior event. Combination ‘New’-‘Clearing’ should be used for the new derivatives resulting from clearing, in particular for derivatives traded on trading venues and cleared on the same day by a CCP. New Step-in When a derivative or position with a new UTI is created for the first time due to a step-in event. New PTRR When a derivative with a new UTI is created for the first time due to a PTRR event. Combination ‘New’-‘PTRR’ at position level is not applicable, as any derivative newly created due to a PTRR event is expected to be reported at trade level (without prejudice to the possibility of including such derivative subsequently in a position). Combination ‘New’-‘PTRR’ can be used in case of rebalancing. New Clearing When a derivative with a new UTI is created for the first time due to a clearing event. This combination includes also a clearing of OTC derivatives which were previously bilaterally agreed among counterparties and subsequently cleared. New Exercise When a derivative with a new UTI is created for the first time due to an exercise event. This combination should be used when reporting the underlying swap following the execution of a swaption New Allocation When a derivative with a new UTI is created for the first time due to an allocation event. New Inclusion in position When a new position is created by inclusion of trades in that position for the first time. New Corporate Event When a derivative or position with a new UTI is created for the first time due to a corporate action on the underlying equity. Modify Trade When a derivative or position with an existing UTI is modified due to renegotiation of the terms of the trade, because of the changes to the 21 https://www.esma.europa.eu/sites/default/files/library/esma74-362-2351_final_report_- _guidelines_on_data_transfer_between_trade_repositories_emir_sftr.pdf

42
Table 6 - Applicability of action type – event type combinations
Action type Event type Applicability Comments terms of the trade agreed upfront in the contract (except for when such changes are already reported e.g. notional schedule) or because previously not available data elements become available. Modify Step-in When a derivative or position with an existing UTI is modified due to a step-in event. This combination includes also a transfer of a derivative at trade or position level from one CCP to another. Modify PTRR When a derivative or position with an existing UTI is modified due to a PTRR event. Combination ‘Modify’-‘PTRR’ at position level should only be used in the case where CCP positions are subject to PTRR (rather than bilateral netting and subsequent reporting at position level). Combination ‘Modify’-‘PTRR’ can be used in the case of compression. Modify Early termination When a derivative or position with an existing UTI is modified due to an early termination agreed in advance or due to a partial termination. In the case of an early termination agreed in advance, the counterparties should update the maturity date. In the case of partial early termination, the counterparties should update the notional. Modify Exercise When a derivative or position, is amended due to the exercise of an option or swaption. Modify Allocation When a derivative with an existing UTI is partially allocated. This is used to report the amended notional of the existing derivative. Modify Credit event When a derivative or position with an existing UTI is modified due to a Credit event. Modify Inclusion in position When a position with an existing UTI is modified because of inclusion of a new trade. Modify Corporate Event When a derivative or position with an existing UTI is modified due to a corporate action on the underlying equity. Modify Update When a derivative or position that is outstanding on the reporting start date is updated in order to conform with the amended reporting requirements.

43
Table 6 - Applicability of action type – event type combinations
Action type Event type Applicability Comments Modify No event type required When a position with an existing UTI is modified due to more than one type of business events that occurred intraday. Intraday reporting is not mandatory for ETDs, consequently counterparties are allowed to report ‘Modify’ at position level without indicating the event type, where such modification is a result of more than one type of business events that occurred intraday. Correct No event type required When a derivative or position with an existing UTI or the data related to the collateral is corrected because of an earlier submission of incorrect information. Terminate Step-in When a derivative or position with an existing UTI is terminated due to a step-in event. This is used for terminating the old UTI post step-in. Terminate PTRR When a derivative or position with an existing UTI is terminated due to a PTRR event. This is used for terminating the old UTI(s) after PTRR operation. Combination ‘Modify’-‘PTRR’ can be used in the case of compression. Terminate Early termination When a derivative or position with an existing UTI is terminated due to an early termination (and when no other cause/event is known as the reason for that termination). Terminate Clearing When a derivative with an existing UTI is terminated due to a Clearing event. This is used for terminating alpha trades. In the case of OTC derivatives concluded bilaterally, counterparties need to terminate the previously reported bilateral trades (with combination ‘Terminate’-‘Clearing’) and report the new cleared trades (with combination ‘New’-‘Clearing’). This also includes a scenario where existing derivatives become eligible for clearing at a later stage. Terminate Exercise When a derivative with an existing UTI is terminated due to an exercise event. E.g. this is used for terminating options/swaptions when these are being exercised. ‘Terminate’ - ‘Exercise’ should not be reported when the option is exercised on the maturity date. More generally, only terminations that take place at a date prior to the maturity date should be reported. Terminate Allocation When a derivative with an existing UTI is terminated due to an allocation event. This is used for

44
Table 6 - Applicability of action type – event type combinations
Action type Event type Applicability Comments terminating the old UTI post allocation. Terminate Credit event When a derivative or position with an existing UTI is terminated due to credit event. This combination should be reported when a credit event leads to termination and settlement of the derivatives, e.g. single name CDS. Terminate Inclusion in position When a derivative or position with an existing UTI is terminated due to inclusion in a position. A derivative at trade level that is immediately included into a position, should be reported with action type ‘Position component’. Only when a derivative is included in the position after being reported with action type ‘New’, it should be reported with action type ‘Terminate’ and event type ‘Inclusion in position’. Terminate Corporate Event When a derivative or position with an existing UTI is terminated due to a corporate action on the underlying equity. Error No event type required When a derivative or position with an existing UTI is cancelled due to an earlier submission of incorrect information. E.g. this is used to cancel the UTI of a derivative or position that should not have been reported (e.g. it is not a derivative transaction) or to cancel outstanding derivatives when the counterparty starts to benefit from an intragroup exemption. Revive No event type required When a derivatives or position that has been cancelled is reinstated due to an earlier submission of incorrect information. E.g. this is used to reinstate the UTI of a derivative or position that has been erroneously terminated. This action type should not be used to reopen a position that was previously netted and terminated. ‘Revive’ should only be used to reopen the trades that were terminated or cancelled by mistake or which were cancelled due to IGT exemption, so that the counterparties do not need to regenerate a new UTI. It should not be used for other reporting scenarios. In particular in the case of netted position, the counterparties need to decide if they maintain the position open (and report the valuation accordingly) or they close the position. If the counterparties

45
Table 6 - Applicability of action type – event type combinations
Action type Event type Applicability Comments close the position and then they enter into another derivative contract of the same type and want to report at position level, they need to report a new position with a new UTI. Valuation No event type required When data related to the valuation are submitted for a derivative or position with an existing UTI. Margin update No event type required When data related to the collateral are submitted for a derivative or position with an existing UTI. Position component No event type required When a new derivative is concluded and included in a position on the same day.
124. Where a counterparty submits by mistake an incorrect event type, there is no
possibility to correct such information, as ‘Event type’ is not applicable for action type ‘Correct’. The counterparty should ensure to submit an appropriate ‘Event type’ in the subsequent report.
3.6.3 Lifecycle events and use of linking IDs (Prior UTI, PTRR ID, Subsequent
position UTI)
125. Counterparties should report, where relevant, linking IDs to allow for
identification of reports pertaining to the same lifecycle events. The linking IDs envisaged for that purpose are following:
a. ‘Prior UTI’ (field 2.3) b. ‘Subsequent position UTI’ (field 2.4)
c. ‘PTRR ID’ (field 2.5)
126. Prior UTI should be used in the case of those life cycle events where a single
derivative is terminated and one or more new derivatives are created. In such cases the prior UTI, i.e. the UTI of the derivative that was terminated, should be populated in field 2.3 in the reports pertaining to all the derivatives created due to the lifecycle event. In particular, the prior UTI will be applicable in the following events:
a. Step-in; b. Clearing (unless the derivative was concluded on a trading venue or a thirdcountry organised trading platform and cleared by a CCP on the same day);
c. Exercise (in the case of swaptions),
d. Allocation, e. Corporate event (in the case of a split).

46
127. Subsequent position UTI should be reported when a derivative is included into
position (and reported either with action type ‘Position component’ or action type ‘Terminate’ and event type ‘Inclusion in position’). It should contain the UTI of the position in which this derivative is included.
128. PTRR ID should be reported when the event type is ‘PTRR’ and the type of
PTRR technique is either compression with a third-party service provider or rebalancing. The same PTRR ID, as provided by the PTRR service provider, should be reported in all reports that are created, modified or terminated due to the same PTRR event. Each PTRR event should be assigned a different PTRR ID.
129. It is possible to report more than one linking ID for a given derivative (e.g. a
derivative may be reported first with a prior UTI when it is cleared, then it may be reported with a PTRR ID if it is modified due to a PTRR event and finally it may be reported with a subsequent position UTI if in the end it is included in a position). However, only the relevant linking ID should be reported in the report pertaining to a given lifecycle event (in the above example, the counterparty reporting inclusion in the position would populate in that report only the field ‘Subsequent position UTI’).
3.7 Reporting at position level
130. In general terms, ’position’ should be understood as the exposure between a
pair of counterparties, consisting of a set of fungible derivatives (trades) with economic and legal relations among them which allows for a common risk management that results in a net or reduced volume of the joint exposure. Trade and transaction are used interchangeably in this section.
131. Following Article 3 of the RTS on reporting, it is possible to report post-trade
events at position level following the initial reporting of the details of a derivative concluded at transaction level and the termination of that derivative due to its inclusion in a position, provided that the following conditions are met: the legal arrangement is such that the risk is at position level, all trade reports made to the TR relate to products that are fungible with each other and the individual trades previously reported to the TR have been subsequently replaced by the position report (e.g. as in the case of trades between a clearing member and a CCP).
132. The categories of derivatives eligible for reporting at position level are: ETDs,
centrally cleared OTC derivatives netted by CCPs and Contracts For Difference (CFDs). Although in the case of such derivatives the information concerning positions is most relevant for the assessment of systemic risk, reporting only at position level is not in line with EMIR requirements under Article 9 of EMIR, which requires all counterparties to report e.g. conclusion of a derivative at transaction level.
133. Contracts with no maturity date, such as CFDs, are strongly recommended to
be reported at position level in order to avoid that each individual outstanding derivative for a financial counterparty needs to receive daily valuation updates until either 1) the derivative is cancelled or 2) infinity, because these derivatives

47 generally have no maturity. The valuation can be provided at position level once the corresponding derivative transactions are included in a position.
134. ESMA acknowledges the potential difficulties in agreeing bilaterally the level of
reporting between counterparties and the impact of such problems on the reconciliation. Nevertheless, ESMA reiterates that the reporting at position level should be agreed between the two counterparties as this obligation stems from the requirement of Article 9(1e) of EMIR to ensure that the details of the derivative contracts are reported correctly and without duplication. This is also stated in the
Article 3 of the RTS on reporting. The two counterparties to a derivative should
either both include the derivative in a position or both continue to report the relevant lifecycle events at trade level. Reporting at position level is generally an option, rather than a requirement and is feasible only when all the relevant conditions are met, including when the two counterparties agree on reporting at position level. In the absence of agreement between the counterparties, reporting at trade level is a default way forward. However, in certain circumstances, the only possible option to comply with EMIR reporting obligations is reporting at position level (e.g. when the counterparties are not able to value the individual position components). Even in these circumstances, agreement between the counterparties involved is a necessary condition.
135. Intraday reporting at position level is not required for any type of derivatives,
neither for ETD nor for OTC, i.e. there is no need to report lifecycle events (e.g.:
modifications) of a position intraday. But, in order to report correctly a position and to reflect all the modifications which affect it (also when a trade is included in a position level report on the same day), the updated details and valuation of the position should be reported by the counterparties at position level at the end of the day. This is in line with the clarifications developed in the sections 3.6 and 3.9, such as the one on the possibility of reporting the event type as “blank” when there are multiple events impacting the same position on a given day in order to simplify the reporting. At trade level, intraday reporting of lifecycle events for ETD trades is not mandatory. For OTC trades the reporting of intraday lifecycle events should be as comprehensive as feasible as of the end of the day.
136. When a position is created, a report with action type ‘New’ and the proper event
type should be reported. Modifications of a position because of inclusion or termination of trades, etc. should be reported with action type ‘Modify’ and, to the extent feasible, the adequate event type. A position ends when its maturity date is reached. If the termination of a position is due to other reasons, an action type ’Terminate’ and the event type which describes the reason for that termination should be reported by the counterparties. Further details are provided in the section 3.6.
137. Taking into account that it is not allowed to report only positions without
previously reporting the original derivatives at trade level, such derivatives at trade level should be updated to have an appropriate status so that it is clear that they are no longer open and to avoid double-counting of the trades that were included into positions. Consequently, the counterparties should report the terminations of all the derivatives at trade level that enter into the position. It should be done using

48 the action type ‘Terminate’ and the event type ’Inclusion in position’ or the action type ‘Position component’ with no event type required, this latter when reporting a new trade that is included in the position on the same day. In addition, the field ‘Level’ should be reported as ‘T’ (trade). In this manner, all the trades which have been included in a position are no longer considered to be outstanding. Then, the position should be reported using the action type ‘New’ if the position is created for the first time or action type ‘Modify’ in the case of an update to an existing position. The field ‘Level’ should be reported as ’P’ (position) for any reporting of the position.
138. When counterparty reports at position level, any subsequent updates,
modifications and life cycle events (including revaluations) should be applied by the TRs to the report of the derivative position and not to the reports of the original trades.
139. All the data elements that are required in trade reports are mandatory as well in
position reporting, with the exception of those that are relevant only at trade level.
140. The field ’Notional‘ should be always populated in reports made at position level.
Furthermore, the value of Notional at position level reports should be calculated as follows:
a. For options: Notional = Total notional quantity x Strike price; b. For futures: Notional = Total notional quantity x settlement price22 .
141. Reporting of modifications in the field ‘Notional’ at position level should take
place only if an event relevant for the position has taken place (e.g. a new relevant trade has been included in the position, this new notional value should be taken into account in the notional of the position). Further details are provided in section
3.17 of these Guidelines.
142. In the case where a position valuation becomes zero, there are only two
possible ways to proceed:
a. Termination of the position and reporting of a new one using a different UTI at a later stage. No valuations are reported between the termination of the first position and the creation of the latter. a. Maintaining the position open and reporting a zero contract value on a daily basis.
143. The ‘effective date’ is the date as of which the obligations under the derivative
come into effect, as included in the confirmation of the derivative or otherwise agreed between the counterparties. Where the counterparties did not specify the effective date as part of the terms of the contract, field ‘Effective date’ should be populated with the date of execution of the derivative. At position level, the Effective date should be represented by the effective date of the trade which has the earliest effective date. If the counterparties did not specify the effective date of the position as part of the terms of the contract, field ‘Effective date’ at position level should be populated with the effective date of the derivative trade which has the earliest 22 Settlement price is not a reportable field

49 effective date or the date part of the execution timestamp (this execution date would be the earliest execution date of the position) in the case that counterparties did not specify the effective date of the contract.
144. The ‘expiration date’ is the date as of which obligations under the derivative stop
being effective, as included in the confirmation of the derivative or otherwise agreed between the counterparties. Early termination does not affect this data element. Expiration date, at position level, should be the furthest expiration date in the future among the trades that are included in the position. If there is a subsequent modification of this expiration date, because this possibility was originally contained in the contract of this trade, a modification report should be sent, modifying the ‘Expiration date’ field accordingly to reflect the updated expiration date at position level.
145. The ’early termination date’ is the date on which there is a termination of the
derivative that occurs prior to its maturity due to e.g. a decision of a counterparty or counterparties. Regarding position level reporting, an action type ‘Terminate’ and event type ”Early Termination” should be populated when the entire position is terminated.
146. The ’reporting timestamp’ is the date and time of the submission of a given
derivative report to the trade repository. It applies in the same way to the reports at position level.
147. The ’execution timestamp’ is the date and time when a derivative (at trade or
position level) was opened for the first time and its UTI was created. In the case of position-level reporting, that field should be populated in a similar manner as the field ’Effective date’, i.e. with the date of the trade that has the earliest execution timestamp.
148. The ’event date’ is defined as the date when a given event took place or when
a modification became ’effective‘ (rather than the date of agreement to modify the derivative). At position level, this field should be populated when relevant events or modifications relating to the position took place. Further details are provided in the
section 3.9.
149. The ’clearing timestamp’ is the date and time when a trade or position is cleared.
At position level, this field should be reported using the execution timestamp of the position as the two timestamps are expected to be equal for positions.
150. At position level, the ‘Venue of execution’ field, should be populated with the
MIC code (defined by ISO 10383) of the venue where the highest number of derivatives that are included in the reported position were executed.
151. A derivative that is a result of PTRR exercise, should be reported at trade level.
152. ESMA reiterates that reporting at position level is a different business case than
reporting of PTRR events, both with different reporting rules. The below table highlights the key differences between the two instances:

50
TABLE 7
3.8 Reporting of on-venue derivatives
153. The ETD contracts are derivative contracts that are subject to the rules of a
trading venue (as defined in Article 4(1)(24) of the Directive 2014/65/EU) and are executed in compliance with those rules. For the purpose of reporting of ‘on-venue derivatives’, account is also taken of similar trading platforms outside the EU. The trading venue´s rules provide the execution and processing of the contract on the trading venue and the subsequent clearing on a central counterparty clearing house (CCP) within one business day after the execution.
154. In order to allow authorities to identify and analyse risk positions, the
counterparties that assume the risk once the contract has been concluded should be clearly identifiable. Under the principal clearing model, upon clearing, the risk lies on the clearing member (CM) vis-à-vis the CCP and on the client of the CM visà-vis the CM. For this reason the following parties have EMIR reporting obligations:
a. The CCP clearing the derivative contract. b. The clearing members of the CCP that are clearing the derivative contract.
c. The MiFID investment firms involved in the trade chain anytime they bear the
risk arising from the derivative by virtue of its contractual relationship with their counterparties (in particular, with the clearing member). d. Other parties that do not fall into any of the categories above and that take the risk arising from the derivative, except when they are exempt because of their status.
155. If one of these parties assumes more than one role (e.g. an investment firm is
also the clearing member), it should submit one report identifying all the applicable roles in the relevant fields, it does not have to report separately for each role. Examples:

51
Scenario 1: The investment firm bears the risk vis-à-vis the CM and, thus, is itself a counterparty. In this case the following reports should be submitted:
TABLE 8
Scenario 2: The investment firm does not bear any risk vis-à-vis the clearing member as, according to the legal arrangements, the client directly bears the risk vis-à-vis the clearing member, once the latter accepts the contract for clearing.
TABLE 9
156. Where a give-up occurs from the investment firm to the clearing member within
the T+1 reporting deadline without any change in the economic terms of the original derivative, the derivative should be reported in its post give-up state. It means that the investment firm does not bear any risk vis-à-vis the clearing member, thus the client bears directly the risk vis-à-vis the clearing member with whom it entered into clearing arrangement. ESMA also reiterates that relevant events impacting derivatives reported at trade level must be reported accordingly (e.g. allocation of trades).
157. Partial executions should be reported separately, because parameters and
counterparties will be different.

52
158. The Report Tracking Number (RTN) is a unique code assigned to the execution
and common for a group of reports related to the same execution. It is a conditionally mandatory field for action type ‘POSC’ at the trade level (required when trade is executed on a trading venue). RTN should not be populated at position level.
159. There is no one-to-one link between the Trading Venue Transaction
Identification Code (TVTIC) required under MiFIR and the Report Tracking number (RTN). TVTIC is an individual transaction identification code for each transaction resulting from the full or partial execution of an order disseminated to both the buying and the selling parties. The RTN is a unique number assigned to the execution and common among a group of reports related to the same execution, in order to allow for identification of reports relating to the same execution. Due to the fact that a systemic internaliser is not considered as a trading venue under the Directive 2014/65/EU (MIFID II) and a RTN is generated by a trading venue, the population of the field RTN when trades are concluded on a SI is not required.
160. The investment firms, the clearing members or the CCPs should provide to the
reporting counterparties the respective RTNs. Likewise, the reporting counterparties should transmit the RTNs to their counterparties to allow them to fulfil their reporting obligations.
161. The reporting of the RTN for CFD (in case they are executed on a venue and
where a group of CFDs are related to the same execution) follows the same rules described above.
162. The Unique Trade Identifier (UTI) is a unique code of a derivative between two
counterparties. A pair of counterparties should use a specific UTI for one single derivative, and not reuse that same UTI to report any other derivative under EMIR. The same principle applies to the UTIs generated for the derivatives reported at position level. The UTI must be identical in the reports of both counterparties entering into a derivative. Further details about Unique Trade ID (UTI) are provided in the section 3.11.
163. The timestamps fields should be populated as follows:
a. The execution timestamp should correspond to the time of execution on the trading venue. b. The clearing timestamp should be reported as the time at which the CCP has legally taken on the clearing of the trade. When clearing takes place using the open offer model, the clearing timestamp and the execution timestamp used are expected to be the same. However, if clearing takes place using novation, the two timestamps may be different.
164. Unless otherwise agreed between the parties, an investment firm is not
expected to submit any report on the value of the collateral as well as any subsequent modification or termination of the concluded derivative contract when the process of collateralisation takes place through direct arrangements between the client (counterparty 1) and the clearing member.

53
165. At trade level and at position level, for on-venue derivatives trades, intraday
reporting of lifecycle events is not mandatory, it is optional. At trade level and at position level, for on-venue-derivatives, all lifecycle events can be reported at the end of the day reflecting the state of the derivative at that point.
166. Example of an on-venue derivative following the RTS on reporting: A
Portuguese credit institution A sends a modification to an on-venue position with a Spanish investment company counterparty B, due to a corporate event occurring in the underlying equity. The report pertains to a position of futures traded on trading venue X on dividends on a share of a Dutch company. The position is collateralised and settlement will be in cash.
167. Not all the required fields have been included.
TABLE 10 REPORTING OF AN ON-VENUE DERIVATIVE
No Field Example
Table 1
1 Reporting timestamp 2021-12-02T09:35:00Z 2 Report submitting entity ID LEI A 3 Entity responsible for reporting LEI A 4 Counterparty 1 (Reporting counterparty) LEI A 5 Nature of the counterparty 1 F 6 Corporate sector of the counterparty 1 CDTI 7 Clearing threshold of counterparty 1 TRUE 8 Counterparty 2 identifier type TRUE 9 Counterparty 2 LEI B 11 Nature of the counterparty 2 F 12 Corporate sector of the counterparty 2 INVF 14 Reporting obligation of the counterparty 2 FALSE

54
16 Clearing member LEI A
17 Direction BYER
20 Directly linked to commercial activity or treasury financing FALSE
Table 2
1 UTI ABCDE24680TTTTT22222
7 ISIN DE000C5XXXXX
9 Product classification FFVCSX
10 Contract type FUTR
11 Asset class EQUI
13 Underlying identification type
I
14 Underlying identification NL001154XXXX
19 Settlement currency 1 EUR
21 Valuation amount 205.100,00
22 Valuation currency EUR
23 Valuation timestamp 2021-12-02T00:59:00Z 24 Valuation method CCPV 26 Collateral portfolio indicator TRUE 27 Collateral portfolio code 1814145_1145_BSC040XXXX 30 Clearing obligation UKWN 31 Cleared Y 32 Clearing timestamp 2021-12-01T00:59:00Z 33 Central counterparty CCP LEI 37 Intragroup FALSE

55
38 PTRR FALSE
41 Venue of execution MIC X
42 Execution timestamp 2021-12-01T00:30:00Z 43 Effective date 2021-11-30 44 Expiration date 2021-12-17 47 Delivery type CASH 48 Price 0,42 49 Price currency EUR 55 Notional amount of leg 1 1554000 56 Notional currency 1 EUR 60 Total notional quantity of leg 1 3700000 151 Action type MODI 152 Event type Corporate Event 153 Event date 2021-12-02 154 Level PSTN
3.9 Timely reporting of conclusion, modification and termination of
a derivative
168. Article 9(1) of EMIR provides that ”Counterparties and CCPs shall ensure that
the details of any derivative contract they have concluded and of any modification or termination of the contract are reported (…) to a trade repository (…)”. Furthermore, the relevant details should be reported “no later than the working day following the conclusion, modification or termination of the contract.
3.9.1 Conclusion of a derivative
169. Each conclusion of a derivative should be reported to a TR. If a derivative that
is concluded is subsequently terminated, then the counterparties or ERR, as applicable, after reporting it with action type ‘New’ should report it with action type ‘Terminate’.

56
170. Counterparties should report the conclusion of a derivative even if the
termination of that derivative occurs before the reporting deadline (e.g. for intraday derivatives). In such case the counterparty should send, within the same reporting deadline, two reports: one with action type ‘New’ and one with action type ‘Terminate’. If the derivative is terminated on the same day due to inclusion in a position, the counterparty should send only one report for that derivative, with action type ‘Position component’.
171. If the original derivative was included in a position and thus reported with the
action type ‘Position Component’, and is subsequently terminated, the counterparties should not send a report with action type ‘Terminate’ for the original derivative, however the counterparties should send a report with action type ‘Modification’ for the position in which the original derivative was included in order to remove this derivative from the position.
172. Action type ‘Error’ should only be used to cancel the derivatives that never came
into existence or that are out of the scope of the reporting obligation under EMIR. Therefore, in the specific scenario where the counterparties agree to conclude a derivative which is conditional upon registration with the CCP and the CCP rejects that derivative, the counterparties should terminate the derivative with action type ’Error‘ because the agreed condition for the contract to take place was not fulfilled, therefore the derivative never came into existence.
3.9.2 Modification or correction of a derivative
173. A modification to a derivative comprises the reporting of the following action
types: ’Modify‘ and ’Correct‘. The timeline for reporting is the same as for the conclusion of a derivative, meaning that from the point in time when a modification is effective, it becomes reportable.
174. Counterparties should report only the modifications that have taken place, i.e.
they should not report modifications that were agreed but will become effective in the future. To give an example, if the counterparties agree to amend the notional on a future date, this amendment should be reported only once the agreed date (the effective date of amendment) is reached.
175. With respect to correction, these should be reported as soon as the incorrectly
reported data is identified.
176. It is not necessary to send a correction report if, following a modification of a
derivative, a counterparty has introduced incorrect information only in its own internal systems but has not reported such incorrect data to the TR. In such cases that counterparty should only send the modification report containing final, correct data (i.e. does not have to send modification report with the incorrect data and then correction).
3.9.3 Reporting of margin and valuation updates
177. In the case of valuation updates, the counterparties should send daily valuations
by the end of the working day following the date of the valuation and populating the

57 date of valuation date in the field ’Event date‘. It should be equal to the date part of the field ‘Valuation timestamp’.
178. Margin updates should be sent daily and counterparties should populate the
field ‘Event date’ with the date for which the margin update is reported (i.e. margin update report should reflect the state of margins at the end of that day). Margin updates should be reported when they become effective, i.e. on the expected settlement date, and they should include any margin that is in transit and pending settlement, without considering temporary settlement failures.
179. In the specific case of margins pre-paid to a CCP in advance of a portfolio of
cleared trades, these should be reported on T+1 of the conclusion of the first applicable derivative in the related portfolio (linked by a portfolio code), rather than on the day following the date on which the collateral was lodged.
180. More generally, no margins should be reported if no derivative covered by those
margins was previously reported.
3.9.4 Termination of a derivative
181. Counterparties should not send a report with action type ’Terminate‘, when a
derivative reaches its maturity date and therefore is no longer outstanding. Once the maturity date is reached, the derivative will be automatically treated as nonoutstanding.
182. If the counterparties agree to terminate a derivative prior to the maturity date or
to terminate the open term derivative, they should either:
a. Submit a report with action type ’Terminate‘ where the agreed termination date is for the same day as the notice of termination, or b. Submit a report with action type ’Modify‘ where the agreed termination date is the following day or later. In this case, the counterparties should modify the maturity date accordingly.
183. The counterparties should not send a report with action type ’Terminate‘ if the
termination date falls on the maturity date. This includes e.g. when a counterparty exercises an option on the maturity date.
184. In a case of a netted position, counterparties may either decide to keep it open
and report valuation on a daily basis or to terminate such position (and report with action type ‘New’ and new UTI in case it needs to be reopened). Both counterparties should report consistently. This aspect is covered in more detail in the section 3.7. Event date
185. Table 11 specifies what should be reported in the field ’Event date’ for each
action type. The event date, by definition, also indicates what is a trigger for reporting, e.g. the valuation date in the case of valuation updates. The actual reports should be submitted by the end of the working day following the event date.

58
Table 11
Action type Event date
New Date of conclusion of the derivative or date of creation of a position Modify Effective date of modification Correct Date from which the correction should apply (typically the date for which previous incorrect data was reported) Terminate Date on which termination becomes effective Error Date of reporting of Error Revive Date of reporting of Revive Valuation Valuation date Position component Date of conclusion of the derivative and of its inclusion in the position Margin update Expected settlement date of the margin
186. In the case where, future dated early termination is agreed, the modification
should be reported by the end of the working day following the date of the agreement. Such modification report should contain the agreement date as the ‘Event date’ and the agreed, future date populated in the ‘Expiration date’ field.
187. Event date must be taken into account by the TRs for the purpose of
constructing the Trade State Report of a derivative. More details in this regard are included in the section 6.1. 3.10Mapping business events to action types and levels
188. ESMA provides below a mapping between business events and the
corresponding action types and event types the counterparties should use in connection with the respective events.
189. Table 12 contains a column ‘Reportable?’ which provides clarifications on the
reportability of each event. As a general rule, however, counterparties should report any new trades that fall under the reporting scope and any modification that affects the reported details.

59
190. Some of the business events (e.g. the default of other counterparty) might differ
from a general case presented in the table. Hence, actual sequence of the reportable events might in some cases differ from the given examples and should always reflect the real-world events as closely as possible.
191. When reporting early termination events (due to e.g. full termination or early
exercise of the derivative contract), counterparties should choose the reportable action type based on the effective date of the event. If the agreed termination date is for the same day as notice of termination, counterparties should use the ‘Terminate’ action type. If the agreed event takes place in the future, counterparties should use ‘Modify’ action type and update the maturity date to reflect the agreedupon termination date.
Table 12
Category Business
Event
Detail Reporta ble?
Action type Event type
Comment
Amendm ents and
Cancellati ons
Amendment
(i.e.
Correction)
Amending details that were originally input incorrectly Yes, if affects reported details Correct Economicall y Immaterial Amendment Yes, if affects reported details Modify Trade Economicall y Material Amendment Yes, if affects reported details Modify Trade Cancellation Trade booked in error and subsequently cancelled. Yes Error Cancellation reported by mistake Trade has been cancelled by mistake and needs to be revived Yes Revive Trade events New Trade Yes New Trade Increase A bilaterally executed agreement to increase the Yes Modify Trade

60
Table 12
Category Business
Event
Detail Reporta ble?
Action type Event type
Comment notional on the transaction
Full
Termination
Full Unwind Yes Terminate/M odify
Early terminati on
Partial
Termination
Partial Unwind Yes Modify Early terminati on Allocation Original Unallocated "Block" Trade allocated to principal parties. Yes Terminate/M odify Allocatio n Modify applicable for partial allocations Subsequent allocated trades Yes New Allocatio n Cleared Positions/Tr ades Original Bilateral Trade (the "alpha" trade) Yes Terminate Clearing Cleared Position ("beta" and "gamma" trades) Yes New Clearing Full Novation Remaining party Yes Terminate+ New Step-in Trade with original counterparty is terminated Step in Yes New Step-in Step out Yes Terminate Step-in Partial Novation Remaining party Yes Modify+New Step-in Step in Yes New Step-in Step out Yes Modify Step-in Option Exercise Full Exercise Only if exercise takes Terminate/M odify Exercise

61
Table 12
Category Business
Event
Detail Reporta ble?
Action type Event type
Comment place before original expiratio n
Partial Exercise Only if exercise takes place before original expiratio n Modify Exercise Giveup/Take-up Remaining party Only if the event takes place later than the reporting deadline (T+1) Modify Step-in Step in New Step in Step out Terminate Step in Position Transfer Remaining party Only if the event takes place later than the reporting deadline (T+1) Modify Step in Step in New Step in Step out Terminate Step in Swaption Exercise Exercise of a Swaption Only if exercise takes place before original expiratio n Terminate Exercise

62
Table 12
Category Business
Event
Detail Reporta ble?
Action type Event type
Comment
Resulting Swap from the exercise of a Swaption.
Yes New Exercise
Compressio n Event
Original Trade -
Terminated
Yes Terminate PTRR
Original Trade -
Amendment
Yes Modify PTRR
New resultant trade
Yes New PTRR
Cash
Settlement
The actual cash settlement of fees, payments, etc No Unwind fees are reported in the termination message Maturity of Contract Derivative contract expiring on the original maturity date No Contract is automaticall y updated to nonoutstanding state by the TR Cascade Breakdown of a position into a more granular level: the initial position in, e.g. a yearly contract Yes Terminate Trade Resulting positions in, e.g. quarterly contracts Yes New Trade Split Dividing a trade and allocating it to multiple positions Yes Terminate Allocatio n Creating/amendin g the impacted positions Yes New/Modify Allocatio n

63
Table 12
Category Business
Event
Detail Reporta ble?
Action type Event type
Comment
Intrinsic changes
Amortizing
Notionals
Changes to the notional during the course of a trade.
No (the amortizin g
schedule
is already reported at the conclusio n of the trade) Dividend Resets No Equity Resets No Rate Resets Changes to the floating rate of a trade No Other Successor Events The other counterparty is succeded LEI change of counterp arty due to corporate events is covered in section 3.14 The reference entity specified in the transaction is succeeded by another entity. Yes Modify Corporat e Event Credit Events Default on a transaction e.g. bankruptcy/restru cturing/ obligation default of the other counterparty. Yes Modify/Term inate Trade/E arly Termina tion The exact sequence of reportable events will depend on details of each

64
Table 12
Category Business
Event
Detail Reporta ble?
Action type Event type
Comment bankruptcy process
Default, e.g. bankruptcy/restru cturing/ obligation default of a reference entity. Yes Modify/Term inate Credit Event Action type depends on the result of event (trade is terminated or, e.g. index factor needs to be updated) Corporate Actions Bonus Issue/Capitalisatio n issue Yes, if the reported underlyin g identifier (e.g. ISIN or LEI) or other trade terms change Modify Corporat e Event Assuming the corporate action takes place in the underlying instrument/i ssuer Special Dividend Modify Corporat e Event Spin-Off Modify Corporat e Event Stock Split/Change in nominal value Modify Corporat e Event Reverse Stock split/Change in nominal value Modify Corporat e Event Other corporate actions affecting reported details Modify Corporat e Event Conversion s Parties mutually agreeing and consenting to a conversion which results in a material amendment. Example would be swap on an ADR Yes Modify Trade

65
Table 12
Category Business
Event
Detail Reporta ble?
Action type Event type
Comment that is converted to swap on the underlying stock as agreed by both parties, or a stock is dual listed and is converted from a GBP line to a HK line as agreed by both parties. Publicly Traded / Listed Swap Index Swap is removed/changed in the index by the administrator of the index (i.e. not at the discretion of the dealer or counterparty). Example would be quarterly roll for index CDS. Would not include rebalancing of the index No, if the underlyin g identifier or other trade terms do not change Triggering of fallback rates Change in floating rate due to fallback event Yes Modify Trade Customized Basket Index Swap Constituents of the basket are changed at the discretion of the dealer or counterparty. Example would be rebalancing the basket by closing a swap on an old ticker and booking that swap on a new ticker. Yes Modify Trade Only the financial instruments traded on a trading venue

66
Table 12
Category Business
Event
Detail Reporta ble?
Action type Event type
Comment
Portfolio
Swap
Addition of
Reference
Underlyer to
Long
Portfolio or
Short
Portfolio
Creation of a new swap contract on
Security XYZ.
Yes New Trade Assuming the portfolio components are reported as individual swaps (potentially
part of a
complex trade)
Removal of
Reference
Underlyer from Long
Portfolio or
Short
Portfolio
Partial or full termination of existing swap contract on Security XYZ. Yes Terminate/M odify Early terminati on Increase in Notional Amount for Existing Reference Underlyer Increasing long or short exposure to Security XYZ. Yes Modify Trade Decrease in Notional Amount for Existing Reference Underlyer Decreasing long or short exposure to Security XYZ in a portfolio swap wrapper. Yes Modify Trade 3.11UTI generation
192. Timely generation and communication of the UTI is crucial to ensure that
counterparties can comply in a timely manner with their reporting obligation. Where one of the counterparties is responsible for the generation of the UTI, both counterparties should make the necessary arrangements in order for the generating counterparty, to timely generate the UTI, use it in its own reporting and communicate it to the other counterparty, and for the receiving counterparty, to ingest the UTI and use the same UTI (without alteration or truncation) in its own reporting. As a best practice, the manual intervention in the process of sharing the UTI should be avoided and digital means should be favoured.

67
193. The 10:00 am deadline for UTI generation and communication applies to all
derivatives, including the derivatives reported at position level. In case the generating party fails to generate or communicate the UTI in due time, which is 10:00 am UTC on T+1, in order to meet the reporting deadline, the receiving party should contact the generating party and enquire about the process instead of reporting using an UTI generated on its own.
194. The below flowchart illustrates how the counterparties should determine the
entity responsible for the UTI generation in accordance with the Article 7 of the ITS on reporting.

68
Yes
If the transaction is concluded between FC and NFC, FC is responsible. If concluded between NFC+ and NFC-, NFC+ is responsible (end). Yes UTI generation pursuant to the to rules of the jurisdiction with the sooner reporting deadline (end). Agreed entity is responsible (end). Confirmation platform is responsible (end). Yes No

69
195. If the entity responsible for the generation of the UTI (e.g. a third-country venue
or a confirmation platform) is not subject to EMIR and is not able/willing to generate the UTI, the parties should follow the next step in the UTI-generation waterfall. If the final step of the waterfall assigns the responsibility to the other counterparty that is not an EU counterparty and that counterparty does not provide the UTI, the reporting counterparty should generate an UTI on its own in order to meet the reporting deadline. However, if the non-EU counterparty provides the UTI late and the EU counterparty has already reported with its own UTI, the EU counterparty should Error the reported derivative and rereport with the UTI generated in line with the ITS on reporting.
196. When the process leads to the ‘counterparty agreement’ step, the
counterparties may decide e.g. that always one of them will be generating the UTI or may decide to apply other commonly agreed rules, including a tie-breaker logic of their choice. The chosen logic should be straightforward enough to ensure clear determination of the counterparty responsible for the UTI generation in all cases.
197. The solution of last resort determines the UTI generating entity by sorting the
LEI identifiers in reversed order. For this purpose, the counterparties should use the ASCII sorting method, where a digit always precedes a letter:
Table 13
Example 1 Example 2
LEI CP1:
1111ABCDEABCDEABC123
CP2:
1111AAAAABBBBBCCC23
CP1:
ABCDEABCDEABCDE12345
CP2:
ABCDEABCDEAAAAA12344
LEI in the reversed order
321CBAEDCBAEDCBA1111
32CCCBBBBBAAAAA1111
54321EDCBAEDCBAEDCBA
44321AAAAAEDCBAEDCBA
Sorted on a character-bycharacter basis, a digit comes always before a letter (ASCII order) 321CBAEDCBAEDCBA1111 because "1" (digit) comes before "C" (letter) 44321AAAAAEDCBAEDCBA because "4" comes before "5"
198. The actual generation of the UTI can be delegated, meaning that any entity
determined as entity responsible for the UTI generation in line with the ITS on reporting, can delegate the generation of the UTI to a third party. It must ensure

70 however that the third party complies with all the relevant requirements with regards to the timeliness of the UTI generation, the structure and format of the UTI etc. 3.12Determining counterparty side
199. Article 4 of the ITS on reporting provides that the counterparty side to the
derivative contract shall be determined at the time of the conclusion of the derivative on the basis of the type of contract concluded.
200. Based on the above, counterparties should determine the counterparty side at
the time of the conclusion of the derivative and report either Buyer/Seller in field ‘Direction’ or Payer/Receiver in fields ‘Direction of Leg 1’ and ‘Direction of Leg 2’ depending on the type of the derivative concluded, as provided in the table below.
201. Counterparties, once determined the counterparty side, should report the fields
related to ‘Direction’, ‘Direction of Leg 1’ and ‘Direction of Leg 2’ with the opposite values.
202. This means that in case where the two counterparties concluded a contract
which requires the population of the field ‘Direction’, if the counterparty 1 reports Buyer in field ‘Direction’, the other counterparty to the contract should report Seller and vice versa.
203. Similarly, assuming that counterparties should agree on the consistent way of
reporting of the respective legs of the derivative, in case where the two counterparties concluded a contract which requires the population of the fields ‘Direction of Leg 1’ and ‘Direction of Leg 2’, if the counterparty 1 reports Payer/Receiver in field ‘Direction of Leg 1’ and Receiver/Payer in field ‘Direction of Leg 2’, the other counterparty to the contract should report Receiver/Payer in field ‘Direction of Leg 1’ and Payer/Receiver in field ‘Direction of Leg 2’. Please refer to the section 6.2.4 for more detailed discussion concerning the reporting and reconciliation of derivatives with two legs.
204. It is also expected that the counterparty which reports Payer in field ‘Direction
of Leg 1’ should report Receiver in field ‘Direction of Leg 2’ and vice versa.
Table 14 Use of Direction fields per product type
Type of contract Direction Direction of leg 1 Direction of leg 2 Option Buyer/Seller - - Swaption Buyer/Seller - -

71
Table 14 Use of Direction fields per product type
Type of contract Direction Direction of leg 1 Direction of leg 2 Currency Forward - Payer/Receiver Receiver/Payer Currency Swap - Payer/Receiver Receiver/Payer Forward Buyer/Seller Non-Deliverable Forward (NDF) - Payer/Receiver Receiver/Payer Future Buyer/Seller CFD Buyer/Seller Spreadbet Buyer/Seller Dividends Swap Buyer/Seller Securities Swap Payer/Receiver Receiver/Payer Interest Rate Swap Payer/Receiver Receiver/Payer Inflation indices Swap Payer/Receiver Receiver/Payer Cross-currency Swap Payer/Receiver Receiver/Payer Instrument for the transfer of credit risk (except options and swaptions) Buyer/Seller Commodities Swap Payer/Receiver Receiver/Payer Forward Rate Agreement Payer/Receiver Receiver/Payer Derivatives related to variance, volatility and correlation Buyer/Seller
205. In relation to the action types ’Valuation’ and ’Margin Update’ the fields
‘Direction’, ‘Direction of Leg 1’ and ‘Direction of Leg 2’ do not have to be reported.
206. When a position is the result of netting of the position to 0, the field ‘Direction’
could be reportable as either Buyer/Seller, Seller/Buyer and the fields ‘Direction of Leg 1’ and ‘Direction of Leg 2’ could be reportable as either Payer/Receiver, Receiver/Payer since for the purpose of reconciliation these fields should not be reconciled in this case. Please refer to the section 6.2.4 for more details concerning the reporting and reconciliation of fields ‘Direction’, ‘Direction of leg 1’ and ‘Direction of leg 2’ when positions are netted to zero.

72
3.13Identification of counterparties
207. Article 3 of the ITS on reporting provides that the counterparty 1 to a derivative
and the entity responsible for reporting shall ensure for the purpose of reporting the conclusion or modification of a derivative that the reference data related to its ISO 17442 LEI code is renewed in accordance with the terms of any of the accredited Local Operating Units of the Global LEI System.
208. Furthermore, according to the Article 3 of the ITS on reporting, the ISO 17442
Legal Entity Identifier (LEI) code should be used to identify a broking entity, a CCP, a clearing member, a counterparty which is a legal entity, a report submitting entity, an entity responsible for reporting, and a post-trade risk reduction service provider.
209. Article 9(5) of EMIR provides that at least the identities of the parties to the
derivative contracts should be reported. This requirement cannot be waived. Therefore, a counterparty dealing with counterparties that cannot be identified because of legal, regulatory or contractual impediments, would not be deemed compliant with Article 9(5) of EMIR.
210. It should be noted that the counterparties reporting under EMIR should always
identify themselves with the LEI of the headquarters, given that the legal responsibility for reporting always lies on the legal entity and not on the branch.
211. In order to reduce reporting issues due to lapsed LEI, the LEI code of the
counterparty 1 and the entity responsible for reporting should be, for the purpose of reporting any new derivative or any modification, duly renewed and maintained according to the terms of any of the endorsed LOUs (Local Operating Units) of the Global Legal Entity Identifier System.
212. Entities other than the counterparty 1 and the entity responsible for reporting
could be reported with a lapsed LEI in accordance with the validation rules.
213. When populated, the LEI of counterparty 2, RSE, broking entity, CCP, Clearing
Member and PTRR service provider should be included in the GLEIF database maintained by the Central Operating Unit, i.e. should be a valid LEI.
214. The point in time relevant for the validation of the LEI status is the date of
reporting, as specified in the validation rules.
215. The field ’Country of the counterparty 2‘ should be populated only when the field
’Counterparty 2 identifier type‘ is ‘False’, i.e. refers to natural persons not acting in business capacity and should refer to the code of the country of residence of that person.
216. Fields ‘Corporate sector of the counterparty 1‘ and ’Corporate sector of the
counterparty 2‘ should be populated with the sector of the counterparty itself and should not refer to the sector of its branch.
217. In case the counterparty 2 to the derivative contract is a natural person not
acting in business capacity, a client code should be used. Client codes should be reported only when the field ’Counterparty 2 identifier type‘ is populated with ’False’.

73
218. If the counterparty 2 is subject to the reporting obligation under EMIR, the field
’Reporting obligation of the counterparty 2‘ should be populated with ‘True’ since the indicator of the reporting obligation is independent from the allocation of responsibility for reporting and from any delegation arrangement.
219. It should be noted that the field ’Reporting obligation of the counterparty 2‘
should be populated with ‘False’ when counterparty 2 to the derivative contract is a natural person not acting in business capacity, a non-EU counterparty, a non-EU CCP, an entity referred in Article 1(4) of EMIR (BIS, Central Banks, etc).
Table 15
Counterparty 2 Reporting obligation of the counterparty 2 EU FC/NFC/CCP TRUE NON EU FC/NFC/CCP FALSE NATURAL PERSON NOT ACTING IN BUSINESS CAPACITY FALSE ENTITIES IN ART. 1(4) OF EMIR (BIS, CENTRAL BANKS, etc) FALSE ENTITIES IN ART. 1(5) OF EMIR (MULTILATERAL DEVELOPMENT BANKS, ESM,ESF, etc) TRUE
220. Client codes should be reported as ’LEI of Counterparty 1 + Internal Identifier of
Individuals‘, where such internal identifier should be unique at the level of the given reporting counterparty (counterparty 1), i.e. the client it is not expected to have one single internal identifier across all entities it trades with. Furthermore, the internal identifier adopted for the identifications of individuals should not contain information referred to as personal data (irrespective of its sensitivity).
221. The LEI component of the client code should not be updated when the reporting
counterparty (to which the LEI pertains) undergoes the corporate event.
222. Furthermore, in case of corporate events, where the affected counterparties
have the same individual as a client and the internal identifier associated with that individual is different between the involved parties, after the merger the reporting counterparty should identify that individual with one of the previously used internal identifiers in order to ensure the traceability. In particular for newly concluded derivatives only one of the client codes should be consistently used, the one starting with the LEI of the reporting counterparty after the merger. Reportable lifecycle events for derivatives outstanding at the time of the merger should be reported with the client codes which were used before the corporate event for those derivatives.
TABLE 16 REPORTING OF CLIENT CODES IN CASE OF A CORPORATE EVENT

74
Before the merger
Reporting timestamp
Reporting
Counterparty
Other
Counterparty Trade ID Action type
T LEIAAAA LEIAAAA123 xyz Modification
T LEIBBBB LEIBBBB456 qwe Modification
LEIBBBB merges into LEIAAAA at T+1
After the merger
Reporting timestamp
Reporting
Counterparty
Other
Counterparty Trade ID Action type
T+2 LEIAAAA LEIAAAA123 xyz Modification
T+2 LEIAAAA LEIBBBB456 qwe Modification
T+2 LEIAAAA LEIAAAA123 jkl New
3.14Procedure when a counterparty undergoes a corporate action
223. Article 8 of the ITS on reporting stipulates that when a counterparty undergoes
a corporate action resulting in the change of its LEI, that counterparty or the ERR or the entity to which reporting was delegated should notify the relevant TR of the change and request update of the LEI. Furthermore, Article 2 of the RTS on data quality provides that the TR to which the request is addressed shall identify the derivatives outstanding at the time of the corporate restructuring event where the entity is reported with the old identifier in the field ‘Counterparty 1 (Reporting counterparty)’ or in the field ‘Counterparty 2’ as informed in the relevant request and shall replace the old identifier with the new LEI in the reports relating to all those derivatives pertaining to that counterparty at the time of the corporate event.
224. Article 2 of the RTS on data quality also provides the procedure and the timeline
to be followed by trade repositories in order to properly finalize the update of the LEIs for all the derivatives pertaining to the counterparty submitting the request under Article 8 of the ITS on reporting.
225. The LEI update should occur on the date of the corporate restructuring event. If
the request to update the LEI due to a corporate event is received by the TR later than 30 days prior to the corporate event, the TR should perform the update as soon as possible and no later than 30 calendar days from receiving the request.
226. To ensure the timely communication between the entity involved in the update
and its TR, the counterparty affected by the change should provide all the necessary information on the merger to its TR no later than 30 calendar days prior to the corporate event date.
227. In case the affected counterparty is a third country entity, the EU counterparty
or entity responsible for reporting or the entity to which the EU reporting counterparty delegated the reporting should be responsible for communicating the change to the TR.
228. In addition, when a counterparty is not responsible and legally liable for
reporting, the entity responsible for reporting is responsible for communicating the

75 change to the TR. In case of delegation, the responsibility for communicating the change to the TR should belong to the report submitting entity.
229. It should be noted that where the affected counterparty does not have any
contractual relationship with the TR, it should inform the report submitting entity or the entity responsible for reporting. Anyway, the responsibility for informing the TR can be specified by the relevant parties in a delegation act.
230. Furthermore, in order to ensure a proper communication process between TRs,
the TR to which a request for update of a LEI is addressed should inform other TRs about a new LEI update execution not later than 3 weeks prior to the corporate event date.
231. To ensure a timely communication process between TRs and their clients, TRs
should inform their clients about a new LEI update execution no later than 2 weeks prior to the corporate event date.
232. When the TR is broadcasting to its clients information about a corporate event,
a reporting counterparty that has no contractual relationship with the TR should be informed of such event without undue delay by the entity responsible for reporting or the report submitting entity, as applicable.
233. Entities involved in the update are expected to provide all the necessary
information to their LOUs in order to ensure a proper and timely update of LEI in GLEIF database.
234. If the request was received later than thirty calendar days prior to the corporate
event, the TR should update the LEI of all derivatives that were outstanding at the time the corporate event took place and between the corporate event date and the date TR performs the update. Therefore, also terminated/expired derivatives between the two dates should be updated.
235. If the affected entities are reported in fields other than ‘Counterparty 1 (reporting
counterparty’, ’Counterparty 2’ or the ‘Entity responsible for reporting’ of the derivative (for example the entity affected by the change is the entity reported in ‘Broker ID’ or ‘Clearing member’ fields), these entities should provide to TRs either the list of UTIs affected by the change or, in case they do not possess this information, all the necessary details so that TRs are able to identify the impacted

76 derivatives. In this case, the TRs should perform such an update only following a confirmation of the impacted records by the counterparty 1 or the entity responsible for reporting, as applicable. Where the counterparty 1 or the entity responsible for reporting does not reply in due time for the performance of the update, the update of the relevant details of these derivatives could be performed by submitting the relevant reports with action type ‘MODI’.
236. In case the corporate event affects only a subset of derivatives (e.g. spin offs),
TRs should put in place common procedures for updating LEI data on those derivatives contracts that could be affected by partial changes of the LEIs. The responsibility for indicating which UTIs are affected by the change should remain with the counterparties or entities responsible for reporting. Both counterparties/ERRs are expected to communicate the change to their TRs.
237. Trades with the old LEI errored or terminated by mistake that are actually
outstanding at the time of the corporate event should be necessarily “revived” before (or at the time of) the corporate event. In case the counterparty or the ERR, as applicable, realizes after the corporate event that a derivative with the old LEI terminated/errored by mistake has not been revived before (or at the time of) the corporate event, the counterparty should report that derivative with a new UTI. In turn the other counterparty should terminate its derivative and re-report it with the newly generated UTI. This latter scenario should occur only as a last resort option considering that counterparties affected by a corporate event should carefully assess the perimeter of outstanding derivatives before the corporate event occurs.
238. TRs should produce any information about the update of the LEI, as specified
in paragraph 3 (b) of Article 2 of RTS on data quality, in machine readable format in order to favour a timely and automatic process of LEI update by the stakeholders (TRs, reporting counterparties, report submitting entities, entities responsible for reporting).
239. The procedure provided in Article 2 of the RTS on data quality and the timelines
provided above should be followed also with reference to the scenario of update from BIC or other identifiers to LEI. 3.15Identification and classification of products General clarifications
240. As specified in the ITS on reporting, the derivatives that are (i) admitted to
trading or traded on a trading venue or (ii) are traded on a systematic internaliser and their underlying is admitted to trading or traded on a trading venue or is an index or basket composed of instruments traded on a trading venue; should be identified in field 2.7 using an ISO 6166 International Securities Identification Number (ISIN) code. The remaining derivatives should be identified in field 2.8 using an ISO 4914 Unique Product Identifier (UPI) code. In the specific case of derivatives traded on exchange in a third country, the identification of the product is not required if both ISIN and UPI are not available. In this way the relevant derivative products can be uniquely identified, while the counterparties are required

77 to provide only one way of identification for a given product and consistency with MiFIR reporting requirements is retained.
241. Additionally, the counterparties should classify all derivatives using the ISO
10692 Classification of Financial Instrument (CFI) code (field 2.9). Counterparties should always use official sources for the CFI. For this purpose, the CFI assigned by ANNA Derivatives Service Bureau (ANNA DSB) or the relevant National Numbering Agency (NNA) should be used. Further information can be obtained from ANNA DSB (https://www.anna-dsb.com/ufaqs/cfi-code/), from ANNA (http://www.annaweb.org/standards/about-identification-standards/), or from the relevant NNA of the derivative.
242. Counterparties should report only valid CFIs. In the case of derivatives identified
with a UPI, the CFI is expected to be always available. For the other derivatives, if the CFI does not exist in the official sources, the counterparties should request it to the relevant NNA. Identification of FX swaps
243. If the counterparties enter into an FX swap (regardless of how the product has
been subsequently confirmed or settled), they should report it in a single report and identify the product with the UPI or ISIN pertaining to that FX swap. It should be noted that the UPI technical guidance explicitly envisages FX swaps as a separate product, thus there is no reason why FX swap would need to be decomposed into FX forwards for the purpose of reporting. UPI reference data
244. ESMA is of the view that majority or all UPI reference data fields should not be
required to be reported for the products identified with UPI, once the UPI system is fully in place and both authorities and markets participants gain more experience with the use of UPI. Additionally, similar consideration applies to the products identified with ISIN for which reference data are available in the Financial Instruments Reference Data System (FIRDS). While all reportable data elements will be required at the beginning of reporting, ESMA is already considering which data elements could be collected from the UPI reference data library or FIRDS instead of being reported to the TRs.
245. Once the validation rules are amended at a later stage to make some or all such
fields conditionally mandatory, the counterparties should follow the validation rules and not report these fields for derivatives identified with a UPI/ISIN. 3.16Identification of underlying
246. The underlying should be identified by using a unique identification for this
underlying based on its type. Fields 2.13-2.18 describe the underlying, and the field ‘Underlying identification type’ in particular indicates that the underlying is either a basket, index or asset identified with an ISIN.

78
247. In the case of derivatives on indices, the counterparties should report the ISIN
of the underlying index, if available, rather than the ISIN of the derivative. In addition, under the RTS on reporting the counterparties should report the standardised code indicating the index (if available) as well as the name of the index which should always be populated.
248. In the case of credit derivatives, field ‘Underlying identification’ should be
reported in case of Credit Default Swap (CDS) based on specific reference obligation. For CDS hedging against the default of an entity, such entity should be reported in the ‘Reference entity’ field.
3.17 Price, notional and quantity fields
Reporting of the price
249. When reporting derivative contracts, in accordance with Article 6(2) of the RTS
on reporting, counterparties should utilise field 2.48 ‘Price’ only when price information is not included in another field of the report.
250. According to Article 6(1) of the RTS on reporting, counterparties should
populate field 2.48 when reporting the following derivative types:
a. swaps with periodic payments relating to commodities (fixed price to be populated in field 2.48); b. forwards relating to commodities or equities (forward price of the underlying to be populated in field 2.48);
c. swaps relating to equities, or contracts for difference (initial price of the
underlying to be populated in field 2.48).
251. The list in Article 6(1) of the RTS on reporting is not exhaustive. When there are
derivatives where the price is not specified in another field, ‘Price’ field should be populated. Examples of such derivatives include futures relating to commodities or equities, where forward price of the underlying is to be reported in the ‘Price’ field.
252. However, field 2.48 is not applicable and should not be populated when
reporting one of the following derivative types:
a. Interest rate swaps and forward rate agreements, as it is understood that the information included in fields ‘Fixed rate of leg 1’/’Fixed rate of leg 2’ and ‘Spread of leg 1’/’Spread of leg 2’ should be interpreted as the price of the derivative. b. Interest rate options and interest rate swaptions, as it is understood that the information included in fields ‘Strike price’ and ‘Option premium amount’ should be interpreted as the price of the derivative.

79
c. Commodity basis swaps, as it is understood that the information included in field
‘Spread of leg 1’/’Spread of leg 2’23 should be interpreted as the price of the derivative. d. Foreign exchange swaps, forwards and options, as it is understood that the information included in fields ‘Exchange rate 1’, ‘Forward exchange rate’, ‘Strike price’, and ‘Option premium amount’ should be interpreted as the price of the derivative. e. Equity options, as it is understood that the information included in the fields ‘Strike price’ and ‘Option premium amount’ should be interpreted as the price of the derivative. f. Credit default swaps and credit total return swaps, as it is understood that the information included in fields ‘Fixed rate of leg 1’/’Fixed rate of leg 2’, ‘Spread of leg 1’/’Spread of leg 2’ and ‘Other payment amount’ (when field ‘Other payment type’ is populated with ‘UFRO’) should be interpreted as the price of the derivative. g. Commodity options, as it is understood that the information included in fields ‘Strike price’ and ‘Option premium amount’ should be interpreted as the price of the derivative.
253. If the derivative contract has price which varies by a schedule throughout the
life of the derivative (and the price information is not reported in another data field), fields 2.50-2.52 should be populated in order to report the price schedule for the whole lifecycle.
254. Examples of the reporting of price for different products (either by specifying it
in the dedicated field or through other data fields) can be found in section 6. Reporting of notional and quantity
255. Notional amount fields (fields 2.55 and 2.64) should be populated in accordance
with Article 5 of the RTS on reporting. Fields 2.57 to 2.59 and 2.66 to 2.68 are repeatable and should be populated in the case of derivatives involving notional amount schedules. The notional amount schedule, if applicable, should also be populated in accordance with Article 5 of the RTS on reporting.
256. When reporting the notional amount schedule, counterparties should indicate:
a. the unadjusted date on which the associated notional amount becomes effective; b. the unadjusted end date of the notional amount; and
c. the notional amount which becomes effective on the associated unadjusted
effective date.
23 Even though the Spread fields are in the Interest Rate section of the table of fields, they should be populated when applicable (according to field descriptions in the RTS). Same approach should be followed when reporting e.g. the spread and fixed rate of CDS.

80
257. In the case of derivatives involving notional amount schedules, the ‘end-date’ is
not required if the end date is back-to-back with the effective date of the subsequent period.
258. In the case of derivatives involving notional amount schedules, the notional
amount input in field 2.55 (‘Notional amount of leg 1’), should be input in the notional amount schedule fields. The same applies for the field ‘notional amount of leg 2’, if applicable.
259. When reporting a notional amount schedule, the date schedules are to be
reported in chronological order.
260. Any updates to the notional amount that are not linked to an agreed upfront
notional schedule, should be reported as a modification.
261. In the case where a position is netted (the notional becomes zero) there are two
possible ways to proceed:
a. The position can be terminated. If the position is reopened it should be reported with a new UTI. b. Counterparties can maintain the open position and report a zero contract value on a daily basis. If new trades are then incorporated into this position the notional, and other relevant fields, should be updated accordingly.
262. It has been observed that zero notional is sometimes reported e.g. in the case
of voluntary right issues given to the holder of a CFD or in the case of CFDs resulting from a corporate action on the underlying (stock split), thus having a purchase price of zero. This is not considered a correct way of reporting.
263. With regards to the population of Notional at position level please refer to the
clarification provided in the section 3.7.
264. With regards to the notional amount for credit index derivatives following a
change in the index factor due to credit events, the counterparties should - to avoid double counting of the adjustment - not modify the notional but rather only update the field 2.147 ‘Index factor’.
265. When reporting non-standard commodity derivatives where the notional is not
known when the contract is executed the following approach should be taken:
report an estimate notional amount, which is periodically reviewed when the transaction is in delivery. If the notional becomes known during the lifetime of the derivative contract a modification should be submitted amending the notional amount.
266. To further elaborate on paragraph above, it is important that the counterparties
to these non-standard commodity derivatives agree on the approach to calculating the notional in order that the reported notional is consistent. For example, the notional reported is based on a production forecast. Counterparties also need to agree when to update the notional to ensure consistency in the updated notional amounts. Total notional quantity fields

81
267. Total notional quantity should be understood as the aggregate notional quantity
of the underlying asset for the term of the derivative. Where the total notional quantity is not known when a new derivative is reported and therefore is reported with a default value, the total notional quantity should be updated as it becomes available.
268. Total notional quantity applies to ETDs more generally. This field is relevant for
equities and commodities. If applicable, it should also be populated for the other asset classes. Fields 2.61 to 2.63 and 2.70 to 2.72 are repeatable and shall be populated in the case of derivatives involving notional quantity schedules.
269. In the case of derivatives involving notional quantity schedules, the total notional
quantity input in field 2.60 (‘Total notional quantity of leg 1’), will also need to be input in the notional quantity schedule fields. The same applies for the field ‘Total notional quantity of leg 2’, if applicable.
270. In the case of derivatives involving notional quantity schedules, the ‘end-date’
is not required if the end date is back-to-back with the effective date of the subsequent period.
271. When reporting a notional quantity schedule, the date schedules are to be
reported in chronological order.
3.18Reporting of valuations
272. Please refer to section 6.2.3 for further guidance on the reconciliation of the
valuation data.
Valuation of the contract
273. Article 4 of the RTS on reporting provides that the counterparties should report
valuation as follows:
a. For cleared derivatives - the valuation of the derivative provided by the CCP. This does not mean that the report should be made by the CCP. The CCP should make data available to counterparties so that the latter report. The use of CCP valuation data does not mean duplication of reporting. b. For uncleared derivatives - the valuation of the derivative performed in accordance with the methodology defined in International Financial Reporting Standard 13 Fair Value Measurement as adopted by the Union and referred to in the Annex to Commission Regulation (EC) No 1126/2008, without applying any adjustment to the fair value. This means that the counterparties should not apply for the purpose of reporting under EMIR any valuation adjustments (such as CVA or DVA), even if such adjustments are applied for the accounting purposes.
274. When counterparties delegate reporting, including valuations, they retain
responsibility for ensuring that reports submitted on their behalf are accurate. In the case of allocation of responsibility for reporting under Article 9(1a)-9(1d) of EMIR,

82 the entity responsible for reporting is responsible for the accuracy of the valuation submitted on behalf of the reporting counterparty.
275. The counterparties should report the actual valuation of the contract (positive or
negative), rather than an absolute value. Typically, the valuation of the contract will be positive for one counterparty and negative for the other. It should be noted that under the technical standards valuation will form part of the reconcilable data, therefore counterparties need to send consistent valuation (i.e. the absolute value of the valuation should reconcile, while the signs will be opposite).
276. In general, the mark to market value should represent the total value of the
contract, rather than a daily change in the valuation of the contract. However, where under the Settle-to-Market (STM) model the valuation is reset to zero on a daily basis and the variation margin is settled, counterparties and CCPs should report the daily change in the valuation.
277. It should also be noted that it is not permissible to report zero valuation of the
contract exclusively on the grounds that there is no market risk because a variation margin has been exchanged. Any margin paid or received would be reflected in the fields 3.12-3.27 and not in the valuation.
278. The valuation requirements apply to CCPs as well as other reporting
counterparties. Pursuant to the Article 4(4) of the draft RTS on reporting, clearing members are required to follow CCP valuation. This does not imply however that CCP’s can set deviating standards - CCPs should comply with the requirements set out in the ITS and RTS on reporting and follow the guidance provided in the Guidelines or in the Q&As.
279. For some contracts the valuation changes infrequently and may not change
from one day to another. However, data quality would not benefit from making exceptions and it would be hard to distinguish the cases of stable valuation from underreporting of the valuations, therefore the counterparties should report valuations on a daily basis also for these contracts (in line with the Article 2 of the ITS on reporting). The requirement to report valuation on a daily basis applies also when the valuation is zero, irrespective of the model used.
280. The first valuation of a given derivative should be reported by the end of the day
following the conclusion of the derivative (reporting deadline), either in the original report with action type ‘New’ or in a separate report with action type ‘Valuation’.
281. It is not necessary to report valuation on the last day of a derivative. In particular,
it is not necessary to report valuation for intraday derivatives (i.e. derivatives that are concluded and terminated on the same day).
282. Where counterparties report packages composed of two or more derivatives,
the valuation should be reported on a per derivative basis.
Valuation method
283. The valuation method should be reported in accordance with the applied
method for determination of the valuation. This means that CCP-cleared trades should have a valuation method indicating that the CCP’s valuation is reported. If

83 at least one valuation input is used that is classified as mark-to-model in the below
table, then the whole valuation should be classified as mark-to-model. If only inputs
are used that are classified as mark-to-market in the table below, then the whole valuation should be classified as mark-to-market.
Table 17 - Classification of valuation inputs
Bucket Inputs used Valuation method
1 Quoted prices in active markets for identical assets or liabilities that the entity can access at the measurement date [IFRS 13:76]. A quoted market price in an active market provides the most reliable evidence of fair value and is used without adjustment to measure fair value whenever available, with limited exceptions. [IFRS 13:77] An active market is a market in which transactions for the asset or liability take place with sufficient frequency and volume to provide pricing information on an ongoing basis. [IFRS 13: Appendix A] Mark-to-market 2 Quoted prices for similar assets or liabilities in active markets [IFRS 13:81] (other than quoted market prices included within bucket 1 that are observable for the asset or liability, either directly or indirectly) Mark-to-market 3 Quoted prices for identical or similar assets or liabilities in markets that are not active [IFRS 13:81] (other than quoted market prices included within bucket 1 that are observable for the asset or liability, either directly or indirectly). Mark-to-model – historic prices from inactive markets should not be directly used 4 Inputs other than quoted prices that are observable for the asset or liability, for example interest rates and yield curves observable at commonly quoted intervals, implied volatilities, credit spreads [IFRS 13:81] (other than quoted market prices Mark-to-market

84
Table 17 - Classification of valuation inputs
Bucket Inputs used Valuation method included within bucket 1 that are observable for the asset or liability, either directly or indirectly) 5 Inputs that are derived principally from or corroborated by observable market data by correlation or other means (“marketcorroborated inputs”) [IFRS 13:81] (other than quoted market prices included within bucket 1 that are observable for the asset or liability, either directly or indirectly) Mark-to-model – the inputs can be derived “principally” from observable market data, meaning that unobservable inputs can be used 6 Unobservable inputs for the asset or liability. [IFRS 13:86] Unobservable inputs are used to measure fair value to the extent that relevant observable inputs are not available, thereby allowing for situations in which there is little, if any, market activity for the asset or liability at the measurement date. An entity develops unobservable inputs using the best information available in the circumstances, which might include the entity’s own data, taking into account all information about market participant assumptions that is reasonably available. [IFRS 13:87-89] Mark-to-model – unobservable inputs are used Delta
284. Counterparties should report the delta of an option or swaption derivative, at
trade or position level, in field 2.25. The reportable value is the ratio of absolute change in price (or value) of a derivative to the change in price (or value) of the underlying. Reported delta should be unadjusted, i.e. the reported value should not contain adjustments pertaining to e.g. counterparty credit risk.
285. CCPs, financial counterparties and non-financial counterparties referred to in
Article 10 of EMIR should use the ‘Valuation update’ messages to report the delta
value as it stands at the end of each day. In practice this means that only those counterparties that are required to send valuation updates are required to update the delta value daily.

85
286. Counterparties other than those referred to in the paragraph above are not
required to report delta.
287. The value of delta may range from -1 to 0 for put options and 0 to 1 for call
options. Reportable delta values are ratios, which means that they don’t have a unit (e.g. currency). In case an exotic option (such as a binary or knock-in/out option) has a delta of less than -1 or more than 1, -1 or 1 should be reported, respectively.
288. For the specific case of swaptions, delta should be understood as the ratio
between the change in value of the swaption to the change in value of the underlying swap.
289. For basket options, delta should not be reported.
3.19 Reporting of margins
290. The collateralisation categories need to be reported in accordance with the
Article 5 of the ITS on reporting.
291. The field ‘Collateralisation’ should be populated based on the agreement and
not on the actual collateral exchanged, i.e. if the agreement considers for a twoway initial margin and variation margin, the field should be populated with ’FLCL’ even though the current situation might be that no initial margin nor variation margin is exchanged.
292. The table below shows different scenarios of collateralisation and how they
should be reported using the categories.
TABLE 18 - COLLATERALISATION CATEGORIES
*UNCL – uncollateralised, PRC1 – Partially collateralised: Counterparty 1, PRC2 - Partially collateralised:
Counterparty 2, PRCL - Partially collateralised, OWC1 - One-way collateralised: Counterparty 1 only, OWC2 - Oneway collateralised: Counterparty 2 only, OWP1 – One-way/partially collateralised: Counterparty 1, OWP2 – Oneway/partially collateralised: Counterparty 2, FLCL – Fully collateralised

86
293. As specified in Article 4.2 of the RTS on reporting, collateral can be reported on
a portfolio basis. This means the reporting of each single executed derivative should not include all the fields related to collateral, to the extent that each single derivative is assigned to a specific portfolio and the relevant information on the portfolio is reported on a daily basis (end-of-day).
294. The reporting counterparties, regardless of their need to report collateral, would
need to submit at least one margin report (field 3.28 ‘Action type’ populated with ‘New’), even to advise that the derivative contract is uncollateralised. Should ’UNCL’ be the latest value submitted, no further margin update is expected. For details regarding the generation of the missing margin information report please see the section 6.3.2.
295. It is not necessary to report margins on the last day of a derivative. In particular,
it is not necessary to report margins for intraday derivatives (i.e. derivatives that are concluded and terminated on the same day).
296. When the Settle-to-Market model applies the mark to market exposure is settled
and reset to zero on a daily basis and the variation margin is paid without a possibility to return. In that case, it is permissible to report zero variation margin. Post-haircut values of margins depend on associated risk of changes in collateral value and therefore on the nature of the collateral posted (or collected). In addition, frequent cash settlement of margin may effectively mitigate this risk completely. Pre- and post-haircut values need to be reported both. If the risk is mitigated completely however, the same values are expected for pre- and post-haircut values.
297. There is only one collateral currency field associated with a collateral type on a
report by a counterparty. Therefore, all collateral for a single portfolio collateral type should be reported in one single currency value for the corresponding collateral type. The reporting counterparty should report the currency that has been contractually agreed between the counterparties. If the currency has not been contractually agreed, the reporting counterparty is free to decide which currency should be used as base currency as long as the base currency chosen is one of the major currencies which represents the greatest weight in the pool and is used consistently for the purpose of collateral reporting for a given portfolio.
298. Non-cash collateral should be reported as its current cash equivalent as
evaluated at the moment of posting/collecting the collateral.
299. The collateral reported should be just the collateral that covers the exposure
related to the reports made under EMIR. If it is impossible to distinguish within a pool of collateral the amount which relates to derivatives reportable under EMIR from the amount which relates to other transactions the collateral reported can be the actual collateral posted covering a wider set of transactions.
300. The meaning of "it is impossible to distinguish" should be referred to the
framework adopted by the reporting counterparties for the calculation of margins (and not just to the use of a common margin account). More in particular, NCAs would expect the following approach:

87 a. if the margin model adopted by the reporting counterparty provides for offsetting of risks between derivatives reportable under EMIR and transactions that are not reportable under EMIR, then the reporting of common collateral amount should be allowed; b. if margins related to derivatives reportable under EMIR and margins related to transactions that are not reportable under EMIR are just collected (and held) together in a common collateral account, but are calculated separately, then only the collateral amount related to EMIR derivatives should be reported.
301. The collateral should be reported as the total market value that has been posted
or collected by the counterparty responsible for the report. The fact that certain types of collateral might take a couple of days to reach the other counterparty should be ignored. Therefore, margin updates should be reported when they become effective, i.e. on the expected settlement date and they should include any margin that is in transit and pending settlement, without considering temporary settlement failures.
302. Although margins data are not reconcilable fields, margins reported by the
counterparties should be consistent.
303. The RTS on reporting specifies that where the collateral related to a contract is
reported on a portfolio basis, the reporting counterparty should report to the trade repository a code identifying the portfolio related to the reported contract. This field should only be populated if the field ‘Collateral portfolio indicator’ has the value ‘Y’. It is up to the reporting counterparty to determine what unique value to populate in the field ‘Collateral portfolio code’. Therefore, different counterparties to a derivative contract can use different collateral portfolio codes.
304. The ITS on reporting specifies that the field 3.27 ‘Collateral portfolio code’ can
have up to 52 alphanumerical characters and that special characters are not allowed. Therefore, a collateral portfolio code that is less than 52 characters in length is permissible provided that it meets the other criteria laid out here.
305. It is permissible to use a value in this field that is supplied by the CCP, but this
is not required and other values could be used.
306. However, NCAs would expect that portfolios reported by the two counterparties,
irrespective of the codes, cover the same collateral.
307. Excess collateral should capture only additional collateral that is posted or received
separately and independently from the initial and variation margin. If counterparties decide to post more collateral than required and this additional collateral is not posted separately and independently of variation margin and initial margin, both counterparties need to include this in the initial and or variation margin reported.
308. Even though in certain circumstances no collateral is exchanged, for example
because of the existence of an agreed “Minimum Transfer Amount” (MTA), other collateral transfer agreement or thresholds between the parties, counterparties should report unchanged margin amount from the previous day. It could occur that in the first day a derivative is concluded, variation margins may be zero. Therefore, in this specific case, if the following days an MTA or other thresholds agreed

88 between the parties are not reached, variation margins should be reported as of the previous day, i.e variation margins fields should be populated with zero.
309. In some circumstances derivatives are exempted from collateral exchange
under EMIR, most notably (1) where an NFC- is counterparty in a derivative, (2) where a counterparty pair benefits from an intragroup exemption from collateral exchange or (3) for certain derivatives as per RTS 2016/2251 such as (i) physically settled foreign exchange forwards and swaps and (ii) single-stock equity options / index options under transitional provision until 4 January 2024. In these cases, although counterparties are not required to exchange collateral, the counterparties are still allowed to have a collateral agreement in place and should report accordingly to the applicable collateral agreement (i.e. ‘UNCL’ only if no collateral agreement is in place and no collateral is exchanged).In addition, the counterparties that are required to report collateral (i.e. CCPs, FCs and NFC+) are expected to report the actual amount of collateral that is exchanged. Where a counterparty pair benefits from an intragroup exemption from reporting, the counterparties should report neither the derivatives nor the collateral.
310. Either variation margin posted or collected should be reported, not both. Please
refer to the example provided in the table and the explaining text below the table.
311. Generally, counterparties and CCPs are required to report the total value of
contract and the margins. Under the STM model, under which the variation margins are settled on a daily basis, the counterparties and CCPs should report the daily change in the value of the variation margin.
312. The margin reporting requirements apply to CCP’s as well as other reporting
counterparties. To ensure consistency, clearing members can follow CCP reported margins.
TABLE 19 REPORTING OF MARGINS
Date CP
1
CP
2
IM posted prehaircut
VM posted prehaircut
IM posted posthaircut
VM posted posthaircut
IM received prehaircut
VM received prehaircut
IM received posthaircut
VM received posthaircut
Level
Day 1 A B 10.000.000 5.000.000 P
Day 1 B A 10.000.000 5.000.000 P
Day 2 A B 10.000.000 5.000.000 P
Day 2 B A 10.000.000 5.000.000 P
Day 3 A B 8.000.000 4.000.000 P
Day 3 B A 8.000.000 4.000.000 P

89
Day 4 A B 13.000.000 6.500.000 P
Day 4 B A 13.000.000 6.500.000 P
Day 5 A B 7.000.000 3.500.000 P
Day 5 B A 7.000.000 3.500.000 P
Day 6 A B 2.000.000 1.000.000 P
Day 6 B A 2.000.000 1.000.000 P
Day 7 A B 0 0 P
Day 7 B A 0 0 P
313. A “VM requirement” is determined as the amount of margins owed by the
counterparty “in debt” in order to cover its exposure against the counterparty “in credit” at the time of the valuation of the contract.
314. Moreover, it is assumed that:
a. A 50% haircut is applied to the collateral exchanged between the counterparties. b. The counterparty “in debt” must post to the counterparty “in credit” an amount of collateral whose post-haircut value is equal to the “VM requirement”.
c. A Minimum Transfer Amount (MTA) of 500,000 is assumed to be in place as
threshold for collateral transfer. d. If the difference between the “VM requirement” and the collateral posted (VM post-haircut) is below the MTA, no collateral is exchanged between the counterparties. e. If the difference between the “VM requirement” and the collateral posted (VM post-haircut) exceeds the MTA, an exchange of collateral occurs between the counterparties. Day 1: Due to valuation of the contract, a VM requirement of 5 million must be posted from B to A. B posts an amount of collateral whose post-haircut value is equal to 5 million (VM posted/received post haircut = 5 million; VM received/posted pre-haircut = 10 million). Day 2: The valuation of the contract results in a reduction of the VM requirement owed by B from 5 million to 4.9 million.

90
Given that the amount A would have to return to B (to align the collateral posted by B with the VM request) is below the MTA (5 million – 4.9 million = 100.000 < MTA = 500.000), no exchange of margins occurs. The Variation Margins reported are the same as of Day 1 Day 3: The valuation of the contract results in a further reduction of the VM requirement owed by B from 4.9 million to 4 million. The difference between the updated value of the “VM requirement” and the collateral posted is equal to 1 million (900.000 from day 3 + 100.000 from day 2). Given that such difference exceeds the MTA, the transfer of collateral takes place:
A returns to B a quantity of collateral whose post-haircut value is 1 million. The updated values of VMs are reported accordingly (VM received/posted posthaircut = 4 million; VM posted/received pre-haircut = 8 million). Day 4: The valuation of the contract results in an increase of the VM requirement owed by B from 4 million to 6.5 million. Given that such a difference exceeds the MTA, the transfer of collateral takes place: B posts additional collateral to A in order to match the new VM requirement. The updated values of VMs posted/received are reported accordingly (VM received/posted post-haircut value = 6.5 million; VM posted/received pre-haircut value = 13 million) Day 5: The valuation of the contract results in a change of the direction of the exposure: the contract turns negative for A, which must cover a VM requirement equal to 3.5 million. Therefore, A returns to B the full amount of collateral previously posted by B. In turn A posts to B additional collateral whose post-haircut value is 3.5 million. Given that such difference exceeds the MTA, the transfer of collateral takes place. The updated values of VMs are reported accordingly: A becomes the counterparty posting collateral (VM posted post-haircut = 3.5 million; VM posted pre-haircut value = 7 million) and B becomes the counterparty receiving the collateral (VM received post-haircut = 3.5 million; VM received pre-haircut = 7 million) Day 6: A reduces its exposure to B by partially selling the contract. Consequently, the valuation of the contract results in a reduction of the VM requirement owed by A from 3.5 million to 1 million. The updated values of VMs are reported accordingly (VM posted/received posthaircut = 1 million; VM received/posted pre-haircut = 2 million)

91
Day 7: A and B netted the position to zero and therefore exchange all outstanding margins, reporting zero in the VM fields. If the counterparties closed the position, they would not need to report margins on the last day of the derivative.
315. Regarding the reporting of value of the collateral for ETDs, in the particular case
when the investment firm is not involved in the process of collecting and/or posting any collateral for the client because of the direct arrangements between the client and the clearing member, the investment firm is not expected to submit any report on the value of the collateral, or on any subsequent modification as well as termination of the concluded derivative contract. 3.20Identification of the trading venue
316. Field 2.41 ‘Venue of execution’ should be used to report the venue where the
derivative was executed, notwithstanding the qualification of the transaction as ETD or OTC.
317. Where a derivative was concluded OTC and the respective instrument is not
admitted to trading or traded on a trading venue and no request for admission has been made, MIC code ‘XXXX’ should be used.
318. Where a derivative was concluded OTC and the respective instrument is
admitted to trading or traded on a trading venue or a request for admission was made, MIC code ‘XOFF’ should be used.
319. The ‘BILT’ value proposed in the CDE guidance should be used when the
reporting counterparty cannot determine whether the instrument is listed or not, as per jurisdictional requirements. Nevertheless, this situation should not arise in the EU since all instruments admitted to trading or traded on a trading venue are made publicly available in the Financial Instruments Reference Data System (FIRDS) on ESMA’s website 24 , therefore the counterparties are expected to be able to determine whether they should report ‘XOFF’ or ‘XXXX’ and the value ‘BILT’ is not allowed in the reporting under EMIR.
320. For derivatives contracts traded on regulated markets or third country trading
venues considered as equivalent to a regulated market, the segment MIC Code will be required (or alternatively the operating MIC in case the segment MIC code does not exist).
321. For derivatives contracts traded on MTFs, OTFs, SIs and organized trading
platforms outside of the Union, the segment MIC code will be required (or alternatively the operating MIC in case the segment MIC code does not exist), even if the derivatives concluded on these venues are OTC derivatives under the definition set out in EMIR.
322. Transactions executed on or pursuant to the rules of venues should be
considered as on venue trading for RMs or third country venues considered as equivalent, MTFs, OTFs, SIs and organized trading platforms outside of the Union. 24 https://registers.esma.europa.eu/publication/searchRegister?core=esma_registers_firds

92
For example, transactions such as bilaterally negotiated or pre-arranged transactions formalised pursuant to the rules of a venue, should be reported with the relevant platform identifier.
323. MIC codes are defined by ISO 10383. This standard identifies two sorts of MIC
code: ‘MIC’ and ‘operating MIC’, also known as ‘segment MIC’ and ‘organisation MIC’ respectively. For EMIR reports, RMs, MTFs, OTFs and SIs should be identified by the relevant MIC code as defined in the ESMA Register at http://registers.esma.europa.eu/publication (segment MIC code). The other venues should be identified using the segment MICs (or alternatively the operating MIC in case the segment MIC code does not exist).
324. In the case where two SIs face each other, those two counterparties should
determine which of them is acting in the SI capacity for the given transaction and report the MIC code of that counterparty as the identifier of the venue.
325. ESMA recalls that derivatives executed on UK regulated markets before Brexit
would be considered ETD. However, derivatives executed on UK regulated markets after Brexit would be considered OTC. The field ’Venue of execution’ would still be identified with the corresponding MIC code. However, such transactions are to be declared as OTC and other fields like the field ’Intragroup‘ and field ’Clearing obligation‘ are required. 3.21Fields related to clearing
326. With respect to the field ‘Cleared’, under the ITS on reporting only two statuses
are allowed, namely cleared (‘Y) and non-cleared (‘N’).
327. In some markets a CCP extends an “open offer” to act as counterparty to market
participants and is interposed between participants at the time trades are executed (open offer model). In other markets, the participants themselves initially are the counterparties. Subsequently the trades may be submitted to a CCP, which is substituted as the seller to the buyer and the buyer to the seller (novation clearing model).
328. Article 2 of the RTS on reporting prescribes that where a derivative contract
whose details have already been reported pursuant to Article 9 EMIR is subsequently cleared by a CCP, that contract should be reported as terminated using the action type ’Terminate‘. The new contracts resulting from clearing should be reported with action type ’New’.
329. The same Article also provides that where a contract is both concluded on a
trading venue and cleared on the same day by a CCP, only the contracts resulting from clearing should be reported (novation clearing model). If the clearing does not occur on same day, the reporting process set in previous paragraph should be applied.
330. With regard to derivatives executed on third country venues and cleared by a
CCP on the same day, Article 2(2) from the RTS on reporting specifies that where a derivative is both concluded on a trading venue or on an organised trading platform located outside of the Union and cleared by a CCP on the same day, only

93 the derivatives resulting from clearing should be reported. These derivatives should be reported by specifying in fields ‘Action type’ and ‘Event type’ either the action type ‘New’ and event type ‘Clearing’, or the action type ‘Position component’ , in accordance with Article 3(2).
331. Execution timestamp for cleared trades should correspond to the time of
execution on the venue of execution. The clearing timestamp should be reported as the time at which the CCP has legally taken on the clearing of the trade. For markets where clearing takes place using the open offer model, execution timestamp and clearing timestamp are expected to be the same. For markets where clearing takes place using novation, these two timestamps may be different.
332. The field ‘Clearing obligation’ is not applicable to the derivatives executed on a
regulated market or a third-country equivalent market and it should be left blank. In the case of cleared trades, this field should be populated with ‘UKWN’ and the field ‘Cleared’ with ‘Y’.
333. The field ‘Central counterparty’ should only be populated with the identifier of a
CCP, i.e. a central counterparty which meets the definition of Article 2(1) of EMIR. Therefore, when a derivative contract is cleared by an entity which is not a CCP within the meaning of EMIR, the clearing house should not be identified in the field ‘Central counterparty’.
334. When a derivative is executed in an anonymised market and cleared by a
clearing house, the counterparty executing the derivative should request the trading venue or the clearing house that matches the counterparties to disclose the identity of the other counterparty before the reporting deadline. 3.22Fields related to confirmation
335. Date and time of confirmation, as determined pursuant to Article 12 of the RTS
on clearing arrangements constitute the ‘Confirmation timestamp‘ that should be reported in the field 2.28, confirmation means should be reported in the field 2.29 ’Confirmed’.
336. The timely confirmation requirement applies only to non-cleared OTC contracts
(confirmation timestamp and confirmation means should not be reported for ETDs nor for cleared OTC derivatives). It applies wherever a new derivative contract is concluded, including as a result of novation and portfolio compression of previously concluded contracts. The requirement does not apply to terminations provided that the termination removes all residual obligations in respect of that derivative. The fields ’Confirmed’ and ’Confirmation timestamp’ should be updated and reported accordingly to the extent that they are required for a given trade.
337. For the field ’Confirmed’, the value ‘NCNF’ (unconfirmed) should be used when
the derivative has to be confirmed by the counterparties but has not been confirmed yet.
338. In other cases, the counterparties should report the ‘ECNF’ or ‘YCNF’ value for
this field depending on the confirmation means used (electronic or non-electronic)

94 and the field ’Confirmation timestamp‘ should be populated. If the value ‘NCNF’ is used, the field ’Confirmation timestamp‘ should be left blank.
339. In the case of trades executed on third-country venues that are not equivalent
to regulated market, those trades are considered OTC under certain provisions of EMIR. This means that fields ’Confirmation timestamp’ and ’Confirmed’ have to be reported to the extent that these trades are not cleared. In the case of derivatives concluded on venue (not cleared) for which the trading supposes the acceptance of transaction terms between parties, if the OTC derivative is automatically documented and agreed upon, it should be regarded as electronically confirmed (field ’Confirmed’ populated with ’ECNF’). On the contrary, if the OTC derivative needs further documentation to be agreed upon, it should be regarded as nonconfirmed (field ’Confirmed’ populated with ‘NCNF‘). 3.23Fields related to settlement
340. The ‘Settlement currency‘ field should be populated for all single currency cashsettled derivatives, as well as those with a specific FX component. The field should
not be populated in the case of a physically settled derivative. The ’Settlement currency‘ field should be specified for each leg of the multicurrency products.
341. An example on the way to report the settlement currency for the two legs of an
FX swap has been included in the section 4.4.
342. Counterparties should report the valid currencies as per ISO 4217 standard.
Currencies which are not covered by ISO standard won't be accepted, therefore the counterparties should report the relevant values in the respective onshore currencies recognized in the ISO standard. 3.24Reporting of regular payments
343. Counterparties should report only those fields related to data elements of
regular payments that are applicable to a given derivative. Therefore, taking into consideration the contract type, the report will contain information on dedicated fields specific for each fixed or floating leg of a derivative. The same rule applies to the data elements describing the reset frequency and reference period of the floating rates.
344. For each leg of a derivative with periodic payments, the fixed rate has to be
reported, where applicable, by specifying positive or negative values expressed as percentages (e.g. 2.57 instead of 2.57%).
345. In the case of floating legs, the periodic payments are calculated based on an
underlying reference rate on predefined dates. Floating rates should be identified, where available, with an ISIN and/or with a 4-letter standardized code, explicitly included in the ITS on reporting.
346. Furthermore, the floating rates should be always identified by using the official
name of the rate as assigned by the index provider.

95
347. There are no expectations to transform the value of the payment frequency
period into another payment frequency period. For example, in the case of yearly payments, counterparties should report a payment frequency of 1 year, rather than 12 months or 365 days. 3.25Reporting of other payments
348. The option premium payment is not included as another payment type, as
premiums for option are reported using the option premium dedicated data element.
349. Novation fees are not included in the RTS on reporting as derivatives-related
cash flows between entities that are not regularly scheduled. Therefore, novation fees are also not reportable as other payments.
350. The allowable values for other payment types are:
a. UFRO = Upfront payment, i.e. the initial payment made by one of the counterparties either to bring a transaction to fair value or for any other reason that may be the cause of an off-market transaction; b. UWIN = Unwind or Full termination, i.e the final settlement payment made when a transaction is unwound prior to its end date; payments that may result due to full termination of derivative transaction(s);
c. PEXH = Principal exchange, i.e. exchange of notional values for cross-currency
swaps.
351. The information provided in other payment fields is only to be reported for the
reportable event to which the payment relates and once the payment details have been reported, the values should not persist in the reports of all subsequent events reported by the counterparty for that trade.
352. Therefore, if a derivative involves both upfront and unwind payment, the
counterparty should report the sequence of payments in subsequent reports, as follows:
Table 20
Action type Event type Other payment type
New Trade
UFRO
Terminate Early termination UWIN
353. Data elements pertaining to the ’other payments‘ can be reported multiple times,
for multiple payments.
354. In the case of the exchange of notional values for cross-currency swaps, the
information related to the payments should be reported at the same time as the derivative contract is reported for the first time, through the ‘NEWT’ report.

96
3.26Dates and timestamps fields
Effective date
355. Effective date is the date at which obligations under the derivative come into
effect, as included in the confirmation. If the counterparties did not specify the effective date as part of the terms of the contract, field ‘Effective date’ should be populated with the date of execution of the derivative.
356. This also applies to cash-settled commodity derivatives as well as in the case
of novations.
357. Execution timestamp should reflect the date and time when the derivative was
originally executed. It should therefore not be changed when counterparties report lifecycle events (e.g. partial termination) for a given derivative. Expiration date / early termination date
358. The expiration date is the unadjusted date at which obligations under the
derivative stop being effective, as included in the confirmation. Early termination does not affect this data element. The expiration date can be used to determine whether the trade is outstanding or not. The content of this field in case of nonconfirmed trades should be as specified in the contract between the counterparties.
359. This applies to both OTC and ETD derivatives.
360. Under Article 9 of EMIR there is a duty to report the termination. However, where
termination takes place in accordance with the original terms of the contract, it can be assumed that such a termination was originally reported, provided that the expiration date has been duly reported. Therefore, only terminations that take place at a different date should be reported.
361. The definition of field 2.44 ‘Expiration date’ in the RTS on reporting specifies
that early terminations of a derivative are not reflected in this field. Accordingly, when an opening of a new contract occurs, the ‘Expiration date’ field represents the original date of expiry of the reported contract. However, when the maturity date of an existing contract is subject to changes which are already foreseen in the original contract specifications, counterparties send a modification report to the initial entry, modifying the ‘Expiration date’ field accordingly to reflect the updated expiration date.
362. The counterparties should report the unadjusted expiration date, as agreed in
the contract, even if it falls on a weekend or a bank holiday.
363. The below example clarifies how to populate field ‘Expiration date’ for an OTC
Fixed for Floating derivative on natural gas with following characteristics:
a. Trade date: 25-Aug-2017Commodity: Natural Gas b. Effective date: 01-Nov-2017
c. Termination date: 31-Mar-2018

97 d. Payment dates: Ten business days after the end of each calculation period subject to e. adjustment in accordance with the Modified Following Business Day Convention. The correct expiration date would be 31/03/2018 as this is the agreed termination date.
364. The following paragraphs clarify how a ’working day‘ should be understood for
the purpose of determining the deadline for reporting.
365. Counterparties should follow their local time to determine the day on which the
derivative was concluded, modified or terminated. The deadline for reporting is the end of the working day following that day. The determination of the deadline for reporting in the local time does not affect the way in which the relevant dates and times (such as execution timestamp) are reported to the TRs. The time convention for reporting is defined in the ITS on reporting.
366. The counterparties should follow the relevant calendar of their Member State to
determine whether a given day is a working day or holiday.
367. This guidance applies also when the two counterparties to the same derivative
follow different calendars and/or are located in different timezones, meaning that each counterparty should follow its own local calendar and use the local time to determine the deadline for reporting. 3.27Reporting of derivatives on crypto-assets
368. Having taken into consideration the ongoing developments in regulation that are
currently being discussed about the crypto-assets, the RTS on reporting do not stipulate any detailed requirements with regard to the reporting of derivatives based on them. Notwithstanding, ESMA has decided to include in the RTS on reporting an additional field named ’Derivative based on crypto-assets‘ in which counterparties would be expected to indicate whether a given derivative is based on a crypto-asset or not. The field is a simple indicator populated with a boolean value. This will allow to assess the trading volumes and outstanding risk in this type of instruments as well as to analyse how these instruments are currently reported.
369. Only derivatives on crypto-assets that fulfil the definition of derivatives under
MiFID are expected to be reported (in line with the general scope of reporting under EMIR).
370. The currency fields in EMIR reporting only allow to be populated with currencies
listed on ISO 4217 Currency Codes. Therefore these fields currently should not be populated with codes relating to crypto-assets that are commonly denominated “crypto-currencies”.
371. ESMA may develop further guidance on such derivatives based on cryptoassets once the relevant regulations have been approved.

98
3.28Reporting of complex products
372. In accordance with the CPMI-IOSCO CDE Guidance the RTS on reporting
introduced new package-related fields. This includes field 2.6 ’Package identifier’, which should, on the one hand, be used by reporting counterparties or entities responsible for reporting as a unique link between reports belonging to the same derivative contract, where the table of fields does not allow to submit the details in only one report and, on the other hand, where the package transaction is composed of a combination of derivative contracts that are negotiated together as the product of a single economic agreement (see also recital 3 and 4 of the RTS on reporting).
373. While there is a requirement for both counterparties to agree on the number of
reports to be submitted for a given contract or package transaction and on the UTI’s assigned to those reports, there is no need to agree on the identifier between the two counterparties. The ’Package identifier‘ will be unique for a set of reports belonging together and assigned by each reporting counterparty or entity responsible for reporting on their own. For this reason there is no need to consume a package identifier from trading venues or the other counterparty.
374. Table 21 illustrates the reporting of UTIs and package identifiers in the case of
package transactions:
Table 21
Report #1
CP 1
Report #2 CP 1 Report #1 CP
2
Report #2 CP
2
Counterparty 1 LEI of CP 1 LEI of CP 1 LEI of CP 2 LEI of CP 2 Counterparty 2 LEI of CP 2 LEI of CP 2 LEI of CP 1 LEI of CP 1 UTI 1234 ABCD 1234 ABCD Package ID PCK1 PCK1 Package987 Package987
375. In the case a package transaction includes reportable and non-reportable
contracts, only the contracts that are in scope of Article 9 of EMIR need to be reported. For example a combination of an FX Spot contract and FX Forward (which is not executed as an FX swap), only the FX Forward would be in scope of Article 9 of EMIR and therefore reportable. Nevertheless the fields related to the entire package (e.g. ’Package transaction price’) need to be populated to provide regulators a holistic view on the package transaction executed.
376. If a derivative contract ceases to exist, but gives birth to another derivative
contract, which is materially different (e.g. an option on a future), those two contracts should be considered individually and not be reported as a package transaction, thus no package identifier should be used to link those reports in such

99 circumstance, while at the same time the field ’Prior UTI‘ would be relevant and would need to be reported.
377. The reporting field 2.53 ’Package transaction price‘ and field 2.54 ’Package
transaction price currency‘ should be populated with the relevant price and currency for the entire package transaction rather than the price and currency of the individual components. If the individual components have individual prices and currencies those should be populated in the relevant report in field 2.28 ’Price‘ and field 2.29 ’Price currency‘ in addition to the population of the field ‘Package transaction price’.
Table 22
Report #1
CP 1
Report #2 CP 1 Report #1 CP
2
Report #2 CP
2
Counterparty 1 LEI of CP 1 LEI of CP 1 LEI of CP 2 LEI of CP 2 Counterparty 2 LEI of CP 2 LEI of CP 2 LEI of CP 1 LEI of CP 1 UTI 1234 ABCD 1234 ABCD Package ID PCK1 PCK1 Package987 Package987 Price 10.23 210.75 10.23 210.75 Price currency EUR Package transaction price 220.98 Package transaction price currency EUR
378. There can be instances where a price for the package transaction becomes
available only after the reporting deadline (T+1). If such instance occurs the package transaction price should be reported with the defined default value, as specified in the validation rules, and should be updated accordingly once it becomes available by using ‘MODI’ in field 2.151 ‘Action type’. Until
379. In the case that the price for an entire package transaction is expressed as a
spread, i.e. the difference between two reference prices, such spread should be populated in field 2.112 ‘Package transaction spread’ together with field 2.113 ‘Package transaction spread currency’. If such spread is not known at the point in

100 time of conclusion of the package transaction it should be reported with the default specified in the validation rules and be updated later when it becomes known. Again this update should be sent by using ‘MODI in field 2.151 ‘Action type’. 3.29Ensuring data quality by counterparties
380. According to the Article 9(1e) of EMIR, counterparties and CCPs should report
correctly and without duplication. Quality of data reported by counterparties is a key aspect to ensure wide usability and quality of data analytical results. Further requirements for ensuring the data quality on the counterparty side are set out in
Article 9 of the ITS on reporting and Article 1 and 3 of the RTS on data quality.
381. To ensure compliance with the requirement to report correctly, to ensure the
consistency of data, as well as to achieve the reduction of reporting burden and alignment of incentives with the entity’s own priorities, counterparties should use the regulatory data for their own internal risk and compliance management processes.
382. Apart from implementing a common set of validation rules providing an
immediate response on the quality of data at the point of data submission, TRs should implement a reconciliation process consisting in paring and matching of the reports pertaining to both sides of the derivative to compare the content of the reports and flag the inconsistencies indicating misreporting by at least one of the counterparties. TRs should provide detailed information on rejections and reconciliation to the relevant participants and users of the TR and also to NCAs. Reporting counterparties, report submitting entities and entities responsible for reporting, as applicable, should investigate the data quality issues flagged by reports’ rejections and unsuccessful reconciliation, and ensure data correction. The ITS on reporting also specifically requires the entities responsible for reporting and the report submitting entities, as applicable, to have in place arrangements which ensure that the feedback on the reconciliation failures provided by the TRs is taken into account.
383. With regards to historical records the counterparties and ERRs are expected to
back report all identified omitted data and correct all data misreported to the TRs.
384. To complement the rejection and reconciliation statistics provided by the TRs to
NCAs, the entity responsible for reporting should promptly (as soon as it becomes aware of them) notify its competent authority and, if different, also the competent authority of the reporting counterparty of any of the following instances:
a. any misreporting caused by flaws in the reporting systems that would affect a significant number of reports, b. any reporting obstacle preventing the report submitting entity from sending reports to a Trade Repository within the deadline set out in the Article 9 of EMIR,
c. any significant issue resulting in reporting errors that would not cause rejection
by a trade repository in accordance with the RTS on data quality.

101
385. The notification should indicate at least the basic information on and
identification of the notification, ERR and RSE(s), the scope of the affected reports, the type of the errors or omissions, the reasons for the errors or omissions, steps taken or planned to resolve the issue, the date of the occurrence, and the timeline for resolution of the issue and data submission or correction. The entity responsible for reporting should provide the notification in a common template published on ESMA website.
386. Each identified data quality issue should be provided within a separate
notification, unless several data quality issues are identified where these issues are closely related, e.g. induced by a common cause, with coinciding resolution timelines or common bug-fixes, or otherwise interlinked and impossible to separate into individual notifications. In such case it is possible to provide single notification for all these related data quality issues.
387. The assessment of significance should be performed as soon as the scope of
the misreporting is identified and the number of records affected by the reporting issue is determined. The notification to NCAs should be sent without undue delay after the assessment is concluded and all the relevant information is gathered. If after the first assessment more affected records are identified, another assessment should be performed and the NCAs should be notified with an update. Since the assessment will be mostly executed on an ad-hoc basis, ESMA does not expect the ERRs to provide the notifications to competent authorities on regular basis.
388. ESMA is aware of the need to specify in more detail the key metrics and
thresholds to assess the scope of notifications, as well as the need to carefully calibrate the proposal. The need for clarification pertains particularly to the “significant number of reports” under point a. and “significant issue” under point c. above. ESMA provides below examples of relevant scenarios and clarifies the metrics for assessing the scope of notifications.
389. Under Article 9(1)(a) of the ITS on reporting any misreporting caused by flaws
in the reporting systems that would affect a significant number of reports should be notified. The requirement pertains to any flaw in the reporting systems on either ERR or RSE side, or at any other third-party reporting system if outsourcing is utilized. This scenario includes for example cases of technical problems excluding a large percentage of records from submission, systematic omission of certain fields in the reports, systematic reporting of incorrect or abnormal values in the reports (e.g. system errors in orders of numerical fields). Since the requirement to notify the authorities pertains to the ERR, RSE or any other third party involved in reporting should inform all the relevant ERRs if they experience system failures or identify any other flaw in their reporting systems. The RSE should send the notification to NCAs only if it is ERR for some or all of the counterparties on whose behalf it reports. Otherwise, if the RSE or any other third party involved in reporting is experiencing data quality issues, it should only inform the relevant ERRs about the details of the issue so that the ERRs are able to perform the assessment of significance of the issue. ERRs and RSEs are expected to have in place sufficient controls at the level of data reporting processes such that any of the above-

102 mentioned issues are timely identified, reported to authorities and permanently remedied.
390. Significant number of reports should be assessed separately for each of the
following categories:
d. Category 1 – reports with action types ‘New’, ‘Modify’, ‘Correct’, ‘Terminate’, ‘Error’, ‘Revive’, ‘Position component’, e. Category 2 – reports with action type ‘Valuation’, f. Category 3 – reports with action type ‘Margin update’.
391. If the number of reports affected by the reporting issue is significant in at least
one of the categories, the competent authorities should be notified of the reporting issue.
392. Number of reports affected by misreporting is significant if it exceeds the
following threshold:
NumOfAffReports / AverageMonthNum > Y% and NumOfAffReports > X i.e. NumOfAffReports >= Threshold = max {X; Y% of AverageMonthNum}, where X and Y are calibration constants, and AverageMonthNum is the average monthly number of submissions calculated on the day of assessment as (NumOfReportsMonth-12 + NumOfReportsMonth-11 + … + NumOfReportsMonth-2 + NumOfReportsMonth-1) / 12 = NumOfReportsLast12Months / 12 using the actual numbers of reports submitted during the last 12 months.
393. To take into account how significant the ERR or RSE is, ESMA intends to
specify the buckets and corresponding calibration constants on the basis of average number of submitted reports as shown in the example in the Table 23 .
394. The assessment of significance should be performed at ERR level or at RSE
level if applicable. The RSE should perform the assessment only if it is ERR for some or all of the counterparties on whose behalf it reports. It is not deemed necessary to calculate the average number of submissions separately for each counterparty, if the ERR or RSE report on behalf of multiple counterparties. As ESMA’s intention is that systematic issues are captured, even if for a single counterparty a threshold is exceeded, the overall picture at the RSE should be considered. Following scenarios aim at facilitating the understanding.
395. Let’s consider the following buckets and thresholds:
TABLE 23
Average monthly number of submissions (AverageMonthNum) 0<=A<100 000 100 000<=A<1 000 000 1 000 000<=A X 100 20000 150000 Y % 20% 15% 10%

103
Scenario A: Three counterparties rely on the same Report Submitting Entity to submit the reports. RSE is below the thresholds, one counterparty is exceeding the threshold.
TABLE 24
Monthly average Affected reports
X Y Thresholds exceeded
Cpt 1 1000 10 10 < 100 1% < 20% No
Cpt 2 1000 250 250 > 100 25% > 20% Yes
Cpt 3 500 10 10 < 100 2% < 20% No
Total RSE 2 500 270 270 > 100 11% < 20% No Even though for counterparty 2, the thresholds are exceeded, the calculation at the level of the RSE is below the thresholds and therefore there is no need for the RSE to notify the relevant NCAs. However, if the RSE is not ERR for all the affected counterparties, it should duly inform all the ERRs of those counterparties about the reporting issue, so that they can assess their overall situation and notify their NCAs if crossing the thresholds. Scenario B: Three counterparties rely on the same Report Submitting Entity to submit the reports. RSE is above the threshold, two counterparties are below the threshold. RSE is ERR only for Cpt 2.
TABLE 25
Monthly average Affected reports X Y
Threshold exceeded
Cpt 1 1000 180 180 > 100 18% < 20% No
Cpt 2 1000 800 800 > 100 80% > 20% Yes
Cpt 3 500 10 10 < 100 2% < 20% No
Total RSE 2 500 990 990 > 100 40% > 20% Yes RSE has a significant issue, but Cpt 1 and Cpt 3 are only slightly affected. In this case the notification to NCAs should include details, such as number of affected reports, which only relate to Cpt 2.

104
Similarly to the previous scenario, if the RSE is not ERR for all the affected counterparties, it should duly inform all the ERRs of those counterparties (in this scenario Cpt 1 and Cpt
3) about the reporting issue, so that they can assess their overall situation and notify their
NCAs if crossing the thresholds.
Scenario C: A counterparty (ERR) is delegating reporting to 2 RSEs and partially reports by itself. At counterparty level, only a subset of reports is affected by the reporting issue at an RSE.
TABLE 26
Monthly average
Affected reports affected by an issue
X Y Threshold s exceeded
Cpt 1000 < 100 0% < 20% No
RSE 1 1000 250 250 > 100 25% > 20% Yes
RSE 2 500 < 100 0% < 20% No
Total ERR 2500 250 250 > 100 10% < 20% No
RSE1 has potentially a significant issue but on the overall level of the counterparty the issue is not significant. In this case the counterparty is not expected to notify its NCA. Nevertheless, it is not prohibited for RSE 1 to notify the counterparty’s NCA if the issue is significant at the level of the RSE 1 and the counterparty relies on the RSE 1 to notify the NCAs.
396. Under Article 9(1)(b) of the ITS on reporting any reporting obstacle preventing
the report submitting entity from submitting reports within the reporting deadline should be notified. These cases include primarily system failures but should not be understood as limited only to technical problems, e.g. operational issues (COVID19), lack of LEI update, impossibility to generate the UTI. To further differentiate from the cases of misreporting and record omission of Article 9(1)(a), ESMA emphasizes that cases under Article 9(1)(b) pertain to complete inability to send any records to the TRs, while data quality issues under Article 9(1)(a) affect only subset of reported records.
397. Under Article 9(1)(c) of the ITS on reporting any significant issue resulting in
reporting errors that would not cause rejection by a trade repository should be notified.
398. Significant issue under Article 9(1)(c) of the ITS on reporting should be
assessed according to the following non exhaustive list of qualitative criteria:
a. Non-reporting or over-reporting of a derivative due to erroneous assessment of its reportability;

105 b. Incorrect or inconsistent interpretation of the number of reports to be reported for a specific derivative (e.g. in dispute with the other counterparty);
c. Incorrect or inconsistent interpretation of the content of the fields (e.g. in dispute
with the other counterparty); d. Reporting of non-standard derivatives for which the fields are not fully suited; e. Errors and omissions that pertain to
i. Incorrect data in the parties identification: fields 1.2 to 1.16, 1.20, 2.33, 2.37;
ii. Incorrect trade details: fields 1.17 to 1.19, 2.1 to 2.12, 2.38 to 2.41;
iii. Incorrect details on underlying: fields 2.13 to 2.18 – in particular when the basket
is not complete;
iv. Amounts and currencies in all related fields (notional, valuation, collateral, price,
strike …);
v. Dates / timestamps: execution, event confirmation, expiration;
vi. Clearing fields 2.30 to 2.32;
vii. Incorrect report details: fields 2.151, 2.152 and 2.154;
viii. Collateral portfolio code: field 3.9;
ix. Errors in valuation methods resulting in incorrect reporting of valuation.
399. Significant issue under Article 9(1)(c) of the ITS on reporting should be further
(accumulatively) assessed according to the quantitative criteria specifying significant number of records affected by the qualitatively significant data quality issue. Scenarios of example above apply analogously for significant issues under
Article 9(1)(c) of the ITS on reporting.
400. The entity responsible for reporting should have processes in place to be able
at any time to assess the significance of identified cases of misreporting as outlined above and to promptly notify them to the relevant NCAs. Specifically, this includes swift identification of impacted records and their numbers and the computation of relevant metrics to assess whether thresholds have been exceeded or not.
401. Counterparties, ERRs or RSEs will need to submit their notifications to the
NCAs in accordance with the procedures adopted by those NCAs in each Member State.
402. Many data quality issues are related to inconsistent interpretation of the rules
for reporting of the derivatives. The aim of these Guidelines is to provide in the relevant sections the necessary guidance for the various reporting scenarios and derivative contracts, including detailed illustrative examples.
403. The population of fields that are specified as optional in the validation rules is
not left at the discretion of the reporting counterparties. Optional fields should be always populated in all cases where the field is relevant in the given scenario or for the given derivative.

106
4 Reporting per product type
404. This section includes clarifications and examples illustrating reporting of certain
derivative products.
405. The examples are provided in form of tables, where each table shows the
reporting fields under the ITS on reporting. The column ‘Field’ shows each field name, and the column ‘Example’ provides an example of what would be included in that field. The final column entitled ‘XML Message’ shows the format of the XML message which should be submitted in the report.
406. Unless otherwise stated in the specific scenario, the following background
information applies to all scenarios set out in this section:
Counterparty A is a German financial counterparty identified with LEI 12345678901234500000 Counterparty B is an Italian financial counterparty identified with LEI ABCDEFGHIJKLMNOPQRST Counterparty C is a Spanish NFC- identified with LEI 123456789ABCDEFGHIJK Counterparty D is a French NFC+ identified with LEI 11223344556677889900 Counterparty J acts also as a clearing member and is identified with LEI CCCCCCCCCCCCCCCCCCCC CCP O is identified with LEI BBBBBBBBBB1111111111
4.1 Reporting of IRS
407. When reporting IRS, the counterparties should describe the underlying fixed or
floating rates in the dedicated rate fields for leg 1 and leg 2 (fields 2.79-2.110), rather than e.g. providing the floating rate in the underlying index field.
408. There are three distinct fields to describe a floating rate:
a. Identifier (fields 2.83 and 2.99), which should be populated with ISIN, b. Indicator (fields 2.84 and 2.100) which should be populated with a standardised 4-letter code, and
c. Name (fields 2.85 and 2.101), which should be populated with the full name of
the rate.
409. Counterparties should always report ISIN and 4-letter code, to the extent that
they are available for a given rate. The name of the rate should be reported in all cases. Fixed-to-floating IRS

107
410. A single currency fixed-to-floating 5-year IRS on 3M EURIBOR vs 0.5% (with
no additional spread). Counterparties exchange payments each six months and reset frequency is set to annual. The day count convention is Actual/360.
Table 27 – Reporting of a fixed-to-floating IRS
No Field Example XML message
79 Fixed rate of leg
1 or coupon 0.5
<IntrstRate>
<FrstLeg>
<Fxd>
<Rate>
<Rate>0.5</Rate>
</Rate>
<DayCnt>
<Cd>A004</Cd>
</DayCnt>
<PmtFrqcy>
<Term>
<Unit>MNTH</Unit>
<Val>6</Val>
</Term>
</PmtFrqcy>
</Fxd>
</FrstLeg>
<ScndLeg>
<Fltg>
<Id>EU0009652783</Id>
<Nm>Euro Interbank Offered
Rate</Nm>
<Rate>
<Cd>EURI</Cd>
</Rate>
<RefPrd>
<Unit>MTH</Unit>
<Val>3</Val>
</RefPrd>
<Sprd>
<Pctg>0</Pctg>
</Sprd>
<DayCnt>
<Cd>A004</Cd>
</DayCnt>
<PmtFrqcy>
<Term>
<Unit>MNTH</Unit>
<Val>6</Val>
</Term>
</PmtFrqcy>
<RstFrqcy>
<Term>
<Unit>YEAR</Unit>
<Val>1</Val>
</Term>
</RstFrqcy>
</Fltg>
80
Fixed rate or coupon day count convention leg 1 A004 81 Fixed rate or coupon payment frequency period leg 1 MNTH 82 Fixed rate or coupon payment frequency period multiplier leg 1 6 99 Identifier of the floating rate of leg 2 EU0009652783 100 Indicator of the floating rate of leg 2 EURI 101 Name of the floating rate of leg 2 Euro Interbank Offered Rate 102 Floating rate day count convention of leg 2 A004 103 Floating rate payment frequency period of leg 2 MNTH 104 Floating rate payment frequency period multiplier of leg 2 6 105 Floating rate reference period of leg 2 – time period MNTH 106 Floating rate reference period 3

108
Table 27 – Reporting of a fixed-to-floating IRS
No Field Example XML message of leg 2 – multiplier </ScndLeg> </IntrstRate> 107 Floating rate reset frequency period of leg 2 YEAR 108 Floating rate reset frequency multiplier of leg 2 1 109 Spread of leg 2 0 110 Spread currency of leg 2
4.2 Reporting of swaptions
411. When reporting swaptions, the counterparties should provide both the fields
related to options (fields 2.132-2.142) as well as the fields characterising the underlying swap (fields 2.79-2.110).
412. Exercise of the swaption should be reported with action type ‘Terminate’ and
event type ‘Exercise’. The resulting swap should be reported with action type ‘New’ and event type ‘Exercise’ as well as with the field 2.3 ‘Prior UTI’ populated.
413. The tables below illustrate how to report an original swaption, exercise of that
swaption and the resulting swap.
4.2.1 Swaption on a fixed-to-floating IRS
414. Counterparty enters into an American put option on a fixed-to-floating IRS
based on 1D SONIA vs 0.75% (with no additional spread). The premium is 200,000 GBP. If exercised, the reporting counterparty will pay fixed rate and the counterparties will exchange payments each 3 months and reset frequency is set to annual. The day count convention is Actual/Actual ISDA.
Table 28 – Reporting of a swaption on a fixed-to-floating IRS
No Field Example XML message
1 UTI AAAAABBBBBCCCCCD
DDDD12345
<Rpt><New><CmonTradData>
<TxData>
<TxId>
<UnqTxIdr>
AAAAABBBBBCCCCCDDDDD12345
</UnqTxIdr>
</TxId>
79 Fixed rate of leg 1 or coupon
0.75

109
Table 28 – Reporting of a swaption on a fixed-to-floating IRS
No Field Example XML message
80
Fixed rate or coupon day count convention leg 1 A008 … <DerivEvt> <Tp>TRAD</Tp> </DerivEvt> … <IntrstRate> <FrstLeg> <Fxd> <Rate> <Rate>0.75</Rate> </Rate> <DayCnt> <Cd>A008</Cd> </DayCnt> <PmtFrqcy> <Term> <Unit>MNTH</Unit> <Val>3</Val> </Term> </PmtFrqcy> </Fxd> </FrstLeg> <ScndLeg> <Fltg> <Id>GB00B56Z6W79</Id> <Nm>Sterling Overnight Index Average</Nm> <Rate> <Cd>SONA</Cd> </Rate> <RefPrd> <Unit>DAIL</Unit> <Val>1</Val> </RefPrd> <Sprd> <Pctg>0</Pctg> </Sprd> <DayCnt> <Cd>A008</Cd> </DayCnt> <PmtFrqcy> <Term> <Unit>MNTH</Unit> <Val>3</Val> </Term> </PmtFrqcy> <RstFrqcy> <Term> <Unit>YEAR</Unit> <Val>1</Val> </Term> </RstFrqcy> </Fltg> </ScndLeg> </IntrstRate> 81 Fixed rate or coupon payment frequency period leg 1 MNTH 82 Fixed rate or coupon payment frequency period multiplier leg 1 3 99 Identifier of the floating rate of leg 2 GB00B56Z6W79 100 Indicator of the floating rate of leg 2 SONA 101 Name of the floating rate of leg 2 Sterling Overnight Index Average 102 Floating rate day count convention of leg 2 A008 103 Floating rate payment frequency period of leg 2 MNTH 104 Floating rate payment frequency period multiplier of leg 2 3 105 Floating rate reference period of leg 2 – time period DAIL 106 Floating rate reference period of leg 2 – multiplier 1 107 Floating rate reset frequency period of leg 2 YEAR 108 Floating rate reset frequency multiplier of leg 2 1 109 Spread of leg 2 0

110
Table 28 – Reporting of a swaption on a fixed-to-floating IRS
No Field Example XML message
110 Spread currency of leg 2
<Optn>
<Tp>PUTO</Tp>
<ExrcStyle>AMER</ExrcStyle>
<StrkPric>
<Pctg>0.75</Pctg>
</StrkPric>
<PrmAmt Ccy="GBP">200000.00
< </PrmAmt>
<PrmPmtDt>2022-07-01
< </PrmPmtDt>
<MtrtyDtOfUndrlyg>2025-12-01
< </MtrtyDtOfUndrlyg>
</Optn>
</TxData>
</CmonTradData></New></Rpt>
132 Option type PUTO
133 Option style AMER
134 Strike price 0.75
138
Strike price currency/currency pair
139 Option premium amount 200000
140 Option premium currency
GBP
141 Option premium payment date 2022-07-01 142 Maturity date of the underlying 2025-12-01 151 Action type NEWT 152 Event type TRAD
Table 29 - Reporting of an exercise of a swaption
No Field Example XML message
1 UTI AAAAABBBBBCCCCCDDD
DD12345
<Rpt><Termntn><CmonTradData>
<TxData>
<TxId>
3 <UnqTxIdr> Prior
UTI

111
Table 29 - Reporting of an exercise of a swaption
No Field Example XML message
45
Early termina tion date
2022-11-01
AAAAABBBBBCCCCCDDDDD12345
</UnqTxIdr>
</TxId>
…
<EarlyTermntnDt>2022-11-01
< </EarlyTermntnDt>
…
<DerivEvt>
<Tp>EXER</Tp>
</DerivEvt>
</TxData>
</CmonTradData></Termntn></Rpt>
15
1
Action type TERM
15
2
Event type EXER
Table 30 - Reporting of a swap after exercise of the swaption
No Field Example XML message
1 UTI AAAAABBBBBCCCCCDD
DDD67890
<Rpt><New><CmonTradData>
<TxData>
<TxId>
<UnqTxIdr>
AAAAABBBBBCCCCCDDDDD67890
</UnqTxIdr>
</TxId>
<PrrTxId>
<UnqTxIdr>
AAAAABBBBBCCCCCDDDDD12345
</UnqTxIdr>
</PrrTxId>
…
<DerivEvt>
<Tp>EXER</Tp>
</DerivEvt>
…
<IntrstRate>
<FrstLeg>
<Fxd>
<Rate>
<Rate>0.75</Rate>
</Rate>
<DayCnt>
<Cd>A008</Cd>
</DayCnt>
<PmtFrqcy>
<Term>
<Unit>MNTH</Unit>
<Val>3</Val>
3 Prior UTI AAAAABBBBBCCCCCDD
DDD12345
79
Fixed rate of leg 1 or coupon
0.75
80
Fixed rate or coupon day count convention leg 1 A008 81 Fixed rate or coupon payment frequency period leg 1 MNTH 82 Fixed rate or coupon payment frequency period multiplier leg 1 3 99 Identifier of the floating GB00B56Z6W79

112
Table 30 - Reporting of a swap after exercise of the swaption
No Field Example XML message rate of leg
2
</Term>
</PmtFrqcy>
</Fxd>
</FrstLeg>
<ScndLeg>
<Fltg>
<Id>GB00B56Z6W79</Id>
<Nm>Sterling Overnight
Index Average</Nm>
<Rate>
<Cd>SONA</Cd>
</Rate>
<RefPrd>
<Unit>DAIL</Unit>
<Val>1</Val>
</RefPrd>
<Sprd>
<Pctg>0</Pctg>
</Sprd>
<DayCnt>
<Cd>A008</Cd>
</DayCnt>
<PmtFrqcy>
<Term>
<Unit>MNTH</Unit>
<Val>3</Val>
</Term>
</PmtFrqcy>
<RstFrqcy>
<Term>
<Unit>YEAR</Unit>
<Val>1</Val>
</Term>
</RstFrqcy>
</Fltg>
</ScndLeg>
</IntrstRate>
</TxData>
</CmonTradData></New></Rpt>
100
Indicator of the floating rate of leg
2
SONA
101
Name of the floating rate of leg
2
Sterling Overnight Index
Average
102
Floating rate day count convention of leg 2 A008 103 Floating rate payment frequency period of leg 2 MNTH 104 Floating rate payment frequency period multiplier of leg 2 3 105 Floating rate reference period of leg 2 – time period DAIL 106 Floating rate reference period of leg 2 – multiplier 1 107 Floating rate reset frequency period of leg 2 YEAR 108 Floating rate reset frequency 1

113
Table 30 - Reporting of a swap after exercise of the swaption
No Field Example XML message multiplier of leg 2 109 Spread of leg 2 0 110 Spread currency of leg 2 151 Action type NEWT 152 Event type EXER
4.3 Reporting of other IR products
415. Forward Rate Agreements (FRAs), cross-currency swaps, caps and floors
should be classified as interest derivatives.
416. When reporting FRAs the counterparties should pay attention to the following:
a. The underlying rate should be reported in the fields pertaining to the underlying
section (fields 2.13-2.16).
b. Execution timestamp should be populated with the relevant date and time when the derivative was concluded by the counterparties and following the specifications in the validation rules.
c. Effective date is the date when obligations under the contract come into effect.
Unless the obligations between the counterparties are postponed to a future date, this is the same as the date part of the execution timestamp. Effective date is not the settlement date referred to in the FRA documentation. d. Maturity date is the date agreed by the counterparties when the obligations under the derivative expire. In the case of FRAs, this is the date on which the exposures between the counterparties are extinguished by the determination of the payment covering the difference between the agreed rate and the prevailing market rate. This is not the final date of the underlying rate. e. Settlement date is the date on which the counterparties settle the underlying. The underlying of a FRA is a forward interest rate and the settlement of the difference between the agreed rate and the prevailing market rate either coincides with the maturity date or it takes place on a later date.
417. Example of a FRA (represented using industry terminology):
• Executed on 22 February
• Fixing Date (2 day fixing) 20 May
• Effective Date (3M) 22 May

114
• Maturity Date (6M) 22 August
• Settlement Date 22 May
418. In the above example, for the purpose of reporting the effective date is 22
February - unless the counterparties agree to postpone the date on which the obligations come into effect - and the maturity date is 20 May.
419. In the case of caps and floors, the counterparties should populate both the fields
relevant for options and fields relevant for interest rate derivatives (similarly to the example of swaption illustrated in the section 4.2).
420. In the case of cross-currency swaps, the counterparties should populate both
the fields relevant for foreign exchange derivatives and fields relevant for interest rate derivatives.
4.4 Reporting of FX swaps and forwards
421. The Final contractual settlement date as specified in the RTS on reporting is not
a repeatable field, therefore it is not possible to report both settlement dates – of the near and far leg – in this field.
422. FX swap is reported in a single report; therefore the Package identifier should
not be populated.
423. The below examples illustrate how an FX swap and a lifecycle event affecting a
single leg of a swap should be reported under Article 9 of EMIR.
4.4.1 FX swaps (spot-forward and forward-forward)
424. Following scenarios are considered:
f. -Scenario A: Reporting of an FX swap composed of a spot and forward leg. g. Scenario B: Reporting of an FX swap composed of two forward legs.
425. In both scenarios the derivatives have the following characteristics:

Banks A and B enter in a EUR/GBP swap instrument on 1 June 2018 (regardless of
how the instrument has been subsequently confirmed or settled);
notional of the contract: 1,000,000 EUR;
maturity date of the contract: 31 December 2018;
the swap is physically settled;
Bank A delivers GBP and receives EUR for the far leg; thus it is identified as the
receiver of leg 1 ( i.e. it receives the currency reported in the field ‘Notional currency 1’, EUR);
the exchange rate of the near leg is 0.88 EUR/GBP, while the exchange rate of the
far leg is 0.865 EUR/GBP.

115
Table 31 - Reporting of an FX swap composed of a spot and forward leg
Item Field Example XML message
1
Reporting timestamp 2018-06-01T12:00:00Z
<New>
<CtrPtySpcfcData>
<CtrPty>
<RptgCtrPty>
<Id>
<Lgl>
<LEI>12345678901234500000

</LEI>

</Lgl> </Id> … <DrctnOrSd><Drctn> <DrctnOfTheFrstLeg>TAKE > </DrctnOfTheFrstLeg> <DrctnOfTheScndLeg>MAKE > </DrctnOfTheScndLeg> </Drctn></DrctnOrSd> </RptgCtrPty> <OthrCtrPty> <IdTp> <Lgl> <LEI>ABCDEFGHIJKLMNOPQRST > </LEI> </Lgl> </IdTp> … </OthrCtrPty> </CtrPty> <RptgTmStmp>2018-06-01T12:00:00Z > </RptgTmStmp> </CtrPtySpcfcData> <CmonTradData> <CtrctData> <CtrctTp>SWAP</CtrctTp> <AsstClss>CURR</AsstClss> <PdctClssfctn>SFAXXP > </PdctClssfctn> </CtrctData> <TxData> <TxId> <UnqTxIdr>123456 </UnqTxIdr> </TxId> … <NtnlAmt> <FrstLeg> <Amt Ccy="EUR">1000000</Amt> </FrstLeg> <ScndLeg> <Amt Ccy="GBP">865000</Amt> </ScndLeg> </NtnlAmt> … <DlvryTp>PHYS</DlvryTp> <ExctnTmStmp>2018-06-01T12:00: 4 Counterparty 1 (Reporting counterparty) 12345678901234500000 9 Counterparty 2 ABCDEFGHIJKLMNOPQRS T 18 Direction of leg 1 TAKE 19 Direction of leg 2 MAKE 1 UTI 123456

116
Table 31 - Reporting of an FX swap composed of a spot and forward leg
Item Field Example XML message

00Z</ExctnTmStmp>
<FctvDy>2018-06-01</FctvDy>
<XprtnDt>2018-12-31</XprtnDt>
<SttlmDt>2018-12-31</SttlmDt>
…
<DerivEvt>

<Tp>TRAD</Tp>
</DerivEvt>
…
<Ccy>
<XchgRate>0.88</XchgRate>
<FwdXchgRate>0.865

</FwdXchgRate>

<XchgRateBsis> <CcyPair> <BaseCcy>EUR</BaseCcy> <QtdCcy>GBP</QtdCcy> </CcyPair> </XchgRateBsis> </Ccy> </TxData> </CmonTradData> </New> 6 Package identifier 9 Product classification SFAXXP 10 Contract type SWAP 11 Asset class CURR 19 Settlement currency 1 20 Settlement currency 2 42 Execution timestamp 2018-06- 01T12:00:00Z

117
Table 31 - Reporting of an FX swap composed of a spot and forward leg
Item Field Example XML message
43 Effective date 2018-06-01
44 Expiration date 2018-12-31
46
Final contractual settlement date
2018-12-31
47 Delivery type PHYS
48 Price
49 Price currency
55
Notional amount of leg 1
1000000
64
Notional amount of leg 2
865000
56 Notional currency 1 EUR
65 Notional currency 2 GBP
113 Exchange rate 1 0.88
114
Forward exchange rate
0.865

118
Table 31 - Reporting of an FX swap composed of a spot and forward leg
Item Field Example XML message
115 Exchange rate basis EUR/GBP
151 Action type NEWT
152 Event type TRAD
Table 32 - Reporting of an FX swap composed of two forward legs
Item Field Example XML message
1
Reporting timestamp 2018-06-01T12:00:00Z
<New>
<CtrPtySpcfcData>
<CtrPty>
<RptgCtrPty>
<Id>
<Lgl>
<LEI>12345678901234500000

</LEI>

119
Table 32 - Reporting of an FX swap composed of two forward legs
Item Field Example XML message
<TxData>
<TxId>
<UnqTxIdr>
123457
</UnqTxIdr>
</TxId>
…
<NtnlAmt>
<FrstLeg>
<Amt Ccy="EUR">

1000000</Amt>
</FrstLeg>

<ScndLeg> <Amt Ccy="GBP"> > 865000</Amt> </ScndLeg> </NtnlAmt> … <DlvryTp>PHYS</DlvryTp> <ExctnTmStmp>2018-06-01T 12:00:00Z</ExctnTmStmp> <FctvDy>2018-06-01</FctvDy> <XprtnDt>2018-12-31</XprtnDt> <SttlmDt>2018-12-31</SttlmDt> … <DerivEvt> <Tp>TRAD</Tp> </DerivEvt> … <Ccy> <XchgRate>0.88</XchgRate> <FwdXchgRate>0.865 > </FwdXchgRate> <XchgRateBsis> <CcyPair> <BaseCcy>EUR</BaseCcy> <QtdCcy>GBP</QtdCcy> </CcyPair> </XchgRateBsis> </Ccy> </TxData> </CmonTradData> </New> 4 Counterparty 1 (Reporting counterparty) 12345678901234500000 9 Counterparty 2 ABCDEFGHIJKLMNOPQ RST 18 Direction of leg 1 TAKE

120
Table 32 - Reporting of an FX swap composed of two forward legs
Item Field Example XML message
19 Direction of leg
2
MAKE
1 UTI 123457
6
Package identifier
9
Product classification SFCXXP
10 Contract type SWAP
11 Asset class CURR
19 Settlement currency 1
20 Settlement currency 2
42 Execution timestamp
2018-06-
01T12:00:00Z
43 Effective date 2018-06-01
44 Expiration date 2018-12-31
46
Final contractual settlement date
2018-12-31
47 Delivery type PHYS
48 Price

121
Table 32 - Reporting of an FX swap composed of two forward legs
Item Field Example XML message
49 Price currency
55 Notional amount of leg 1 1000000
64 Notional amount of leg 2 865000
56 Notional currency 1 EUR
65 Notional currency 2 GBP
113 Exchange rate 1 0.88
114 Forward exchange rate 0.865
115 Exchange rate basis EUR/GBP
151 Action type NEWT
152 Event type TRAD
4.4.2 Compression of the near leg of the FX swap
426. The following scenario is considered:

The derivative is concluded on 1 June 2018;
notional of the contract: 1,000,000 EUR;
maturity date of the contract: 31 December 2018;
the swap is physically settled;
Bank A sells EUR and gets GBP for the near leg (and delivers GBP and receives EUR
for the far leg);
the exchange rate of the near leg is 0.88 EUR/GBP, while the exchange rate of the
far leg is 0.865 EUR/GBP;

122

the two settlement dates are 01/08/2018 and 31/12/2018.

On 17 July there is a compression of the near leg, while the far leg continues.
Therefore, the FX swap needs to be terminated with action type ‘TERM’ and event type ’COMP’ and the FX forward contract arising from this compression has to be reported with a new UTI and flagging the ‘PTRR’ field as true. ‘PTRR ID’ is provided by the PTRR service provider WWWWWXXXXXYYYYYZZZZZ and populated both for the FX forward and the termination report of the FX swap.
This way of reporting is envisaged only in the cases where lifecycle events
impact a single leg of an FX swap. It should not be followed in case of a normal settlement of a near leg, as envisaged in the original contract.
In line with the validation rules, only a limited subset of fields is required for
action type ’TERM’.
Table 33 - New Report (for a swap)
No Field Example XML message
1
Reporting timestamp
2018-06-
01T12:00:00Z <New>

<LEI>12345678901234500000 >
</LEI>
</Lgl>
</Id>
…
<DrctnOrSd><Drctn>
<DrctnOfTheFrstLeg>TAKE

</DrctnOfTheFrstLeg>

<DrctnOfTheScndLeg>MAKE

</DrctnOfTheScndLeg>

</Drctn></DrctnOrSd>
</RptgCtrPty>
<OthrCtrPty>
<IdTp>
<Lgl>

<LEI>ABCDEFGHIJKLMNOPQRST >
</LEI>
</Lgl>
</IdTp>
…
</OthrCtrPty>
</CtrPty>
<RptgTmStmp>2018-06-01T
12:00:00Z</RptgTmStmp>
</CtrPtySpcfcData>
<CmonTradData>
<CtrctData>

123
Table 33 - New Report (for a swap)
No Field Example XML message
<CtrctTp>SWAP</CtrctTp>
<AsstClss>CURR</AsstClss>
<PdctClssfctn>SFCXXP

</PdctClssfctn>

</CtrctData> <TxData> <TxId> <UnqTxIdr> 123456 </UnqTxIdr> </TxId> … <NtnlAmt> <FrstLeg> <Amt Ccy="EUR"> > 1000000</Amt> </FrstLeg> <ScndLeg> <Amt Ccy="GBP"> > 865000</Amt> </ScndLeg> </NtnlAmt> … <DlvryTp>PHYS</DlvryTp> <ExctnTmStmp>2018-06-01T 12:00:00Z</ExctnTmStmp> <FctvDy>2018-06-01</FctvDy> <XprtnDt>2018-12-31 </XprtnDt> <SttlmDt>2018-12-31 </SttlmDt> … <PstTradRskRdctnFlg>FALSE > </PstTradRskRdctnFlg> … <DerivEvt> <Tp>TRAD</Tp> </DerivEvt> … <Ccy> <XchgRate>0.88</XchgRate> <FwdXchgRate>0.865 > </FwdXchgRate> <XchgRateBsis> <CcyPair> <BaseCcy>EUR</BaseCcy> <QtdCcy>GBP</QtdCcy> </CcyPair> </XchgRateBsis> </Ccy> </TxData> </CmonTradData> <Lvl>TCTN</Lvl> </New>

124
Table 33 - New Report (for a swap)
No Field Example XML message
4
Counterparty 1
(Reporting counterparty)
12345678901234500000
9 Counterparty 2 ABCDEFGHIJKLMNOPQRS
T
18 Direction of leg 1 TAKE19 Direction of leg 2 MAKE 1 UTI 123456 5 PTRR ID 9 Product classification SFCXXP 10 Contract type SWAP 11 Asset class CURR 19 Settlement currency 1 20 Settlement currency 2 38 PTRR FALSE 42 Execution timestamp 2018-06- 01T12:00:00Z 43 Effective date 2018-06-01

125
Table 33 - New Report (for a swap)
No Field Example XML message
44 Expiration date 2018-12-31
45 Early termination date
46
Final contractual settlement date
2018-12-31
47 Delivery type PHYS
48 Price
49 Price currency
55 Notional amount of leg 1 1000000
64 Notional amount of leg 2 865000
56 Notional currency
1
EUR
65 Notional currency
2
GBP
113 Exchange rate 1 0.88
114 Forward exchange rate 0.865
115 Exchange rate basis EUR/GBP
151 Action type NEWT
152 Event type TRAD
154 Level TCTN

126
Table 34 – Termination (due to compression) of leg 1
No Field Example XML example
1
Reporting timestamp
2018-07-
17T12:00:00Z
<Termntn>
<CtrPtySpcfcData>
<CtrPty>
<RptgCtrPty>
<Id>
<Lgl>

<LEI>ABCDEFGHIJKLMNOPQRST
</LEI>
</Lgl>
</IdTp>
…
</OthrCtrPty>
</CtrPty>
<RptgTmStmp>2018-07-
17T12:00:00Z
</RptgTmStmp>
</CtrPtySpcfcData>
<CmonTradData>
<TxData>
<TxId>
<UnqTxIdr>
123456
</UnqTxIdr>
</TxId>

<Strr>WWWWWXXXXX

YYYYYZZZZZ</Strr>

<Id>1234567</Id>
4
Counterparty 1
(Reporting counterparty)
12345678901234500000
9 Counterparty 2 ABCDEFGHIJKLMN OPQRST
18 Direction of leg 1 -
19 Direction of leg 2 -
1 UTI 123456
5 PTRR ID WWWWWXXXXXYYYYYZZZZZ1234567
9
Product classification -
10 Contract type -
11 Asset class -
19 Settlement currency 1
20 Settlement currency 2
38 PTRR
42 Execution timestamp -
43 Effective date -
44 Expiration date -

127
Table 34 – Termination (due to compression) of leg 1
No Field Example XML example
45 Early termination date 2018-07-17

</PstTradRskRdctnIdr> </Id> </DerivEvt> … </TxData> </CmonTradData> <Lvl>TCTN</Lvl> </Termntn> 46 Final contractual settlement date 47 Delivery type 48 Price 49 Price currency 55 Notional amount of leg 1 64 Notional amount of leg 2 - 56 Notional currency 1 65 Notional currency 2 113 Exchange rate 1 114 Forward exchange rate 115 Exchange rate basis 151 Action type TERM 152 Event type COMP 154 Level TCTN

128
Table 35 – New report of FX forward (for the far leg of the previous swap)
No Field Example XML schema
1
Reporting timestamp
2018-07-
17T12:00:00Z
<New>
<CtrPtySpcfcData>
<CtrPrty>
<RptgCtrPty>
<Id>
<Lgl>
<LEI>
12345678901234500000
</LEI>
</Lgl>
</Id>
<DrctnOrSd><Drctn>
<DrctnOfTheFrstLeg>
TAKE
</DrctnOfTheFrstLeg>
<DrctnOfTheScndLeg>
MAKE
<DrctnOfTheScndLeg>
</Drctn></DrctnOrSd>
</RptgCtrPty>
<OthrCtrPty>
<Id>
<Lgl>
<LEI>
ABCDEFGHIJKLMNOPQRST
</LEI>
</Lgl>
</Id>
</OthrCtrPty>
</CtrPty>
<RptgTmStmp>2018-07-17T
12:00:00Z</RptgTmStmp>
</CtrPtySpcfcData>
<CmonTradData>
<CtrctData>
<CtrctTp>FORW</CtrctTp>
<AsstClss>CURR</AsstClss>
<PdctClssfctn> a JFTXFP
</PdctClssfctn>
</CtrctData>
<TxData>
<TxId>
<UnqTxIdr>789ABC
</UnqTxIdr>
</TxId>
…
<NtnlAmt>
<FrstLeg>
<Amt Ccy="EUR">

1000000</Amt>
</FrstLeg>

4
Counterparty 1
(Reporting counterparty)
12345678901234500000
9 Counterparty 2 ABCDEFGHIJKLMNOPQRST
18 Direction of leg 1 TAKE
19 Direction of leg 2 MAKE
1 UTI 789ABC
5 PTRR ID WWWWWXXXXXYYYYYZZZZZ1
234567
9
Product classification JFTXFP
10 Contract type FORW
11 Asset class CURR
19 Settlement currency 1
20 Settlement currency 2

129
Table 35 – New report of FX forward (for the far leg of the previous swap)
No Field Example XML schema
38 PTRR TRUE
<ScndLeg>
<Amt Ccy="GBP">

865000</Amt>
</ScndLeg>

</NtnlAmt> … <DlvryTp>PHYS</DlvryTp> <ExctnTmStmp>2018-06-01 T12:00:00Z</ExctnTmStmp> <FctvDy>2018-07-17 </FctvDy> <XprtnDt>2018-12-31 </XprtnDt> <SttlmDt>2018-12-31 </SttlmDt> … <PstTradRskRdctnFlg> true </PstTradRskRdctnFlg> … <DerivEvt> <Tp>COMP</Tp> <Id> <PstTradRskRdctnIdr> <Strr>WWWWWXXXXX YYYYYZZZZZ</Strr> <Id>1234567</Id> </PstTradRskRdctnIdr> </Id> </DerivEvt> … <Ccy> <FwdXchgRate>0.865 > </FwdXchgRate> <XchgRateBsis> <CcyPair> <BaseCcy>EUR </BaseCcy> <QtdCcy>GBP </QtdCcy> </CcyPair> </XchgRateBsis> </Ccy> </TxData> </CmonTradData> <Lvl>TCTN</Lvl> </New> 42 Execution timestamp 2018-06- 01T12:00:00Z 43 Effective date 2018-07-17 44 Expiration date 2018-12-31 45 Early termination date 46 Final contractual settlement date 2018-12-31 47 Delivery type PHYS 48 Price 49 Price currency 55 Notional amount of leg 1 1000000

130
Table 35 – New report of FX forward (for the far leg of the previous swap)
No Field Example XML schema
64 Notional amount of leg 2 865000
56 Notional currency
1
EUR
65 Notional currency
2
GBP
113 Exchange rate 1
114 Forward exchange rate 0.865
115 Exchange rate basis EUR/GBP
151 Action type NEWT
152 Event type COMP
154 Level TCTN
4.4.3 FX option
430. Considering a currency option with the following setup:

Banks A and B enter in a EUR/GBP European call option instrument on 1 June 2018
notional of the contract: 1,000,000 EUR;
maturity date of the contract: 31 December 2018;

131

the option is physically settled;
Bank A is the buyer of the option;
the strike of the option is 0.87;
option premium is 200,000 EUR and is paid on 5 June 2018.

The option has only one leg and the direction should be defined in accordance
with the buyer/seller model. It should be determined by which counterparty buys or sells the option.
Table 36 – Reporting of a new FX option
Ite m
Field Example XML example
1
Reporting timestamp
2018-06-
01T12:00:00Z <New>

<CtrPtySpcfcData> <CtrPty> <RptgCtrPty> <Id> <Lgl> <LEI>12345678901234500000 > </LEI> </Lgl> </Id> … <DrctnOrSd> <CtrPtySd>BYER</DrctnOrSd> </DrctnOrSd> </RptgCtrPty> <OthrCtrPty> <IdTp> <Lgl> <LEI>ABCDEFGHIJKLMNOPQRST > </LEI> </Lgl> </IdTp> … </OthrCtrPty> </CtrPty> <RptgTmStmp>2018-06-01T12:00:00Z > </RptgTmStmp> </CtrPtySpcfcData> <CmonTradData> <CtrctData> <CtrctTp>OPTN</CtrctTp> <AsstClss>CURR</AsstClss> <PdctClssfctn>HFTAVP > </PdctClssfctn> </CtrctData> <TxData> <TxId> 4 Counterparty 1 (Reporting counterparty) 1234567890123450000 0 9 Counterparty 2 ABCDEFGHIJKLMNOP QRST 17 Direction BYER 1 UTI 123OPT 9 Product classification HFTAVP 10 Contract type OPTN 11 Asset class CURR 19 Settlement currency 1 20 Settlement currency 2 42 Execution timestamp 2018-06- 01T12:00:00Z

132
Table 36 – Reporting of a new FX option
Ite m
Field Example XML example
43 Effective date 2018-06-01
<UnqTxIdr>123OPT</UnqTxIdr>
</TxId>
…
<NtnlAmt>
<FrstLeg>
<Amt Ccy="EUR">

1000000</Amt>
</FrstLeg>

<ScndLeg> <Amt Ccy="GBP"> > 870000</Amt> </ScndLeg> </NtnlAmt> … <DlvryTp>PHYS</DlvryTp> <ExctnTmStmp>2018-06-1T12:00: > 00Z</ExctnTmStmp> <FctvDy>2018-06-01</FctvDy> <XprtnDt>2018-12-31</XprtnDt> <SttlmDt>2019-01-02</SttlmDt> … <DerivEvt> <Tp>TRAD</Tp> </DerivEvt> … <Ccy> <XchgRateBsis> <CcyPair> <BaseCcy>EUR</BaseCcy> <QtdCcy>GBP</QtdCcy> </CcyPair> </XchgRateBsis> </Ccy> <Optn> <Tp>CALL</Tp> <ExrcStyle>EURO</ExrcStyle> <StrkPric> <Pctg>0.87</Pctg> </StrkPric> <PrmAmt> <Amt Ccy="EUR">200000</Amt> </PrmAmt> <PrmPmtDt>2018-06-05 x </PrmPmtDt> </Optn> </TxData> </CmonTradData> <Lvl>TCTN</Lvl> </New> 44 Expiration date 2018-12-31 46 Final contractual settlement date 2019-01-02 47 Delivery type PHYS 48 Price 49 Price currency 55 Notional amount of leg 1 1000000 56 Notional currency 1 EUR 64 Notional amount of leg 2 870000 65 Notional currency 2 GBP 132 Option type CALL 133 Option style EURO 134 Strike price 0.87 138 Strike price currency/currency pair EUR/GBP 139 Option premium amount 200000

133
Table 36 – Reporting of a new FX option
Ite m
Field Example XML example
140 Option premium currency
EUR
141 Option premium payment date
2018-06-
05
151 Action type NEWT
152 Event type TRAD
154 Level TCTN
4.4.4 Additional considerations on the reporting of currencies
432. The reporting of the direction of the derivative and of the currencies involved
should be done by parties taking into account their own booking irrespective of the other party booking. Consequently the direction and the order of currencies may vary in the reporting. Such difference should be managed by TRs in their reconciliation process so that direction of the derivative is considered based on the currencies provided in the reporting.
4.5 Reporting of NDFs
433. Non-deliverable forwards (NDFs) are cash-settled foreign exchange forward
contracts. Such a cash-settled forward contract specifies an exchange rate against the currency of delivery (the convertible currency), typically the US dollar, a notional amount of the non-convertible currency and a settlement date. A cash-settled FX forward contract is akin to a classical physically-settled FX forward contract, but contrary to the former there is no physical delivery of the designated currencies at maturity. On the maturity date, the spot market exchange rate is instead compared to the forward rate in order to value the NDF. The cash-settled contract is settled on a net basis, in the convertible currency based on the notional amount.
4.5.1 NDF
434. Considering a currency non-deliverable forward (NDF) with the following setup:

Banks A and B enter in a BRL/USD NDF instrument on 1 June 2018
notional of the contract: 1,000,000 BRL;
maturity date of the contract: 31 December 2018;
-settlement date of the contract: 2 January 2019;
the forward is cash-settled because of its non-deliverable nature;

134

Bank A delivers or receives the difference (according to its sign) in USD between the
spot and the forward at the settlement date;
USD is populated in Settlement Currency 1;
the forward exchange rate is 0.29 BRL/USD.

In the case of forwards related to currencies, the counterparty 1 should identify
itself as either the payer or the receiver for leg 1 (BRL in this example). Given that in this example the reporting counterparty would receive the difference in case of increase in the BRL value (decrease in the exchange rate), it is identified as the receiver of leg 1.
Price is not populated as the price information is considered to be included in
the forward exchange rate field.
Given that there is just one settlement currency, it should be always populated
as settlement currency 1.
Table 37 – Reporting of an NDF
No Field Example XML schema
1
Reporting timestamp
2018-06-
01T12:00:00Z <New>

<CtrPtySpcfcData> <CtrPty> <RptgCtrPty> <Id> <Lgl> <LEI>12345678901234500000 > </LEI> </Lgl> </Id> … <DrctnOrSd><Drctn> <DrctnOfTheFrstLeg>TAKE > </DrctnOfTheFrstLeg> <DrctnOfTheScndLeg>MAKE > </DrctnOfTheScndLeg> </Drctn></DrctnOrSd> </RptgCtrPty> <OthrCtrPty> <IdTp> <Lgl> <LEI>ABCDEFGHIJKLMNOPQRST > </LEI> </Lgl> </IdTp> … </OthrCtrPty> </CtrPty> <RptgTmStmp>2018-06-01T12:00:00Z > </RptgTmStmp> </CtrPtySpcfcData> <CmonTradData> <CtrctData> 4 Counterparty 1 (Reporting counterparty) 1234567890123450000 0 9 Counterparty 2 ABCDEFGHIJKLMNOPQR ST 18 Direction of leg 1 TAKE 19 Direction of leg 2 MAKE 1 UTI 123NDF 9 Product classification JFTXFC 10 Contract type FORW 11 Asset class CURR 19 Settlement currency 1 USD 20 Settlement currency 2 - 42 Execution timestamp 2018-06- 01T12:00:00Z

135
Table 37 – Reporting of an NDF
No Field Example XML schema
43 Effective date 2018-06-01
<CtrctTp>FORW</CtrctTp>
<AsstClss>CURR</AsstClss>
<PdctClssfctn>JFTXFC

</PdctClssfctn>

<SttlmCcy><Ccy>USD</Ccy>
</SttlmCcy>
</CtrctData>
<TxData>
<TxId>
<UnqTxIdr>123NDF</UnqTxIdr>
</TxId>
…
<NtnlAmt>
<FrstLeg>
<Amt Ccy="BRL">1000000</Amt>
</FrstLeg>
<ScndLeg>
<Amt Ccy="USD">290000</Amt>
</ScndLeg>
</NtnlAmt>
…
<DlvryTp>CASH</DlvryTp>
<ExctnTmStmp>2018-06-01T12:00:

00Z</ExctnTmStmp>
<FctvDy>2018-06-01</FctvDy>
<XprtnDt>2018-12-31</XprtnDt>
<SttlmDt>2019-01-02</SttlmDt>
…
<DerivEvt>

<Tp>TRAD</Tp>
</DerivEvt>
…
<Ccy>
<FwdXchgRate>0.29

</FwdXchgRate>

<XchgRateBsis> <CcyPair> <BaseCcy>BRL</BaseCcy> <QtdCcy>USD</QtdCcy> </CcyPair> </XchgRateBsis> </Ccy> </TxData> </CmonTradData> <Lvl>TCTN</Lvl> </New> 44 Expiration date 2018-12-31 46 Final contractual settlement date 2019-01-02 47 Delivery type CASH 48 Price 49 Price currency 55 Notional amount of leg 1 1000000 56 Notional currency 1 BRL 64 Notional amount of leg 2 290000 65 Notional currency 2 USD 114 Forward exchange rate 0.29 115 Exchange rate basis BRL/USD 151 Action type NEWT 152 Event type TRAD 154 Level TCTN 4.6 Reporting of CFDs 438. Contracts for Difference (CFDs) generally do not have any specified maturity date and at the moment of their conclusion the termination date is also not specified. Counterparties may at any moment decide to close the contract, with immediate

136 effect. They can also close it partially as counterparties may terminate only a part of the volume on one day and the other part or parts of the contract on any other day.
439. Each opening of a new contract should be reported by the counterparties to the
TR as a new entry. This means that each CFD be reported with its distinct Unique Trade Identifier and action type ‘New’ or if the trade is included in a position on the same day it can be reported with action type ‘Position Component’, even if they are executed and then netted or terminated for other reasons during the same day.
440. Furthermore, the CFDs have to be reported even if they are concluded with a
counterparty that is not subject to the reporting obligation, such as an individual not carrying out an economic activity and who is consequently not considered as an undertaking.
441. Subsequent CFDs do not have to be included in a position, however, it is
strongly recommended to do so. As these derivatives have no maturity, it would imply that without including in a position each individual CFD by a financial counterparty would need to receive daily valuation updates until either 1) the CFD is terminated or 2) infinity. Outstanding CFDs need valuation updates, but when included in a position, the valuation can be provided at position level in accordance with the section 3.7.
442. Similarly to any other contract, the reported valuation of a CFD should represent
the total value of the contract, rather than a daily change in its valuation.
443. ESMA considers offsetting CFDs to be reportable derivatives requiring a Unique
Trade Identifier for each derivative. In case CFDs are not netted into a position, offsetting CFDs need to be terminated.
444. Once the CFD is closed, the counterparty should send a termination report to
the initial entry, completing the field ’Early termination date‘. If the CFD is closed partially, counterparties send a report with action type ‘Modify’ and event type ‘Early termination’ to the initial entry, reducing only its notional amount (remaining volume is equal to the not yet terminated volume). If there is another partial close, yet another modification report is sent – until the contract is finally closed in whole. Then, the counterparties send a termination report with action type ‘Terminate’ and event type ‘Early termination’, completing the field “Early termination date”. In these cases, the opening price of the contract is reported only in the first report (with action type ‘New’) and it is not updated in the following modification reports. Please note that the possibility to modify the notional of a given trade, as just described, should only be used in the event that both parties in fact agree to partially terminate that trade. If however they agree to conclude an offsetting trade with a smaller notional, then a report with action type ‘New’ is required.
4.6.1 CFD
445. The below table illustrates population of fields for a new CFD (that is not
included in a position) on a share XS1234567890. The UPI assigned to that CFD

137 product is AAA111222333. The initial price of the share is 30 EUR and the reporting counterparty A buys a CFD on 1,000 shares.
Table 38 - Reporting of a new CFD
No Field Example XML message
1
Reporting timestamp
2023-06-
06T12:00:00Z
<New>
<CtrPtySpcfcData>
<CtrPty>
<RptgCtrPty>
<Id>
<Lgl>
<LEI>12345678901234500000

</LEI>

</Lgl> </Id> … <DrctnOrSd> <CtrPtySd>BYER</CtrPtySd> </DrctnOrSd> </RptgCtrPty> <OthrCtrPty> <IdTp> <Lgl> <LEI>ABCDEFGHIJKLMNOPQRST > </LEI> </Lgl> </IdTp> … </OthrCtrPty> </CtrPty> <RptgTmStmp>2023-06-06T12:00: x 00Z</RptgTmStmp> </CtrPtySpcfcData> <CmonTradData> <CtrctData> <CtrctTp>CFDS</CtrctTp> <AsstClss>EQUI</AsstClss> <PdctClssfctn>JESXCC > </PdctClssfctn> <PdctId><UnqPdctIdr><Id> AAA111222333 </Id></UnqPdctIdr></PdctId> <UndrlygInstrm><ISIN> XS1234567890 </ISIN></UndrlygInstrm> <SttlmCcy><Ccy>EUR</Ccy> </CtrctData> <TxData> <TxId> <UnqTxIdr>123CFD</UnqTxIdr> </TxId> … <TxPric> <Pric> <MntryVal> <Amt Ccy="EUR">30</Amt> 4 Counterparty 1 (Reporting counterparty) 12345678901234500000 9 Counterparty 2 ABCDEFGHIJKLMNOPQR ST 17 Direction BYER 1 UTI 123CFD 8 UPI AAA111222333 9 Product classification JESXCC 10 Contract type CFDS 11 Asset class EQUI 13 Underlying identification type I 14 Underlying identification XS1234567890 19 Settlement currency 1 EUR 20 Settlement currency 2 - 42 Execution timestamp 2023-06- 05T11:43:00Z 43 Effective date 2023-06-05 44 Expiration date - 46 Final contractual settlement date - 47 Delivery type CASH

138
Table 38 - Reporting of a new CFD
No Field Example XML message
48 Price 30
</MntryVal>
</Pric>
</TxPric>
…
<NtnlAmt>
<FrstLeg>
<Amt Ccy="EUR">

30000</Amt>
</FrstLeg>

</NtnlAmt> <NtnlQty> <FrstLeg> <TtlQty>1000</TtlQty> </FrstLeg> </NtnlQty> … <DlvryTp>CASH</DlvryTp> <ExctnTmStmp>2023-06-05 x T11:43:00Z</ExctnTmStmp> <FctvDy>2023-06-05</FctvDy> … <DerivEvt> <Tp>TRAD</Tp> </DerivEvt> … </TxData> </CmonTradData> <Lvl>TCTN</Lvl> </New> 49 Price currency EUR 55 Notional amount of leg 1 30000 56 Notional currency 1 EUR 60 Total notional quantity of leg 1 1000 15 1 Action type NEWT 15 2 Event type TRAD 15 4 Level TCTN 4.7 Reporting of equity derivatives 446. Equity derivatives are a type of derivatives whose value is derived, at least partly, from one or more underlying equity securities. Options and futures are the most common equity derivatives. The type of contract should be specified in field 2.10 and the asset class (EQUI) should be specified in field 2.11 as indicated in the RTS and the ITS on reporting. 447. A Total Return Swap is a contract between two parties who exchange returns from a financial asset (underlying) between them. In this kind of derivatives, one party makes payments based on a set rate while the other party makes payments based on the total return of the underlying asset. The underlying assets are usually a bond, equity, equity index, interest, or loan. 448. For example, a Total Return Swap on an equity index should be reported with the value ’EQUI’ in field 2.11 ‘Asset Class’, whereas a Total Return Swap on a bond or loan should be reported with the value ’CRDT’ in field 2.11 ‘Asset Class’.

139
449. The event type ‘Corporate Event’ should be used in the case of lifecycle events
triggered by corporate actions on the underlying equities. See section 3.6 for more details.
450. The direction of the trade of most equity swaps should be reported following the
approach in which the counterparties would indicate whether the reporting counterparty is payer/receiver for a given leg at the time of the derivative, using an indicator in the dedicated fields ( ’Direction of leg 1’ or ’Direction of leg 2‘). See the
section 3.12 of these Guidelines for further details.
451. In addition, as stated in the Article 4 of the ITS on reporting, in the swaps related
to dividends, the counterparty receiving the equivalent dividend amount payments should be identified as the buyer and the counterparty paying that equivalent dividend amount payments should be identified as the seller. Furthermore, for swaps related to securities other than dividend swaps, the counterparty 1 should identify itself as either the payer or the receiver for leg 1, and the opposite for leg
2. The counterparty 2 should populate these two fields with the opposite values
related to the counterparty 1.
452. More details on the reporting of notional and prices are provided in the section
3.17 of these Guidelines.
453. The strike price of equity options, when this strike price is expressed as
monetary amount, should be reported with any value up to 18 numeric characters including up to 13 decimal places; e.g.: USD 6.39 expressed as 6.39. If the value has more than 13 digits after the decimal, reporting counterparties should round half-up (field 2.134 in the RTS/ITS on reporting).
454. The strike price of equity options should be reported in the currency in which
the strike price is denominated (fields 2.137 and 2.138 in the RTS/ITS on reporting).
4.7.1 Dividend swap
455. A credit institution concludes and reports an equity swap derivative on a single
stock where the return or payout trigger is the dividend. The entity reports also a collateral and valuation update, according to its internal model. The other counterparty is an investment firm of its group. The notional amount is EUR 1 million, the transaction is fully collateralised.
Table 39 – Reporting of an equity derivative
No Field Example XML schema
Table 1 <ValtnUpd>
<CtrPtySpcfcData>
<CtrPty>
<RptgCtrPty>
<Id><Lgl><LEI>
12345678901234500000
1
Reporting timestamp 2021-02-24T17:00:00Z
2
Report submitting entity ID
12345678901234500000

140
Table 39 – Reporting of an equity derivative
No Field Example XML schema
3
Entity responsible for reporting
12345678901234500000
</LEI></Lgl></Id>
<Ntr>
<FI>
<Sctr>
<Cd>CDTI</Cd>
</Sctr>
<ClrThrshld>true
</ClrThrshld>
</FI>
</Ntr>
<DrctnOrSd><Drctn>
<CtrPtySd>SLLR</CtrPtySd>
</Drctn></DrctnOrSd>
</RptgCtrPty>
<OthrCtrPty>
<IdTp>
<Lgl>
<LEI>ABCDEFGHIJKLMNOPQRST
</LEI>
</Lgl>
</IdTp>
<Ntr>
<FI>
<Sctr>
<Cd>INVF</Cd>
</Sctr>
<ClrThrshld>true
</ClrThrshld>
</FI>
</Ntr>
</OthrCtrPty>
<SubmitgAgt>
<LEI>12345678901234500000</LEI>
</SubmitgAgt>
<NttyRspnsblForRpt>
<LEI>12345678901234500000</LEI>
</NttyRspnsblForRpt>
</CtrPty>
<Valtn>
<CtrctVal>
<Amt Ccy="EUR">6827412379
</Amt>
</CtrctVal>
<TmStmp>2021-03-02T17:00:00Z
</TmStmp>
<Tp>MTMO</Tp>
</Valtn>
<RptgTmStmp>2021-02-24T17:00:00Z
</RptgTmStmp>
</CtrPtySpcfcData>
<CmonTradData>
<CtrctData>
<CtrctTp>SWAP</CtrctTp>
4
Counterparty 1
(Reporting counterparty)
12345678901234500000
5
Nature of the counterparty 1 F
6
Corporate sector of the counterparty 1
CDTI
7
Clearing threshold of counterparty 1
TRUE
8
Counterparty 2 identifier type TRUE
9 Counterparty 2 ABCDEFGHIJKLMNOPQRST
11 Nature of the counterparty 2 F
12
Corporate sector of the counterparty 2
INVF
17 Direction SLLR
Table 2
1 UTI AAAAABBBBBCCCCCDDDDD
5 PTRR ID
9
Product classification SESDXC
10 Contract type SWAP
11 Asset class EQUI
13
Underlying identification type
I
14 Underlying identification ES1234567890
21 Valuation amount 6827412379
22 Valuation currency
EUR
23 Valuation timestamp 2021-03-02T17:00:00Z 24 Valuation method MTMO

141
Table 39 – Reporting of an equity derivative
No Field Example XML schema
26
Collateral portfolio indicator
FALSE
<AsstClss>EQUI</AsstClss>
<PdctClssfctn>SESDXC
</PdctClssfctn>
<UndrlygInstrm><ISIN>
ES1234567890
</ISIN></UndrlygInstrm>
<SttlmCcy><Ccy>EUR</Ccy>
</SttlmCcy>
</CtrctData>
<TxData>
<TxId>
<UnqTxIdr>
AAAAABBBBBCCCCCDDDDD
</UnqTxIdr>
</TxId>
<CollPrtflCd>
<Prtfl><NoPrtfl>NOAP
</NoPrtfl></Prtfl>
</CollPrtflCd>
<PltfmIdr>XXXX</PltfmIdr>
<NtnlAmt>
<FrstLeg>
<Amt Ccy="EUR">
1000000</Amt>
</FrstLeg>
</NtnlAmt>
…
<DlvryTp>CASH</DlvryTp>
<ExctnTmStmp>2021-02-23T17:00
:00Z</ExctnTmStmp>
<FctvDy>2021-02-24</FctvDy>
<XprtnDt>2024-06-15</XprtnDt>
<PstTradRskRdctnFlg> false
</PstTradRskRdctnFlg>
<TradClr>
<ClrOblgtn>FLSE</ClrOblgtn>
<ClrSts><NonClrd><Rsn>
NORE
</Rsn></NonClrd></ClrSts>
<IntraGrp>true</IntraGrp>
</TradClr>
…
</TxData>
</CmonTradData>
<Lvl>TCTN</Lvl>
</ValtnUpd>
30 Clearing obligation FALSE
31 Cleared N
37 Intragroup TRUE
38 PTRR FALSE
41 Venue of execution XXXX
42 Execution timestamp 2021-02-23T17:00:00Z 43 Effective date 2021-02-24 44 Expiration date 2024-06-15 47 Delivery type CASH 55 Notional amount of leg 1 1000000 56 Notional currency 1 EUR 151 Action type VALU 152 Event type 154 Level TCTN
Table 3
7
Collateral timestamp 2021-03-24T17:00:00Z <MrgnUpd> <EvtDt>2021-03-24</EvtDt>

142
Table 39 – Reporting of an equity derivative
No Field Example XML schema
8
Collateral portfolio indicator
FALSE
<TxId>
<UnqTxIdr>
AAAAABBBBBCCCCCDDDDD
</UnqTxIdr>
</TxId>
<Coll>
<CollPrtflCd>
<Prtfl>
<NoPrtfl>NOAP<NoPrtfl>
<Prtfl>
</CollPrtflCd>
<CollstnCtgy>FLCL</CollstnCtgy>
<TmStmp>2021-03-24T17:00:00Z
</TmStmp>
</Coll>
<PstdMrgnOrColl>
<InitlMrgnPstdPreHrcut>
<Amt Ccy="EUR">5000000</Amt>
</InitlMrgnPstdPreHrcut>
<InitlMrgnPstdPstHrcut>
<Amt Ccy="EUR">4500000</Amt>
</InitlMrgnPstdPstHrcut>
<VartnMrgnPstdPreHrcut>
<Amt Ccy="EUR">1000000</Amt>
</VartnMrgnPstdPreHrcut>
<VartnMrgnPstdPstHrcut>
<Amt Ccy="EUR">800000</Amt>
</VartnMrgnPstdPstHrcut>
</PstdMrgnOrColl>
<RcvdMrgnOrColl>
<InitlMrgnRcvdPreHrcut>
<Amt Ccy="EUR">5000000</Amt>
</InitlMrgnRcvdPreHrcut>
<InitlMrgnRcvdPstHrcut>
<Amt Ccy="EUR">4300000</Amt>
</InitlMrgnRcvdPstHrcut>
</RcvdMrgnOrColl>
</MrgnUpd>
9
Collateral portfolio code
10 UTI AAAAABBBBBCCCCCDDDDD
11 Collateralisation category FLCL
12
Initial margin posted by counterparty 1
(pre haircut)
5000000
13
Initial margin posted by the counterparty 1 (post haircut) 4500000 14 Currency of the initial margin posted EUR 15 Variation margin posted by the counterparty 1 (pre-haircut) 1000000 16 Variation margin posted by the counterparty 1 (post-haircut) 800000 17 Currency of the variation margins posted EUR 20 Initial margin collected by the counterparty 1 (pre-haircut) 5000000 21 Initial margin collected by the counterparty 1 (post-haircut) 4300000 22 Currency of initial margin collected EUR 23 Variation margin collected by the counterparty 1 (pre-haircut)

143
Table 39 – Reporting of an equity derivative
No Field Example XML schema
24
Variation margin collected by the counterparty 1 (post-haircut) 25 Currency of variation margin collected 28 Action type MARU 29 Event date 2021-03-24
456. Another example on ETDs future on equities can be found in the section 3.8.
4.8 Reporting of credit derivatives
457. A credit derivative is a financial contract in which the underlying is a credit asset
(debt or fixed-income instrument). The purpose of a credit derivative is to transfer credit risk without transferring the asset itself. The type of contract should be specified in field 2.10 and the asset class (’CRDT’) should be specified in the field 2.11.
458. Total Return Swaps (defined above in the section Reporting of equity
derivatives of these Guidelines) should be classified based on the underlying. For example, a Total Return Swap on an equity index should be reported with the value ’EQUI’ in the field 2.11 whereas a Total Return Swap on a bond or loan should be reported with the value ‘CRDT’.
459. In the case of credit derivatives following a change in the index factor (field 2.147
in the RTS on reporting) due to credit events, the counterparties should not modify the notional, but rather they should only update the index factor.
460. With regard to the reporting of reference entity (field 2.144) for credit derivatives,
ISO 3166 and ISO 3166-2 codes should only be used in the case of credit derivatives where the reference entity is a supranational, a sovereign or a municipality, respectively. In all other cases the reference entity should be identified with a LEI.
461. In the case of the reporting of a CDS with a coupon payment realised in a single
payment on the maturity date rather than with a monthly, quarterly, semi-annual or annual frequency, counterparties should populate the field 2.81 ’Fixed rate or coupon payment frequency period leg 1‘ of the ITS on reporting using the code ‘EXPI’ = payment at term.
462. CDS index tranches are standardised synthetic collateralised debt obligations
(CDOs) based on a CDS index, where each tranche references a different segment

144 of the loss distribution of the underlying CDS index. The riskiness of a tranche decreases with the tranche’s seniority in the securitisation’s capital structure. This enables investors to take on exposures to specific segments of the CDS index default loss distribution where each tranche has a different sensitivity to credit risk correlations among entities in the index.
463. Tranches of a CDS index that absorb losses sequentially are defined by an
attachment and a detachment point. They are defined in the fields 2.149 and 2.150 of the RTS on reporting.
464. Both data elements, attachment and detachment points, are not applicable if
the derivative is not a CDS tranche derivative (index or custom basket).
465. For example, the notional in a tranche with an attachment point of 3% and a
detachment point of 6% will be reduced after there have been 3% of losses in the portfolio. 6% losses in the portfolio deplete the notional of the tranche.
466. ’Credit event’ event type applies only to credit derivatives. It is defined as a credit
event that results in a modification of a credit derivative, at a trade or position level. For further details see section 3.6 in these Guidelines.
467. In accordance with the Article 4 of ITS on reporting, in the case of derivative
instruments for the transfer of credit risk as the credit derivatives (mainly CDSs), the counterparty buying the protection should be identified as the buyer and the counterparty selling the protection should be identified as the seller. In the case of options and swaptions the rule under Article 4(2) of the ITS on reporting applies, i.e. the buyer of the option/swaption should be identified as the buyer.
468. The price of credit default swaps and credit total return swaps should be
reported in the fields ‘Fixed rate’, ‘Spread’ and ‘Other payment amount’ (with field ‘Other payment type’ =’UFRO’). More details are provided in the section 3.173.17 of this guideline.
469. For Credit Default Swaps (CDS), when an underlying is reported, the ISIN of
the reference obligation should be provided (field 2.14).
470. The strike price of credit swaptions quoted in spread, when this strike price is
expressed as percentage, should be reported with value up to 11 numeric characters including up to 10 decimal places; e.g.: 2.1 instead of 2.1% (fields 2.134 and 2.137).
471. The seniority of the debt security, or debt basket or index underlying a derivative
should be reported in ‘Seniority’ field for credit derivatives (field 2.143).
472. If it is applicable, the series number of the composition of the index used should
be reported for credit derivatives as well as a new version of a series is issued if one of the constituents defaults and the index has to be re-weighted to account for the new number of total constituents within the index (fields 2.145 and 2.146).
473. If a credit derivative contract is tranched, field 2.148 ‘Tranche’ should be
reported as ‘True’.
474. The field 2.47 ‘Delivery type’ for credit derivatives in the case of credit event
auction should be reported as ‘CASH‘ (Cash) for credit derivatives that are cash-

145 settled. However, the counterparties should report ‘PHYS’ (Physical) in the case of physical delivery of the underlying of the credit derivative from the counterparty that is protection buyer to the other counterparty.
4.8.1 CDS
475. A French investment firm reports the recent purchase, priced with an internal
model, of a default protection. This protection is based on a bilateral derivative entered into with an Irish investment entity. The notional of the derivative is
520.000.000 EUR. The derivative falls into the category of CDS tranche derivative
with an attachment point of 10% and detachment point of 20%. The underlying of the derivative corresponds to a certain series of the Itraxx Europe index. A fixed monthly coupon of 1% is paid. The derivative is partially collateralised by the purchaser.
Table 40 - Reporting of a CDS
No Field Example XML schema
Table 1 <New>
<CtrPtySpcfcData>
<CtrPrty>
<RptgCtrPty>
<Id>
<Lgl>

<LEI>12345678901234500000</LEI>
</Lgl>
</Id>
<Ntr>
<FI>
<Sctr>
<Cd>INVF</Cd>
</Sctr>
<ClrThrshld>true
</ClrThrshld>
</FI>
</Ntr>
<DrctnOrSd>
<Drctn>
<CtrPtySd>BYER
</CtrPtySd
</Drctn>
</DrctnOrSd>
</RptgCtrPty>
<OthrCtrPty>
<Id>
<Lgl>
<LEI>ABCDEFGHIJKLMNOPQRST
</LEI>
</Lgl>
1
Reporting timestamp 2020-05-19T14:23:26Z
2
Report submitting entity ID
12345678901234500000
3
Entity responsible for reporting
12345678901234500000
4
Counterparty 1
(Reporting counterparty)
12345678901234500000
5
Nature of the counterparty 1 F
6
Corporate sector of the counterparty 1
INVF
7
Clearing threshold of counterparty 1
TRUE
8
Counterparty 2 identifier type TRUE
9 Counterparty 2 ABCDEFGHIJKLMNOPQRS
T
11 Nature of the counterparty 2 F
12
Corporate sector of the counterparty 2
INVF

146
Table 40 - Reporting of a CDS
No Field Example XML schema
17 Direction BYER </Id>
<Ntr>
<FI>
<Sctr>
<Cd>INVF</Cd>
</Sctr>
</FI>
</Ntr>
</OthrCtrPty>
<SubmitgAgt>
<LEI>1234567890
1234500000</LEI>
</SubmitgAgt>
<NttyRspnsblForRpt>
<LEI>
12345678901234500000</LEI>
</NttyRspnsblForRpt>
</CtrPrty>
<Valtn>
<CtrctVal>
<Amt Ccy="EUR">
8954030.09</Amt>
</CtrctVal>
<TmStmp>
2020-05-19T14:23:26Z
</TmStmp>
<Tp>MTMO</Tp>
</Valtn>
<RptgTmStmp>2020-05-19T
14:23:26Z</RptgTmStmp>
</CtrPtySpcfcData>
<CmonTradData>
<CtrctData>
<CtrctTp>SWAP</CtrctTp>
<AsstClss>CRDT</AsstClss>
<PdctClssfctn>SCVCCA
</PdctClssfctn>
<UndrlygInstrm>
<Indx>
<Nm>ITRAXX EUROPE SERIES
28 V</Nm>
</Indx>
</UndrlygInstrm>
</CtrctData>
<TxData>
<TxId>
<UnqTxIdr>
AABBCCDDEEFF
GGHHIIPP
</UnqTxIdr>
</TxId>
<CollPrtflCd>
<Prtfl>
<NoPrtfl>NOAP</NoPrtfl>
Table 2
1 UTI AABBCCDDEEFFGGHHIIPP
5 PTRR ID
9
Product classification SCVCCA
10 Contract type SWAP
11 Asset class CRDT
13
Underlying identification type
X
14 Underlying identification
15
Indicator of the underlying index
16
Name of the underlying index
ITRAXX EUROPE SERIES
28 V
21 Valuation amount 8954030.09
22 Valuation currency
EUR
23 Valuation timestamp 2020-05-19T14:23:26Z 24 Valuation method MTMO 26 Collateral portfolio indicator FALSE 28 Confimation timestamp 2020-05-18T14:39:32Z 29 Confirmed ECNF 30 Clearing obligation UKWN 31 Cleared N 37 Intragroup FALSE 38 PTRR FALSE 41 Venue of execution XXXX 42 Execution timestamp 2020-05-18T14:39:32Z 43 Effective date 2020-05-19 44 Expiration date 2022-12-20 47 Delivery type PHYS

147
Table 40 - Reporting of a CDS
No Field Example XML schema
55 Notional amount of leg 1 520000000 </Prtfl> </CollPrtflCd> <PltfmIdr>XXXX</PltfmIdr> <NtnlAmt> <FrstLeg> <Amt Ccy="EUR"> 520000000</Amt> </FrstLeg> </NtnlAmt> <DlvryTp>PHYS</DlvryTp> <ExctnTmStmp>2020-05-18 T14:39:32Z</ExctnTmStmp> <FctvDt>2020-05-19</FctvDt> <XprtnDt>2022-12-20</XprtnDt> <PstTradRskRdctnEvt> false</PstTradRskRdctnEvt> <DerivEvt> <Tp>TRAD</Tp> </DerivEvt> <TradConf> <Confd> <Tp>ECNF</Tp> <TmStmp> 2020-05-18T14:39:32Z </TmStmp> </Confd> </TradConf> <TradClr> <ClrOblgtn>UKWN</ClrOblgtn> <ClrSts> <NonClrd><Rsn>NORE</Rsn> </NonClrd> </ClrSts> <IntraGrp>false</IntraGrp> </TradClr> <IntrstRate> <FrstLeg> <Fxd> <Rate> <Rate>0.01</Rate> </Rate> <DayCnt><Cd>A004 </Cd></DayCnt> <PmtFrqcy> <Term> <Unit>MNTH</Unit> <Val>1</Val> </Term> </PmtFrqcy> </Fxd> </FrstLeg> </IntrstRate> <Cdt> <Snrty>SNDB</Snrty> <Srs>28</Srs> 56 Notional currency 1 EUR 79 Fixed rate of leg 1 or coupon 0.01 80 Fixed rate or coupon day count convention leg 1 A004 81 Fixed rate or coupon payment frequency period leg 1 MNTH 82 Fixed rate or coupon payment frequency period multiplier leg 1 1 143 Seniority SNDB 144 Reference entity 145 Series 28 146 Version 2 147 Index factor 1 148 Tranche TRUE 149 CDS index attachment point 0.10 150 CDS index detachment point 0.20 151 Action type NEWT 152 Event type TRAD 154 Level TCTN

148
Table 40 - Reporting of a CDS
No Field Example XML schema
<Vrsn>2</Vrsn>
<IndxFctr>1</IndxFctr>
<Trch>
<Trnchd>
<AttchmntPt>0.10
</AttchmntPt>
<DtchmntPt>0.20
</DtchmntPt>
</Trnchd>
</Trch>
</Cdt>
</TxData>
</CmonTradData>
<Lvl>TCTN</Lvl>
</New>
Table 3
7
Collateral timestamp 2020-05-18T14:39:32Z
<MrgnUpd>
<EvtDt>2020-05-18</EvtDt>
<Coll>
<CollPrtflCd>
<Prtfl>
<NoPrtfl>NOAP</NoPrtfl>
</Prtfl>
</CollPrtflCd>
<CollstnCtgy>PRC1</CollstnCtgy>
<TmStmp>2020-05-
18T14:39:32Z</TmStmp>
</Coll>
<PstdMrgnOrColl>
<VartnMrgnPstdPreHrcut>
<Amt Ccy="EUR">1000000</Amt>
</VartnMrgnPstdPreHrcut>
<VartnMrgnPstdPstHrcut>
<Amt Ccy="EUR">745000</Amt>
</VartnMrgnPstdPstHrcut>
</PstdMrgnOrColl>
</MrgnUpd>
8
Collateral portfolio indicator
FALSE
9
Collateral portfolio code
11 Collateralisatio n category PRC1
12
Initial margin posted by the counterparty 1 (pre-haircut) 13 Initial margin posted by the counterparty 1 (post-haircut) 14 Currency of the initial margin posted 15 Variation margin posted by the counterparty 1 (pre-haircut) 1000000 16 Variation margin posted by the counterparty 1 (post-haircut) 745000

149
Table 40 - Reporting of a CDS
No Field Example XML schema
17
Currency of the variation margins posted
EUR
20
Initial margin collected by the counterparty 1 (pre-haircut) 21 Initial margin collected by the counterparty 1 (post-haircut) 22 Currency of initial margin collected 23 Variation margin collected by the counterparty 1 (pre-haircut) 24 Variation margin collected by the counterparty 1 (post-haircut) 25 Currency of variation margin collected 28 Action type MARU 29 Event date 2020-05-18
4.9 Reporting of commodity derivatives
476. Table 2 of the RTS on reporting contains dedicated fields for reporting of
commodity derivatives: fields 2.116-2.118 for all commodity deriatives and additional fields 2.119-2.131 for energy derivatives.
477. In particular, the classification of commodities should be reported in the fields
2.116-2.118 in line with the categories specified in the Table 4 of the ITS on reporting. The reported classification of the underlying commodity should be as granular as possible. For example, in the case of derivatives on gold, the counterparty should specify ‘Metals’, ‘Precious’ and ‘Gold’ in the fields 2.116, 2.117 and 2.118, respectively. Only if the underlying commodity does not correspond to any of the specific categories included in the ITS on reporting, it should be reported as ‘Other’. In case no specific values are set out in the ITS on reporting for a given product for fields 2.117 and 2.118 (e.g. for the category ‘Multi Commodity Exotic’),

150 the counterparty should not report any values for these fields, in line with the XML schema.
478. The counterparties should not identify commodities in the currency fields, even
if a dedicated code has been designated to such commodity in the ISO 4217 standard (e.g.XAU for gold or XBA for silver). The commodities should only be identified via commodity classification fields.
479. The commodity classification fields (2.116-2.118) are not repeatable. Therefore,
in the case of commodity swaps including two commodity underlyings, the counterparty should report such swap as a complex trade composed of two commodity forwards and populate the Package ID in both reports (see section 3.28).
480. In the case of derivatives based on electricity or natural gas, the counterparties
should report fields 2.119-2.131 (in addition to other relevant reportable details concerning the derivative and the counterparties, as illustrated in other sections).
481. The fields 2.122-2.131 for energy derivatives are repeatable. Additionally, for
the field 2.127 ‘Days of the week’ it is possible to report multiple values, e.g. MOND, TUED (Mo-Tu) or WDAY, XBHL (weekdays excluding bank holidays) or other combinations.
4.9.1 Electricity future
482. Table 41 shows an example of a peak load future on the price of electricity in
the Spanish wholesale market. The contract is negotiated in MWh/h and the delivery should take place in Q2 2022 for a 100 MWh at 58 euros.
Table 41- Reporting of a peak-load electricity future
No Field Example XML message
116 Base product NRGY <Cmmdty>
<Ngry>
<Elctrcty>
<BasePdct>NRGY</BasePdct>
<SubPdct>ELEC</SubPdct>
<AddtlSubPdct>PKLD
</AddtlSubPdct>
</Elctrcty>
</Ngry>
</Cmmdty>
<NrgySpcfcAttrbts>
<DlvryPtOrZone>
<Cd>10YES-REE------0</Cd>
</DlvryPtOrZone>
<IntrCnnctnPt>
<Cd>XXXXXXXXXXXXXXXX</Cd>
</IntrCnnctnPt>
<LdTp>PKLD</LdTp>
<DlvryAttr>

151
Table 41- Reporting of a peak-load electricity future
No Field Example XML message
<DlvryIntrvl>
<FrTm>08:00:00Z</FrTm>
<ToTm>19:59:59Z</ToTm>
</DlvryIntrvl>
<DlvryDt>
<FrDt>2022-04-01</FrDt>
<ToDt>2022-06-30</ToDt>
</DlvryDt>
<Drtn>QURT</Drtn>
<WkDay>WDAY</WkDay>
<DlvryCpcty>
<Qty>100</Qty>
</DlvryCpcty>
<QtyUnit>
<Cd>MWHH</Cd>
</QtyUnit>
<PricTmIntrvlQty>
<Amt Ccy="EUR">58</Amt>
</PricTmIntrvlQty>
</DlvryAttr>
</NrgySpcfcAttrbts>
117 Sub-product ELEC
118 Further subproduct
PKLD
119 Delivery point or zone
10YES-REE------0
120 Interconnection point
XXXXXXXXXXXXXXXX
121 Load type PKLD
122 Delivery interval start time
08:00:00Z
123 Delivery interval end time
19:59:59Z
124 Delivery start date
2022-04-01
125 Delivery end date
2022-06-30

152
Table 41- Reporting of a peak-load electricity future
No Field Example XML message
126 Duration QURT
127 Days of the week
WDAY
128 Delivery capacity
100
129 Quantity unit MWHH
130 Price/time interval quantity
58
131 Currency of the price/time interval quantity EUR 5 EMIR Tables of fields
483. Article 1(1) of the RTS on reporting provides that “Reports to trade repositories
made pursuant to Article 9 of Regulation (EU) No 648/2012 shall include the complete and accurate details set out in Tables 1, 2 and 3 of the Annex that pertain to the derivative concerned.” The use cases included in sections 5.1, 5.2, and 5.3 do not necessarily include all the fields that pertain to the derivative concerned, but they focus on specific sections of data fields in order to provide more granular and detailed guidance on the reporting without any unnecessary repetition or inclusion of other data elements.
484. The validation rules contain the complete guidance on applicable fields per
action type and level, as well as the relevant dependencies.
485. The following sections include various scenarios and corresponding tables
clarifying how these scenarios should be reported. Each table shows the reporting fields under the ITS on reporting. The column ‘Field’ shows each field name, and the column ‘Example’ provides an example of what would be included in that field. The final column entitled ‘XML Message’ shows the format of the XML message which should be submitted in the report.
486. Unless otherwise stated in the specific scenario, the following background
information applies to all scenarios set out in section 6:
Counterparty A is a German financial counterparty identified with LEI 12345678901234500000

153
Counterparty B is an Italian financial counterparty identified with LEI ABCDEFGHIJKLMNOPQRST Counterparty C is a Spanish NFC- identified with LEI 123456789ABCDEFGHIJK Counterparty D is a French NFC+ identified with LEI 11223344556677889900 Counterparty J acts also as a clearing member and is identified with LEI CCCCCCCCCCCCCCCCCCCC CCP O is identified with LEI BBBBBBBBBB1111111111
5.1 Table 1 Counterparty data
487. This section of the Guidelines details the population of the counterparty data
section for several different use cases. The actual reporting in accordance with the
ISO 20022 XML schemas is provided too.
488. When a derivative is cleared, each counterparty should report in the ‘Clearing
member’ field its clearing member.
489. When a voluntary delegation of reporting or allocation of responsibility exists,
the report submitting entity or entity responsible for reporting should submit separately the counterparty data, the contract data and collateral data for each of the two sides reported.
490. When there are use cases that cover two or more of the use cases included
below, the reporting counterparties, the entities responsible for reporting or the report submitting entities should include all the relevant details based on the below guidance.
Table 42
Use Cases
Cleared Option between FCs (ETD)
Cleared Option between FCs with voluntary delegation agreement (ETD) Non-Cleared Option between FCs OTC Option between NFC - and FC OTC Option between NFC - and NFC + OTC Contract type between FCs which requires the population of fields ‘Direction of Leg 1’ and ‘Direction of Leg 2’
5.1.1 Cleared Option between FCs (ETD)
491. Table 43 illustrates reporting of an ETD cleared option where the counterparty
1 (counterparty A with LEI 12345678901234500000) is a German Financial Counterparty above the clearing thresholds, submit its own report (i.e. there is no separate report submitting entity) and is the entity responsible for reporting. The

154 option is concluded with the counterparty 2 (counterparty B with LEI ABCDEFGHIJKLMNOPQRST) which is an Italian Financial Counterparty above the clearing threshold. Counterparty A accesses the CCP via clearing member J (counterparty J with LEI CCCCCCCCCCCCCCCCCCCC).
492. It should be noted that ‘Central counterparty’ field pertains to Table 2, and hence
its population is covered in section 5.2.
Table 43 - Cleared Option between FCs (ETD)
No Field Example Xml message
1
Reporting timestamp
2021-03-
17T15:17:00Z
<CtrPtySpcfcData>
<CtrPrty>
<RptgCtrPty>
<Id>
<Lgl><LEI>
12345678901234500000
</LEI></Lgl>
</Id>
<Ntr>
<FI>
<Sctr>
<Cd>CDTI</Cd>
</Sctr>
<ClrThrshld>true
</ClrThrshld>
</FI>
</Ntr>
<DrctnOrSd>
<Drctn>
<CtrPtySd>BYER
</CtrPtySd
</Drctn>
</DrctnOrSd>
</RptgCtrPty>
<OthrCtrPty>
<Id>
<Lgl><LEI>
ABCDEFGHIJKLMNOPQRST
</LEI></Lgl>
</Id>
<Ntr>
<FI>
<Sctr>
<Cd>CDTI</Cd>
</Sctr>
<ClrThrshld>true
</ClrThrshld>
</FI>
</Ntr>
<RptgOblgtn>true
</RptgOblgtn>
</OthrCtrPty>
2
Report submitting entity ID 12345678901234500000 3 Entity responsible for reporting 12345678901234500000 4 Counterparty 1 (Reporting counterparty) 12345678901234500000 5 Nature of the counterparty 1 F 6 Corporate sector of the counterparty 1 CDTI 7 Clearing threshold of counterparty 1 TRUE 8 Counterparty 2 identifier type TRUE 9 Counterparty 2 ABCDEFGHIJKLMNOPQRST 10 Country of the counterparty 2 11 Nature of the counterparty 2 F 12 Corporate sector of the counterparty 2 CDTI 13 Clearing threshold of counterparty 2 TRUE

155
Table 43 - Cleared Option between FCs (ETD)
No Field Example Xml message
14
Reporting obligation of the counterparty 2 TRUE <SubmitgAgt> <LEI> 12345678901234500000 </LEI> </SubmitgAgt> <NttyRspnsblForRpt> <LEI> 12345678901234500000 </LEI> </NttyRspnsblForRpt> <ClrMmb> <Lgl><LEI> CCCCCCCCCCCCCCCCCCCC </LEI></Lgl> </ClrMmb> </CtrPrty> <RptgTmStmp>2020-05-19T 14:23:26Z</RptgTmStmp> </CtrPtySpcfcData> 15 Broker ID 16 Clearing member CCCCCCCCCCCCCCCCCCC C 17 Direction BYER 18 Direction of leg 1 19 Direction of leg 2 20 Directly linked to commercial activity or treasury financing
5.1.2 Cleared Option between FCs with voluntary delegation agreement (ETD)
493. Table 44 illustrates reporting of an ETD cleared option where the counterparty
1 (counterparty A with LEI 12345678901234500000) is a German Financial Counterparty above the clearing thresholds, is the entity responsible for reporting but delegates its reporting to the other counterparty (counterparty B with LEI ABCDEFGHIJKLMNOPQRST). The option is concluded with the counterparty 2 (counterparty B) which is an Italian Financial Counterparty above the clearing threshold.
494. Counterparty A accesses the CCP via clearing member J (counterparty J with
LEI CCCCCCCCCCCCCCCCCCCC).
495. It should be noted that ‘Central counterparty’ field pertains to Table 2, and hence
its population is covered in section 5.2.
Table 44 - Cleared Option between FCs with voluntary delegation agreement (ETD)
No Field Example Xml message
1 Reporting timestamp
2021-03-
17T15:17:00Z <CtrPtySpcfcData>
<CtrPty>
<RptgCtrPty>
<Id>
<Lgl><LEI>

12345678901234500000
</LEI></Lgl>
2 Report submitting entity ID
ABCDEFGHIJKLMNOPQRST
3 Entity responsible for reporting
12345678901234500000

156
Table 44 - Cleared Option between FCs with voluntary delegation agreement (ETD)
No Field Example Xml message
4 Counterparty 1
(Reporting counterparty)
12345678901234500000 </Id>
<Ntr>
<FI>
<Sctr>
<Cd>CDTI</Cd>
</Sctr>
<ClrThrshld>true
</ClrThrshld>
</FI>
</Ntr>
<DrctnOrSd>
<Drctn>
<CtrPtySd>BYER
</CtrPtySd
</Drctn>
</DrctnOrSd>
</RptgCtrPty>
<OthrCtrPty>
<IdTp>
<Lgl>
<LEI>

ABCDEFGHIJKLMNOPQRST
</LEI>
</Lgl>
</IdTp>
<Ntr>
<FI>
<Sctr>
<Cd>CDTI</Cd>
</Sctr>
<ClrThrshld>true
</ClrThrshld>
</FI>
</Ntr>
<RptOblgtn>true
</RptOblgtn>
</OthrCtrPty>
<SubmitgAgt>
<LEI>
ABCDEFGHIJKLMNOPQRST
</LEI>
</SubmitgAgt>
<NttyRspnsblForRpt>
<LEI>
12345678901234500000
</LEI>
</NttyRspnsblForRpt>
<ClrMmb>
<LEI>
CCCCCCCCCCCCCCCCCCCC
</LEI>
</ClrMmb>
</CtrPty>
<RptgTmStmp>
5 Nature of the counterparty 1
F
6 Corporate sector of the counterparty 1
CDTI
7 Clearing threshold of counterparty 1
TRUE
8 Counterparty 2 identifier type
TRUE
9 Counterparty 2 ABCDEFGHIJKLMNOPQRST
10 Country of the counterparty 2
11 Nature of the counterparty 2
F
12 Corporate sector of the counterparty 2
CDTI
13 Clearing threshold of counterparty 2
TRUE
14 Reporting obligation of the counterparty 2 TRUE 15 Broker ID 16 Clearing member CCCCCCCCCCCCCCCCCCCC 17 Direction BYER 18 Direction of leg 1 19 Direction of leg 2 20 Directly linked to commercial activity or treasury financing

157
Table 44 - Cleared Option between FCs with voluntary delegation agreement (ETD)
No Field Example Xml message
2021-03-17T15:17:00Z
</RptgTmStmp>
</CtrPtySpcfcData>
5.1.3 Non-Cleared Option between FCs
496. Table 45 illustrates reporting of a non cleared option where the counterparty 1
(counterparty A with LEI 12345678901234500000) is a German Financial Counterparty above the clearing thresholds, is the entity responsible for reporting and report its own report. The option is concluded with the counterparty 2 (counterparty B with LEI ABCDEFGHIJKLMNOPQRST) which is an Italian Financial Counterparty above the clearing threshold.
Table 45 – Non cleared option between FCs
No Field Example Xml message
1 Reporting timestamp
2021-03-
17T15:17:00Z
<CtrPtySpcfcData>
<CtrPty>
<RptgCtrPty>
<Id>
<Lgl><LEI>
12345678901234500000
</LEI></Lgl>
</Id>
<Ntr>
<FI><Sctr>
<Cd>CDTI</Cd>
</Sctr>
<ClrThrshld>true
</ClrThrshld></FI>
</Ntr>
<DrctnOrSd>
<Drctn>
<CtrPtySd>BYER
</CtrPtySd
</Drctn>
</DrctnOrSd>
</RptgCtrPty>
<OthrCtrPty>
<IdTp>
<Lgl>
<LEI>
ABCDEFGHIJKLMNOPQRST
2
Report submitting entity ID 12345678901234500000 3 Entity responsible for reporting 12345678901234500000 4 Counterparty 1 (Reporting counterparty) 12345678901234500000 5 Nature of the counterparty 1 F

158
Table 45 – Non cleared option between FCs
No Field Example Xml message
6
Corporate sector of the counterparty 1 CDTI </LEI> </Lgl> </IdTp> <Ntr> <FI><Sctr> <Cd>CDTI</Cd> </Sctr> <ClrThrshld>true </ClrThrshld></FI> </Ntr> <RptOblgtn>true </RptOblgtn> </OthrCtrPty> <SubmitgAgt> <LEI> 12345678901234500000 </LEI> </SubmitgAgt> <NttyRspnsblForRpt> <LEI> 12345678901234500000 </LEI> </NttyRspnsblForRpt> </CtrPty> <RptgTmStmp> 2021-03-17T15:17:00Z </RptgTmStmp> </CtrPtySpcfcData> 7 Clearing threshold of counterparty 1 TRUE 8 Counterparty 2 identifier type TRUE 9 Counterparty 2 ABCDEFGHIJKLMNOPQ RST 10 Country of the counterparty 2 11 Nature of the counterparty 2 F 12 Corporate sector of the counterparty 2 CDTI 13 Clearing threshold of counterparty 2 TRUE 14 Reporting obligation of the counterparty 2 TRUE 15 Broker ID 16 Clearing member

159
Table 45 – Non cleared option between FCs
No Field Example Xml message
17 Direction BYER
18 Direction of leg 1
19 Direction of leg 2
20
Directly linked to commercial activity or treasury financing
5.1.4 OTC Option between NFC - and FC
497. Table 46 illustrates reporting of OTC option where the counterparty 1
(counterparty C with LEI 123456789ABCDEFGHIJK) is a Spanish Non-Financial Counterparty below the clearing thresholds. The option is concluded with the counterparty 2 (counterparty A with LEI 12345678901234500000) which is a German Financial Counterparty above the clearing threshold. In this case the counterparty A is entity responsible for reporting and the report submitting entity in accordance with the provisions on allocation of responsibility for reporting.
Table 46 – OTC between NFC- and FC
No Field Example Xml message
1 Reporting timestamp
2021-03-
17T15:17:00Z
<CtrPtySpcfcData>
<CtrPty>
<RptgCtrPty>
<Id>
<Lgl><LEI>
123456789ABCDEFGHIJK
</LEI></Lgl>
</Id>
<Ntr>
<NFI><Sctr><Id>K
</Id></Sctr>
<ClrThrshld>false
</ClrThrshld>
<DrctlyLkdActvty> false
</DrctlyLkdActvty>
</NFI>
2
Report submitting entity
ID
123456789012345000
00
3
Entity responsible for reporting
123456789012345000
00
4
Counterparty 1 (Reporting counterparty)
123456789ABCDEFG
HIJK
5
Nature of the counterparty
1
N

160
Table 46 – OTC between NFC- and FC
No Field Example Xml message
6
Corporate sector of the counterparty 1 K
</Ntr>
<DrctnOrSd>
<Drctn>
<CtrPtySd>BYER
</CtrPtySd
</Drctn>
</DrctnOrSd>
</RptgCtrPty>
<OthrCtrPty>
<IdTp>
<Lgl>
<LEI>
12345678901234500000
</LEI>
</Lgl>
</IdTp>
<Ntr>
<FI><Sctr><Cd>CDTI
</Cd></Sctr>
<ClrThrshld>true
</ClrThrshld></FI>
</Ntr>
<RptOblgtn>true
</RptOblgtn>
</OthrCtrPty>
<SubmitgAgt>
<LEI>
12345678901234500000
</LEI>
</SubmitgAgt>
<NttyRspnsblForRpt>
<LEI>
12345678901234500000
</LEI>
</NttyRspnsblForRpt>
</CtrPty>
<RptgTmStmp>
2021-03-17T15:17:00Z
</RptgTmStmp>
</CtrPtySpcfcData>
…
<Lvl>TCTN</Lvl>
7
Clearing threshold of counterparty 1 FALSE 8 Counterparty 2 identifier type TRUE 9 Counterparty 2 123456789012345000 00 10 Country of the counterparty 2 11 Nature of the counterparty 2 F 12 Corporate sector of the counterparty 2 CDTI 13 Clearing threshold of counterparty 2 TRUE 14 Reporting obligation of the counterparty 2 TRUE 15 Broker ID 16 Clearing member - 17 Direction BYER 18 Direction of leg 1 19 Direction of leg 2 20 Directly linked to commercial activity or treasury financing FALSE 15 4 Level TCTN
5.1.5 OTC Option between NFC - and NFC +
498. Table 47 illustrates reporting of OTC option where the counterparty 1
(counterparty C with LEI 123456789ABCDEFGHIJK) is a Spanish Non-Financial Counterparty below the clearing thresholds. The option is concluded with the counterparty 2 (counterparty D with LEI 11223344556677889900) which is a

161
French Non-Financial Counterparty above the clearing threshold. Counterparty C is the entity responsible for reporting and the report submitting entity.
Table 47 – OTC between NFC- and NFC+
No Field Example Xml message
1
Reporting timestamp
2021-03-
17T15:17:00Z
<CtrPtySpcfcData>
<CtrPty>
<RptgCtrPty>
<Id>
<Lgl><LEI>
123456789ABCDEFGHIJK
</LEI></Lgl>
</Id>
<Ntr>
<NFI><Sctr><Id>K
</Id></Sctr>
<ClrThrshld>false
</ClrThrshld>
<DrctlyLkdActvty> false
</DrctlyLkdActvty>
</NFI>
</Ntr>
<DrctnOrSd>
<Drctn>
<CtrPtySd>BYER
</CtrPtySd
</Drctn>
</DrctnOrSd>
</RptgCtrPty>
<OthrCtrPty>
<IdTp>
<Lgl>
<LEI>
ABCDEFGHIJKLMNOPQRST
</LEI>
</Lgl>
</IdTp>
<Ntr>
<NFI><Sctr><Id>L
</Id></Sctr>
<ClrThrshld>true
</ClrThrshld>
</NFI>
</Ntr>
<RptOblgtn>true
</RptOblgtn>
</OthrCtrPty>
<SubmitgAgt>
<LEI>
123456789ABCDEFGHIJK
</LEI>
</SubmitgAgt>
<NttyRspnsblForRpt>
<LEI>
123456789ABCDEFGHIJK
2
Report submitting entity ID
123456789ABCDEFGHIJK
3
Entity responsible for reporting
123456789ABCDEFGHIJK
4
Counterparty 1
(Reporting counterparty)
123456789ABCDEFGHIJK
5
Nature of the counterparty 1 N
6
Corporate sector of the counterparty 1
K
7
Clearing threshold of counterparty 1
FALSE
8
Counterparty 2 identifier type TRUE
9 Counterparty 2 11223344556677889900
10 Country of the counterparty 2
11 Nature of the counterparty 2 N
12
Corporate sector of the counterparty 2
L
13
Clearing threshold of counterparty 2
TRUE
14
Reporting obligation of the counterparty 2 TRUE 15 Broker ID 16 Clearing member 17 Direction BYER 18 Direction of leg 1

162
Table 47 – OTC between NFC- and NFC+
No Field Example Xml message
19 Direction of leg
2
</LEI>
</NttyRspnsblForRpt>
</CtrPty>
<RptgTmStmp>
2021-03-17T15:17:00Z
</RptgTmStmp>
</CtrPtySpcfcData>
…
<Lvl>TCTN</Lvl>
20
Directly linked to commercial activity or treasury financing FALSE 154 Level TCTN
5.1.6 OTC Contract type which requires the population of fields ‘Direction of Leg 1’
and ‘Direction of Leg 2’ between FCs
499. Table 48 illustrates reporting of an OTC Contract type which requires the
population of fields ‘Direction of Leg 1’ and ‘Direction of Leg 2’ where the counterparty 1 (counterparty A with LEI 12345678901234500000) is a German Financial Counterparty above the clearing thresholds. The contract is concluded with the counterparty 2 (counterparty B with LEI ABCDEFGHIJKLMNOPQRST) which is an Italian Financial Counterparty above the clearing threshold.
Table 48 - OTC Contract type which requires the population of fields Direction of Leg
1 and Direction of Leg 2 between FCs
No Field Example Xml message
1
Reporting timestamp
2021-03-
17T15:17:00Z
<<CtrPtySpcfcData>
<CtrPty>
<RptgCtrPty>
<Id>
<Lgl><LEI>
12345678901234500000
</LEI></Lgl>
</Id>
<Ntr>
<FI><Sctr><Cd>CDTI</Cd>
</Sctr><ClrThrshld>true
</ClrThrshld></FI>
</Ntr>
<DrctnOrSd><Drctn>
<DrctnOfTheFrstLeg>MAKE

</DrctnOfTheFrstLeg>

<DrctnOfTheScndLeg>TAKE
</DrctnOfTheScndLeg>
</Drctn></DrctnOrSd>
2
Report submitting entity ID
12345678901234500000
3
Entity responsible for reporting
12345678901234500000
4
Counterparty 1
(Reporting counterparty)
12345678901234500000
5
Nature of the counterparty 1 F

163
Table 48 - OTC Contract type which requires the population of fields Direction of Leg
1 and Direction of Leg 2 between FCs
No Field Example Xml message
6
Corporate sector of the counterparty 1
CDTI
</RptgCtrPty>
<OthrCtrPty>
<IdTp>
<Lgl>
<LEI>
ABCDEFGHIJKLMNOPQRST
</LEI>
</Lgl>
</IdTp>
<Ntr>
<FI><Sctr><Cd>CDTI</Cd>
</Sctr><ClrThrshld>true
</ClrThrshld></FI>
</Ntr>
<RptOblgtn>true
</RptOblgtn>
</OthrCtrPty>
<SubmitgAgt>
<LEI>
12345678901234500000
</LEI>
</SubmitgAgt>
<NttyRspnsblForRpt>
<LEI>
12345678901234500000
</LEI>
</NttyRspnsblForRpt>
</CtrPty>
<RptgTmStmp>
2021-03-17T15:17:00Z
</RptgTmStmp>
</CtrPtySpcfcData>
7
Clearing threshold of counterparty 1
TRUE
8
Counterparty 2 identifier type TRUE
9 Counterparty 2 ABCDEFGHIJKLMNOPQRST
10 Country of the counterparty 2
11 Nature of the counterparty 2 F
12
Corporate sector of the counterparty 2
CDTI
13
Clearing threshold of counterparty 2
TRUE
14
Reporting obligation of the counterparty 2 TRUE 15 Broker ID 16 Clearing member 17 Direction - 18 Direction of leg 1 MAKE 19 Direction of leg 2 TAKE 20 Directly linked to commercial activity or treasury financing

164
5.2 Table 2 Common data
500. Following the population of the counterparty data fields, the population of the
common data fields for different use cases is included. The reporting in accordance with the ISO 20022 XML schemas is provided too.
501. Each of the subsections includes a short description of the reporting logic for
the relevant fields.
5.2.1 Reporting of action types at trade and position level
502. This subsection illustrates population of relevant fields to report lifecycle events.
5.2.1.1 New bilateral derivative at trade level that is not cleared
503. Table 49 illustrates the population of the reporting fields in case of a new
derivative, which is not cleared. This is how the derivatives that are bilateral should be reported, at trade level.
Table 49 - New derivative at trade level that is not cleared
No Field Example XML Message
2.1 UTI UTI1 <New>
…
<TxData>
<TxId>
<UnqTxIdr>
UTI1
</UnqTxIdr>
</TxId>
…
<DerivEvt>
<Tp>TRAD</Tp>
</DerivEvt>
…
<TradClr>
<ClrSts>
<NonClrd>
<Rsn>NORE</Rsn>
</NonClrd>
</ClrSts>
</TradClr>
</TxData>
…
<Lvl>TCTN</Lvl>
</New>
2.31 Cleared N
2.151 Action type NEWT
2.152 Event type TRAD
2.154 Level TCTN

165
5.2.1.2 New bilateral derivative at trade level that is cleared on the same day or after
504. Table 50, Table 51 and Table 52 illustrate the population of the reporting fields
by a counterparty in case a new derivative is concluded bilaterally and cleared afterwards on the same day or after. Counterparties should submit a derivative report with action type ‘Terminate’ and event type ‘Clearing’ to indicate the termination of the trade reported as uncleared. Afterwards the counterparty should submit a derivative report with action type ‘New’ and event type ‘Clearing’ to indicate that the derivative has been cleared. The counterparty should provide ‘Prior UTI’ in this last report. The sequence of the submissions is illustrated in the below tables.
Table 50 - New bilateral derivative at trade level that is cleared on the same
day or after
No Field Example XML Message
2.1 UTI UTI1 <New>
…
<TxData>
<TxId>
<UnqTxIdr>
UTI1
</UnqTxIdr>
</TxId>
…
<DerivEvt>
<Tp>TRAD</Tp>
</DerivEvt>
…
<TradClr>
<ClrSts>
<NonClrd>
<Rsn>NORE</Rsn>
</NonClrd>
</ClrSts>
</TradClr>
</TxData>
…
<Lvl>TCTN</Lvl>
</New>
2.31 Cleared N
2.151 Action type NEWT
2.152 Event type TRAD
2.154 Level TCTN
Table 51 - Termination of the bilateral derivative at trade level due to clearing
on the same day or after
No Field Example XML Message
2.1 UTI UTI1 <Termntn>
…

166
Table 51 - Termination of the bilateral derivative at trade level due to clearing
on the same day or after
No Field Example XML Message
2.151 Action type TERM <TxData>
<TxId>
<UnqTxIdr>
UTI1
</UnqTxIdr>
</TxId>
…
<DerivEvt>
<Tp>CLRG</Tp>
</DerivEvt>
…
</TxData>
…
<Lvl>TCTN</Lvl>
</Termntn>
2.152 Event type CLRG
2.154 Level TCTN
Table 52 - New cleared derivative at trade level resulting from clearing of a
bilateral derivative on the same day or after No Field Example XML Message
2.1 UTI UTI2 <New>
…
<TxData>
<TxId>
<UnqTxIdr>
UTI2
</UnqTxIdr>
</TxId>
<PrrTxId>
<UnqTxIdr>
UTI1
</UnqTxIdr>
</PrrTxId>
…
<DerivEvt>
<Tp>CLRG</Tp>
</DerivEvt>
…
<TradClr>
<ClrSts>
<Clrd>
…
</Clrd>
</ClrSts>
</TradClr>
2.3 Prior UTI UTI1
2.31 Cleared Y
2.151 Action type NEWT
2.152 Event type CLRG
2.154 Level TCTN

167
Table 52 - New cleared derivative at trade level resulting from clearing of a
bilateral derivative on the same day or after No Field Example XML Message </TxData> … <Lvl>TCTN</Lvl> </New>
505. Note that Table 50 and Table 51 report is not expected if the trade is concluded
on a trading venue and cleared by a CCP on the same day, only Table 52 report is expected in such case (without ‘Prior UTI’ field). Furthermore, Table 52 illustrates the reporting in the case where a cleared derivative is not included immediately in a position (in which case it would be reported with action type POSC as clarified in the subsequent examples).
5.2.1.3 New bilateral derivative at trade level that is cleared on the same day or after and
immediately included in the position
506. Table 53, 54, 55 and 56 illustrate the population of the reporting fields by a
counterparty in case of a new derivative is concluded bilaterally, cleared afterwards on the same day or after and immediately included into a position. Counterparties should submit a derivative report with action type ‘Terminate’ and event type ‘Clearing to indicate the termination of the trade which is cleared. Subsequently, they should report that cleared derivative, which is immediately included into a position, with action type ‘Position component’. In the context of the examples for derivatives at position level, these are identified with Unique Trade Identifier (UTI) of the position, ‘PUTI1’. Position UTI should also be reported in the field ‘Subsequent position UTI’ in the derivative at trade level that is included in the position so that the reports can be linked. Afterwards the counterparty should submit a derivative report with action type ‘Modify’ to indicate that the respective derivative at position level has been updated due to an inclusion of a trade. The sequence of the submissions is illustrated in the below tables.
Table 53 - New bilateral derivative at trade level that is cleared on the same
day or after
No Field Example XML Message
2.1 UTI UTI1 <New>
…
<TxData>
<TxId>
<UnqTxIdr>
UTI1
</UnqTxIdr>
2.31 Cleared N
2.151 Action type NEWT

168
Table 53 - New bilateral derivative at trade level that is cleared on the same
day or after
No Field Example XML Message
2.152 Event type TRAD </TxId>
…
<DerivEvt>
<Tp>TRAD</Tp>
</DerivEvt>
…
<TradClr>
<ClrSts>
<NonClrd>
<Rsn>NORE</Rsn>
</NonClrd>
</ClrSts>
</TradClr>
</TxData>
…
<Lvl>TCTN</Lvl>
</New>
2.154 Level TCTN
Table 54 - Termination of the bilateral derivative at trade level due to clearing
on the same day or after
No Field Example XML Message
2.1 UTI UTI1 <Termntn>
…
<TxData>
<TxId>
<UnqTxIdr>
UTI1
</UnqTxIdr>
</TxId>
…
<DerivEvt>
<Tp>CLRG</Tp>
</DerivEvt>
…
</TxData>
…
<Lvl>TCTN</Lvl>
</Termntn>
2.151 Action type TERM
2.152 Event type CLRG
2.154 Level TCTN

169
TABLE 55- NEW CLEARED DERIVATIVE WHICH IS INCLUDED IMMEDIATELY INTO A
POSITION
No Field Example XML Message
2.1 UTI UTI2 <PosCmpnt>
…
<TxData>
<TxId>
<UnqTxIdr>
UTI2
</UnqTxIdr>
</TxId>
<PrrTxId>
<UnqTxIdr>
UTI1
</UnqTxIdr>
</PrrTxId>
<SbsqntTxId>
<UnqTxIdr>
PUTI1
</UnqTxIdr>
</SbsqntTxId>
…
<TradClr>
<ClrSts>
<Clrd>
…
</Clrd>
</ClrSts>
</TradClr>
</TxData>
…
<Lvl>TCTN</Lvl>
</PosCmpnt>
2.3 Prior UTI UTI 1
2.4 Subsequent
position UTI
PUTI1
2.31 Cleared Y
2.151 Action type POSC
2.152 Event type
2.154 Level TCTN
Table 56 – Modification of a derivative at position level resulting from the
inclusion of a trade
No Field Example XML Message
2.1 UTI PUTI1 <Mod>
…
<TxData>
<TxId>
<UnqTxIdr>
PUTI1
</UnqTxIdr>
2.31 Cleared Y
2.151 Action type MODI

170
Table 56 – Modification of a derivative at position level resulting from the
inclusion of a trade
No Field Example XML Message
2.152 Event type INCP </TxId>
…
<DerivEvt>
<Tp>INCP</Tp>
</DerivEvt>
…
<TradClr>
<ClrSts>
<Clrd>
…
</Clrd>
</ClrSts>
</TradClr>
</TxData>
…
<Lvl>PSTN</Lvl>
</Mod>
2.154 Level PSTN
5.2.1.4 New derivative concluded on a trading venue and cleared on the same day,
reported as position component
507. Table 57 and Table 58 illustrate the population of the reporting fields in case of
a new derivative that is concluded on a trading venue or an organized trading platform and cleared by a central counterparty on the same day as well as included in a position on that same day. In particular, only the derivative in its cleared form should be reported. In the context of the examples for derivatives at position level, these are identified with Unique Trade Identifier (UTI) of the position, ‘PUTI1’. Position UTI should also be reported in the field ‘Subsequent position UTI’ in the derivative at trade level that is included in the position so that the reports can be linked.
Table 57 - New derivative concluded on a trading venue and cleared by a CCP
on the same day and reported with position component at trade level No Field Example XML Message
2.1 UTI UTI1 <PosCmpnt>
…
<TxData>
<TxId>
<UnqTxIdr>
2.4 Subsequent
position UTI
PUTI2

171
Table 57 - New derivative concluded on a trading venue and cleared by a CCP
on the same day and reported with position component at trade level No Field Example XML Message
2.31 Cleared Y UTI1
</UnqTxIdr>
</TxId>
<SbsqntTxId>
<UnqTxIdr>
PUTI2
</UnqTxIdr>
</SbsqntTxId>
…
<TradClr>
<ClrSts>
<Clrd>
…
</Clrd>
</ClrSts>
</TradClr>
</TxData>
…
<Lvl>TCTN</Lvl>
</PosCmpnt>
2.151 Action type POSC
2.152 Event type
2.154 Level TCTN
Table 58 - New derivative reported at position level
No Field Example XML Message
2.1 UTI PUTI2 <New>
…
<TxData>
<TxId>
<UnqTxIdr>
PUTI2
</UnqTxIdr>
</TxId>
…
<DerivEvt>
<Tp>INCP</Tp>
</DerivEvt>
…
<TradClr>
<ClrSts>
<Clrd>
…
2.31 Cleared Y
2.151 Action type NEWT25
2.152 Event type INCP
2.154 Level PSTN
25 In this example a new position is created. In the case where a cleared transaction is included in an existing position, it would be reported as modification of that position (with action type MODI) as in the example…

172
Table 58 - New derivative reported at position level
No Field Example XML Message
</Clrd>
</ClrSts>
</TradClr>
</TxData>
…
<Lvl>PSTN</Lvl>
</New>
5.2.1.5 Modification of a derivative at position level due to inclusion of a new derivative
into the position
508. This example illustrates how to report modification of a position when a new
derivative at trade level is included in that position.
Table 59 - Modification of a derivative at position level
No Field Example XML Message
2.1 UTI PUTI1 <Mod>
…
<TxData>
<TxId>
<UnqTxIdr>
PUTI1
</UnqTxIdr>
</TxId>
…
<DerivEvt>
<Tp>INCP</Tp>
</DerivEvt>
…
</TxData>
…
<Lvl>PSTN</Lvl>
</Mod>
2.151 Action type MODI
2.152 Event type INCP
2.154 Level PSTN
5.2.1.6 Modification of a derivative at position level due to multiple lifecycle events
509. This example illustrates how to report modification of a derivative at position
level, when the position is impacted by several events during the day and it is not possible to specify the event type due to which the modification occured.

173
Table 60 - Modification of a derivative at position level
No Field Example XML Message
2.1 UTI PUTI1 <Mod>
…
<TxData>
<TxId>
<UnqTxIdr>
PUTI1
</UnqTxIdr>
</TxId>
…
</TxData>
…
<Lvl>PSTN</Lvl>
</Mod>
2.151 Action type MODI
2.152 Event type
2.154 Level PSTN
5.2.1.7 Modification of a derivative at trade level
510. Table 61 illustrates the population of the reporting fields in case a previously
reported derivative at trade level is modified following to the counterparties’ agreement to amend certain terms of the derivative.
Table 61 - Modification of a derivative at trade level
No Field Example XML Message
2.1 UTI UTI1 <Mod>
…
<TxData>
<TxId>
<UnqTxIdr>
UTI1
</UnqTxIdr>
</TxId>
…
<DerivEvt>
<Tp>TRAD</Tp>
</DerivEvt>
…
</TxData>
…
<Lvl>TCTN</Lvl>
</Mod>
2.151 Action type MODI
2.152 Event type TRAD
2.154 Level TCTN

174
5.2.1.8 Correction of a derivative at trade level
511. Table 62 illustrates the population of the reporting fields when there is a
correction of data fields that were submitted wrongly in a previous report of a derivative at trade level.
Table 62 - Correction of a derivative at trade level
No Field Example XML Message
2.1 UTI UTI1 <Crrctn>
…
<TxData>
<TxId>
<UnqTxIdr>
UTI1
</UnqTxIdr>
</TxId>
…
</TxData>
…
<Lvl>TCTN</Lvl>
</Crrctn>
2.151 Action type CORR
2.152 Event type
2.154 Level TCTN
5.2.1.9 Correction of the valuation of a derivative at trade level
512. Table 63 illustrates the population of the reporting fields when there is a
correction of data fields pertaining to the valuation that were submitted wrongly in a previous report of a derivative at trade level. Please note that the population of the valuation fields is shown in a separate example in section 5.2.2.3.
Table 63 - Correction of a derivative at trade level
No Field Example XML Message
2.1 UTI UTI1 <Crrctn>
…
<TxData>
<TxId>
<UnqTxIdr>
UTI1
</UnqTxIdr>
</TxId>
…
</TxData>
…
<Lvl>TCTN</Lvl>
</Crrctn>
2.151 Action type CORR
2.152 Event type
2.154 Level TCTN

175
5.2.1.10 Valuation of a derivative at trade level
513. Table 64 illustrates the population of the reporting fields when the counterparty
submits a daily valuation update for a previously reported derivative at trade level. Please note that the population of the valuation fields is shown in a separate example in section 5.2.2.3.
Table 64 - Valuation of a derivative at trade level
No Field Example XML Message
2.1 UTI UTI1 <ValtnUpd>
…
<TxData>
<TxId>
<UnqTxIdr>
UTI1
</UnqTxIdr>
</TxId>
…
</TxData>
…
<Lvl>TCTN</Lvl>
</ValtnUpd>
2.151 Action type VALU
2.152 Event type
2.154 Level TCTN
5.2.1.11 Reporting of margin update for a derivative collateralized at trade level
514. Table 65 illustrates the population of the reporting fields when the counterparty
submits a daily margin update for a previously reported derivative at trade level and that derivative is individually collateralized. Please note that the population of the margin fields is shown in separate examples in section 5.3.
Table 65 - Margin update for a trade-level derivative collateralized at trade level
No Field Example XML Message
3.8 Collateral
portfolio indicator
FALSE <MrgnUpd>
…
<TxId>
<UnqTxIdr>
UTI1
</UnqTxIdr>
</TxId>
<Coll>
<CollPrtflCd>
<Prtfl>
<NoPrtfl>
NOAP
</NoPrtfl>
3.9 Collateral
portfolio code
3.10 UTI UTI1
3.28 Action type MARU

176
Table 65 - Margin update for a trade-level derivative collateralized at trade level
No Field Example XML Message
</Prtfl>
</CollPrtflCd>
…
<MrgnUpd>
5.2.1.12 Reporting of margin update for a derivative collateralized at portfolio level
515. Table 66 illustrates the population of the reporting fields when the counterparty
submits a daily margin update in case of a collateralisation at portfolio level. Please note that the population of the margin fields is shown in separate examples in
section 5.3.
Table 66 - Margin update for a trade-level derivative collateralized at portfolio
level
No Field Example XML Message
3.8 Collateral
portfolio indicator
TRUE <MrgnUpd>
…
<Coll>
<CollPrtflCd>
<Prtfl>
<Cd>
COLLPCODE1
</Cd>
</Prtfl>
</CollPrtflCd>
…
</MrgnUpd>
3.9 Collateral
portfolio code
COLLPCODE1
3.10 UTI
3.28 Action type MARU
5.2.1.13 Correction of margin data at portfolio level
516. Table 67 illustrates the population of the reporting fields when there is a
correction of margin data fields that were submitted wrongly in a previous report of collateral at portfolio level.
Table 67 - Correction of margin data at portfolio level
No Field Example XML Message
3.8 Collateral
portfolio indicator
TRUE <Crrctn>
…
<Coll>
<CollPrtflCd>

177
Table 67 - Correction of margin data at portfolio level
No Field Example XML Message
3.9 Collateral
portfolio code
COLLPCODE1 <Prtfl>
<Cd>
COLLPCODE1
</Cd>
</Prtfl>
</CollPrtflCd>
…
</Crrctn>
3.10 UTI
3.28 Action type CORR
5.2.1.14 Early termination of a derivative at trade level
517. Table 68 illustrates the population of reporting fields when a derivative at trade
level is terminated prior to its maturity date following the counterparties’ agreement to early terminate (rather than due to a specific event resulting in a termination of a derivative).
Table 68 - Early termination of a derivative at trade level
No Field Example XML Message
2.1 UTI UTI1 <Termntn>
…
<TxData>
<TxId>
<UnqTxIdr>
UTI1
</UnqTxIdr>
</TxId>
…
<DerivEvt>
<Tp>ETRM</Tp>
</DerivEvt>
…
</TxData>
…
<Lvl>TCTN</Lvl>
</Termntn>
2.151 Action type TERM
2.152 Event type ETRM
2.154 Level TCTN
5.2.1.15 Early termination of a derivative at position level
518. Table 69 illustrates the population of reporting fields when a derivative at
position level is terminated prior to its maturity date following the counterparties’ agreement to early terminate (rather than due to a specific event resulting in a termination of a derivative). This can occur for example when the position is netted

178 to zero and the counterparties prefer to close the position rather than to continue to report valuation on a daily basis.
Table 69 - Early termination of a derivative at position level
No Field Example XML Message
2.1 UTI PUTI1 <Termntn>
…
<TxData>
<TxId>
<UnqTxIdr>
PUTI1
</UnqTxIdr>
</TxId>
…
<DerivEvt>
<Tp>ETRM</Tp>
</DerivEvt>
…
</TxData>
…
<Lvl>PSTN</Lvl>
</Termntn>
2.151 Action type TERM
2.152 Event type ETRM
2.154 Level PSTN
5.2.1.16 Erroring a derivative at trade level
519. Table 70 illustrates the population of reporting fields in case of a cancellation of
a wrongly submitted entire report where the derivative never came into existence or was not subject to EMIR reporting requirements, but which was reported to a TR by mistake.
Table 70 - Erroring a derivative at trade level
No Field Example XML Message
2.1 UTI UTI1 <Err>
…
<TxData>
<TxId>
<UnqTxIdr>
UTI1
</UnqTxIdr>
</TxId>
…
</TxData>
…
<Lvl>TCTN</Lvl>
</Err>
2.151 Action type EROR
2.152 Event type
2.154 Level TCTN

179
5.2.1.17 Reviving a derivative at trade level
520. Table 71 illustrates the population of reporting fields in case where a derivative
that was terminated or errored by mistake is revived.
Table 71 - Reviving a derivative at trade level
No Field Example XML Message
2.1 UTI UTI1 <Revi>
…
<TxData>
<TxId>
<UnqTxIdr>
UTI1
</UnqTxIdr>
</TxId>
…
</TxData>
…
<Lvl>TCTN</Lvl>
</Revi>
2.151 Action type REVI
2.152 Event type
2.154 Level TCTN
5.2.2 Other reportable details
5.2.2.1 Reporting of cleared / non-cleared trade
5.2.2.1.1 Cleared trade in an open offer model
521. When a trade is cleared in an open offer model, the clearing takes place at same
time as the conclusion of the trade. Hence, execution timestamp and clearing timestamp are expected to be the same.
522. Table below illustrates the population of the Table 2 fields of the abovementioned situation from the CCP (with LEI BBBBBBBBBB1111111111) and
Counterparty 1 perspective, as in this case, it is identical.
523. The following group of reporting fields should be reported:
’Cleared‘ (field 2.31) is populated with 'Y'; ’Clearing timestamp‘ (field 2.32) is equal to field ’Execution timestamp’ (field 2.42); ’Central counterparty‘ (field 2.33) is populated with the LEI of the CCP.

180
Table 72 - Cleared trade in an open offer model
Item Field Example XML Message
31 Cleared Y <CmonTradData>
<TxData>
<ExctnTmStmp>
2021-03-17T15:17:00Z
</ExctnTmStmp>
<MstrAgrmt>
<Tp>
<Tp>OTHR</Tp>
</Tp>
<OthrMstrAgrmtDtls>
CCP Clearing Conditions
</OthrMstrAgrmtDtls>
</MstrAgrmt>
<TradClr>
<ClrSts><Clrd>
<Dtls>
<CCP>
<LEI>BBBBBBBBBB
1111111111
</LEI>
</CCP>
<ClrDtTm>2021-03-
17T15:17:00Z
</ClrDtTm>
</Dtls></Clrd>
</ClrSts>
</TradClr>
</TxDate>
</CmonTradData>
32 Clearing timestamp
2021-03-
17T15:17:00Z
33 Central counterparty
BBBBBBBBBB1111111111
34 Master
Agreement type
OTHR
35 Other master agreement type
CCP Clearing
Conditions
43 Execution timestamp
2021-03-
17T15:17:00Z
5.2.2.1.2 Cleared trade in a novation model.
524. When a derivative is cleared in a novation model, the clearing takes place after
the time of conclusion of the trade.

181
525. The table below illustrates the population of fields, from the CCP and the CP1
perspective, when a derivative is cleared by the CCP in a novation model.
526. In this respect, the following group of reporting fields should be reported:
’Prior UTI‘ (field 2.3) should be reported with the prior UTI (that of the original bilateral derivative in the case of CCP-cleared derivatives); ’Cleared‘ (field 2.31) is populated with 'Y'; ’Clearing timestamp‘ (field 2.32) time is after the time provided in field ’Execution timestamp’ (field 2.42); ’Central counterparty‘ (field 2.33) is populated with the LEI of the CCP.
Table 73 - Cleared derivative in a novation model
Item Field Example XML Message
1 UTI UTI2 <New>
...
<CmonTradData>
<TxDate>
<TxId>
<UnqTxIdr>UTI2</UnqTxIdr>
</TxId>
<PrrTxId>
<UnqTxIdr>UTI1</UnqTxIdr>
</PrrTxId>
<ExctnTmStmp>
2021-03-17T15:17:00Z
</ExctnTmStmp>
<MstrAgrmt>
<Tp>
<Tp>OTHR</Tp>
</Tp>
<OthrMstrAgrmtDtls>
CCP Clearing Conditions
</OthrMstrAgrmtDtls>
</MstrAgrmt>
...
<DerivEvt>
<Tp>CLRG</Tp>
</DerivEvt>
<TradClr>
<ClrSts><Clrd>
<Dtls>
<CCP>
<LEI
BBBBBBBBBB1111111111
</LEI>
3 Prior UTI UTI1
31 Cleared Y
32 Clearing timestamp
2021-03-
18T18:00:00Z
33 Central counterparty
BBBBBBBBBB1111111111
34 Master
Agreement type
OTHR
35 Other master agreement type
CCPClearing
Conditions
43 Execution timestamp
2021-03-

182
Table 73 - Cleared derivative in a novation model
Item Field Example XML Message
17T15:17:00Z </CCP>
<ClrDtTm>
2021-03-18T18:00:00Z
</ClrDtTm>
</Dtls></Clrd>
</ClrSts>
</TradClr>
...
</TxDate>
</CmonTradData>
</New>
151 Action type NEWT
152 Event type CLRG
Table 74 - Termination of a previous derivative (alpha trade) in a novation model
Item Field Example XML Message
1 UTI UTI1 <Termntn>
...
<CmonTradData>
<TxData>
<TxId>
<UnqTxIdr>
UTI1
</UnqTxIdr>
</TxId>
<EarlyTermntnDt>
2021-03-18
</EarlyTermntnDt>
...
<DerivEvt>
<Tp>CLRG</Tp>
</DerivEvt>
...
</TxData>
</CmonTradData>
</Termntn>
45 Early termination date
2021-03-18
151 Action type TERM
152 Event type CLRG

183
5.2.2.1.3 Non-cleared trade
527. The field ’Cleared‘ (field 2.31) is populated with 'N'. The rest of the fields related
to clearing are not populated.
Table 75 - Non cleared trade
No Field Example XML Message
1 UTI UTI1 <CmonTradData>
<TxData>
<TxId>
<UnqTxIdr>
UTI1
</UnqTxIdr>
</TxId>
<ExctnTmStmp>
2021-03-17T15:17:00Z
</ExctnTmStmp>
<TradClr>
<ClrSts>
<NonClrd>
<Rsn>NORE</Rsn>
</NonClrd>
</ClrSts>
</TradClr>
</TxData>
</CmonTradData>
2 Report tracking number
31 Cleared N
32 Clearing timestamp
33 Central counterparty
43 Execution timestamp
2021-03-
17T15:17:00Z
5.2.2.2 Trading venue
528. The field ’Venue of execution‘ (field 2.41) should be populated in accordance
with the type of conclusion of the derivative.
529. The counterparties should use the ISO 10383 segment MIC for derivatives
executed on a trading venue, Systematic Internaliser (SI) or organised trading platform outside of the Union. Where the segment MIC does not exist, they should use the operating MIC.
530. The counterparties should use the MIC code 'XOFF' for financial instruments
admitted to trading or traded on a trading venue or for which a request for admission was made, where the derivative on that financial instrument is not executed on a trading venue, SI or organised trading platform outside of the Union, or where a counterparty does not know it is trading with a counterparty 2 acting as an SI.

184
531. The counterparties should use the MIC code 'XXXX' for financial instruments
that are not admitted to trading or traded on a trading venue or for which no request for admission has been made and that are not traded on an organised trading platform outside of the Union.
5.2.2.2.1 Example of two SIs facing each other
532. Two counterparties, A and B, that are both SIs, trade with each other. For this
derivative, counterparty A acts in the SI capacity, thus both entities should report MIC of that counterparty in the venue field.
533. Counterparty A is identified with LEI 12345678901234500000 and MIC 1234.
534. Counterparty B is identified with LEI ABCDEFGHIJKLMNOPQRST and MIC
ABCD.
Table 76 - Reporting of the trading venue from the counterparty A perspective
Item Field Example XML Message
4 Counterparty 1 12345678901234500000 <CtrPtySpcfcData> <CtrPty> <RptgCtrPty> <Id> <Lgl> <Id> <LEI> 12345678901234500000 </LEI> </Id> </Lgl> </Id> </RptgCtrPty> <OthrCtrPty> <IdTp> <Lgl> <Id> <LEI> ABCDEFGHIJKLMNOPQRST </LEI> </Id> </Lgl> </IdTp> </OthrCtrPty> ... </CtrPty> </CtrPtySpcfcData> <CmonTradData> <TxData> ... <PltfmId>1234</PltfmId> </TxData> </CmonTradData> 9 Counterparty 2 ABCDEFGHIJKLMNOPQRST 41 Venue of execution 1234

185
Table 76 - Reporting of the trading venue from the counterparty A perspective
Item Field Example XML Message
Table 77 - Reporting of the trading venue from the counterparty B perspective
Item Field Example XML Message
4 Counterparty 1 ABCDEFGHIJKLMNOPQRST <CtrPtySpcfcData> <CtrPty> <RptgCtrPty> <Id> <Lgl> <Id> <LEI> ABCDEFGHIJKLMNOPQRST </LEI> </Id> </Lgl> </Id> </RptgCtrPty> <OthrCtrPty> <IdTp> <Lgl> <Id> <LEI> 12345678901234500000 </LEI> </Id> </Lgl> </IdTp> </OthrCtrPty> ... </CtrPty> </CtrPtySpcfcData> <CmonTradData> <TxData> ... <PltfmId>1234</PltfmId> </TxData> </CmonTradData> 9 Counterparty 2 12345678901234500000 41 Venue of execution 1234

186
Table 77 - Reporting of the trading venue from the counterparty B perspective
Item Field Example XML Message
5.2.2.2.2 Example of post Brexit derivative executed on a UK regulated market
535. Derivatives executed on UK regulated markets before Brexit would be
considered ETD.
536. On the other hand, derivatives executed on UK regulated markets after Brexit
would be considered OTC. The field ‘Venue of execution’ should still be populated with the corresponding MIC code. However, it would have impact on other fields such as the field ’Intragroup‘ and ’Clearing obligation‘ which are required for OTC derivatives.
Table 78 - Derivative executed before Brexit
Item Field Example XML Message
41 Venue of execution
XLON <CmonTradData>
<TxData>
…
<PltfmId>XLON</PltfmId>
<ExctnTmStmp>
2020-12-31T17:00:00Z
</ExctnTmStmp>
…
</TxData>
</CmonTradData>
43 Execution timestamp
2020-12-
31T17:00:00Z
30 Clearing obligation
37 Intragroup

187
Table 79 - Derivative executed after Brexit
Item Field Example XML Message
41 Venue of execution
XLON <CmonTradData>
<TxData>
…
<PltfmId>XLON</PltfmId>
<ExctnTmStmp>
2021-01-04T15:00:00Z
</ExctnTmStmp>
…
<TradClr>
<ClrOblgtn>false
</ClrOblgtn>
<IntraGrp>false</IntraGrp>
</TradClr>
…
</TxData>
</CmonTradData>
43 Execution timestamp
2021-01-
04T15:00:00Z
30 Clearing obligation
FALSE
37 Intragroup FALSE
5.2.2.3 Reporting of valuations
537. Table 80 illustrates the population of the valuation data when the counterparty
submits a daily valuation update for a previously reported derivative at trade level.
5.2.2.3.1 Valuation of a derivative at trade level
538. In this example, the counterparty A (with LEI 12345678901234500000) is buyer
of a call option that is in-the-money and which has been valued on the preceding day at 221,100 EUR. Given that the derivative concerned is an option, the delta is computed and populated (0.6). Counterparty B (with LEI ABCDEFGHIJKLMNOPQRST) is the seller.
Table 80 - Valuation of a derivative at trade level
No Field Example XML Message
1.1 Reporting
timestamp
2023-05-16T19:15:05Z <ValtnUpd>
<CtrPtySpcfcData>
<CtrPty>
<RptgCtrPty>
<Id>
<Lgl>
<Lgl><Id><LEI>
12345678901234500000
1.2 Report
submitting entity
ID
12345678901234500000

188
Table 80 - Valuation of a derivative at trade level
No Field Example XML Message
1.3 Entity
responsible for reporting
12345678901234500000 </LEI></Id></Lgl>
</Id>
</RptgCtrPty>
<OthrCtrPty>
<IdTp>
<Lgl><Id><LEI>
ABCDEFGHIJKLMNOPQRST
</LEI></Id></Lgl>
</IdTp>
</OthrCtrPty>
<SubmitgAgt>
<LEI>
12345678901234500000
</LEI>
</SubmitgAgt>
<NttyRspnsblForRpt>
<LEI>
12345678901234500000
</LEI>
</NttyRspnsblForRpt>
</CtrPty>
<Valtn>
<CtrctVal>
<Amt Ccy="EUR">
221100</Amt>
</CtrctVal>
<TmStmp>
2023-05-15T18:00:00Z
</TmStmp>
<Tp>MTMA</Tp>
<Dlta>0.6</Dlta>
</Valtn>
<RptgTmStmp>
2023-05-16T19:15:05Z
</RptgTmStmp>
</CtrPtySpcfcData>
<CmonTradData>
<TxData>
<TxId>
<UnqTradIdr>
UTI1</UnqTradIdr>
</TxId>
<DerivEvt>
<TmStmp>
2023-05-15
</TmStmp>
</DerivEvt>
</TxData>
</CmonTradData>
<Lvl><TCTN</Lvl>
</ValtnUpd>
1.4 Counterparty 1
(Reporting counterparty)
12345678901234500000
2.8 Counterparty 2
identifier type
TRUE
2.9 Counterparty 2 ABCDEFGHIJKLMNOPQRST
2.1 UTI UTI1
2.21 Valuation
amount
221100
2.22 Valuation
currency
EUR
2.23 Valuation
timestamp
2023-05-15T18:00:00Z
2.24 Valuation
method
MTMA
2.25 Delta 0.6
2.151 Action type VALU
2.153 Event date 2023-05-15
2.154 Level TCTN

189
5.2.2.3.2 Valuation of a derivative at position level
539. Table 81 illustrates the population of the valuation data for an IRS position when
the position is netted to zero and the counterparties decide to maintain the position open (and thus submit the valuation daily).
Table 81 - Valuation of a derivative at position level
No Field Example XML Message
1.1 Reporting
timestamp
2023-06-06T20:00:00Z <ValtnUpd>
<CtrPtySpcfcData>
<CtrPty>
<RptgCtrPty>
<Id>
<Lgl>
<Lgl><Id><LEI>
12345678901234500000
</LEI></Id></Lgl>
</Id>
</RptgCtrPty>
<OthrCtrPty>
<IdTp>
<Lgl><Id><LEI>
ABCDEFGHIJKLMNOPQRST
</LEI></Id></Lgl>
</IdTp>
</OthrCtrPty>
<SubmitgAgt>
<LEI>
12345678901234500000
</LEI>
</SubmitgAgt>
<NttyRspnsblForRpt>
<LEI>
12345678901234500000
</LEI>
</NttyRspnsblForRpt>
</CtrPty>
<Valtn>
<CtrctVal>
<Amt Ccy="EUR">
0</Amt>
</CtrctVal>
<TmStmp>
2023-06-06T20:00:00Z
</TmStmp>
<Tp>MTMA</Tp>
</Valtn>
<RptgTmStmp>
2023-05-16T19:15:05Z
</RptgTmStmp>
</CtrPtySpcfcData>
<CmonTradData>
<TxData>
1.2 Report
submitting entity ID
12345678901234500000
1.3 Entity
responsible for reporting
12345678901234500000
1.4 Counterparty 1
(Reporting counterparty)
12345678901234500000
2.8 Counterparty 2
identifier type
TRUE
2.9 Counterparty 2 ABCDEFGHIJKLMNOPQRST
2.1 UTI PUTI1
2.21 Valuation
amount
0
2.22 Valuation
currency
EUR
2.23 Valuation
timestamp
2023-06-05T19:00:00Z
2.24 Valuation
method
MTMA
2.151 Action type VALU
2.153 Event date 2023-06-05

190
Table 81 - Valuation of a derivative at position level
No Field Example XML Message
2.154 Level PSTN <TxId>
<UnqTradIdr>
PUTI1</UnqTradIdr>
</TxId>
<DerivEvt>
<TmStmp>
2023-06-05
</TmStmp>
</DerivEvt>
</TxData>
</CmonTradData>
<Lvl>PSTN</Lvl>
</ValtnUpd>
5.2.2.4 Reporting of other payments
5.2.2.4.1 Reporting of upfront payment
540. Table 82 illustrates the population of the reporting fields when the counterparty
A (with LEI12345678901234500000) which takes responsibility for the risk makes an initial payment to the counterparty B (with LEI ABCDEFGHIJKLMNOPQRST) to cover any future defaults and submits a report at the trade level.
Table 82 - Reporting of upfront payment
No Field Example XML Message
1.1 Reporting
timestamp
2021-03-06T18:20:05Z <New>
<CtrPtySpcfcData>
<CtrPty>
<RptgCtrPty>
<Id>
<Lgl>
<Lgl><Id><LEI>
12345678901234500000

</LEI></Id></Lgl>
</Id>
</RptgCtrPty>
<OthrCtrPty>
<IdTp>
<Lgl><Id><LEI>

ABCDEFGHIJKLMNOPQRST

</LEI></Id></Lgl>
</IdTp>
1.2 Report
submitting entity ID
12345678901234500000
1.3 Entity
responsible for reporting
12345678901234500000
1.4 Counterparty 1
(Reporting counterparty)
12345678901234500000
1.9 Counterparty 2 ABCDEFGHIJKLMNOPQRST

191
Table 82 - Reporting of upfront payment
No Field Example XML Message
2.1 UTI 123456 </OthrCtrPty>
<SubmitgAgt>
<LEI>

12345678901234500000
</LEI>
</SubmitgAgt>
<NttyRspnsblForRpt>
<LEI>

12345678901234500000
</LEI>

</NttyRspnsblForRpt> </CtrPty> <RptgTmStmp> 2023-03-06T18:20:05Z </RptgTmStmp> </CtrPtySpcfcData> <CmonTradData> <TxData> <TxId> <UnqTradIdr>

123456</UnqTradIdr>
</TxId>
<DerivEvt>
<Tp>TRAD</Tp>
</DerivEvt>
<OthrPmt>
<PmtAmt>
<Amt Ccy="EUR">
100000
</Amt>
</PmtAmt>
<PmtTp>
<Tp>UFRO</Tp>
</PmtTp>
<PmtDt>
2021-03-05
</PmtDt>
<PmtPyer>
<Lgl><LEI>

12345678901234500000
</LEI></Lgl>
</PmtPyer>
<PmtRcvr>
<Lgl>
<Lgl><LEI>

ABCDEFGHIJKLMNOPQRST
2.73 Other payment
type
UFRO
2.74 Other payment
amount
100000
2.75 Other payment
currency
EUR
2.76 Other payment
date
2021-03-05
2.77 Other payment
payer
12345678901234500000
2.78 Other payment
receiver
ABCDEFGHIJKLMNOPQRST
2.151 Action type NEWT
2.152 Event type TRAD
2.154 Level TCTN

192
Table 82 - Reporting of upfront payment
No Field Example XML Message
</LEI>
</Lgl>
</PmtRcvr>
</OthrPmt>
…
</TxData>
</CmonTradData>
<Lvl>TCTN</Lvl>
</New>
5.2.2.4.2 Reporting of unwind payment
541. Table 83 illustrates the population of the reporting fields when the same
counterparty A unwinds the full termination payment and submits a report at the trade level.
Table 83 - Reporting of unwind payment
No Field Example XML Message
1.1 Reporting
timestamp
2021-03-06T18:20:05Z <Termntn>
<CtrPtySpcfcData>
<CtrPty>
<RptgCtrPty>
<Id>
<Lgl><Id><LEI>
12345678901234500000

</LEI></Id></Lgl>
</Id>
</RptgCtrPty>
<OthrCtrPty>
<IdTp>
<Lgl><Id><LEI>

ABCDEFGHIJKLMNOPQRST

</LEI></Id></Lgl>
</IdTp>
</OthrCtrPty>
<SubmitgAgt>
<LEI>

12345678901234500000
</LEI>
</SubmitgAgt>
1.2 Report
submitting entity ID
12345678901234500000
1.3 Entity
responsible for reporting
12345678901234500000
1.4 Counterparty 1
(Reporting counterparty)
12345678901234500000
1.9 Counterparty 2 ABCDEFGHIJKLMNOPQRST
2.1 UTI 456789
2.45 Early
termination date
2021-03-05

193
Table 83 - Reporting of unwind payment
No Field Example XML Message
2.73 Other payment
type
UWIN <NttyRspnsblForRpt>
<LEI>

12345678901234500000
</LEI>

</NttyRspnsblForRpt> </CtrPty> <RptgTmStmp> 2023-03-06T18:20:05Z </RptgTmStmp> </CtrPtySpcfcData> <CmonTradData> <TxData> <TxId> <UnqTradIdr>

456789</UnqTradIdr>
</TxId>
<EarlyTermntnDt>
2021-03-05
</EarlyTermntnDt>
<DerivEvt>
<Tp>ETRM</Tp>
</DerivEvt>
<OthrPmt>
<PmtAmt>
<Amt Ccy="EUR">
70000
</Amt>
</PmtAmt>
<PmtTp>
<Tp>UWIN</Tp>
</PmtTp>
<PmtDt>
2021-03-05
</PmtDt>
<PmtPyer>
<Lgl><LEI>

12345678901234500000
</LEI></Lgl>
</PmtPyer>
<PmtRcvr>
<Lgl>
<Lgl><LEI>

ABCDEFGHIJKLMNOPQRST
</LEI></Lgl>
</Lgl>
</PmtRcvr>
</OthrPmt>
…
2.74 Other payment
amount
70000
2.75 Other payment
currency
EUR
2.76 Other payment
date
2021-03-05
2.77 Other payment
payer
12345678901234500000
2.78 Other payment
receiver
ABCDEFGHIJKLMNOPQRST
2.151 Action type TERM
2.152 Event type ETRM
2.154 Level TCTN

194
Table 83 - Reporting of unwind payment
No Field Example XML Message
</TxData>
</CmonTradData>
<Lvl>TCTN</Lvl>
</Termntn>
5.2.2.4.3 Reporting of principal exchange
542. Table 84 illustrates the population of the reporting fields when a principal
exchange takes place, related to a cross-currency swap.
543. In this example, counterparties A and B agreed an OTC derivative contract,
which specifies:

an initial exchange of notional currency in each different currency and the terms
of that repayment of notional currency over the life of the swap;
an exchange of regular payments benchmarked against two interest rates,
denominated in two different currencies.

The counterparty A will pay 5M EUR and counterparty B will pay 4.3M GBP, as
initial principal exchange for each of them. Counterparties will exchange payments each 6 months for agreed float-to-float 3-year IRS
The re-exchange of the same notional of currencies will take place at the
maturity date.
The below table illustrates the reporting of principal exchange payments from
the perspective of the counterparty A. The counterparty reports both the payments made and received, on the initial and final exchange date – given that all these payments are known at the time of reporting.
Table 84 - Reporting of notional exchanges from Counterparty A perspective
No Field Example XML Message
1.1 Reporting
timestamp
2021-05-20T18:00:15Z <CtrPtySpcfcData> <CtrPty>

<RptgCtrPty> <Id> <Lgl> <Id> <LEI> 12345678901234500000 </LEI> </Id> </Lgl> </Id> <DrctnOrSd><Drctn> 1.2 Report submitting entity ID 12345678901234500000 1.3 Entity responsible for reporting 12345678901234500000

195
Table 84 - Reporting of notional exchanges from Counterparty A perspective
No Field Example XML Message
1.4 Counterparty
1 (Reporting counterparty)
12345678901234500000 <DrctnOfTheFrstLeg>
TAKE
</DrctnOfTheFrstLeg>
<DrctnOfTheScndLeg>
MAKE
</DrctnOfTheScndLeg>
</Drctn></DrctnOrSd>
</RptgCtrPty>
<OthrCtrPty>
<IdTp>
<Lgl>
<Id>
<LEI>
ABCDEFGHIJKLMNOPQRST
</LEI>
</Id>
</Lgl>
</IdTp>
</OthrCtrPty>
<SubmitgAgt>
<LEI>
12345678901234500000
</LEI>
</SubmitgAgt>
<NttyRspnsblForRpt>
<LEI>
12345678901234500000
</LEI>
</NttyRspnsblForRpt>
</CtrPty>
<RptgTmStmp>
2021-05-20T18:00:15Z
</RptgTmStmp>
</CtrPtySpcfcData>
<CmonTradData>
<CtrctData>
<CtrctTp>SWAP</CtrctTp>
</CtrctData>
<TxData>
<TxId>
<UnqTradIdr>
AABB123456
</UnqTradIdr>
</TxId>
…
<NtnlAmt>
<FrstLeg><Amt>
<Amt Ccy="EUR">5000000
</Amt></Amt></FrstLeg>
1.9 Counterparty
2
ABCDEFGHIJKLMNOPQRST
1.18 Direction of
leg 1
TAKE
1.19 Direction of
leg 2
MAKE
2.1 UTI AABB123456
2.10 Contract type SWAP
2.42 Execution
timestamp
2021-05-19T13:10:25Z
2.
44
Expiration date
2024-05-18
2.55 Notional
amount of leg 1
5000000
2.56 Notional
currency 1
EUR
2.64 Notional
amount of leg 2
4300000
2.65 Notional
currency of leg 2
GBP
2.73 Other
payment type
PEXH

196
Table 84 - Reporting of notional exchanges from Counterparty A perspective
No Field Example XML Message
2.74 Other
payment amount
5000000 <ScndLeg><Amt>
<Amt Ccy="GBP">4300000
</Amt></Amt></ScndLeg>
</NtnlAmt>
<ExctnTmStmp>
2021-05-19T13:10:25Z
</ExctnTmStmp>
<XprtnDt>
2024-05-18
</XprtnDt>
<OthrPmt>
<PmtAmt>
<Amt Ccy="EUR">
5000000</Amt>
</PmtAmt>
<PmtTp>
<Tp>PEXH</Tp>
</PmtTp>
<PmtDt>
2021-05-20
</PmtDt>
<PmtPyer>
<Lgl>
<LEI>
12345678901234500000
</LEI>
</Lgl>
</PmtPyer>
<PmtRcvr>
<Lgl>
<LEI>
ABCDEFGHIJKLMNOPQRST
</LEI>
</Lgl>
</PmtRcvr>
</OthrPmt>
<OthrPmt>
<PmtAmt>
<Amt Ccy="GBP">
4300000</Amt>
</PmtAmt>
<PmtTp>
<Tp>PEXH</Tp>
</PmtTp>
<PmtDt>
2021-05-20
</PmtDt>
<PmtPyer>
<Lgl>
<LEI>
ABCDEFGHIJKLMNOPQRST
2.75 Other
payment currency
EUR
2.76 Other
payment date
2021-05-20
2.77 Other
payment payer
12345678901234500000
2.78 Other
payment receiver
ABCDEFGHIJKLMNOPQRST
2.73 Other
payment type
PEXH
2.74 Other
payment amount
4300000
2.75 Other
payment currency
GBP
2.76 Other
payment date
2021-05-20
2.77 Other
payment payer
ABCDEFGHIJKLMNOPQRST
2.78 Other
payment receiver
12345678901234500000

197
Table 84 - Reporting of notional exchanges from Counterparty A perspective
No Field Example XML Message
2.73 Other
payment type
PEXH </LEI>
</Lgl>
</PmtPyer>
<PmtRcvr>
<Lgl>
<LEI>
12345678901234500000
</LEI>
</Lgl>
</PmtRcvr>
</OthrPmt>
<OthrPmt>
<PmtAmt>
<Amt Ccy="GBP">
4300000</Amt>
</PmtAmt>
<PmtTp>
<Tp>PEXH</Tp>
</PmtTp>
<PmtDt>
2021-05-18
</PmtDt>
<PmtPyer>
<Lgl>
<LEI>
12345678901234500000
</LEI>
</Lgl>
</PmtPyer>
<PmtRcvr>
<Lgl>
<LEI>
ABCDEFGHIJKLMNOPQRST
</LEI>
</Lgl>
</PmtRcvr>
</OthrPmt>
<OthrPmt>
<PmtAmt>
<Amt Ccy="EUR">
5000000</Amt>
</PmtAmt>
<PmtTp>
<Tp>PEXH</Tp>
</PmtTp>
<PmtDt>
2021-05-18
</PmtDt>
<PmtPyer>
<Lgl>
<LEI>
ABCDEFGHIJKLMNOPQRST
2.74 Other
payment amount
4300000
2.75 Other
payment currency
GBP
2.76 Other
payment date
2024-05-18
2.77 Other
payment payer
12345678901234500000
2.78 Other
payment receiver
ABCDEFGHIJKLMNOPQRST
2.73 Other
payment type
PEXH
2.74 Other
payment amount
5000000
2.75 Other
payment currency
EUR
2.76 Other
payment date
2024-05-18
2.77 Other
payment payer
ABCDEFGHIJKLMNOPQRST

198
Table 84 - Reporting of notional exchanges from Counterparty A perspective
No Field Example XML Message
2.78 Other
payment receiver
12345678901234500000 </LEI>
</Lgl>
</PmtPyer>
<PmtRcvr>
<Lgl>
<LEI>
12345678901234500000
</LEI>
</Lgl>
</PmtRcvr>
</OthrPmt>
5.3 Table 3 Margin data
547. Counterparties should report all relevant types of collateral (initial margin,
variation margin and excess collateral), providing both pre- and post-haircut values. Each type of collateral should be reported as a single figure, being the sum of the values of all assets posted/received expressed in a single currency.
548. Collateral can be reported on a portfolio basis. It is up to the reporting
counterparty to determine what unique value to put in the field ‘Collateral Portfolio Code’, but this value should be consistent over the lifetime of the portfolio and not be re-assigned every day for the same portfolio. At the same time, different counterparties can use different collateral portfolio codes for the same set of derivatives.
5.3.1 Reporting of margin update for a new uncollateralised derivative
549. Table 85 illustrates the population of the reporting fields when the counterparty
submits the margin report for an uncollateralised derivative . There is no need to send any further margin updates, unless the collateralisation category changes.
Table 85 – Report of margin update for an uncollateralized derivative
No Field Example XML Message
3.8 Collateral portfolio
indicator
FALSE <Rpt>
<MrgnUpd>
<TxId>
<UnqTxIdr>
UTI3
</UnqTxIdr>
</TxId>
<Coll>
<CollPrtflCd>
3.9 Collateral portfolio
code
3.10 UTI UTI3

199
Table 85 – Report of margin update for an uncollateralized derivative
No Field Example XML Message
3.11 Collateralisation
category
UNCL <Prtfl>
<NoPrtfl>
<Rsn>NOAP</Rsn>
</NoPrtfl>
</Prtfl>
</CollPrtflCd>
<CollstnCtgy>
UNCL
</CollstnCtgy>
</MrgnUpd>
</Rpt>
3.28 Action type MARU
5.3.2 Reporting of margin for a new derivative collateralized at portfolio level
550. In the scenario below, the reporting counterparty, Counterparty J (with LEI
CCCCCCCCCCCCCCCCCCCC) is also a clearing member. It reports the amount of 1,000,000 EUR posted as initial margin and the amount of 300,000 EUR as variation margin posted to CCP O (with LEI BBBBBBBBBB1111111111). The counterparty also reports excess collateral of 100,000 EUR.
Table 86 - Margin update at portfolio level for a cleared derivative
No Field Example XML Message
3.1 Reporting
timestamp
2023-07-19T18:05:45Z <MrgnUpd>
<RptgTmStmp>
2023-07-19T18:05:45Z
</RptgTmStmp>
<CtrPtyId>
<RptgCtrPty>
<Id>
<Lgl>
<Id>
<LEI>
CCCCCCCCCCCCCCCCCCC
</LEI>
</Id>
</Lgl>
</Id>
</RptgCtrPty>
<OthrCtrPty>
<IdTp>
<Lgl>
<Id>
<LEI>
BBBBBBBBBB1111111111
</LEI>
</Id>
</Lgl>
3.2 Report
submitting entity ID
CCCCCCCCCCCCCCC
CCCCC
3.3 Entity
responsible for reporting
CCCCCCCCCCCCCC
CCCCCC
3.4 Counterparty 1
(Reporting counterparty)
CCCCCCCCCCCCCC
CCCCCC
3.5 Counterparty 2
identifier type
TRUE
3.6 Counterparty 2 BBBBBBBBBB111111
1111

200
Table 86 - Margin update at portfolio level for a cleared derivative
No Field Example XML Message
3.7 Collateral
timestamp
2023-07-18T18:00:00Z </IdTp>
</OthrCtrPty>
<SubmitgAgt>
<LEI>
CCCCCCCCCCCCCCCCCCCC
</LEI>
</SubmitgAgt>
<NttyRspnsblForRpt>
<LEI>
CCCCCCCCCCCCCCCCCCCC
</LEI>
</NttyRspnsblForRpt>
</CtrPtyId>
<EvtDt>
2023-07-18
</EvtDt>
<Coll>
<CollPrtflCd>
<Prtfl>
<Cd>
CODEPORTFOLIO123
</Cd>
</Prtfl>
</CollPrtflCd>
<CollstnCtgy>
OWC1
</CollstnCtgy>
<TmStmp>
2023-07-18T18:00:00Z
</TmStmp>
<PstdMrgnOrColl>
<InitlMrgnPstdPreHrcut Ccy="EUR">1000000
</InitlMrgnPstdPreHrcut>
<InitlMrgnPstdPstHrcut Ccy="EUR">1000000
</InitlMrgnPstdPstHrcut>
<VartnMrgnPstdPreHrcut Ccy="EUR">300000
</VartnMrgnPstdPreHrcut>
<VartnMrgnPstdPstHrcut Ccy="EUR">300000
</VartnMrgnPstdPstHrcut>
<XcssCollPstd Ccy="EUR">100000
</XcssCollPstd>
</PstdMrgnOrColl>
</MrgnUpd>
3.8 Collateral
portfolio indicator
TRUE
3.9 Collateral
portfolio code
CODEPORTFOLIO123
3.10 UTI
3.11 Collateralisation
category
OWC1
3.12 Initial margin
posted by the counterparty 1
(pre-haircut)
1000000
3.13 Initial margin
posted by the counterparty 1
(post-haircut)
1000000
3.14 Currency of the
initial margin posted
EUR
3.15 Variation
margin posted by the counterparty 1
(pre-haircut)
300000
3.16 Variation
margin posted by the counterparty 1
(post-haircut)
300000

201
Table 86 - Margin update at portfolio level for a cleared derivative
No Field Example XML Message
3.17 Currency of the
variation margins posted
EUR
3.18 Excess
collateral posted by the counterparty 1
100000
3.19 Currency of the
excess collateral posted
EUR
3.20 Initial margin
collected by the counterparty 1
(pre-haircut)
3.21 Initial margin
collected by the counterparty 1
(post-haircut)
3.22 Currency of
initial margin collected
3.23 Variation
margin collected by the counterparty 1
(pre-haircut)
3.24 Variation
margin collected by the counterparty 1
(post-haircut)
3.25 Currency of
variation margin collected

202
Table 86 - Margin update at portfolio level for a cleared derivative
No Field Example XML Message
3.26 Excess
collateral collected by the counterparty 1
3.27 Currency of
excess collateral collected
3.28 Action type MARU
3.29 Event date 2023-07-18
5.3.3 Reporting of margin update at an individual transaction level for an uncleared
derivative
551. In the next scenario, two counterparties exchange collateral for an uncleared
derivative. Both counterparties post IM and VM according to the collateral agreement. Counterparty A (with LEI 12345678901234500000) posted 800,000 EUR of IM in cash and 220,000 EUR of IM in securities subject to 10% haircut. Counterparty B (with LEI ABCDEFGHIJKLMNOPQRST ) posted 1,000,000 EUR of IM in cash. Counterparty B would also be expected to post 100,000 EUR of VM based on the most recent valuation of the contract, however this amount is below the minimum transfer amount (MTA) agreed between the counterparties.
Table 87- Margin update at an individual transaction level for an uncleared
derivative
No Field Example XML Message
3.1 Reporting
timestamp
2023-04-07T10:00:00Z <MrgnUpd>
<RptgTmStmp>
2023-04-07T10:00:00Z
</RptgTmStmp>
<CtrPtyId>
<RptgCtrPty>
<Id>
<Lgl>
3.2 Report
submitting entity ID
1234567890123450
0000

203
Table 87- Margin update at an individual transaction level for an uncleared
derivative
No Field Example XML Message
3.3 Entity
responsible for reporting
1234567890123450
0000
<Id>
<LEI>
12345678901234500000
</LEI>
</Id>
</Lgl>
</Id>
</RptgCtrPty>
<OthrCtrPty>
<IdTp>
<Lgl>
<Id>
<LEI>
ABCDEFGHIJKLMNOPQRST
</LEI>
</Id>
</Lgl>
</IdTp>
</OthrCtrPty>
<SubmitgAgt>
<LEI>
12345678901234500000
</LEI>
</SubmitgAgt>
<NttyRspnsblForRpt>
<LEI>
12345678901234500000
</LEI>
</NttyRspnsblForRpt>
</CtrPtyId>
<EvtDt>
2023-04-06
</EvtDt>
<TxId>
<UnqTxIdr>UTI1</UnqTxIdr>
</TxId>
<Coll>
<CollPrtflCd>
<Prtfl>
<NoPrtfl>
NOAP
</NoPrtfl>
</Prtfl>
</CollPrtflCd>
<CollstnCtgy>
FLCL
</CollstnCtgy>
<TmStmp>
2023-04-06T20:30:00Z
3.4 Counterparty 1
(Reporting counterparty)
1234567890123450
0000
3.5 Counterparty 2
identifier type
TRUE
3.6 Counterparty 2 ABCDEFGHIJKLMN
OPQRST
3.7 Collateral
timestamp
2023-04-06T20:30:00Z
3.8 Collateral
portfolio indicator
FALSE
3.9 Collateral
portfolio code
3.10 UTI UTI1
3.11 Collateralisation
category
FLCL
3.12 Initial margin
posted by the counterparty 1
(pre-haircut)
1020000
3.13 Initial margin
posted by the counterparty 1
(post-haircut)
998000
3.14 Currency of the
initial margin posted
EUR

204
Table 87- Margin update at an individual transaction level for an uncleared
derivative
No Field Example XML Message
3.15 Variation
margin posted by the counterparty 1
(pre-haircut)
</TmStmp>
<PstdMrgnOrColl>
<InitlMrgnPstdPreHrcut Ccy="EUR">1020000
</InitlMrgnPstdPreHrcut>
<InitlMrgnPstdPstHrcut Ccy="EUR">998000
</InitlMrgnPstdPstHrcut>
</PstdMrgnOrColl>
<RcvdMrgnOrColl>
<InitlMrgnRcvdPreHrcut Ccy="EUR">
1000000
</InitlMrgnRcvdPreHrcut>
<InitlMrgnRcvdPstHrcut Ccy="EUR">
1000000
</InitlMrgnRcvdPstHrcut>
<VartnMrgnRcvdPreHrcut Ccy="EUR">
0
</VartnMrgnRcvdPreHrcut>
<VartnMrgnRcvdPstHrcut Ccy="EUR">
0
</VartnMrgnRcvdPstHrcut>
</RcvdMrgnOrColl>
</MrgnUpd>
3.16 Variation
margin posted by the counterparty 1
(post-haircut)
3.17 Currency of the
variation margins posted
3.18 Excess
collateral posted by the counterparty 1
3.19 Currency of the
excess collateral posted
3.20 Initial margin
collected by the counterparty 1
(pre-haircut)
1000000
3.21 Initial margin
collected by the counterparty 1
(post-haircut)
1000000
3.22 Currency of
initial margin collected
EUR
3.23 Variation
margin collected by the
0

205
Table 87- Margin update at an individual transaction level for an uncleared
derivative
No Field Example XML Message counterparty 1 (pre-haircut)
3.24 Variation
margin collected by the counterparty 1
(post-haircut)
0
3.25 Currency of
variation margin collected
EUR
3.26 Excess
collateral collected by the counterparty 1
3.27 Currency of
excess collateral collected
3.28 Action type MARU
3.29 Event date 2023-04-06
6 Guidelines on derivatives data management
6.1 Trade State Report
6.1.1 Introduction
552. The correct preparation of the Trade State Report (TSR) by TRs is essential to
ensure the achievement of one of the main objectives of EMIR – the monitoring of systemic risks to financial stability.

206
553. TRs should include the most up-to-date information relating to outstanding
derivatives in the TSR in order to allow the authorities to have a direct and immediate access to the most granular information on existing risk exposures between counterparties. TRs should also allow each individual counterparty to have a clear understanding of its own exposures vis-à-vis each market participant with which it has an open derivative.
554. The requirements for TRs to produce TSR are included in Article 2 and 5 of the
RTS on data access and Article 4 of the RTS on data quality.
555. In sections 0 and 3.6.2, ESMA provides clarifications on the allowable
sequences of action types and on the allowable combinations between action types and event types. Furthermore, in section 3.9 ESMA includes guidance with regards to the timeliness of reporting of the conclusion, modification and termination of a derivative.
556. TRs should use the information reported by counterparties, ERRs and RSEs to
prepare the TSR. The only instance where the TRs are allowed to update the most current TSR without an action by the aforementioned entities is detailed in section 6.1.7.
557. If a counterparty uses a third party to report their transactions, but the
counterparty submits its valuation reporting itself, it should be possible for all the reporting information to be amalgamated in the TSR so that all the parties have all the relevant information available. In particular, the TSR provided to the authorities should contain all the information, including trade, valuation and margin data.
6.1.2 Treatment of event date
558. When constructing the TSR, TRs should take into account the lifecycle events
based on the logical order derived from the fields ‘Event date’, ’Action type‘ and ’Event type‘. TRs should update the TSR based on the latest information for a given derivative as derived from the field ’Event date‘. In the case of valuation and margins reports with the same event date, the TRs should also consider the fields ‘Valuation timestamp’ and ‘Collateral timestamp’, respectively.
559. Where for a given event date there are several lifecycle events that affect the
data reported for a given derivative, they should all be included in the latest report for that event date and the given action type. TRs should therefore consider the field ’Reporting timestamp‘ only with regards to the given event date.
560. TRs should ensure that derivative contracts that mature on a given day should
still be included in the TSR for that day.
561. The information from previously submitted lifecycle events should in general
persist in the TSR when counterparties report subsequent lifecycle events for which certain fields are not requested to be populated (i.e. not applicable). On the contrary, TRs should not preserve the previous information in the updated TSR when subsequent lifecycle events submitted by counterparties leave certain optional fields blank. Counterparties should consistently report optional information

207 in order to avoid the deletion of available information, which otherwise could lead to reconciliation breaks and missing information in the latest trade state.
562. TRs should update the state in the past for all outstanding derivatives, whereas
for non-outstanding derivatives TRs should be in a position to update their state for up to ten years following their maturity or termination. This limit is related to the requirement under Article 80(3) of EMIR for TRs to keep records of derivatives for at least ten years following their maturity or termination.
563. Updating the state in the past does not imply that TRs should reproduce and
dispatch corrected historical TSRs on a recurrent basis and in an automated manner every time late reports or lifecycle events referring to event dates in the past are received. The TSR produced for a specific date should be considered as a snapshot of all available information at a certain point in time. However, it is essential that TRs’ internal databases should always be updated accordingly when such reports are received.
564. TRs should have in place a process for reproducing and dispatching corrected
historical TSRs based on ad-hoc requests made by authorities or counterparties, RSEs and ERRs. Such TSRs, when reproduced, should include missing information from late submitted reports and lifecycle events referring to event dates in the past which were not included in the original TSR produced at a specific point in time in the past. TRs should make use of the versioning prefix part of the TRACE file name convention to distinguish old versions from more recent versions.
565. Below tables illustrate the logic for different use cases:
Use case 1: Lifecycle event ‘NEWT’ for a previous event date Lifecycle event Action type Reporting timestamp Event date Notional Val.amount Val.timestamp NEWT-3 100 - - TR’s database before update TSR Date Action type Reporting timestamp Event date Notional Val.amount Val.timestamp T-4 - - - - - - T-3 - - - - - - T-2 - - - - - - T-1 - - - - - - T - - - - - - TR’s database after update TSR Date Action type Reporting timestamp Event date Notional Val.amount Val.timestamp T-4 - - - - - - T-3 NEWT-3 100 - - T-2 NEWT-3 100 - - T-1 NEWT-3 100 - - T NEWT-3 100 - - The TR should populate its database with the history from T-3 to T. Use case 2: Lifecycle event ‘MODI’ for a previous event date

208
Lifecycle event
Action type
Reporting timestamp
Event date
Notional Val.amount Val.timestamp
MODI T T-2 120 - -
TR’s database before update
TSR Date Action type
Reporting timestamp
Event date
Notional Val.amount Val.timestamp
T-4 - - - - - -
T-3 NEWT T-3 T-3 100 - -
T-2 NEWT T-3 T-3 100 - -
T-1 NEWT T-3 T-3 100 - -
T NEWT T-3 T-3 100
TR’s database after update
TSR Date Action type
Reporting timestamp
Event date
Notional Val.amount Val.timestamp
T-4 - - - - - -
T-3 NEWT T-3 T-3 100 - -
T-2 MODI T T-2 120 - -
T-1 MODI T T-2 120 - -
T MODI T T-2 120 - -
The TR should modify the information stored in its database from T-2 to T. Use case 3: Lifecycle event ‘CORR’ including both trade and valuation details for a previous event date Lifecycle event Action type Reporting timestamp Event date Notional Val.amount Val.timestamp CORR T T-2 140 110 T-2 TR’s database before update TSR Date Action type Reporting timestamp Event date Notional Val.amount Val.timestamp T-4 - - - - - - T-3 NEWT T-3 T-3 100 - T-3 T-2 VALU T-2 T-2 100 95 T-2 T-1 VALU T-1 T-1 100 94 T-1 T VALU T T 100 93 T TR’s database after update TSR Date Action type Reporting timestamp Event date Notional Val.amount Val.timestamp T-4 - - - - - - T-3 NEWT T-3 T-3 100 - T-3 T-2 CORR T T-2 140 110 T-2 T-1 CORR T T-2 140 94 T-1 T CORR T T-2 140 93 T The TR should correct the trade details from T-2 to T and the valuation details should only be corrected from T-2 to T-2 in order to preserve the more recent valuation updates. Use case 4: Lifecycle event ‘CORR’ including both trade and valuation details for a previous event date which falls in between ‘NEWT’ and another lifecycle event (e.g. ‘MODI’) Lifecycle event Action type Reporting timestamp Event date Notional Val.amount Val.timestamp

209
CORR T T-2 140 110 T-2
TR’s database before update
TSR Date Action type
Reporting timestamp
Event date
Notional Val.amount Val.timestamp
T-4 - - - - - -
T-3 NEWT T-3 T-3 100 - T-3
T-2 VALU T-2 T-2 100 95 T-2
T-1 VALU T-1 T-1 100 94 T-1
T MODI T T 120 94 T-1
TR’s database after update
TSR Date Action type
Reporting timestamp
Event date
Notional Val.amount Val.timestamp
T-4 - - - - - -
T-3 NEWT T-3 T-3 100 - T-3
T-2 CORR T T-2 140 110 T-2
T-1 CORR T T-2 140 94 T-1
T MODI T T 120 94 T-1
The TR should correct the trade details from T-2 to T-1 in order to avoid overwriting the information from the more recent ‘MODI’ lifecycle event, and the valuation details should only be corrected from T-2 to T-2 in order to preserve the more recent valuation updates. Use case 5: Lifecycle event ‘TERM’ for a previous event date Lifecycle event Action type Reporting timestamp Event date Notional Val.amount Early term.date TERM T T-2 - - T-2 TR’s database before update TSR Date Action type Reporting timestamp Event date Notional Val.amount Early term.date T-4 - - - - - - T-3 NEWT T-3 T-3 100 - T-3 T-2 VALU T-2 T-2 100 95 T-2 T-1 VALU T-1 T-1 100 94 T-1 T VALU T T 100 93 T TR’s database after update TSR Date Action type Reporting timestamp Event date Notional Val.amount Early term.date T-4 - - - - - - T-3 NEWT T-3 T-3 100 - T-3 T-2 TERM - - - - - T-1 - - - - - - T - - - - - - The TR should log the termination of the outstanding derivative on T-2 and should remove the history from that date onwards. Use case 6: Lifecycle event ‘VALU’ for a previous event date Lifecycle event Action type Reporting timestamp Event date Notional Val.amount Val.timestamp VALU T T-2 - 100 T-2

210
TR’s database before update
TSR Date Action type
Reporting timestamp
Event date
Notional Val.amount Val.timestamp
T-4 - - - - - -
T-3 NEWT T-3 T-3 100 - -
T-2 MODI T-2 T-2 120 - -
T-1 MODI T-2 T-2 120 - -
T MODI T-2 T-2 120 - -
TR’s database after update
TSR Date Action type
Reporting timestamp
Event date
Notional Val.amount Val.timestamp
T-4 - - - - - -
T-3 NEWT T-3 T-3 100 - -
T-2 VALU T T-2 120 100 T-2
T-1 VALU T T-2 120 100 T-2
T VALU T T-2 120 100 T-2
Since there is not any more recent valuation information, the TR should update the relevant valuation information from T-2 to T,and not only for T-2, trade detail information remains unchanged. Use case 7: Lifecycle event ‘VALU’ for a previous event date which falls in between ‘NEWT’ and another ‘VALU’ lifecycle event Lifecycle event Action type Reporting timestamp Event date Notional Val.amount Val.timestamp VALU T T-2 - 90 T-2 TR’s database before update TSR Date Action type Reporting timestamp Event date Notional Val.amount Val.timestamp T-4 - - - - - - T-3 NEWT T-3 T-3 100 - - T-2 NEWT T-3 T-3 100 - - T-1 NEWT T-3 T-3 100 - - T VALU T T 100 95 T TR’s database after update TSR Date Action type Reporting timestamp Event date Notional Val.amount Val.timestamp T-4 - - - - - - T-3 NEWT T-3 T-3 100 - - T-2 VALU T T-2 100 90 T-2 T-1 VALU T T-2 100 90 T-2 T VALU T T 100 95 T The TR should update the relevant valuation information from T-2 to T-1 and preserve the valuation information from the more recent ‘VALU’ lifecycle event. Use case 8: Lifecycle event ‘EROR’ Lifecycle event Action type Reporting timestamp Event date Notional Val.amount Val.timestamp EROR T T - - -

211
TR’s database before update
TSR Date Action type
Reporting timestamp
Event date
Notional Val.amount Val.timestamp
T-4 - - - - - -
T-3 NEWT T-3 T-3 100 - -
T-2 NEWT T-3 T-3 100 - -
T-1 NEWT T-3 T-3 100 - -
T NEWT T-3 T-3 100 - -
TR’s database after update
TSR Date Action type
Reporting timestamp
Event date
Notional Val.amount Val.timestamp
T-4 - - - - - -
T-3 - - - - - -
T-2 - - - - - -
T-1 - - - - - -
T - - - - - -
The event date of an ‘EROR’ lifecycle event should always be equal to the reporting date. The TR should nevertheless remove the information from the inception date, i.e. the event date of ‘NEWT’. Use case 9: Lifecycle event ‘REVI’ Lifecycle event Action type Reporting timestamp Event date Notional Val.amount Expiration.date REVI T T 100 94 T+20 TR’s database before update TSR Date Action type Reporting timestamp Event date Notional Val.amount Expiration.date T-4 - - - - - - T-3 NEWT T-3 T-3 100 - T+20 T-2 VALU T-2 T-2 100 94 T+20 T-1 TERM T-1 T-1 T - - - - - - TR’s database after update TSR Date Action type Reporting timestamp Event date Notional Val.amount Expiration.date T-4 - - - - - - T-3 NEWT T-3 T-3 100 - - T-2 VALU T-2 T-2 100 94 - T-1 REVI T T 100 94 T+20 T REVI T T 100 94 T+20 The event date of a ‘REVI’ lifecycle event should always be equal to the reporting date. The TR should nevertheless revive the derivative contract starting from the date of termination, i.e. T-1 in this case. Use case 10: Reporting of multiple valuations for the same event date Lifecycle event Action type Reporting timestamp Event date Notional Val.amount Val.timestamp VALU T T-1 95 T 18:00:00

212
TR’s database before update
TSR Date Action type
Reporting timestamp
Event date
Notional Val.amount Val.timestamp
T-4
T-3 NEWT T-3 T-3 100 - T-3 18:00:00
T-2 VALU T-2 T-2 100 95 T-2 18:00:00
T-1 VALU T-1 T-1 100 94 T-1 16:00:00
T VALU T T 100 93 T 18:00:00
TR’s database after update
TSR Date Action type
Reporting timestamp
Event date
Notional Val.amount Val.timestamp
T-4
T-3 NEWT T-3 T-3 100 - T-3 18:00:00
T-2 VALU T-2 T-2 100 95 T-2 18:00:00
T-1 VALU T-1 T-1 100 95 T-1 18:00:00
T VALU T T 100 93 T 18:00:00
The entity has sent more than one valuation report for the same event date. In this case the TR should update the TSR for date T-1, because the valuation timestamp submitted in the second report is later than the valuation timestamp submitted in the first report. The same logic should apply in the case of multiple margins reports for the same event date – in this case he TRs should consider the collateral timestamp.
6.1.3 Uniqueness of derivatives and special fields
566. The uniqueness of a derivative until the application of the revised RTS on
reporting was ensured at the level of the combination of LEI1-LEI2-UTI. It should be noted that TRs used this unique combination to incorporate any modification or the termination to the derivative.
567. From the date of application of the revised technical standards on reporting
under EMIR the uniqueness of derivatives concluded after that date should be ensured at the level of the UTI, i.e. for the derivatives concluded after that date there should not be two same UTIs, no matter the combination of counterparties. This is of course notwithstanding that for double-sided reports (i.e. where both sides report under EMIR), the same UTI would appear twice, reported by either of the counterparties.
568. From that date onwards, TRs should therefore use the full triplet (LEI1-LEI2-
UTI) only to update the state of the derivatives concluded prior to the application date of the RTS on reporting. To update the state of derivatives concluded after the application date of the RTS on reporting, the TRs can use the combination LEI1- UTI. For simplicity, the TRs can use full triplet in all cases to update the state of the derivative (incl. derivatives concluded after the application date of the RTS on reporting). The uniqueness of the newly reported UTIs should be ensured by the counterparties and ERRs when reporting and by the TRs when verifying the reports in accordance with the validation rules.

213
569. Counterparties and TRs should be reminded that the requirement included in
Article 8 of the ITS on reporting is the only way for reporting counterparties and
ERRs to update the two LEIs.
570. Counterparties should not amend fields 1.4 ’Counterparty 1’, 1.9 ’Counterparty
2’ and 2.1 ‘UTI’ of previous submissions by submitting a report with action type ’CORR’ and TRs should not accept any such submissions. Furthermore, it is not possible to correct information reported in the fields ‘Event date’, ‘Event type’, ‘Reporting timestamp’ and ‘Action type’, as the information included in these fields in the report with action type ‘CORR’ will refer to the correction, rather than to the previous submissions.
6.1.4 Treatment of action type ‘Revive’.
571. When the counterparty or the ERR submits a report with action type ’Revive‘,
the TR should process the report and based on the information included in the fields ’Expiration date‘ or ’Early termination date‘, assess whether to reinclude it in the TSR or simply update its internal database relating to that derivative (see also an example on update of TSR after a report with action type ‘Revive’ in section 6.1.2).
572. The reporting counterparty or the ERR should provide complete information
regarding the expiration date and the early termination date of a derivative. The provided information should follow the logical timeline sequence included in the validation rules. In particular, early termination date should not be in the future.
573. The field ‘Event date’ and the date part of the field ‘Reporting timestamp’ for
reports with action type ‘Revive’ should be the same.
574. Where the expiration date in the derivative report is in the future or it is not
populated, and the early termination date is not populated, the TR should include the derivative in the TSR with all the values that have been included in the submission with action type ’Revive‘.
575. Where the expiration date or the early termination date are both in the past, the
TR should update its own records, but not the TSR.
576. Where the expiration date is in the future, but the early termination date is in the
past, the TR should update its own records, but not the TSR.
577. Where the early termination date is populated with a date later than the event
date or when it is populated with a date equal to or later than the expiration date, such report would not impact the TSR as it would be rejected due to its noncompliance with the validation rules. The below table summarises the relevant instances.

214
Table 88 - Interaction between TSR and reports with action type ’Revive’
Expiration date Early termination date Impact to the TSR Earlier than event date Earlier than event date No impact to the TSR, only internal database should be updated Equal to event date Empty Update TSR and internal database Equal to event date Earlier than event date No impact to the TSR, only internal database should be updated Later than event date or empty Empty Update TSR and internal database Later than event date or empty Equal to or earlier than event date No impact to the TSR, only internal database should be updated Later than event date or empty Earlier than expiration date, but later than event date No impact to the TSR (rejected) Earlier, equal to or later than event date Equal to or later than expiration date No impact to the TSR (rejected)
6.1.5 Reporting with action type ‘EROR‘ and ‘REVI’
578. Where a counterparty sends an ‘EROR‘ report for its side of the derivative, the
TR that has received such report should remove the derivative reported by that counterparty from the TSR. The TR should do so even when the other counterparty reports to the same TR and has not made the same report. Counterparties should be responsible for resolving any type of mismatch caused by the usage of ‘EROR’ reports.
579. The TR should restore the derivative to the TSR when a report with action type
‘Revive‘ has been received and it is compliant with the validation rules and the logical rules included in table under paragraph 576. The TR should do so even when the other counterparty reports to the same TR and has not made the same report. Counterparties should be responsible for resolving any type of mismatch caused by the usage of ‘REVI’ reports.

215
6.1.6 Inclusion in the TSR of schedule information
580. The RTS and the ITS on reporting detail the requirements for reporting of
notional schedules and other payments.
581. TRs should include in the TSR only the current value from the schedules
reported, as opposed to including all the values from the schedules. This should be applied for the following schedule fields: 2.50-2.52 (‘Price’), 2.57-2.59 (‘Notional amount of leg 1’), 2.61-2.63 (‘Notional quantity of leg 1’), 2.66-2.68 (‘Notional amount of leg 2’), 2.70-2.72 (‘Notional quantity of leg 2’), and 2.135-2.137 (‘Strike price’). This will reduce the amount of data provided to authorities and would facilitate the immediate assessment of exposures.
582. TRs should use the date fields referring to the effective date and end date of the
information contained in the schedule to determine which data point to include in the TSR. For example, a schedule with the following characteristics is reported:
‘value’ {100, 150, 200}, ‘effective date’ {T, T+10, T+20}, ‘end date’ {T+9, T+19, T+29}. The TSRs generated for reporting dates T to T+9 should display the value 100, the TSRs generated for reporting dates T+10 to T+19 should display the value 150, and finally, the TSRs generated for reporting dates T+20 to T+29 should display the value 200.
583. For fields 2.73-2.78, referring to other payments, TRs should include in the TSR
all relevant payments. Payments of different types should not be overwritten. This means that if a counterparty reports the same payment type more than one time (in different reports), the TSR should update such value. Below example illustrates the logic:
Event date CP reports TSR for that day
T UFRO, 100 UFRO, 100
T+1
PEXH, 150; PEXH,
200 UFRO, 100; PEXH, 150; PEXH, 200
T+2
PEXH, 250; PEXH,
300 UFRO, 100; PEXH, 250; PEXH, 300
T+3 UWIN, 50 UFRO, 100; PEXH, 250; PEXH, 300; UWIN, 50
584. For fields 2.122-2.131, referring to commodities, TRs should include all the
information as it is reported by counterparties.
585. The most up-to-date linking IDs should persist in the TSR when a counterparty
reports a lifecycle event where these fields are not applicable. On the contrary, the linking IDs should not persist in the TSR when a counterparty reports a lifecycle event where these fields are optional and reported as blank. The same approach should apply also to fields like ‘Event type’.

216
6.1.7 Dead derivatives
586. Where a counterparty ceases to exist, without being acquired or merged, no
derivatives should remain outstanding at the trade repository.
587. If the reporting counterparty reports directly to the TR and notifies the TR in
order to cancel its membership, the TR should liaise with the reporting counterparty to terminate the relevant derivatives, while it is still active, by submitting reports with action types ‘TERM‘ where the termination date is at the latest the date of the dissolution of the reporting counterparty.
588. If the reporting counterparty does not report directly to the TR, and the ERR or
RSE notifies the TR, the TR should liaise with that entity so that the ERR or RSE terminates the relevant derivatives, while the reporting counterparty is still active, by submitting reports with action types ‘TERM’ where the termination date is at the latest the date of the dissolution of the reporting counterparty.
589. Where the reporting counterparty has ceased to exist and has not terminated
the outstanding derivatives and the TR becomes aware of this situation, the following waterfall should be followed:
a. If the ERR is different from the reporting counterparty and that ERR has not used RSE, the TR should contact the ERR, should request the submission of reports with action types ‘TERM where the termination date is at the latest the date of the dissolution of the reporting counterparty and, simultaneously, should raise the issue to the NCA of the reporting counterparty. If the reporting counterparty or the ERR has used a RSE and that entity is still an active RSE at the TR, the TR should contact the RSE, should request the submission of reports with action types ‘TERM’ where the termination date is at the latest the date of the dissolution of the reporting counterparty and, simultaneously, should raise the issue to the NCA of the reporting counterparty. b. If the previous step in point a is not applicable, the TR should assess the maturity date of the outstanding derivatives that should be terminated to assess whether they would naturally expire in the following twelve months. If that is the case, no further action should be undertaken by the TR. This is to alleviate the work of TRs and minimise the risks associated with the process of excluding dead derivatives.
c. If the previous step in point b is not applicable, the TR should contact the other
counterparty/ies to the outstanding derivatives, where those entities report directly to the TR, and request them to terminate the outstanding derivatives on behalf of the reporting counterparty while, if possible, raise the issue to the NCA(s) to follow-up with the other counterparty/ies. d. Finally, in case none of the above is applicable, the TR, upon confirming with the NCA and notifying ESMA, should flag the relevant derivatives accordingly and not take them into consideration for the purposes of TSR, reconciliation process or any subsequent aggregations such as position reports.

217
590. In the case of derivatives that have remained outstanding at the date of
application of the new reporting requirements, the process referred to in paragraph 589, should be performed by the TRs at the earliest opportunity and no later than by the end of the transition period.
6.2 Reconciliation
6.2.1 Scope of data subject to reconciliation
591. TRs should ensure consistent determination of the scope of data subject to
reconciliation. TRs therefore should only include in the reconciliation process derivatives, both at trade and at position level, where all the below conditions are fulfilled:
a. Counterparty 1 has reporting obligation, i.e. it is a counterparty established in the EU or an AIF, whose AIFM is established in the EU, based on the GLEIF. b. Counterparty 2 has reporting obligation as indicated if established in the EU or an AIF, whose AIFM is established in the EU, based on the GLEIF or the field
1.14 ‘Reporting obligation of the counterparty 2’ is populated with ‘True’.
c. The derivative has not been subject to a report with action type ‘EROR’, unless
it has been followed by a report with action type ‘REVI’. d. The derivative is outstanding, as referred to in Article 2(2)(a) and 2(2)(b) of the ITS on reporting, or it has been outstanding in the last thirty calendar days.
592. TRs should include late reported derivatives in the reconciliation process if the
late report refers to an outstanding derivative subject to reconciliation.
593. TRs should remove derivatives from the reconciliation process that have been
non-outstanding for thirty-one calendar days or more, and this should be determined based on the earliest date reported in either field ’Expiration date’ or field ‘Early termination date’. Moreover, derivatives that have received a report with action type ’EROR’ should also be removed.
594. It is worth recalling that TRs should reconcile the data in line with the relevant
reconciliation tolerance, as well as the relevant start date as included in Table 2 of the Annex to the RTS on data quality.
6.2.2 Position-level vs trade-level reconciliation
595. TRs should therefore reconcile, both position-level and trade-level reports, as
determined by the latest applicable event date, which should be two working days before the date on which the reconciliation takes place. For instance, in case the reconciliation takes place on Wednesdays, TRs should include the derivatives reported whose event date is Monday or earlier. In case the reconciliation takes place on Monday, the TRs should include the derivatives whose event date is Thursday or earlier. TARGET 2 calendar should be used to determine working days.

218
Table 89– Information flow asymmetries between the reconciliation process performed
with a 2-day lag and the TSR
Business day
Event date Events
T T
• Counterparties 1 and 2 execute a new derivative contract on
event date T
• Counterparty 1 sends the report to the TR on business day T
T+1 T+1
• Counterparty 2 sends the report to the TR on business day
T+1
• TSR delivered on business day T+1 by 06.00 UTC to
entities / 12.00 UTC to authorities include the latest state of reported derivatives on business day T with event date T-1 or earlier, i.e. above derivative is not included.
• Reconciliation report delivered on business day T+1 by
06.00 UTC to entities / 12.00 UTC to authorities for event
date T-2 or earlier does not include the above derivative
• Reconciliation process runs until midnight UTC for reported
derivatives during business day T or earlier with event date T-1 or earlier. T+2 T+2
596. TSR delivered on business day T+2 by 06.00 UTC to
entities / 12.00 UTC to authorities include the latest state of reported derivatives on business day T+1 with event date T or earlier, i.e. above derivative is included but has not yet been subject to reconciliation (reconciliation flag = “NA”).
• Reconciliation report delivered on business day T+2 by
06.00 UTC to entities / 12.00 UTC to authorities for event
date T-1 or earlier does not include the above derivative
• Reconciliation process runs until midnight UTC for reported
derivatives during business day T+1 or earlier with event date T or earlier. T+3 T+3
597. TSR delivered on business day T+3 by 06.00 UTC to
entities / 12.00 UTC to authorities include the latest state of reported derivatives on business day T+2 with event date T+1 or earlier, i.e. above derivative is included and has

219 been subject to reconciliation (reconciliation flag is updated accordingly)
• Reconciliation report delivered on business day T+3 by
06.00 UTC to entities / 12.00 UTC to authorities for event
date T or earlier include above derivative.
6.2.3 Reconciliation of valuation
598. The reconciliation of valuation from trade-level or position-level perspective
should follow the guidance provided in section 6.2.2.
599. When one of the counterparties to the derivative is an NFC-, that entity is not
required to report valuation data. Even if an entity not obliged to report valuation information does so, TRs should omit such information from the reconciliation process.
600. When both counterparties have an obligation to report valuations, TRs should
include all the relevant valuation data in the reconciliation process and flag the derivatives where one of the counterparties have not reported valuation or where there are reconciliation breaks between the information as not reconciled.
601. Please refer to section 6.3.3 on the interplay of the reconciliation of valuation
status with the reconciliation status of the derivative.
6.2.4 Derivatives with two legs

TRs should reconcile derivatives with two legs by reconciling each of the
legs as reported by the counterparties.
It is worth noting that in the case of most types of derivatives with two legs such
as interest-rate swaps, cross-currency swaps and FX swaps, the order of the legs cannot be unequivocally defined, as there is no specific prevalence of one leg over the other. Therefore, when counterparties report inconsistently the two legs of the derivative, the TR should intend matching the two legs irrespective of the sequence, taking into account the values reported by the two counterparties under field ‘Direction of leg 1’ by matching the legs with opposite values. In case counterparty 1 has reported it with ‘payer’ the TR should reconcile it with the leg that is identified as ‘receiver’ or with the leg that is not identified, when leg 1 is identified with ‘payer’.
When an outstanding position is the result of netting of a position to zero (Level
= P and Quantity=0), TR should exclude from the reconciliation the fields ‘Direction’, ‘Direction of leg 1’ and ‘Direction of leg 2’.
6.2.5 Reconciliation of schedule information
TRs should only reconcile the data on schedule fields that are included in the
TSR. This approach is aligned with the one described in section 6.1.6 Inclusion in the TSR of schedule information.

220
6.3 Data Quality feedback
6.3.1 Rejection feedback
605. Article 1(1) of the RTS on data quality requires the TRs to verify the data they
receive from the report submitting entities upon their reception. In accordance with
Article 1(3) of the RTS on data quality TRs shall provide the RSEs with detailed
information on the results of the data verification. This immediate rejection feedback shall be provided to the relevant RSE within 60 minutes from the reception of the data, i.e. from the moment the submitted file enters the system of the TR.
606. Apart from the provision of immediate rejection response to the RSE, the TR
can provide this feedback also to the reporting counterparties and entities responsible for reporting if those have access to the TR and they express interest to receive the immediate rejection response.
607. Article 1(1) of the RTS on data quality provides a list of specific verification
checks which should be executed by the TRs. Authentication according to Article 1(1)(a) should be performed upfront, therefore no specific rejection feedback should be provided with respect to this first verification step. The remaining verification checks should be performed at the point of submission and result in rejection feedback in accordance with the following rejection categories:
a. Schema validation of a submission as per Article 1(1)(b); b. Authorization / permission of a report submitting entity as per Article 1(1)(c);
c. Logical validation of a submission as per Articles 1(1)(d) to 1(1)(k);
d. Business rules or content validation of a submission as per Article 1(1)(l), as clarified by these Guidelines.
608. Under Article 1(2) of the RTS on data quality a TR shall “reject a derivative report
that does not comply with one of the requirements set out in paragraph 1 and assign to it one of the rejection categories” mentioned above.
609. To implement these verification checks TRs should apply validation rules to
ensure that reporting is performed according to the EMIR regime, including the specifications of the technical standards, as clarified by these Guidelines. Accordingly, reporting counterparties or submitting entities should comply with the reporting requirements specified by the validation rules which are published together with these Guidelines on ESMA’s website.
610. To keep the technical aspects of the data quality requirements relevant and
correctly applied, ESMA updates the validation rules when necessary or appropriate. When the validation rules are updated, ESMA specifies the effective day of application of the updated validation rules and the TRs should ensure that they implement the changes in the specified timeframe and start performing the verification checks with the updated validation rules on the designated date of application.

221
611. Similarly the reporting counterparties, ERRs or RSEs as applicable should
update their reporting systems so that the submitted reports are compliant with the new validation rules on the designated date of application.
612. The validation rules contain a specific error code and error message containing
an xml path for each of the validation rules and the TRs should use these error codes and messages to specify the rejection reason when communicating rejections to the relevant parties. When a derivative report is rejected, the rejection response should contain all the error codes of the validation rules that the submitted derivative report failed. Therefore, the information on the error codes should be provided at report level.
613. If the submitted report is correct and compliant with all the reporting
requirements, and with the technical specifications in the validation rules, the feedback should indicate that the derivative report was accepted.
614. The TR should verify compliance of the file with the XML schema (syntax of the
whole file and specific derivative reports). If the file is not compliant, the whole file (all derivatives included in the file) is rejected, and the reason will be that the file is ‘corrupted’. In the statistics this should be reported as 1 file rejection even if the file contradicts the XML schema in multiple instances.
615. If, however, the file is compliant with the XML schema and contains e.g. 3
derivatives, but all the derivatives fail validations, the statistics should show the file as accepted with 3 rejected and 0 accepted derivatives.
616. Following the receipt of an immediate rejection response, to ensure their
compliance with the reporting obligation under Article 9 of EMIR, the reporting counterparties or ERR should, either directly or through a RSE, submit correct and complete reports by the reporting timeline.
617. Further to the immediate rejection feedback, Article 4(1)(c) of the RTS on data
quality requires the TRs to make available to the reporting counterparties, RSEs, ERRs and third parties which have been granted an access to EMIR data under
Article 78(7) of EMIR end-of-day reports of derivatives that have been rejected
during that day. As specified in the RTS on data quality, this report shall be made accessible by 6:00 UTC to entities and 12.00 UTC to authorities on the following working day. For the determination of working days TARGET 2 calendar should be used.
618. The TRs should use all the data they have collected to determine what
information they should provide and to which RSEs, ERRs and counterparties. Information on errors pertaining to the whole file should be made available to the RSE of the file and to all ERRs and counterparties populated in fields 1.3 and 1.4 in that rejected file as applicable, assuming it is possible to read the information from the rejected file. Information on errors pertaining to a specific record should be made available to the RSE, ERR and counterparty 1 populated in this record to the extent the entities are on-boarded.
619. Regarding the deadlines for provision of (immediate and end-of-day) rejection
response under special circumstances, such as scheduled or non-scheduled

222 maintenance, the TRs should proceed analogously to the existing guidance on operational aspects on data access, as detailed in section 6.4.1.
6.3.1.1 Immediate rejection feedback
620. Immediate rejection response shall according to Article 1(3) of the RTS on data
quality be provided by the TRs in the standardized response messages compliant with ISO 20022 format, specifically the XSD schema. It should contain the following information:
Table 90 - Immediate rejection feedback
No. Field Details to be reported XML Message 1 File identification Textual value … <RjctnSttstcs> <CtrPtyId> <RptgCtrPrty> <LEI>12345678901234500000</LEI> </RptgCtrPrty> <RptSubmitgNtty> <LEI>12345678901234500000</LEI> </RptSubmitgNtty> <NttyRspnsblForRpt> <LEI>12345678901234500000</LEI> </NttyRspnsblForRpt> </CtrPtyId> <RptSttstcs> <TtlNbOfRpts>1</TtlNbOfRpts> <TtlNbOfRptsAccptd>1 </TtlNbOfRptsAccptd> <TtlNbOfRptsRjctd>0 </TtlNbOfRptsRjctd> </RptSttstcs> <DerivSttstcs> <DtldSttstcs> <TtlNbOfTxs>10 </TtlNbOfTxs> <TtlNbOfTxsAccptd>9 </TtlNbOfTxsAccptd> <TtlNbOfTxsRjctd>1 </TtlNbOfTxsRjctd> <TxsRjctnsRsn> <TxId> <ActnTp>NEWT</ActnTp> <RptgTmStmp> 2025-0407T10:00:00Z </RptgTmStmp> <DerivEvtTp>TRAD </DerivEvtTp> <EvtTmStmp><Dt> 2025-04-07 </Dt></EvtTmStmp> <OthrCtrPty> <Lgl><LEI> 2 Rejection reason Error code 3 Rejection description Error description 4 Number of derivatives received 10 5 Number of derivatives accepted 9 6 Number of derivatives rejected 1 7 Identification of the derivatives 8 Counterparty 1 (Reporting counterparty) 123456789012345 00000 9 Counterparty 2 ABCDEFGHIJKLM NOPQRST 10 UTI UTI1 11 Reporting timestamp 2025-04-07T10:00:00Z 12 Event date 2025-04-07 13 Event type TRAD 14 Action type NEWT 15 Status Accepted ACPT 16 Status Rejected RJCT 17 Rejection reason EMIR-VR-1001-6

223
621. Where the rejection pertains to field 1.4 ‘Counterparty 1 (Reporting
counterparty)’ or field ‘1.9 Counterparty 2’, these fields might not be populated in the rejection report.
6.3.1.2 End-of-day rejection report
622. End-of-day rejection report shall be provided by the TRs in the standardized
response messages compliant with ISO 20022 format in accordance with Article 4(1)(c) of the RTS on data quality, specifically the XSD schema. It should contain the following information:
Table 90 - Immediate rejection feedback
No. Field Details to be reported XML Message ABCDEFGHIJKLMNOPQRST </LEI></Lgl> </OthrCtrPty> <TxId> <UnqTxIdr> UTI1 </UnqTxIdr> </TxId> <Sts>RJCT</Sts> <DtldVldtnRule> <Id>EMIR-VR-1001-6</Id> <Desc>Xpath of the Erroneous field</Desc> </DtldVldtnRule> </TxsRjctnsRsn> </DtldSttstcs> … 18 Rejection description Xpath of the erroneous field
Table 91 - End-of-day rejection report
No. Field Details to be reported XML Message 1 Number of files received 3 … <RjctnSttstcs> <CtrPtyId> <RptgCtrPrty> <LEI>12345678901234500000</LEI> </RptgCtrPrty> <RptSubmitgNtty> <LEI>12345678901234500000</LEI> </RptSubmitgNtty> <NttyRspnsblForRpt> 2 No. of files accepted 2 3 No. of files rejected 1 4 File identification REPORT1 5 Rejection reason CRPT 6 Rejection description File is corrupted 7 Number of derivatives received 10

224
Table 91 - End-of-day rejection report
No. Field Details to be reported XML Message 8 Number of derivatives accepted 9 <LEI>12345678901234500000</LEI> </NttyRspnsblForRpt> </CtrPtyId> <RptSttstcs> <TtlNbOfRpts>3</TtlNbOfRpts> <TtlNbOfRptsAccptd>2 </TtlNbOfRptsAccptd> <TtlNbOfRptsRjctd>1 </TtlNbOfRptsRjctd> <NbOfRptsRjctdPerErr> <DtldNb>1</DtldNb> <RptSts> <MsgRpId>REPORT1</MsgRpId> <Sts>CRPT</Sts> </RptSts> </NbOfRptsRjctdPerErr> </RptSttstcs> <DerivSttstcs> <DtldSttstcs> <TtlNbOfTxs>10 </TtlNbOfTxs> <TtlNbOfTxsAccptd>9 </TtlNbOfTxsAccptd> <TtlNbOfTxsRjctd>1 </TtlNbOfTxsRjctd> <TxsRjctnsRsn> <TxId> <ActnTp>NEWT</ActnTp> <RptgTmStmp> 2025-0407T10:00:00Z </RptgTmStmp> <DerivEvtTp>TRAD </DerivEvtTp> <EvtTmStmp><Dt> 2025-04-07 </Dt></EvtTmStmp> <OthrCtrPty> <Lgl><LEI> ABCDEFGHIJKLMNOPQRST </LEI></Lgl> </OthrCtrPty> <TxId> <UnqTxIdr> UTI1 </UnqTxIdr> </TxId> <Sts>RJCT</Sts> <DtldVldtnRule> <Id>EMIR-VR-1001-6</Id> <Desc>Xpath of the erroneous field</Desc> </DtldVldtnRule> 9 Number of derivatives s rejected 1 10 Identification of the derivatives 11 Counterparty 1 (Reporting counterparty) 123456789012345 00000 12 Counterparty 2 ABCDEFGHIJKLM NOPQRST 13 UTI UTI1

225
623. Where the rejection pertains to field 1.4 ‘Counterparty 1 (Reporting
counterparty)’ or field 1.9 ‘Counterparty 2’, these fields might not be populated in the rejection report.
624. End-of-day rejection report should be provided electronically in ISO 20022 XML
message. TRs could, in addition, use another interface so that e.g. in case the reporting counterparty or the entity responsible for reporting are not reporting directly to the TR, but have a view only account, will be able to have detailed understanding on their compliance with the reporting obligation under EMIR.
6.3.2 Warnings feedback
625. Article 4(1)(e) to 4(1)(g) of the RTS on data quality requires the TRs to make
available to the reporting counterparties, RSEs, ERRs and third parties which have been granted an access to EMIR data under Article 78(7) of EMIR end-of-day reports on missing valuations of outstanding derivatives, missing margin information of outstanding derivatives, as well as on abnormal values reported in the fields.
626. These end-of-day reports shall be made accessible to entities by 6:00 UTC and
to authorities by 12.00 UTC on the following working day. For the determination of working days TARGET 2 calendar should be used.
627. The TRs should use all the data they have collected to determine what
information they should provide and to which RSEs, ERRs and counterparties.
628. The inclusion of derivatives into the end-of-day warnings feedback reports for
missing valuations and margin information should follow the same rules as the inclusion of derivatives into the Trade State Report as described in detail in section
Table 91 - End-of-day rejection report
No. Field Details to be reported XML Message </TxsRjctnsRsn> </DtldSttstcs> … 14 Reporting timestamp 2025-04- 07T10:00:00Z 15 Event date 2025-04-07 16 Event type TRAD 17 Action type NEWT 18 Status Accepted ACPT 19 Status Rejected RJCT 20 Rejection reason EMIR-VR-1001-6 21 Rejection description Xpath of the erroneous field

226
6.1. Therefore, the warnings should be provided on the basis of TSR and for
example dead derivatives should be excluded (as explained in section 6.1.7).
629. The inclusion of derivatives into the end-of-day warnings feedback report for
abnormal values should instead be based on the TAR, where reports received with action type ‘New’, ‘Position component’, ‘Modify’ or ‘Correct’ should be used for this purpose.
630. The number of derivatives included in the warnings feedback reports should be
assessed from the viewpoint of counterparty 1.
631. End-of-day warnings feedback reports on missing valuations and margin
information should exclude records pertaining to counterparties who are not obliged to submit daily valuations and margin information on outstanding derivatives. The identification of these out-of-scope records should be achieved by filtering field 1.5 ‘Nature of counterparty 1’ = ‘N’ and field 1.7 ‘Clearing threshold of counterparty 1’ = ‘False’. Moreover, the warnings feedback report on missing margin information should exclude uncollateralized trades. The identification of the out-of-scope uncollateralized records should be achieved by filtering field 3.11 ‘Collateralisation category’ = ‘UNCL’.
632. The TRs should provide the relevant data in scope for the warnings feedback
reports to the relevant RSEs, and to all ERRs and counterparties as applicable.
633. End-of-day reports providing information on missing or abnormal data do not
entail rejection of derivative reports, they are of informative nature and should provide warnings on possible faults in reporting to the relevant parties. Nevertheless, despite the informative nature, the reporting counterparties, ERRs and RSEs as applicable should always investigate the identified issues and if misreporting is confirmed the data should be corrected or missing data reported without undue delay.
634. Regarding the deadlines for provision of end-of-day warnings feedback reports
under special circumstances, such as scheduled or non-scheduled maintenance, the TRs should proceed analogously to the existing guidance on operational aspects on data access included under section 6.4.1.
635. End-of-day warnings feedback reports should be provided electronically in the
standardized response messages compliant with ISO 20022 format. TRs could, in addition, use another interface so that e.g. in case the reporting counterparty or the entity responsible for reporting are not reporting directly to the TR, but have a view only account, will be able to have detailed understanding on their compliance with the reporting obligation under EMIR Refit.
6.3.2.1 Missing valuations report
636. According to Article 4(1)(e) of the RTS on data quality the outstanding
derivatives for which no valuation has been reported, or the valuation that was reported is dated more than fourteen calendar days earlier than the day for which the report is generated shall be included in the end-of-day missing valuations

227 report. To provide the missing valuations feedback the TRs should use as reference the TSR generated in accordance with section 6.1.
637. Therefore, this report should include:
a) any outstanding derivative in scope of valuation reporting requirements for which field
2.21 ‘Valuation amount’ was never reported as well as
b) any outstanding derivative in scope of valuation reporting requirements for which field
2.21 ‘Valuation amount’ was reported at least once, but the most recent value of this
field, i.e. with most recent field 2.23 ‘Valuation timestamp’, has the value of this timestamp more than fourteen calendar days earlier than the day for which the report is generated.
638. End-of-day missing valuations report provided by the TRs in the standardized
response messages compliant with ISO 20022 format, specifically the XSD schema, should contain the information specified in the Table 92.
Table 92 - End-of-day missing valuations report
No. Field Details to be reported XML Message 1 Number of outstanding derivatives 10 <MssngValtn> <Rpt> <NbOfOutsdngDerivs>10 </NbOfOutsdngDerivs> <NbOfOutsdngDerivsWithNoValtn>1 </NbOfOutsdngDerivsWithNoValtn> <NbOfOutsdngDerivsWithOutdtValtn>0 </NbOfOutsdngDerivsWithOutdtValtn> <Wrnngs> <CtrPtyId> <RptgCtrPrty> <LEI>12345678901234500000</LEI> </RptgCtrPrty> <RptSubmitgNtty> <LEI>12345678901234500000</LEI> </RptSubmitgNtty> <NttyRspnsblForRpt> <LEI>12345678901234500000</LEI> </NttyRspnsblForRpt> </CtrPtyId> <NbOfOutsdngDerivs>10 </NbOfOutsdngDerivs> <NbOfOutsdngDerivsWithNoValtn>1 </NbOfOutsdngDerivsWithNoValtn> <NbOfOutsdngDerivsWithOutdtValtn>0 </NbOfOutsdngDerivsWithOutdtValtn> <TxDtls> <TxId> <OthrCtrPty> <Lgl><LEI> ABCDEFGHIJKLMNOPQRST </LEI></Lgl> </OthrCtrPty> 2 Number of outstanding derivatives with no valuation 1 3 Number of outstanding derivatives with outdated valuation 0 4 Identification of the derivatives 5 Counterparty 1 (Reporting counterparty) 123456789012345 00000 6 Counterparty 2 ABCDEFGHIJKLM NOPQRST 7 UTI UTI1 8 Valuation amount 5000000 EUR 9 Valuation timestamp 2023-04- 07T10:00:00Z

228
6.3.2.2 Missing margin information report
639. According to Article 4(1)(f) of the RTS on data quality the outstanding derivatives
for which no margin information has been reported, or the margin information that was reported is dated more than fourteen calendar days earlier than the day for which the report is generated shall be included in the end-of-day missing margin information report. To provide the missing margin information feedback the TRs should use as reference the TSR generated in accordance with section 6.1.
640. Therefore, this report should include:
a. any outstanding derivative in scope of margin reporting requirements for which margin report was never reported with action type ‘MARU’ for the given UTI (or it was reported but then the UTI with corresponding margin was errored and no margin information was reported after reviving the derivative) and b. any outstanding derivative in scope of margin reporting requirements for which margin report was reported at least once, but the most recent report, i.e. with most recent field 3.7 ‘Collateral timestamp’, has the date value of this timestamp more than fourteen calendar days earlier than the day for which the report is generated.
641. End-of-day missing margin information report provided by the TRs in the
standardized response messages compliant with ISO 20022 format, specifically the XSD schema, should contain the information included in the below table. <UnqIdr> <UnqTxIdr> UTI1 </UnqTxIdr> </UnqIdr> </TxId> <ValtnAmt><Amt Ccy="EUR">5000000 </Amt></ValtnAmt> <ValtnTmStmp> 2023-04-07T10:00:00Z </ValtnTmStmp> </TxDtls> </Wrnngs> </MssngValtn>
Table 93 - End-of-day missing margin information report
No. Field Details to be reported XML Message 1 Number of outstanding derivatives 10 <MssngMrgnInf> <Rpt> <NbOfOutsdngDerivs>10 </NbOfOutsdngDerivs> <NbOfOutsdngDerivsWithNoMrgnInf>1 2 Number of outstanding derivatives with no margin information 1

229
6.3.2.3 Abnormal values report
642. According to Article 4(1)(g) of the RTS on data quality the derivatives that were
received with action type ‘New’, ‘Position component’, ‘Modify’ or ‘Correct’ whose
Table 93 - End-of-day missing margin information report
No. Field Details to be reported XML Message 3 Number of outstanding derivatives with outdated margin information 0 </NbOfOutsdngDerivsWithNoMrgnInf>

<NbOfOutsdngDerivsWithOutdtMrgnInf>0
</NbOfOutsdngDerivsWithOutdtMrgnInf>
<TxDtls>
<TxId>
<OthrCtrPty>
<Lgl><LEI>
ABCDEFGHIJKLMNOPQRST
</LEI></Lgl>
</OthrCtrPty>
<UnqIdr>
<UnqTxIdr>
UTI1
</UnqTxIdr>
</UnqIdr>
</TxId>
<CollTmStmp>
2023-04-07T10:00:00Z
</CollTmStmp>
</TxDtls>
</Wrnngs>
</MssngMrgnInf>
4
Identification of the derivatives
5
Counterparty 1 (Reporting counterparty)
123456789012345
00000
6 Counterparty 2
ABCDEFGHIJKLM
NOPQRST
7 UTI UTI1
8 Collateral timestamp
2023-04-
07T10:00:00Z

230 notional amount is greater than a threshold for that class of derivatives shall be included in the end-of-day abnormal values report.
643. Derivative reports received on the working day prior to the working day when
the feedback is generated by 6 a.m. UTC should be included in the warnings feedback report for the given day. If the TR accepts also submissions on nonworking days, the warnings feedback report should include also submitted reports received on non-working days preceding the working day when the feedback is generated (e.g. for Monday warnings feedback report submissions received on Friday, Saturday and Sunday).
644. Abnormal values (outliers) should be identified for the following fields:
c. 2.55 ‘Notional amount of leg 1’,
d. 2.59 ‘Notional amount in effect on associated effective date of leg 1’, e. 2.60 ‘Total notional quantity of leg 1’, f. 2.63 ‘Notional quantity in effect on associated effective date of leg 1’, g. 2.64 ‘Notional amount of leg 2’, h. 2.68 ‘Notional amount in effect on associated effective date of leg 2’,
i. 2.69 ‘Total notional quantity of leg 2’,
j. 2.72 ‘Notional quantity in effect on associated effective date of leg 2’.
645. A derivative report should be included into the warnings feedback report when
at least one of the listed fields was populated with an abnormal value. If the derivative report contains abnormal values for more than one field, all of these abnormal values should be indicated in the feedback.
646. The values of these fields should be converted into the EUR equivalent amounts
for the purpose of abnormal values detection.
647. Abnormal values should be identified for each class and level of derivatives
(credit, commodity, currency, equity, interest rates), as categorized by field 2.11 ‘Asset class’, and field 2.154 ‘Level’ separately.
648. To ensure compliance with Article 4(1)(g) of the RTS on data quality, the TR
should inform ESMA on the outlier detection method chosen and the thresholds applied for that particular method.
649. The TR should also make the information on outlier detection method and
thresholds available to the relevant entities receiving end-of-day abnormal values reports, so that they are fully informed about the content of these reports.
650. End-of-day abnormal values report provided by the TRs in the standardized
response messages compliant with ISO 20022 format, specifically the XSD schema, should contain the information included in the below table.
Table 94 - End-of-day abnormal values report

231
No. Field Details to be reported XML Message 1 Number of derivatives reported with NEWT, POSC, MODI, CORR 10 <AbnrmlVals> <Rpt> <NbOfDerivsRptd>10 </NbOfDerivsRptd> <NbOfDerivsRptdWthOtlrs>1 </NbOfDerivsRptdWthOtlrs> <Wrnngs> <CtrPtyId> <RptgCtrPrty> <LEI>12345678901234500000</LEI> </RptgCtrPrty> <RptSubmitgNtty> <LEI>12345678901234500000</LEI> </RptSubmitgNtty> <NttyRspnsblForRpt> <LEI>12345678901234500000</LEI> </NttyRspnsblForRpt> </CtrPtyId> <NbOfDerivsRptd>10 </NbOfDerivsRptd> <NbOfDerivsRptdWthOtlrs>1 </NbOfDerivsRptdWthOtlrs> <TxDtls> <TxId> <ActnTp>NEWT</ActnTp> <RptgTmStmp> 2025-0407T10:00:00Z </RptgTmStmp> <DerivEvtTp>TRAD </DerivEvtTp> <DerivEvtTmStmp><Dt> 2025-04-07 </Dt></DerivEvtTmStmp> <OthrCtrPty> <Lgl><LEI> ABCDEFGHIJKLMNOPQRST </LEI></Lgl> </OthrCtrPty> <TxId> <UnqTxIdr> UTI1 </UnqTxIdr> </TxId> <NtnlAmt> <FrstLeg> <Amt> <Amt Ccy="EUR">10000</Amt> </Amt> <SchdlPrd> <Amt> <Amt Ccy="EUR">10000</Amt> </Amt> </SchdlPrd> </FrstLeg> 2 Number of derivatives reported with outliers 1 3 Identification of the derivatives 4 Counterparty 1 (Reporting counterparty) 123456789012345 00000 5 Counterparty 2 ABCDEFGHIJKLM NOPQRST 6 UTI UTI1

232
6.3.3 Reconciliation feedback
651. In Table 3 to the Annex of the RTS on data quality, ESMA has included different
categories of statuses for a derivative, as follows:
Table 95
Reconciliation categories Allowable values Reporting requirement for both counterparties Yes/No <ScndLeg> <Amt> <Amt Ccy="GBP">3000</Amt> </Amt> <SchdlPrd> <Amt> <Amt Ccy="EUR">3000</Amt> </Amt> </SchdlPrd> </ScndLeg> </NtnlAmt> </TxDtls> </Wrnngs> </AbnrmlVals> 7 Reporting timestamp 2025-04- 07T10:00:00Z 8 Event date 2025-04-07 9 Event type TRAD 10 Action type NEWT 11 Notional amount of leg 1 Field 2.55 or blank if no outlier detected 12 Notional amount in effect on associated effective date of leg 1 Field 2.59 or blank if no outlier detected 13 Total notional quantity of leg 1 Field 2.60 or blank if no outlier detected 14 Notional quantity in effect on associated effective date of leg 1 Field 2.63 or blank if no outlier detected 15 Notional amount of leg 2 Field 2.64 or blank if no outlier detected 16 Notional amount in effect on associated effective date of leg 2 Field 2.68 or blank if no outlier detected 17 Total notional quantity of leg 2 Field 2.69 or blank if no outlier detected 18 Notional quantity in effect on associated effective date of leg 2 Field 2.72 or blank if no outlier detected

233
Table 95
Reconciliation categories Allowable values Reporting type Single-sided/dual-sided Pairing Paired/unpaired Reconciliation Reconciled/not reconciled Valuation reconciliation Reconciled/not reconciled Revived Yes/No Further modifications: Yes/No
652. The category ‘Reporting requirement for both counterparties’ should be filled by
the TR based on the information in field 1.14. Where the field is populated ‘True’, then the status of the reconciliation category should be ‘Yes’, otherwise it should be ‘No’.
653. The category ‘Reporting type’ should be populated with ‘Single-sided’ when the
TR has received only one side of the derivatives, and ‘Dual-sided’ when both counterparties have reported to the same TR.
654. The category ‘Pairing’ should be populated with ‘Paired’ when the TR has been
able to identify the two sides of the same derivative or ‘Unpaired’ when it has not yet been able to do so. When a TR identifies a derivative as ‘Dual-sided’ in the category ‘Reporting type’, it should only identify it as ‘Paired’ in the category ‘Pairing’.
655. Only derivatives that have been paired can be reconciled. Therefore status of
‘Reconciled’ for either the category ’Reconciliation‘ or the category ‘Valuation reconciliation’ should only be assigned by the TR for derivatives that are ‘Paired’.
656. The TRs should take into account that valuation updates for ETD trades are
reported at position level and that NFC- are not obliged to submit valuation updates for their derivatives. These cases should be flagged in the schema as ‘Not applicable’ as opposed to categorising them as ‘Not reconciled’.
657. The TRs should identify as ‘Reconciled’ only those derivatives for which all the
reconcilable fields are within the allowed tolerances of reconciliation.
658. Finally, the population of the categories ‘Revived’ and ‘Further modifications’ is
independent from the rest of reconciliation categories. Category ‘Further modifications’ should be set to ‘Yes’ when a lifecycle event other than ‘NEWT’ is received, and this value should be kept until the updated derivative contract is reconciled. Category ‘Revive’ should be set to ‘Yes’ when a lifecycle event ‘REVI’ is received, and this value should be kept until the derivative contract is no longer outstanding.
659. In the table included below all the allowable combinations are included. TRs
should only use the below combinations when providing reconciliation feedback.

234
Table 96
Reporting requirement for both counterparties Reporting type Pairing Reconciliation Valuation reconciliation* Revived Further modifications No Single-sided Unpaired Not reconciled Not reconciled No Single-sided Unpaired Not reconciled Not reconciled Yes No No Single-sided Unpaired Not reconciled Not reconciled No Yes No Single-sided Unpaired Not reconciled Not reconciled Yes Single-sided Unpaired Not reconciled Not reconciled No No Yes Single-sided Unpaired Not reconciled Not reconciled Yes No Yes Single-sided Unpaired Not reconciled Not reconciled No Yes Yes Single-sided Unpaired Not reconciled Not reconciled Yes Single-sided Paired Not reconciled Not reconciled No No Yes Single-sided Paired Not reconciled Not reconciled Yes No Yes Single-sided Paired Not reconciled Not reconciled No Yes Yes Single-sided Paired Not reconciled Not reconciled Yes Single-sided Paired Reconciled Not reconciled No No Yes Single-sided Paired Reconciled Not reconciled Yes No Yes Single-sided Paired Reconciled Not reconciled No Yes Yes Single-sided Paired Reconciled Not reconciled Yes Single-sided Paired Reconciled Reconciled No No Yes Single-sided Paired Reconciled Reconciled Yes No Yes Single-sided Paired Reconciled Reconciled No Yes Yes Single-sided Paired Reconciled Reconciled Yes Single-sided Paired Not reconciled Reconciled No No Yes Single-sided Paired Not reconciled Reconciled Yes No Yes Single-sided Paired Not reconciled Reconciled No Yes Yes Single-sided Paired Not reconciled Reconciled Yes Dual-sided Paired Not reconciled Not reconciled No No Yes Dual-sided Paired Not reconciled Not reconciled Yes No Yes Dual-sided Paired Not reconciled Not reconciled No Yes Yes Dual-sided Paired Not reconciled Not reconciled Yes Dual-sided Paired Reconciled Not reconciled No No Yes Dual-sided Paired Reconciled Not reconciled Yes No Yes Dual-sided Paired Reconciled Not reconciled No Yes Yes Dual-sided Paired Reconciled Not reconciled Yes Yes

235
6.3.3.1 Immediate feedback
660. When providing the immediate reconciliation feedback in accordance with
Article 3(5) of the RTS on data quality, the TRs shall provide information only about
those derivatives that have been subject to reconciliation in the relevant reconciliation cycle.
661. The following information should be included in the reconciliation feedback:
Table 97 - Reconciliation Feedback
No. Field Details to be reported
XML Message
1
Reporting counterparty
123456789012345
00000
<Rpt>
…
<RcncltnCtgrs>
<RptgRqrmnt>
<RptgTp>TWOS</RptgTp>
<Pairg>PARD</Pairg>
<Rcncltn>RECO</Rcncltn>
<ValtnRcncltn>RECO
</ValtnRcncltn>
<Rvvd>true</Rvvd>
<FrthrMod>true</FrthrMod>
</RptgRqrmnt>
</RcncltnCtgrs>
<TtlNbOfTxs>10</TtlNbOfTxs>
<TxDtls>
<CtrPtyId>
<RptgCtrPrty>
<LEI>
2 UTI Field 2.1
3
Other counterparty Field 1.11
4
Reporting requirement for both counterparties True 5 Reporting type Dual-sided 6 Pairing Paired 7 Reconciliation Reconciled 8 Valuation reconciliation Reconciled 9 Revived True
Table 96
Reporting requirement for both counterparties Reporting type Pairing Reconciliation Valuation reconciliation* Revived Further modifications Yes Dual-sided Paired Reconciled Reconciled No No Yes Dual-sided Paired Reconciled Reconciled Yes No Yes Dual-sided Paired Reconciled Reconciled No Yes Yes Dual-sided Paired Reconciled Reconciled Yes Dual-sided Paired Not reconciled Reconciled No No Yes Dual-sided Paired Not reconciled Reconciled Yes No Yes Dual-sided Paired Not reconciled Reconciled No Yes Yes Dual-sided Paired Not reconciled Reconciled Yes Yes *Should be populated in certain cases with “Not applicable” as per paragraph 656

236
Table 97 - Reconciliation Feedback
No. Field Details to be reported
XML Message
10
Further modifications
True
12345678901234500000
</LEI>
</RptgCtrPrty>
…
</CtrPtyId>
<TtlNbOfTxs>10</TtlNbOfTxs>
<RcncltnRpt>
<TxId>
<OthrCtrPty>
<Lgl><LEI>
ABCDEFGHIJKLMNOPQRST
</LEI></Lgl>
</OthrCtrPty>
<UnqIdr>
<UnqTxIdr>
UTI1
</UnqTxIdr>
</UnqIdr>
</TxId>
<MtchgCrit>
…
</MtchgCrit>
</RcncltnRpt>
</TxDtls>
</Rpt>
6.3.3.2 End-of-day reconciliation information
662. When providing end-of-day reconciliation information included in Article 4(1)(d)
of the RTS on data quality, the TR should provide information about all derivatives that are in the scope of the reconciliation process.
6.4 Data access
6.4.1 Operational aspects
663. When providing access to transaction data in accordance with Article 2 of the
RTS on data access, TRs should include all details of derivatives, irrespective of whether the report for a derivative has been accepted or rejected by the TR. Further clarifications to the requirement in the RTS on data access are provided in the below paragraphs.
664. A Union competent authority (including the competent authorities of the EU
Member States) has access to all transaction data on all derivatives concluded by a counterparty that fall within the scope of that authority, where such counterparty

237 is reported under field 1.4 ‘Counterparty 1 (reporting counterparty )’ or field 1.9 ‘Counterparty 2’).
665. A competent authority from a Member State has access to all transaction data
on all derivatives concluded by a counterparty that is from the same Member State, where these competent authorities should be provided with access to data in accordance with Article 81(3) of EMIR.
666. Union securities and market authorities, as referred to in Article 81(3)(j) of EMIR,
should be given access to all transaction data on derivatives when it is the Relevant Competent Authority (RCA) according to FIRDS either in relation to the derivative itself (field 2.7) or the underlying (field 2.14). Considering that the RCA may change over time, trade repositories are expected to provide access to the authority designated as RCA at the time the report is generated.
667. Union securities and market authorities, as referred to in Article 81(3)(j) of EMIR,
should be given access to all transaction data on derivatives where the field ‘Underlying identification type’ (field 2.13) is reported with an ‘X’ or a ‘B’ and the field ‘Underlying identification’ (field 2.14) is populated with either:
a. ISIN of the underlying index or an ISIN belonging to any of the individual components of the underlying basket, whose first two letters represent the country code of that competent authority, or an ISIN belonging to any of the individual components of the underlying basket, where the Relevant Competent Authority (RCA) as determined in the FIRDS database is that competent authority, or b. ISIN of the underlying index or an ISIN belonging to any of the individual components of the underlying basket of indices, whose first two letters do not represent the country code of that competent authority, however is needed for that authority in order to perform its responsibilities and mandates, or
c. full names (assigned by index providers) or standardised 4-letter codes of
additional indices that, though not identified by ISIN, are needed for that authority in order to perform its responsibilities and mandates.
668. In that regard, each competent authority can provide ESMA with an up to date
list of the ISINs and/or full names (assigned by index providers) of additional indices and/or indicators of the underlying index for which that authority also requires access to transaction data if a given index is identified in the report as the underlying index or a component of the underlying basket or a list with principles, e.g. derivatives referring to stock issued in a member state if a detailed list of derivative types or underlyings is not feasible and might result in an undue restriction of data access. That list should be maintained by ESMA, based on the information provided by the authorities, and made available to Trade Repositories. The TRs should filter the list of indices without taking into account case-sensitiveness of the reported characters.
669. From the perspective of providing access based on the UPI, the TRs should
make use of the available information published by ANNA-DSB.

238
670. The TRs should establish the data access of the third country authorities in
accordance with Article 3 of the RTS on data access.
671. Articles 5(7) and 5(8) of the RTS on data access, do not refer to the timelines
that trade repositories should follow in the event of carrying out scheduled maintenance that impacts TR services related to authorities’ access to data, irrespective of the channel or format used.
672. Trade repositories should plan carefully the scheduled maintenance that
impacts TR services related to authorities’ access to data so that it does not coincide with working days determined in accordance with a calendar consistently agreed in the Union such as the TARGET 2 calendar. Where under exceptional circumstances it coincides with such a working day, the scheduled maintenance should be carried out outside normal working hours, i.e. very early in the morning or very late at night. The trade repositories should make sure that the aforementioned scheduled maintenance is not performed in a way that circumvents the timely availability of derivatives information to authorities.
673. Trade repositories should use electronic means to notify all authorities of the
start and end dates and times of their scheduled maintenance as fast as technically possible.
674. Where an annual planning of scheduled maintenance windows that impact TR
services related to authorities’ access to data exists at the TR, the TR should notify all authorities of that planning on an annual basis and with at least three working days’ notice. Furthermore, any additional specific notifications on scheduled maintenance that impact TR services related to authorities’ access to data, that are not notified on an annual basis, should be made at the earliest opportunity and at least three working days before the starting date of the scheduled maintenance that impacts TR services related to authorities’ access to data.
675. Trade repositories should keep a record of the relevant notifications that can be
made available to ESMA upon request. The records related to scheduled maintenance notifications should contain, at least, the following information: the timestamp of the notification, the start and the end of the scheduled maintenance that impacts TR services related to authorities’ access to data and the relevant list of users notified.
676. In the case of verification of requests under Article 5(8) of the RTS on data
access, trade repositories should confirm receipt and verify the correctness and completeness of any request to access data, at the earliest opportunity and no later than sixty minutes after the finalisation of the relevant scheduled maintenance that impacts TR services related to authorities’ access to data.
677. In the case of non-scheduled maintenance, the trade repositories should meet
the timelines included in Articles 5(7) and 5(8) of the RTS on data access and these timelines will be taken as reference when assessing the compliance of the trade repository.

239
678. Trade repositories should notify ESMA and the entities listed in Article 81(3) of
EMIR that have access to data at that TR of the non-scheduled maintenance in accordance with their procedures.
6.4.2 Template form for data access
679. TRs should use the following template, presented across the below subsections
to set up the access to derivatives data pursuant to Article 4 of the RTS on data access.
680. As positions and tasks may change, an entity listed in Article 81(3) of EMIR
should only lay down its mandate, but not any information regarding their internal organisation.
681. TRs should ensure regular review of data access for authorities, on an ongoing
basis as soon as they become aware of a change and at least once per year and should update the data access in accordance with the same timeline for the initial set up of access as per Article 4(1) of the RTS on data access.
682. As per Article 4 (1) (d) of the RTS on data access, TRs should set up access to
details of transaction data on derivatives for the entities listed in Article 81(3) of EMIR based on the information provided in the form referred to in the Article 4(2) of the RTS on data access. It is therefore important that the information provided in the form is as accurate and complete as possible and to this end TRs are expected to proactively engage with the authorities. In particular, if a TR, based on the information it has collected and analyzed, believes that there are errors or omissions in the form (for instance, a specific mandate has not been ticked by an authority), the TR should contact the authority and confirm the scope of its mandate, as soon as feasible and with a view to ensure the provision of access as per the timeline set out in Article 4(1) (f) of the RTS on data access. TRs should make use of publicly available data, for instance ESMA registers for CCP and trading venues, to confirm the information included by Authorities in the data access form as well as to monitor any potential updates to their mandates.
683. For the provision of access to authorities under Article 81(3) (f) of EMIR TRs
should be provided by each authority with the list of MIC codes under its supervision in the access form.
684. The list of EMIR fields to be used by TRs for filtering data for each of the
mandates listed in Article 81(3) of EMIR can be found in Table 96 below. If at least one field contains information based on which it can be determined that the authority is entitled to receive the data, then this data should be made available to this authority.
685. With regard to calculated position data access, each specific regulatory field
should be used by TRs to determine which position data should be made available to authorities, e.g. by currency. To establish the access to derivatives reported at position level, TRs should follow the same rules as for derivatives reported at transaction level.

240
686. With regard to takeover bids, TRs should retrieve data related to all the involved
parties as e.g. in takeover bids / offers / securities as defined in Article 2 of Directive 2004/25/EC.
6.4.2.1 Contact information
TABLE 98
Regulator Information and Authorised signatory Full name of the entity (with English translation where appropriate) Click or tap here to enter text. Website of the entity listed in Article 81(3) EMIR Click or tap here to enter text. Authorised signatory contact name Click or tap here to enter text. Authorised signatory mailing address Click or tap here to enter text. Authorised signatory email address Click or tap here to enter text.
6.4.2.2 Contact details for TR data user (or team) at the entity listed under Article 81(3)
EMIR to receive important notifications

241
TABLE 99
Contact name Click or tap here to enter text.
Email address Click or tap here to enter text.
Phone number Click or tap here to enter text.
Credentials for a secure SSH FTP connection Click or tap here to enter text. TRACE code of the authority Click or tap here to enter text. Key of the authority Click or tap here to enter text. Any other technical information relevant to the entity's access to details of derivatives. Click or tap here to enter text.
6.4.2.3 EMIR Mandates applicable to a given entity listed in Article 81(3) EMIR
TABLE 100
(EU) 648/2012, Article 81(3) Comments (Please indicate each of the mandates that in your view allow you access to data and the relation between such mandate and the data requested. In the comments section please identify the legal instrument or enabling legislation in your jurisdiction that sets out the relevant mandate). Entity listed in Article 81(3) EMIR Comments Please Tick (A) ESMA Click or tap here to enter text. ☐ (B) EBA Click or tap here to enter text. ☐ (C) EIOPA Click or tap here to enter text. ☐ (D) The ESRB Click or tap here to enter text. ☐ (E)The competent authority supervising CCPs accessing the trade repositories Click or tap here to enter text. ☐ (F) The competent authority supervising the trading venues where the reported derivatives were concluded Click or tap here to enter text. ☐

242
Entity listed in Article 81(3) EMIR Comments Please Tick (G1) A member of the ESCB, whose currency is the euro Click or tap here to enter text. ☐ (G2) A member of the ESCB, whose currency is not the euro Click or tap here to enter text. ☐ (G3) The ECB Click or tap here to enter text. ☐ (H) The relevant authorities of a third country that has entered into an international agreement with the Union as referred to in Article 75. Click or tap here to enter text. ☐ (I) Supervisory authorities designated under Article 4 of Directive 2004/25/EC of the European Parliament and of the Council. Click or tap here to enter text. ☐ (J) The relevant European Union securities and market authorities whose respective supervisory responsibilities and mandate cover contracts, markets, benchmarks, participants and underlying which fall within the scope of EMIR Click or tap here to enter text. ☐ (K) The relevant authorities of a third country that has entered into a cooperation arrangement with ESMA, as referred to in Article 76 Click or tap here to enter text. ☐ (L) The Authority for the Cooperation of Energy Regulators established by Regulations (EC) No 713/2009 of the European Parliament and of the Council Click or tap here to enter text. ☐ (M) The resolution authorities designated under Article 3 of Directive 2014/59/EU of the European Parliament and the Council Click or tap here to enter text. ☐ (N) The Single Resolution Board established by Regulation (EU) No 806/2014 Click or tap here to enter text. ☐ (O) Competent authorities or national competent authorities within the meaning of Regulations (EU) No 1024/2013 and (EU) No 909/2014 and of Directives 2003/41/EC, 2001/61/EU, 2013/36/EU and, 2014/65/EU and supervisory authorities within the meaning of Directive 2009/138/EC Click or tap here to enter text. ☐ (P) The competent authorities designated in accordance with Article 10(5) of this regulation. Click or tap here to enter text. ☐

243
(Q) The relevant authorities of a third country in respect of which an implementing act pursuant to Article 76a has been adopted. Click or tap here to enter text. ☐ (R) the resolution authorities designated under Article 3 of Regulation (EU) 2021/23 Click or tap here to enter text. ☐
6.4.2.4 Relevant data fields for filtering
TABLE 101
The applicant is competent for counterparties in its Member State, the euro area or the Union Click or tap here to enter text. ☐ The types of counterparties for which the entity is competent as per the classification in Table 1 of Annex I to the RTS on reporting Click or tap here to enter text. ☐ Types of underlyings to derivatives for which the authority is competent Click or tap here to enter text. ☐ Trading venues that are supervised by the entity, if any Click or tap here to enter text. ☐ CCPs that are supervised or overseen by the entity, if any Click or tap here to enter text. ☐ Currency that is issued by the entity, if any Click or tap here to enter text. ☐ Delivery and interconnection points; Click or tap here to enter text. ☐ Benchmarks used in the Union, for whose administrator the entity is competent Click or tap here to enter text. ☐ Characteristics of underlyings that are supervised by that entity Click or tap here to enter text. ☐ Relevant clearing members, brokers and reference entity Click or tap here to enter text. ☐

244
Authorised Signatory:
Name: Click or tap here to enter text.
Title: Click or tap here to enter text.
Signature:
Date (dd/mmm/yyyy): Click or tap here to enter text.
6.4.3 EMIR fields for data filtering
687. According to Article 81(3) of EMIR a trade repository shall make the necessary
information available to the following entities to enable them to fulfil their respective responsibilities and mandates. In this regard the TRs should use the clarifications in the following table. The indicated fields are based on the existing empowerments and mandates at the time of the drafting of these Guidelines, hence TRs should not be bound by the clarifications included in these Guidelines, but proactively monitor the evolutions of the relevant responsibilities and mandates and adjust the access to authorities accordingly. Prior to implementing an adjustment, TRs should confirm it with ESMA and the relevant authority.
TABLE 102
List of entities in
Article 81 (3) EMIR Fields for filtering Values for filtering
a) ESMA N/A N/A b) EBA N/A N/A c) EIOPA N/A N/A d) The ESRB N/A N/A e) The competent authority supervising CCPs accessing the trade repositories Field 2.33 ‘Central counterparty’ List of LEIs provided by the Authority Field 1.4 ‘Counterparty 1 (Reporting counterparty)’ List of LEIs provided by the Authority Field 1.9 ‘Counterparty 2’ List of LEIs provided by the Authority f) The competent authority supervising the trading venues of the reported contracts Field 2.41 ‘Venue of execution’ ISO list for MIC codes, country code provided by the Authority

245 g) The relevant members of the ESCB, including the ECB in carrying out its tasks within a single supervisory mechanism under Council Regulation (EU) No 1024/2013 Field 2.144 ‘Reference entity’ GLEIF database filtered by euro area and a list of entities in non-euro area Member state subject to ECB SSM, as applicable Field 2.14 ‘Underlying identification’ Prefix for the Member State, EU, EZ, XS, XA, XB, XC, XD Field 1.4 ‘Counterparty 1 (Reporting counterparty)’ GLEIF database filtered by euro area and a list of entities in non-euro area Member state subject to ECB SSM, as applicable Field 1.9 ‘Counterparty 2’ GLEIF database filtered by euro area and a list of entities in non-euro area Member state subject to ECB SSM, as applicable Field 1.15 ‘Broker ID’ GLEIF database filtered by euro area and a list of entities in non-euro area Member state subject to ECB SSM, as applicable Field 1.16 ‘Clearing member’ GLEIF database filtered by euro area and a list of entities in non-euro area Member state subject to ECB SSM, as applicable h) The relevant authorities of a third country that has entered into an international agreement with the Union as referred to in
Article 75
N/A N/A i) Supervisory authorities designated under Article 4 of Directive 2004/25/EC of the European Parliament and of the Council Field 2.14 ‘Underlying identification’ Prefix for the Member State, EU, EZ, XS, XA, XB, XC, XD, and List of ISIN(s) provided by the Authority j) The relevant Union securities and market authorities whose respective supervisory responsibilities and mandate cover contracts, markets, benchmarks, participants and underlying which fall within the scope of EMIR Field 1.4 ‘Counterparty 1 (Reporting counterparty)’ GLEIF database filtered by euro area or non-euro area Member state, as applicable Field 1.9 ‘Counterparty 2’ GLEIF database filtered by euro area or non-euro area Member state, as applicable Field 1.15 ‘Broker ID’ GLEIF database filtered by euro area or non-euro area Member state, as applicable Field 1.16 ‘Clearing member’ GLEIF database filtered by euro area or non-euro area Member state, as applicable Field 2.14 ‘Underlying identification’ Relevant competent authority (RCA) from FIRDS database, prefix for the Member State, EU, EZ, XS, XA, XB, XC, XD Field 2.7 ‘ISIN’ Relevant competent authority (RCA) from FIRDS database, prefix for the Member State, EU, EZ, XS, XA, XB, XC, XD Field 2.41 ‘Venue of execution’ ISO list for MIC codes, country code to be provided by the Authority Field 2.8 ‘UPI’ List of UPI(s) provided by the Authority26 Field 2.15 ‘Indicator of the underlying index’ List of benchmark(s) provided by the Authority Field 2.16 ‘Name of the underlying index’ List of benchmark(s) provided by the Authority 26 Access to data based on the UPI comes in addition to any other mandates

246
Field 2.83 ‘Identifier of the floating rate of leg 1’ List of benchmark(s) provided by the Authority Field 2.84 ‘Indicator of the floating rate of leg 1’ List of benchmark(s) provided by the Authority Field 2.85 ‘Name of the floating rate of leg 1’ List of benchmark(s) provided by the Authority Field 2.99 ‘Identifier of the floating rate of leg 2’ List of benchmark(s) provided by the Authority Field 2.100 ‘Indicator of the floating rate of leg 2’ List of benchmark(s) provided by the Authority Field 2.101 ‘Name of the floating rate of leg 2’ List of benchmark(s) provided by the Authority k) the relevant authorities of a third country that have entered into a cooperation arrangement with ESMA, as referred to in
Article 76;
N/A N/A l) the Agency for the
Cooperation of Energy
Regulators established by Regulation (EC) No 713/2009 of the European Parliament and of the Council; Field 2.116 ‘Base product’ Field 2.117 ‘Sub-product’ [(field 2.16 ‘Base product’ = 'NRGY') and (field 2.17 ‘Sub-product’ = ‘ELEC’ or field 2.17 ‘Sub-product’ = ‘NGAS’)] or [(field 2.16 ‘Base product’ = ‘ENVR' and field 2.17 ‘Subproduct’ = ‘EMIS’] m) the resolution authorities designated under Article 3 of Directive 2014/59/EU of the European Parliament and the Council; Field 1.4 ‘Counterparty 1 (Reporting counterparty)’ Field 1.6 ‘Corporate sector of the counterparty 1’ GLEIF database filtered by the Member State, where field 1.6 ‘Corporate sector of the counterparty 1’ equals ‘INVF' Investment firm authorized in accordance with Directive 2014/65/EU or 'CDTI' credit institution authorised in accordance with Directive (EU) 2013/36/EU Field 1.9 ‘Counterparty 2’ Field 1.12 ‘Corporate sector of the counterparty 2’ GLEIF database filtered by the Member State, where field 1.12 ‘Corporate sector of the counterparty 2’ are equal to ‘INVF' Investment firm authorized in accordance with Directive 2014/65/EU or 'CDTI' credit institution authorised in accordance with Directive (EU) 2013/36/EU Field 1.15 ‘Broker ID’ List of LEIs provided by the Authority Field 1.16 ‘Clearing member’ List of LEIs provided by the Authority n) the Single Resolution Board established by Regulation (EU) No 806/2014; Field 1.4 ‘Counterparty 1 (Reporting counterparty)’ List of LEIs subject to the SRB, provided by SRB Field 1.9 ‘Counterparty 2’ List of LEIs subject to the SRB, provided by SRB Field 1.15 ‘Broker ID’ List of LEIs subject to the SRB, provided by SRB Field 1.16 ‘Clearing member’ List of LEIs subject to the SRB, provided by SRB o) competent authorities or national competent authorities within the meaning of Field 1.4 ‘Counterparty 1 (Reporting counterparty)’ Field 1.6 ‘Corporate sector of the counterparty 1’ GLEIF database filtered by the Member State where field 1.6 ‘Corporate sector of the counterparty 1’ equals:

247
Regulations (EU) No
1024/2013 and (EU)
No 909/2014 and of
Directives 2003/41/EC,
2009/65/EC,
2011/61/EU,
2013/36/EU and
2014/65/EU, and supervisory authorities within the meaning of Directive 2009/138/EC; 'CDTI' credit institution authorised in accordance with Directive (EU) 2013/36/EU; or 'CSDS' central securities depository authorised in accordance with Regulation (EU) No 909/2014; or 'INVF' Investment firm authorized in accordance with Directive 2014/65/EU; or 'INUN' insurance undertaking or reinsurance undertaking authorised in accordance with Directive 2009/138/EC; or 'AIFD' an alternative investment fund as defined in Directive 2011/61/EU; or 'UCIT' a UCITS and, where relevant, its management company authorised in accordance with Directive 2009/65/EC; or 'ORPI' an institution for occupational retirement provision (IORP) as defined under Directive 2016/2341 Field 1.9 ‘Counterparty 2’ Field 1.12 ‘Corporate sector of the counterparty 2’ GLEIF database filtered by the Member State where field 1.12 ‘Corporate sector of the counterparty 2’ equals:
'CDTI' credit institution authorised in accordance with Directive (EU) 2013/36/EU; or 'CSDS' central securities depository authorised in accordance with Regulation (EU) No 909/2014; or 'INVF' Investment firm authorized in accordance with Directive 2014/65/EU; or 'INUN' insurance undertaking or reinsurance undertaking authorised in accordance with Directive 2009/138/EC; or 'AIFD' an alternative investment fund as defined in Directive 2011/61/EU; or 'UCIT' a UCITS and, where relevant, its management company authorised in accordance with Directive 2009/65/EC; or 'ORPI' an institution for occupational retirement provision (IORP) as defined under Directive 2016/2341 Field 2.10 ‘Country of the counterparty 2’ Filtered by the Member State p) the competent authorities designated in accordance with
Article 10(5) of EMIR
Field 1.4 ‘Counterparty 1
(Reporting counterparty)’
Field 1.5 ‘Nature of the counterparty 1’
GLEIF database filtered by the Member State and ‘Nature of the counterparty 1’=’N where ‘N’ stands for non-financial counterparty Field 1.9 ‘Counterparty 2’ Field 1.11 ‘Nature of the counterparty 2’ GLEIF database filtered by the Member State and ‘Nature of the counterparty 2’=’N where ‘N’ stands for non-financial counterparty q) the relevant authorities of a third country in respect of which an implementing act pursuant to Article 76a has been adopted N/A N/A

Guidelines for reporting under EMIR

Lineage: In force

Similar documents from other regulators