EMIR reporting obligation (2024)

Who should report under EMIR?

EMIR establishes the reporting obligation on both counterparties that should report the details of the derivative trades to one of the trade repositories (TRs), i.e. the buying party should report and the selling party should report. This obligation covers both financial and non-financial counterparties. Only the individuals are exempted from the obligation to report their derivatives trades. However as their counterparty is usually a financial institution, the latter has the obligation to report those trades.
EMIR uses the term “non-financial counterparty” which covers all other counterparties that cannot be qualified as a financial counterparty. EMIR sets obligations and requirements applicable to the non-financial counterparties that enter into derivative contracts thus expanding the coverage of the regulation.

What should be reported under EMIR?

EMIR requires reporting of the transaction details for both types of derivatives trades – exchange traded derivatives (ETD) and OTC derivatives. ‘OTC derivative’ or ‘OTC derivative contract’ (under Article 2 of EMIR) is a derivative contract the execution of which does not take place on a regulated market or on a third- country market considered as equivalent to a regulated market. For example, the derivative contracts traded on MTFs (multilateral trading facilities) are OTC derivatives in the context of EMIR. The exchange traded derivatives (EDT) are not explicitly defined under EMIR.
From legal point of view the scope of the financial instruments covered by EMIR are set out in Annex I, Section C, points (4) to (10) of MiFID II Directive 2014/65/EU of the European Parliament and of the Council of 15 May 2014:

(4) Options, futures, swaps, forward rate agreements and any other derivative contracts relating to securities, currencies, interest rates or yields, emission allowances or other derivatives instruments, financial indices or financial measures which may be settled physically or in cash;

(5) Options, futures, swaps, forwards and any other derivative contracts relating to commodities that must be settled in cash or may be settled in cash at the option of one of the parties other than by reason of default or other termination event;

(6) Options, futures, swaps, and any other derivative contract relating to commodities that can be physically settled provided that they are traded on a regulated market, a MTF, or an OTF, except for wholesale energy products traded on an OTF that must be physically settled;

(7) Options, futures, swaps, forwards and any other derivative contracts relating to commodities, that can be physically settled not otherwise mentioned in point 6 of this Section and not being for commercial purposes, which have the characteristics of other derivative financial instruments;

(8) Derivative instruments for the transfer of credit risk;

(9) Financial contracts for differences;

(10) Options, futures, swaps, forward rate agreements and any other derivative contracts relating to climatic variables, freight rates or inflation rates or other official economic statistics that must be settled in cash or may be settled in cash at the option of one of the parties other than by reason of default or other termination event, as well as any other derivative contracts relating to assets, rights, obligations, indices and measures not otherwise mentioned in this Section, which have the characteristics of other derivative financial instruments, having regard to whether, inter alia, they are traded on a regulated market, OTF, or an MTF;

(11) Emission allowances consisting of any units recognised for compliance with the requirements of Directive 2003/87/EC (Emissions Trading Scheme).

Guidancefor points C6 and C7 (commodities that can be physically settled) isavailable here.

Please note that EMIR does not cover the following:
(1) Transferable securities;
(2) Money-market instruments;
(3) Units in collective investment undertakings.

On 20.12.2022 ESMA has published Guidelines for reporting under EMIR covering EMIR REFIT. Although the Guidelines are applicable since 29 April 2024, we would recommend that you fully comply with them prior to the application date.

ESMA clarifies the reportable instruments under EMIR:

Currency derivatives

MIFID RTS on organisational requirements for investment firms clarifies in Article 10 the characteristics of other derivative contracts relating to currencies.

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 circ*mstances 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.

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.

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 JSE30 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.

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.

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.

Derivatives on crypto-assets

Only derivatives on crypto-assets that fulfil the definition of ‘derivative’ or ‘derivative contract’ under EMIR are expected to be reported.

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.

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)

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.

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

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.

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

The following transactions do not fall under the definition of a derivative under EMIR and thus should not be reported under EMIR:

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”.

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”.

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.

To whom should be reported?

All OTC derivative contracts and exchange traded derivatives should be reported to one of the registered trade repositories.
Please find below a list with the trade repositories that have been registered by ESMA:

How the derivatives can be reported?

In order to assist you finding the best solution for your EMIR reporting we can perform an evaluation of the IT infrastructure of the company as well as available the resources and the type of the instruments and the number of trades that should be reported.
We can suggest the best cost effective option for your EMIR reporting solution.
Generally there are three main options:

