(Jens Woeste, March 3rd 2020)

The EU Securities Financing Transaction Regulation (SFTR) comes into effect on April 11th (April 14th depending on holiday calendar). Most if not all market participants should by now have concluded the implementation and be ready for migrating their solutions into production. 

According to SFTR the reporting requirements start at the so-called Go-live date (in the document denoted G) which is defined as 12 months after the Regulatory Technical Standard (RTS) came into force on April 11th 2019 for the first wave (credit institutions and investment firms) and then separated with 3 months for subsequent reporting entity groups.

Adjusted for holiday calendars the actual go-live dates will be:

• Tuesday 14 April 2020 credit institutions and investment firms (or on Monday, 13 April 2020, if this is not a public holiday)
• Monday 13 July 2020 CCPs and CSDs
• Monday 12 October 2020 insurance firms, UCITSs, AIFs and pension funds
• Monday 11 January 2021 non-financial entities

The ICMA European Repo and Collateral Council released a set of recommendations for SFTR reporting last week. It is quite comprehensive and could be used as a good “pre-flight” checklist before the go-live. Obviously it is “just” recommendations on the interpretation of the regulation but I think it is a fair assumption to say that they are quite accurate and represent market consensus.

Key recommendations:

• Transactions (including collateral) with a member of the European System of Central Banks should not be reported or included in re-use calculations.
• Collateral transformation should be reported under SFTR. If transformation is achieved through back-to-back repos then these should be reported as two separate transactions with separate UTI.
• Intra-day repos should be reported
• Fails-curing transactions should be reported as an uncollateralized lending transaction.
• Synthetic repos (cash vs securities transaction leg vs a total return swap) should not be reported under SFTR (they will be reported under MIFid and EMIR respectively)
• Current assessment is that pledge repos should be reported as a repurchase transaction.

Some challenges may still be out there
Besides the immense task of data consolidation and cleansing which is the key foundation for achieving a good success rate in matching the trade reporting of your counterparts (or using a data enrichment service aligned with your counterparts to ensure matching), one of the main issues is the fact that the reporting requirements are heavily dependant on the state transitions of the products in question. Needless to say you need to have your products implemented using a market standard best-practice processing workflow in order to be able to identify and capture the events that trigger a reporting entry – and be sure that your counterparts uses the exact same process.

A basic example of a potential challenge related to this could be a trading system that handles trade amendments and lifecycle actions in a “Terminate->New” style where the original trade is terminated and a new trade is generated as a copy of the original plus the amendments. For the purpose of processing this might be feasible as you can easily suppress processing rules and actions depending on the origination of the apparent “new trade”. The problem is that for SFTR it can have a big impact in terms of knowing if a lifecycle action was applied and obviously which. Was it a rerate or maybe just an amendment of information? In addition you have the added complexity of the various maturity types out there. How would you manage evergreens, extendibles and ROE for example? Over the years I have experienced many “workarounds” implemented for processing which did get the job done but I seriously doubt that these kinds of workarounds will be manageable with respect to SFTR.

Another potential issue (which remains to be seen) is regarding the end-of-day reporting requirement. This means that participants may have the perception that they can design their reporting solutions around an end-of-day snapshot of trading activity. The caveat therein can be illustrated with a very simplistic example. Imagine a trade that goes through the following transition: New -> Amend -> Cancel. If nothing was sent to the outside world (confirmations, etc) then many trading systems will act as if the trade never existed because it was cancelled before it went out the door. If the reporting solution is based on an end-of-day snapshot of trading activity the risk is that this trade may not be flagged as it (according to the trading system) never existed. The SFTR reporting requirement however would be 3 reporting lines – NEWT – MODI – EROR. This can only be accomplished if the reporting system is capable of catching these actions based on events generated by the trading system as they occur.       

LEIs – basing reporting requirements on incomplete information…
The Global Legal Entity Identifier Foundation (GLEIF) was established in the wake of the 2008 financial crisis and was inaugurated in 2014. The aim was to be able to accurately identify any participant in a financial transaction. Based on this it seemed natural to incorporate LEIs as a core component of the transaction reporting. However, according to a statement issued by ESMA on January 6th this year it is estimated that only 88% of instruments issued by EU based issuers have a LEI code and the non-EU average is down to about 30%. Based on this ESMA stated that they will allow for a “smooth” transition period of 12 months ending on April 13th 2021. During this transition period participants are required to search the GLEIF data set and document all cases where no LEIs can be found. ESMA continued the statement saying they would monitor the evolution of issuance of LEIs for third-country issuers. Besides the fact that the LEI data is incomplete it is also not clear which “Golden Copy” should be active for reporting which could lead to inconsistencies between participants LEI information and hence matching issues.

Backloading – the mother of all uploads (and mismatch)
The initial reporting requirement regarding backloading is defined as transactions executed before the relevant go-live date (G) (which means April 11th 2020!) with more than 180 days remaining to maturity and shall be reported no later than G +189 days.

This means that institutions can wait to backload these trades in the event that they end up doing an early termination of these in which case reporting is not required. 

Not only does the requirement for backloading of trades pose a potentially large amount of transactions to be reported but it also requires the various participants to agree on when and what to report (in the event that early terminations are likely). In any event this will likely lead to mismatches in net exposures during the backloading phases.

Final remarks
It is clear that a lot of preparation and resources has gone into complying with SFTR. The recommendations published by ICMA constitutes to me the benchmark interpretation of the requirements. Even if some of the recommendation could be seen as debatable it still constitutes a market consensus and should be followed for the sake of peace and prosperity. The challenges highlighted in this article are obviously not representative of the full scope of what the SFTR reporting entails but if nothing else then maybe it can be food for thought for those participants who may have chosen to simplify their implementation of SFTR based on the notion that this is just simply another homegrown end-of-day report. It is a well known fact that the good horse only jumps as high as it needs to.

It will be interesting to see whether the authorities will actually monitor and act with sanctions or penalties on the basis of reported transactions or whether it will be a write-only database with no added value for market participants filling up some data centre. For now I will put my seat and table to the upright position, fasten my seatbelt and wait for further instructions.

Sources:
ICMA Recommendations for Reporting under SFTR
https://www.icmagroup.org/assets/documents/Regulatory/Repo/SFTR/ICMA-recommendations-for-reporting-under-SFTR-240220.pdf
ESMA statement on implementation of the LEI requirements under the SFTR reporting regime
https://www.esma.europa.eu/sites/default/files/library/esma74-362-388_lei_statement_sftr.pdf
Global Legal Identifier Foundation
https://www.gleif.org

Disclaimer:
The views and opinions expressed in this article are those of the authors and do not necessarily reflect the official policy or position of any other agency, organisation, employer or company. Assumptions made in the analysis are not reflective of any entity other than the author(s) – and, since we are critically-thinking human beings, these views are always subject to change, revision and rethinking at any time.