SFTR & EMIR – Same Same but Different?
By Christian Thygesen, Partner & Chairman of the Board | The 27th of May, 2019
Level 2 legislation for regulatory reporting under SFTR was published on March 20th and will come into force on April 11th, 2020 for banks and three respectively six months later for other entities subject to reporting.
In the very short version, SFTR is just an extension of EMIR to cover repos, buy-sell-backs and the various kinds of securities lending transactions. So, if you can handle EMIR, do you really need to worry about SFTR?
In my opinion, the short answer is: Yes, whether sell-side or buy-side, you need to worry about SFTR. Even if there are striking similarities, the differences are far from negligible and will require a focused effort to overcome.
The Implementation of EMIR
EMIR was tedious to implement for many different reasons. Three of the central issues was the fact that EMIR
a ) Covered a new universe of instruments compared to earlier trade reporting under MiFID
b ) Included reporting of the legal framework under which the trade took place
c ) Required reporting of collateral
As for a ) this is indeed also the case for SFTR. One could argue that both from a system and a market perspective, securities financing is less mature today than derivatives trading was in 2014, and for that reason alone, SFTR will require even more efforts than EMIR did.
As for b ) our experience was that under EMIR, this was a headache for many, first of all establishing what legal framework actually governed the relationship with the different counterparties, second to link the (newly formed) legal repository with the trade reporting system. It is our impression that the lesson learned from EMIR and the awareness and formalization of the legal repositories also may have covered any SFT counterparts, so hopefully, this will be less than a headache than under EMIR?
As for c ) this is with great certainty going to be a lot more work than under EMIR. The significant extension of fields to be reported (from 91 under the original EMIR requirements to 153 under SFTR) mainly concerns collateral, and more specifically the reuse of collateral. This has an impact both from an organizational and systems point of view, in particular for buy-side institutions.
Collateral Management
Most banks that I know of, run their collateral management in separate systems not linked to the systems in which they handle their repo, buy-sell-back or securities lending – and most banks actually don’t have one system in which such diverse operations are handled. The collateral management systems will now have to deliver significantly more detailed data and link these to the individual reportable transaction. This, I believe, is non-trivial.
For banks, it is probably manageable. In most cases it will “just” be an issue of getting the right data out of different systems and linking them correctly. For the buy-side, I believe this will be harder. By nature, they have larger pools of securities, and it is quite common to outsource the optimization of these holdings to a third party that performs the actual securities financing operations. This adds organizational complexity to the systems complexity already mentioned.
Data Requirements
To make matters worse, it is my impression, that the majority of buy-side firms, at least in Denmark, have not fully realized this complexity, possibly because they believe that they can delegate SFTR reporting to their counterparts, just as they did with EMIR. For two reasons, I am not sure that such an assumption holds.
First, under EMIR, your counterpart would already have the overwhelming share of data needed to do the full reporting as they were just the mirror of what they were reporting themselves. As already discussed, SFTR requires more data than EMIR, and the new data to be reported relates to the use and reuse of collateral, that your counterpart is unlikely to have. Transferring data to your counterpart in order to allow them to take care of your reporting is thus a significantly bigger job under SFTR than under EMIR.
Second, the nature of the data you have to report to your counterpart in order to make delegation work is not necessarily the kind of data you wish to show to one out of several competing counterparts. Telling the counterparts, you wish to delegate to, how you reuse the collateral received from them may for some not be politically acceptable.
Considerable Issues
Another issue, the ramifications of which I fear are not entirely clear to buy-side firms is, that although they only have to start reporting in October 2020, there is a hitch in the form of a backloading requirement. Any deal alive in October 2020 has to be reported. In practice this means that buy-side firms have to exchange UTIs with their counterparts already from April 2020, for any deal that with a maturity after their own go-live date.
A last issue, where SFTR is markedly different from EMIR is the formatting requirement. Clear formatting requirements at field level were non-existent under EMIR. Almost no matter how a specific field had been filled out, they were accepted by the Trade Repositories. This led to appalling reconciliation levels at the inception of EMIR in 2014. Since then, the industry has had to deal with a series of expanding formatting requirements to increase reconciliation levels. On the back of that experience, ESMA has taken a quite different route on SFTR, requiring from the start that all fields fulfill ISO 20022 formatting standards. This will be quite an up-front investment for all reporting parties – but should save us from the long-term formatting work.
And so, in practice my take on SFTR is that although it has significant high-level similarities to EMIR, the devil – as always – is hidden in the details, and the details differ significantly. Starting with the comparable immaturity of the SFT market and the systems and processes supporting it, going to the increase in data to be reported, and the consequential issues for delegation and ending up with the formatting standards to be observed, SFTR is significantly more of a challenge than just the extension of EMIR to cover a few new instruments.
Christian Thygesen, Partner & Chairman of the Board
Christian Thygesen has been employed in the financial sector since joining the Danish Central Bank in 1992. From 1998 to 2002 he worked for the European Central Bank in Frankfurt, dealing first with financial infrastructure monitoring and then monetary policy in the office of capital markets and financial infrastructure. From 2002 to 2007 he was Head of Projects & Analysis at Roskilde Bank.
Since then he has worked as a consultant in the capital markets area with focus on efficient implementation of regulation and system selection in its many guises.
You can read Christian’s previous posts on the long term effect of MiFID II on the equity market, the bond market, and the derivatives market on the CMP blog.