• Direct reporting to the TR: establishment of procedures, usage of plugins and template files that will be available to your company, as well as assistance in choosing the best cost effective trade repository (TR) in the context of the number of trades that are or should be reported.
• Delegated reporting to a counterparty: analysis of the options about your counterparties to report on your behalf, i.e. the number and type of the counterparties that can take over the EMIR reporting functions for certain transactions that go through them.
• Delegated reporting to a third party solution: analysis and pointing out a third party solution in the context of cost-efficiency and implementation advantages.

EMIR Reporting Ready, Ltd. has established strong relations with third party solutions companies whose IT infrastructure can be used in order to establish a smooth EMIR reporting process. For further information please click here for ourSolutions.

What is LEI?

LEI stands for Legal Entity Identifier. It is a unique sequence of numbers and letters that identifies the counterparties, CCPs, beneficiaries and brokers. The information about the LEIs of all your partners and clients (legal entities) is essential for successful transaction reporting.

What is UTI?

UTI stands for Unique Trade Identifier. It identifies a specific trade and it is generated under certain rules provided by ESMA. This is required in order to ensure accurate identification of reported trades by both counterparties.

Current rules

According to art. 4a of Commission Implementing Regulation (EU) No 1247/2012 in case counterparties fail to agree on the entity responsible for generating the unique trade identifier to be assigned to the report, the counterparties shall determine the entity responsible for generating a unique trade identifier in accordance with the following:

(a) for centrally-executed and cleared trades, the unique trade identifier shall be generated at the point of clearing by the central counterparty (CCP) for the clearing member. Another unique trade identifier shall be generated by the clearing member for its counterparty;

(b) for centrally-executed but not centrally-cleared trades, the unique trade identifier shall be generated by the trading venue of execution for its member;

(c) for centrally-confirmed and cleared trades, the unique trade identifier shall be generated at the point of clearing by the CCP for the clearing member. Another unique trade identifier shall be generated by the clearing member for its counterparty;

(d) for trades that were centrally-confirmed by electronic means but were not centrally-cleared, the unique trade identifier shall be generated by the trade confirmation platform at the point of confirmation;

(e) for all trades other than those referred to in points (a) to (d), the following shall apply:

(i) where financial counterparties trade with non-financial counterparties, the financial counterparties shall generate the unique trade identifier;

(ii) where non-financial counterparties above the clearing threshold trade with non-financial counterparties below the clearing threshold, those non-financial counterparties above the clearing threshold shall generate the unique trade identifier;

(iii) for all trades other than those referred to in points (i) and (ii), the seller shall generate the unique trade identifier.

Commission Implementing Regulation (EU) No 148/2013 specifies that the Trade ID can have up to 52 characters, including four special characters, the special characters not being allowed at the beginning or at the end of the code. Therefore, a Trade ID that is less than 52 characters in length is permissible provided that it meets the other criteria laid out here. There is no requirement to pad out Trade ID values to make them 52 characters long.

EMIR Q&As TR Answer 18 further clarifies that one Trade ID should be applicable to any one derivative contract that is reported to a trade repository under EMIR and that the same Trade ID is not used for any other derivative contract. It is also acknowledged that contracts reported under EMIR rules might also reported under the rules of other jurisdictions. Hence, the same Trade ID should be allowed to be used in both those jurisdictions for reporting the given contract in order to facilitate the reconciliation among all the data sets.

As an illustration, ESMA considers that any of the methods provided in the following list of Trade ID construction would be deemed to meet the requirements for reporting under EMIR. ESMA reserves the initial three-character sequences ‘E00’ to ‘E99’ inclusive for these purposes. The Trade ID should be formed by the concatenation (without separators) of the three elements in each case.

Method 1:

1. The characters ‘E01’.
2. The MIC code (ISO 10383) of the applicable trading venue.
3. A unique code generated by that trading venue (for centrally executed but non-centrally cleared trades) or by a CCP used by that trading venue to clear the derivative contract (for centrally executed and cleared trades). If the CCP generates the code and if derivative contracts executed on that trading venue could be cleared by more than one CCP, then measures should be put in place to avoid different CCPs generating the same value.

Method 2:

