SFTR, just like EMIR, is the product of a more enhanced supervisory activity of the Financial Stability Board (FSB) and the European Systemic Risk Board (ESRB) in the European Union, in the aftermath of the 2008-2009 financial crises. With previous regulation limited in its scope in the field of derivatives and securities financing transaction reporting, ESMA was tasked to perform a ground-breaking exercise: the systematic standardisation of two uncharted reporting regimes, topped up with potential regular layers of updates by way of revised technical and implementing technical standards.
Two regulations so similar in structure
EMIR and SFTR both have a series of commonalities, namely the counterparties’ classifications, the entities subject to reporting requirements, the granularity level at which the reporting is required, the mechanics of reporting and the approach to collecting reference data associated with the financial instruments in scope.
SFTR transaction reporting is expected to follow the same structure as EMIR: the two counterparties to a derivative contract would have the obligation to report to a trade repository by T+1 - i.e. no later than the end of the following business day.
Both regulations are structured along a life-cycle approach, whereby the details of the contract are reported at the inception and subsequent events (including modifications or terminations) that affect the terms of the contract are reported as they occur until the expiry or scheduled termination of the contract. Just like under EMIR, counterparties will have a duty to keep a record of any SFT that they have concluded, modified or terminated for at least five years following the termination of the transaction.
Although fundamentally different in scope, the two regulations appear to mirror each other in many ways. The trade reporting action type “position component”, was newly introduced under the revised EMIR RTS/ITS to align the standards with the those endorsed under the SFTR. Conversely, the reconciliation of SFTR transaction data appears to follow the same design of the end-of-day reports under EMIR.
The framework of the reconciliation process under EMIR and SFTR outlines the use of a two way key (LEI + UTI). The Inter-Trade Repository (TR) reconciliation process under both EMIR and SFTR will be determined by the ‘pairing’ and ‘matching’ processes, with certain tolerances. All authorised EMIR TRs have established an Inter-TR Reconciliation process and the SFTR Inter-TR Reconciliation process is expected to follow the same working model.
One area of divergence between the regimes is the level of the LEI required to identify the counterparty. Under EMIR, the LEI used should only ever be at the head office level whereas SFTR requires the reporting of trades entered not only at the head office level but also identification using branch level LEIs, when the solution will be fully implemented. Until that time, ISO country codes should be reported.
Following the amendment of EMIR, in line with the data access requirements under the SFTR, there could be more than 100 different authorities entitled to access data reported under EMIR and SFTR.
The SFTR trade repositories will need to create a trade-state report, a reconciliation status report as well as a rejections report, on top of the missing collateral report.
Yet, so different in scope
However despite these similarities, EMIR and SFTR do differ in the scope of transactions reported (the former applies to derivatives transactions reporting whereas the latter applies to SFT and total return swap transactions), in trade scenarios, in the content and structure of transaction reports as well as in the UTI generation procedure.
At first glance, the counter-party classifications of EMIR seem to be retained under SFTR with complementary and correlative data held by the TRs under both regulations. There is however a caveat that the definition of financial counterparties (FCs) and Non-Financial counterparties (NFCs) under SFTR is broader than under EMIR. It extends to non-EU (third country) entities because EU branches of third country entities are in scope for SFTR.
The EU regulators are looking into streamlining the data sources with the view to ensure data consistency and data management. Here’s a snapshot of the data field categories as it stands:
|Counterparty data - 16 fields||Margin data - 20 fields|
|Counterparty data - 18 fields||Common data - 94 fields|
|Collateral data - 19 fields||Loan and collateral data - 99 fields|
|Re-use data - 16 fields|
With the technical standards currently in draft format, firms should stay vigilant about the true scope of SFTR.
A significant number of ‘unknowns’ still exist in the SFTR reporting equation. SFTR is yet to be clearly defined, however, firms need to start assessing the commonalities and differences proposed by the SFTR final report, with the aim of leveraging the existing EMIR implementation framework: i.e. ISO 20022 reporting standards, key reference data such as LEIs etc.
It is also imperative that firms understand what SFT products are in scope as well the logic and the structure of their reports prescribed by ESMA. As an active SFT market participant, you need to assess and understand the territoriality effect of EEA versus non-EEA branch level reporting as well as the implications of the proposed rules for ‘data fields’ categories.
UnaVista is London Stock Exchange Group’s award-winning regulatory reporting platform and an EMIR trade repository, approved by ESMA to be a trade repository across all derivatives asset classes. As such, UnaVista intends to leverage the existing successful TR model and extend its registration conditions under SFTR in the near future. As an experienced Trade Repository under EMIR, we are committed to helping clients alleviate the upcoming challenges announced by the SFT regulation especially with creating reporting efficiencies to fulfil multiple regulatory reporting requirements without the need for multiple systems.
© 2020 funds europe