EMIR Refit – Key changes and challenges
In December 2022, The European Securities and Markets Authority (ESMA) published the guidelines and technical documentation for the EMIR Refit which some are referring to as EMIR 3.0. The goal of the refit is to “further enhance the harmonisation and standardisation of reporting under EMIR”, which supports both EMIR’s main purpose of monitoring systemic risk as well as containing costs for market participants and trade repositories.
The EMIR Refit is set to go live the 29th of April 2024 in Europe and the 30th of September 2024 for the United Kingdom. There are a lot of changes for firms to ensure that they are ready to meet those deadlines. This blog sets out the key changes and challenges for the coming year.
New reportable fields
The new technical standards contain a total of 203 fields which is an increase of 74 fields. In addition to these newly introduced fields, there are also changes made to the format and content of existing fields (e.g. contract type, asset class). A small number of fields have also been removed, such as “Trading capacity”, “Beneficiary ID”, and “Price Notation” due to their limited added value.
There are four new fields relating to the counterparty details, such as the nature, corporate sector, and clearing threshold of the other counterparty to the trade (“Counterparty 2”). These are reference data points that organisations currently may not have and therefore need to be acquired.
Another key change is the addition of the “Event Type” field which is introduced to increase the transparency around the lifecycle of a trade. This new field hopes to remove the current ambiguity of the “Action Type” field and provides a more explicit indicator of the lifecycle event. This field will work alongside “Action Type” and the combination of the two fields should provide a clearer indication of the lifecycle event which triggered the reporting. For example, the Action Type “Termination” should now be combined with an Event Type, such as “Clearing”, “Exercise”, or “Inclusion in Position”, providing additional information on the reason for termination.
Unique Product Identifier (UPI)
The UPI is a newly introduced identifier of the derivative product and will complement the information currently captured by the International Securities Identification Number (ISIN) and Classification of Financial Instruments (CFI) code. The UPI contains a subset of the data elements provided an ISIN but is more exhaustive than the CFI.
The ISIN remains the unique identifier reportable for instruments that are admitted to trading on a trading venue (ToTV) or traded on a systematic internaliser (SI) with the underlying instrument being ToTV. All other instruments are required to be reported with a 12 character UPI which must be present in the Derivatives Service Bureau (DSB) database.
The DSB will function as the issuer of UPI codes as well as operator of the UPI reference data library. Therefore, market participants need to ensure that they are on-boarded to the UPI platform ahead of the EMIR Refit go-live. The DSB timelines specify that the system will be ready to be used in production from mid-October 2023, but firms should already be able to start user-acceptance testing now.
Introduction of ISO20022
ISO20022 is the global standard of communication of financial data and is already used in other European reporting regimes such as MIFIR and SFTR. In line with the goal of harmonizing and standardising data, the ISO20022 standard is now also introduced for EMIR Reporting. This effectively means that all messaging of EMIR reports must be done according to a standardized XML structure.
The key challenge for the industry is to correctly implement this new standard in the current reporting pipeline. Additionally, any in-house reconciliations also need to be re-designed as these often still rely on the use of csv extract which are generally considered to be more user-friendly.
Technical standards for Trade Repositories
With the objective to increase data quality and consistency in the EMIR reporting ESMA has introduced the Regulatory Technical Standards (RTS) on the reconciliation and verification of data, which is specifically aimed at the trade repositories.
This RTS sets out the required level of verification of submitted data which includes verifying the correctness and completeness of the report as well as validating the lifecycle events reported for a trade. Additionally, the RTS sets out the required steps to be undertaken regarding the reconciliation between Trade Repositories (TRs). There are 87 fields that need to be reconciled at the initial go-live and this will be expanded to 148 after two years.
Unique Trade Identifier (UTI)
An important change has been introduced to the generation process of the UTI. Currently, the ITS sets out the expectation that counterparties agree bilaterally on which entity is responsible for the generation of the UTI. In case the entities can not agree on this, there is logic in place to determine the entity responsible.
The new ITS is more prescriptive and clearly sets out the responsible entity in different trading scenarios. The bilateral agreement between entities is considered the fall-back approach and should only be used in trading scenarios not covered by the ITS. In case counterparties cannot agree bilaterally the responsible entity is determined based on the alphabetical ordering of their Legal Entity Identifiers (LEI).
This will change current arrangements in place between entities and therefore the new approach should be clearly communicated and aligned.
In Summary
The changes will undoubtedly help the regulators better understand systemic risk but they represent a significant change in the reporting content, including new data that participants may not already have, a change to the technical format of reporting and new agreements with counter parties. This is likely to require a major overhaul of the existing EMIR reporting systems and approaches with relatively little time to make and test such major changes.
