ESMA recently published the final reporting validations for EMIR Refit for European (EEA) based firms. As firms prepare for the go-live date of 29 April 2024 (Europe) and 30 September 2024 (UK), this article highlights some of the key changes that firms face for derivatives reporting under EMIR.
1. A large number of changes to the reportable fields
There’s no better place to start than the data fields themselves. In short, the vast majority of fields will change. The addition of 89 new fields, the withdrawal of 15 and updates to the name, definition or format of how to report a field.
This brings the total number of reportable fields from 129 to 203, which is twice the size of MiFIR trade and transaction combined, and even outstrips the weighty SFTR reporting requirements.
A lot of the additions are logical, such as asset class specific fields, the removal of ‘Beneficiary’ and ‘Trading Capacity’ (something I’ve championed for some time). Other fields will be more of a challenge for firms, specifically ‘Clearing Threshold of Counterparty 2’, ‘Reporting Obligation of Counterparty 2’ and ‘Corporate Sector of Counterparty 2’ require firms to know more detail on the counterparties they have traded with in order to fulfil their own reporting obligation. I expect that ‘Prior Unique Trade Identifier’ and ‘Subsequent Position Unique Trade Identifier’ will be difficult for many firms.
2. EMIR reporting via XML
Next, the way to report these fields will change. Firms have long favoured the flexibility of reporting in CSV, chiefly due to its ‘pick up and go’ style. With no need for specific CSV training, organisations could simply populate fields and amend the same submissions when they encounter validation errors.
EMIR reporting will be the latest derivative regime to adopt XML submissions using ISO 20022 standards, as favoured in the CDE Guidance.
But the move to XML submissions is a heavy lift, and is the primary reason why the proposed changes will be implemented in 18 months, rather than the usual 12. The corresponding benefits of this change are important. They include a much more ‘level playing field’ for reporting to a trade repository (TR), whichever repository you use. And porting between TRs will be much easier given the uniform format across jurisdictions.
On the flip side, multiple TR specific submission specifications across the same derivatives reporting regime is far from ideal. Further to this, the ability to add repository specific fields in my opinion only adds work, confusion and ambiguity for reporting firms within a regulation that is already complicated enough.
3. Inter-TR reconciliation pulled into regulatory documentation
This change has been a long time coming, but the Inter-TR reconciliation process is now being formally dictated. I remember being present at the first Inter-TR reconciliation meeting between EMIR trade tepositories, who, in earnest, wanted to create a suitable reconciliation process for separate submissions, but with virtually no guidance from the regulators on what was required or how to achieve it. Six trade repositories, six different preferred ways to achieve it! That said, the smart folk at the TRs agreed on a process reasonably quickly, but the formalising of this inter-TR reconciliation process is welcome, and comes with some significant improvements – such as the minimum time requirements (10am next day), and later, explicit requirements for the TRs to send mismatched fields with corresponding data to the firms each day.
One subtle but sensible proposal from the FCA/BoE for UK EMIR reporting has been not including the reconcilable fields and their tolerance levels in the technical standards. Instead they will be provided as guidance, allowing for relatively quick amendments, and avoiding any unduly high mismatches relating to the reconciliation criteria.
This trial and error approach is unusual, but sensible in its rationale, indicating that the slow and steady approach may be the most pragmatic going forward.
4. Unique Product Identifiers (UPI)
Long before EMIR came into force in 2012 and reporting began in 2014, the industry had not been able to agree on a unique reference type for identifying product types. As a result, EMIR has had over seven years of reporting with a mix of ISINs, Classification of Financial Instrument (CFI) codes with other fields, and sometimes nothing at all! Interpretation of these identifier related fields has been widespread, often confused and almost always inconsistent.
The use of CFI codes is often wrong, and simply doesn’t correspond to the same data reported elsewhere in the same report (such as delivery type). Indeed populating just the first two characters of six, leaving the remaining characters as XXXX (for example JRXXXX) is unfortunately an all too common misconception. The introduction of the UPI under ANNA DSB is therefore a welcome improvement. One centralised place for UPIs will surely reduce inconsistency and importantly, will hopefully reduce the volume of reportable fields in the future, as many separate data fields can be obtained from the UPI.
But these advantages will not be without cost and effort for firms. Firms will need to apply for UPIs, and will be charged for the pleasure of doing so.
They will also need to allow enough time to have a UPI allocated and still adhere to its T+1 reporting requirement, or otherwise need to make regulatory notifications for missed/late reporting. This will require planning with checks and balances in place for derivatives trading firms, banks and asset management houses, especially when new derivatives are executed.
5. Unique Trade Identifiers (UTIs)
Rounding up the top five important changes, the consultation paper has made changes to the use of the Unique Trade Identifier. Unlike the UPI, reporting firms are well versed on the use and merits of the UTI, which has been used since reporting inception.
The changes to the UTI’s format are not ‘show stoppers’ (e.g. no special characters), and are generally welcome, but the revision of the UTI generation waterfall will prove challenging for many reporting counterparties.
Today, firms are expected to agree bilaterally who will create and disseminate a UTI, so that both counterparties to a trade can meet their T+1 reporting requirement. Where no agreement exists, firms fall back on the UTI waterfall for generation of this identifier. Under these new proposals, the bilateral agreement between firms is no longer the default choice, and falls much further down the waterfall, following Critical Data Elements (CDE) guidance, with significantly more prescriptive steps inserted above, dictating which firm should create the UTI for different reporting situations. Market participants will argue the benefits of such an approach are primarily aimed at global reporting harmonisation, and many will comment that the flexibility of the bilateral agreement as default option is the strength of the process, and the most flexible option too. One welcome change here has to be the specification that the UTI must be provided to the other firm by 10am T+1, allowing both firms to report their trade on time.
One more thing…
I hope this blog has helped to highlight the significant size and scope of the amendments under the EMIR Refit, and the granularity to which changes are being applied. One notable addition to this list is the requirement to amend all outstanding derivatives to adhere to these new technical standards within six months from go-live. This easily missed requirement is no small feat, and could present problems for firms that may not have all the required data points for historically executed derivatives.
The move to harmonise derivatives reporting globally via CMPI IOSCO’s CDE Guidance is a welcome enhancement, and will hopefully help to achieve a high quality of reported data, as desired by ESMA, but may undoubtedly result in a significant change request for firms caught by EMIR reporting.