The FCA have published a joint statement with the Bank of England regarding changes to reporting requirements under UK EMIR.
The UK EMIR consultation paper (CP21/31) released in February 2022 indicates that the FCA has proposed to harmonise UK EMIR Refit with the EU EMIR Refit rules (and global CPMI-IOSCO reporting data elements).
The FCA have provided the supporting technical specification documents for UK EMIR Validation rules and XML Schemas under UK EMIR. Links to the documents are below – both are applicable from 30 September 2024:
Please refer to our separate article for details of the EU EMIR Reporting requirements and how they are changing in April 2024.
What are the major changes?
1. ISO20022 XML
ISO 20022 is currently used for other regulatory regimes and has been widely accepted in the financial industry. The FCA will introduce the harmonised XML submissions for UK EMIR reporting as part of the global standardisation. A standardised format for reporting aims to eliminate the risk of discrepancies in data.
2. Unique Product Identifier (UPI)
FCA has specified in its Standards Instrument Article 7 that derivatives which are admitted to trading or traded on a trading venue or a systematic internaliser should be using an International Securities Identification Number (ISIN) code. The remaining derivatives should be identified using a Unique Product Identifier (UPI) code.
The Derivatives Service Bureau (DSB) Ltd has been designated as the service provider for the future UPI system. The DSB will be the sole issuer of UPI codes and operator of the UPI reference data library.
UPIs will be assigned to over-the-counter (OTC) derivatives products and used for identifying the product in transaction reporting data. This will enable authorities to aggregate data on OTC derivatives transactions by product or by any UPI reference data element. Such aggregation will facilitate the effective use of OTC trade data, including helping authorities assess systemic risk and detect market abuse.
3. Unique Trande Identifier (UTI)
In order to align with international standards, the FCA is adopting standards promoted by CPMI-IOSCO for defining the logic structure of Unique Trade Identifiers (UTIs). The introduction of these changes will enhance data harmonisation globally.
The change to the UTI generation waterfall model considers bilateral agreements as fallbacks. In a situation where there is no agreement in place, firms follow the UTI waterfall for generation of this identifier.
There is a deadline set by ISDA where the counterparty generating the UTI shall communicate the UTI to the other counterparty timely, which is by 10:00 a.m. UTC on T+1 (Standards Instrument Article 8)
4. Legal Entity Identifier (LEI)
Moving forward, the renewal of LEIs will be validated only for the reporting counterparty and the entity responsible for reporting. This means lapsed LEIs are allowed for other counterparties. (Standards Instrument Article 4)
5. Revised reporting lifecycle events
The Action Type field alone is insufficient to describe the business event, so Event Type will be introduced to provide more granularity about the type of business event triggering a given report.
Here is the combination of Action Types and Event Types:
ESMA have provided the above table guide to explain Action and Event Type scenarios, which should also apply to UK EMIR Refit
6. Changes to reportable fields
There is a total of 204 fields in the new UK EMIR Refit.
A new field introduced is the Derivative Based on Crypto-assets, where counterparties are expected to indicate whether a security is based on a crypto-asset. This will allow the FCA to assess the trading volumes and risk of crypto-tokens which in turn will facilitate the development of more granular requirements in the future.
Some existing fields have been removed, such as the Trading Capacity and Beneficiary ID fields which were found to provide little to no value.
The one extra field UK EMIR will have over EU EMIR is ‘Execution Agent’. This specifies the entity that executed the transaction on behalf of the counterparty and binds the counterparty to the terms of the transaction, but isn’t a broker. This is an optional field.