EMIR Refit implications for the SFTR Review

With the go live of EMIR Refit this week, ESMA’s attentions will surely turn next to what to do about SFTR. Next year, SFTR will be five years post-implementation and it will be time for the delayed SFTR Review to commence.

Having studied the EMIR Refit, it’s apparent that quite a few of the changes were piloted by the SFTR introduction in 2020. Lessons learned by ESMA from the original EMIR regulation and implementation subsequently fed through to SFTR. And it seems likely that many of the developments rolled out in the EMIR Refit will find their way into the SFTR Review.

Opposite directions

As a bit of an EMIR outsider, it’s somewhat alarming the extent to which EU regulation and the industry dynamic are moving in opposite directions. The industry is focused on adopting standards, the Regulatory Oversight Committee’s (ROC) common data elements, common booking models, common domain models (CDM), simplification and far greater automation through machine reading and blockchain. CDMs focus on non-proprietary, non-licensed fundamental transaction, position and lifecycle data, an approach that is about achieving fully matched, perfectly replicable trade data with relatively few fields and no complications. CDMs should in theory dramatically reduce the number of manual touchpoints on any trade, significantly reducing operational costs.

However EU regulators are looking for more data, extensive embellishment and enrichment, to not only achieve a truly forensic analysis of a firm’s balance sheet, processes and operations, but also to negate the need for them to hold any reference or static data at all. Indeed, thinking that 155 fields for SFTR was a lot, we now face up to 203 fields under EMIR Refit (a 65% increase on the original). There are ‘just’ 110 common data elements listed by the ROC…

Which EMIR Refit elements are likely to be incorporated into the SFTR Review?

• Bilateral variation margin reporting. Back in 2016 at the Paris hearings on SFTR technical standards, I suggested that there be a separate table to report bilateral variation margins for repo transactions, as ESMA insisted that Table 3, the Margin Table, was exclusively for CCP margins. This motion wasn’t carried and consequently, it is evident that SFTR bilateral variation margin reporting is currently flawed and frequently underreported. The approach required under SFTR v1 of providing trade level collateral updates with UTIs and bilateral variation margin collateral updates without UTIs does not appear to ever have been fully understood. Therefore, the EMIR Refit change that incorporates both CCP margins together with bilateral variation margining in the same margin table would be a welcome step forward, removing confusion and enhancing regulatory certainty.
• Executing Agent field. The introduction of an executing agent field (as per EMIR Refit) would also significantly enhance the trade repository reconciliation process, particularly when reporting or facing funds as one of the counterparties. This should mitigate current misreporting, where the agent lender or broker fields are often misused to represent fund managers.
  
• Intra-group trade identifier. Another party to the transaction field that may carry from EMIR is an Intra-group trade identifier. This omission was something highlighted in the recent ESMA Market Report on EU Securities Financing Transactions Markets 2024. While not strictly necessary (intra-group entities can be identified by their LEI), it would further reduce the burden on regulators to establish this relationship themselves. 
• Waterfall guidance on UTI. EMIR Refit was written post-Brexit and consequently, they have taken account of the fact that many transactions in Europe today are single sided, being cross-jurisdictional. Therefore, there is a new waterfall providing guidance about responsibility to generate and share unique transaction identifiers (UTIs) when trading across borders. This measure should reduce late reporting (where there is uncertainty about UTI generation and sharing and consequently late reporting) and again provide clearer direction and certainty for reporting counterparties.   
• Effective dates are another EMIR Refit feature that are likely to benefit SFTR.  At present the need to delay reports until agreed contractual modifications take effect certainly presents a timing challenge to complete and accurate reporting. The revive action type (allowing the reopening of matured or terminated/cancelled by mistake trades) may also be broadly welcomed, aiding in dealing with trades failing over their maturity date/end date for example.
• Additional EMIR Refit changes that are likely to be mooted include event types complementing certain action types, package identifiers (useful for identifying products such as collateral swaps) and the requirement to report the nature and corporate sector of the other counterparty in addition to the reporting counterparty.

There is no better way to prepare for SFTR 2 than to get your house in order for SFTR 1. For help addressing your SFTR data quality concerns, please get in touch.