1. The characters ‘E02’.
2. The (20 character) Legal Entity Identifier of the generating entity (normally one of the parties to the trade and pursuant to the points (a), (c) and (e) of the hierarchy mentioned in Article 1(4) of the Commission Implementing Regulation (EU) No 1247/2012 (ITS on reporting to TR).
3. A unique code generated by the unique Trade ID generating entity.

Method 3:

1. The characters ‘E03’.
2. A unique code generated independently by both counterparties based on the pre-agreed set of information about the trade in such a way that both counterparties will arrive at the same code and that it would be unique with respect to any other report. The two counterparties are responsible for providing the same code. The information used should include Common Data from Table 2 of the Commission Delegated Regulation (EU) No 148/2013 and the Legal Entity Identifiers of the two counterparties.

For derivative contracts that are also reportable under the provisions of the Dodd-Frank Act the same value as the one to be reported under the Dodd-Frank Act, i.e. the Unique Swap Identifier16, could be used.

Counterparties should agree which form of a unique Trade ID they will use before reporting the derivative contract. This therefore includes determining the approach that they will use to define which entity generates the unique Trade ID.

EMIR REFIT applicable on 29 April 2024

ESMA provides the following information in the final report:

• The agreement between the counterparties is no longer a first option but becomes rather a fallback scenario for some specific cases
• UTI generation waterfall approach is in line with the global UTI guidance
• The rules on UTI generation equally apply for reporting at position level
• In case of delegated reporting the UTI can be generated by the delegated party
• In case both counterparties have the same status, the sorting of the LEI will determine the entity responsible for generating the UTI – the LEI that is first when sorting.

Please find below Article 7 of Commission Implementing Regulation (EU) 2022/1860

1. The counterparties shall report derivatives using the UTI generated in accordance with paragraphs 2, 3 and 5.
2. A derivative, reported either at transaction or position level, shall be identified using a ISO 23897 Unique Transaction Identifier (UTI) in field 1 in Table 2 of the Annex. The UTI shall be composed by the LEI of the entity which generated that UTI followed by a code containing up to 32 characters which is unique at the level of the generating entity.
3. The counterparties shall determine the entity responsible for generating the UTI in accordance with the following:

(a) for cleared derivatives other than derivatives between two CCPs, the UTI shall be generated at the point of clearing by the CCP for the clearing member. A different UTI shall be generated by the clearing member for its counterparty for a trade in which the CCP is not a counterparty;

(b) for centrally-executed but not centrally-cleared derivatives, the UTI shall be generated by the venue of execution for its member;

(c) for derivatives other than those referred to in points (a) and (b), where either counterparty is subject to the reporting requirements in a third country, the UTI shall be generated pursuant to the rules of the jurisdiction of the counterparty that must comply first with those reporting requirements.

Where the counterparty subject to reporting under Article 9 of Regulation (EU) No 648/2012 must comply first with the reporting requirements, the entity responsible for generating the UTI shall be as follows:

(i) for derivatives that were centrally-confirmed by electronic means, the trade confirmation platform at the point of confirmation;

(ii) for all other derivatives, the counterparties shall agree on the entity responsible for generating the UTI. Where the counterparties fail to agree, the counterparty whose LEI is first based on sorting the identifiers of the counterparties with the characters of the identifier reversed shall be responsible for the generation.

Where the applicable laws of the relevant third country provide for the same reporting deadline as the one applicable to the counterparty subject to reporting under Article 9 of Regulation (EU) No 648/2012 pursuant to first subparagraph of Article 9(1) of Regulation (EU) No 648/2012, the counterparties shall agree on the entity responsible for generating the UTI.

Where the counterparties fail to agree, and the derivative was centrally-confirmed by electronic means, the UTI shall be generated by the trade confirmation platform at the point of confirmation.

If the UTI cannot be generated by the trade confirmation platform at the point of confirmation, and the details of the derivative have to be reported to a single trade repository, that trade repository shall be responsible for generating the UTI.

If the UTI cannot be generated by the trade repository to which the details of the derivative have been reported, the counterparty whose LEI is first when sorting the identifiers of the counterparties with the characters reversed shall be responsible for the generation;

(d) for derivatives other than those referred to in points (a), (b) and (c), that were centrally-confirmed by electronic means, the UTI shall be generated by the trade confirmation platform at the point of confirmation;

(e) for all derivatives other than those referred to in points (a) to (d), the following shall apply:

(i) where financial counterparties conclude a derivative with non-financial counterparties, the financial counterparties shall generate the UTI;

(ii) where non-financial counterparties above the clearing threshold conclude a derivative with non-financial counterparties below the clearing threshold, those non-financial counterparties above the clearing threshold shall generate the UTI;

(iii) for all derivatives other than those referred to in points (i) and (ii), the counterparties shall agree on the entity responsible for generating the UTI. Where the counterparties fail to agree, the counterparty whose LEI is first based on sorting the identifiers of the counterparties with the characters of the identifier reversed shall be responsible for the generation.

4. The counterparty generating the UTI shall communicate the UTI to the other counterparty in a timely manner and no later than 10:00 a.m. Coordinated Universal Time of the working day following the date of the conclusion of the derivative.
5. Notwithstanding paragraph 3, the generation of the UTI may be delegated to an entity different from that determined in accordance with paragraph 3. The entity generating the UTI shall comply with the requirements set out in paragraphs 2 and 4.

What is UPI?

UPI stands for unique product identifier. This is a new field that will apply from 29 April 2024.

The product identifier (UPI) used in derivatives reporting fulfils a series of conditions, such as uniqueness, persistence, consistency, neutrality, reliability, open source, scalability, accessibility, availability at a reasonable cost basis, appropriate governance framework.

The global aggregation of OTC data will require the adoption of a global UPI by the relevant jurisdictions. ESMA is following the principles applied in the IOSCO UPI technical guidance.

Furthermore, ESMA maintains the following approach: all derivatives admitted to trading or traded on a trading venue or a systematic internaliser will need to be identified with an ISIN (only), whereas all remaining derivatives will need to be identified with UPI (only).

ESMA will ensure sufficient flexibility of the XML schemas for reporting.

What are the new collateral fields on and after 29 April 2024?

Current reportable valuation and collateral fields are provided in the EMIR table 1, Counterparty Data, fields 17 to 26. Please refer to the table below.

Current RTS and ITS on reporting only require the reporting of margins before haircuts have been applied.

On and after 29 April 2024allcollateral data should be submitted with a separate XML report. New fields are introduced for pre-haircut and post-haircut margins:

• Variation margin posted by the counterparty 1 (pre-haircut)
• Variation margin posted by the counterparty 1 (post-haircut)
• Initial margin collected by the counterparty 1 (pre-haircut)
• Initial margin collected by the counterparty 1 (post-haircut)
• Variation margin collected by the counterparty 1 (pre-haircut)
• Variation margin collected by the counterparty 1 (post-haircut)

Article 5 of Commission Implementing Regulation (EU) 2022/1860 regarding collateralization:

Reporting counterparty shall identify the type of collateralisation of the derivative contract or a portfolio of derivatives referred to in field 11 in Table 3 of the Annex as follows:

(a) as ‘uncollateralised’ where no collateral agreement exists between the counterparties or where the collateral agreement between the counterparties stipulates that the counterparties post neither initial margin nor variation margin with respect to the derivative or a portfolio of derivatives;

(b) as ‘partially collateralised: counterparty 1 only’ where the collateral agreement between the counterparties stipulates that the reporting counterparty only posts regularly variation margins and that the other counterparty does not post any margin with respect to the derivative or a portfolio of derivatives;

(c) as ‘partially collateralised: counterparty 2 only’ where the collateral agreement between the counterparties stipulates that the other counterparty only posts regularly variation margin and that the reporting counterparty does not post any margin with respect to the derivative or a portfolio of derivatives;

(d) as ‘partially collateralised’ where the collateral agreement between the counterparties stipulates that both counterparties only post regularly variation margin with respect to the derivative or a portfolio of derivatives;

(e) as ‘one-way collateralised: counterparty 1 only’ where the collateral agreement between the counterparties stipulates that the reporting counterparty posts the initial margin and regularly posts variation margins and that the other counterparty does not post any margins with respect to the derivative or a portfolio of derivatives;

(f) as ‘one-way collateralised: counterparty 2 only’ where the collateral agreement between the counterparties stipulates that the other counterparty posts the initial margin and regularly posts variation margins and that the reporting counterparty does not post any margins with respect to the derivative or a portfolio of derivatives;

(g) as ‘one-way/partially collateralised: counterparty 1’ where the collateral agreement between the counterparties stipulates that the reporting counterparty posts the initial margin and regularly posts variation margin and that the other counterparty regularly posts only variation margin with respect to the derivative or a portfolio of derivatives;

(h) as ‘one-way/partially collateralised: counterparty 2’ where the collateral agreement between the counterparties stipulates that the other counterparty posts the initial margin and regularly posts variation margin and that the reporting counterparty regularly posts only variation margin with respect to the derivative or a portfolio of derivatives

(i) as ‘fully collateralised’ where the collateral agreement between the counterparties stipulates that both counterparties post initial margin and regularly post variation margins with respect to the derivative with respect to the derivative or a portfolio of derivatives.

How to calculate the mark-to-market value?

ESMA requires that the primary valuation methodology which should be used is mark-to-market. Only where mark-to-market is not feasible (for example due to a market being ‘inactive’), then “reliable and prudent” marking-to-model may be used to value trades and positions. The relevant EMIR regulation (No 149/2013) also requires the reporting counterparty to take steps to review and document the use of an appropriate model, which may require the counterparty to obtain appropriate internal approvals and liaise with other counterparties.

For centrally cleared contracts, the valuations reported by each counterparty should be those calculated by the CCP, on a daily basis, at а position level. This does not mean that the report should always be made by the CCP. The CCP may make data available to the counterparties, so that the latter can report.

For uncleared business, the contracts should be valued by the counterparties themselves.

The counterparties are subject to the requirement to daily mark-to-market/mark-to-model the valuation of the reported transactions. The changes in mark-to-market or mark-to-model valuations on already reported transactions need to be reported on a daily basis (end of day).

The mark-to-market value should be based on the End of Day settlement price of the market (or the CCP) from which the prices are taken as reference. If an End of Day settlement price is not available, then the mark-to-market value should be based on the closing mid-price of the market concerned.

The mark-to-market value should represent the absolute value of the contract.

Should the valuations be agreed between the counterparties?

As the valuation is part of the Counterparty data fields, in the case of derivative not cleared by a CCP, the counterparties do not need to agree on the valuation reported.

On and after 29 April 2024 the valuation data should be agreed between the counterparties.

How to calculate the value of the collateral?

After 1st Nov 2017 according to Commission Delegated Regulation (EU) 2017/104 (revised EMIR RTS) all posted and received collateral should be reported. The fields that specify the type of the collateralhave increased from 1 to 6 different fields: initial margin posted; variation margin posted; initial margin received; variation margin received; excess collateral posted; excess collateral received.

In case the collateral agreement allows the covering of exposures in transactions that are not reportable under EMIR, the value of 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.

After 29th April 2024 new fields for pre-haircut and post-haircut are introduced.

Which currency to be used as the collateral base currency?

ESMA advises All collateral for a single portfolio should be reported in one single currency value. The reporting counterparty is free to decide which currency should be used as a base currency as long as this base currency is one of the major currencies and is used consistently for the purpose of collateral reporting for a given portfolio.

How the change in the amount of collateral should be reported?

Valuation update (V) in field No. 58 refers to any change in fields 17 to 26 of table 1 and for that reason changes in the amount of the collateral should be reported as a (V) in field 58.

Should the collateral details be reported at the trade, position or portfolio level?

Collateral should be reported at the same level at which it has been posted. If collateral has been posted against a portfolio of trades or positions, for example, then the details should be reported at the portfolio level.

What are the changes in RTS/ITS applicable on 29 April 2024?

ISO 20022 XML will applyon29 April 2024.

On 17th Dec, 2020 ESMA has published a Final Report on technical standards (RTS and ITS) under the EMIR REFIT Regulation. The report covers data reporting to Trade Repositories (TRs), procedures to reconcile and validate the data, access by the relevant authorities to data and registration of the TRs.

On 7th Oct, 2022 EU EMIR REFIT regulatory technical standards (RTS) and implementing technical standards (ITS) have been published in theOfficial Journal of the European Union.

On 20th Dec, 2022 ESMA has published Guidelines on EMIR reporting covering EMIR REFIT.

The final report on Guidelinesis accompanied by the validation rules and the reporting instructions (here and here), i.e. XML schemas.

The validation rules document sets out detailed technical rules on how the TRs should verify the completeness and accuracy of the reported data as well as the conditions and thresholds to be applied to determine whether the values reported by both counterparties match or not. Finally, the Validation rules document contains also a template for notifications of reporting errors and omissions to the NCAs.

The reporting instructions contain EMIR XML messages which were updated or newly developed based on the revised technical standards and validation rules. A fully standardised format for reporting will eliminate the risk of discrepancies due to inconsistent data. End-to-end reporting in ISO 20022 XML is expected to further enhance data quality and consistency and mitigate the data integrity risks, by reducing the need for data cleaning/normalisation and facilitate their exploitation for various supervisory and/or economic analysis based on the changes presented by the EMIR Refit regulation. The implemented schema sets were designed to ensure the backward compatibility of the data reporting.

For more information please feel free to contact us at office@emirreporting.eu.