Are you ready for SFTR?

Michael Schuler
Senior Business Consultant, Regulatory Center of Excellence, SimCorp

Gernot Schmidt
Product Manager for Regulatory Solutions, SimCorp

Connect with Gernot on LinkedIn

The Securities Financing Transaction Regulation (SFTR)¹ is an EU regulation set out to increase the transparency of securities financing transactions and the reuse of collateral. The regulation covers two aspects of transparency. The first, which this article focuses on, is the reporting obligation for SFTs that have been concluded, modified, or terminated and the related collateral and reuse information under Article 4 of the regulation. The second part is a transparency requirement for investors regarding funds in their periodic reporting (Article 13 ff.) The objective of this article is to describe the impact for different market participants and suggest how to overcome the challenges.

SFTR – key requirements

The reporting requirement set out in the regulation states that the conclusion, modification, termination, and related collateral information of Repos, Reverse repos, Securities Lending and Borrowing, Sell-Buy-Back, Buy-Sell-Back, and Margin Lending (henceforth “SFT trades”) must be reported. The reporting must include a variety of data elements that the European Securities and Markets Authority (ESMA) has structured into four tables. The report must then be sent to a Trade Repository (TR) on t+1, i.e. the day following the execution, modification, or termination of the SFT, in a defined XML format (ISO 20022). This reporting format adds significant complexity to the reporting solution since it needs to accommodate more than 5000 different reporting scenarios under SFTR. The reporting is dual sided, i.e. both sides to the trade (the collateral giver and the taker) have to report the information in a consistent way and TRs have to pair the trades based on the Unique Trade Identifier (UTI) and match a defined number of fields of the two counterparties’ submissions.

For those familiar with derivatives reporting under the European Markets Infrastructure Regulation (EMIR), many of these aspects sound familiar and this is not a coincidence. ESMA took outset in EMIR with the aim to harmonize the two regulations in the future, specifically by changing some of the aspects of EMIR.

SFTR – the timeline

On March 22, 2019, the Regulatory and Implementing Technical standards (RTS and ITS) have been published², while taking effect on April 11, 2019. Given the phased implementation period set out in the text, four groups of market participants have to start reporting as follows below

April 11, 2020: Reporting obligation for investment firms and credit institutions

July 11, 2020: Reporting obligation for CCPs and CSDs

October 11, 2020: Reporting obligation for UCITS and AIF, pension funds, and insurance companies

January 11, 2021: Non-financial counterparties

This gives the first group of reporting participants a bit over five months until the go-live.

SFTR implementation schedule

Confirmaed timeline

Reporting details – the four tables

The reporting requirement consists of a total of 155 fields, divided into four tables with further sub-sections in each table.³

Table 1 contains information on counterparty data, specifically the identification of the reporting counterparty, the other counterparty, the report submitting entity, the agent, clearing member, etc. Here, the static data maintenance of Legal Entity Identifier (LEI) codes and related party structures (e.g. for branches) need to be taken into consideration. In Table 2, the loan and collateral data must be reported. Here, a list of 99 fields is used to identify the security lent or borrowed, the collateral involved, the SFT specific information (e.g. the repo rate), and identification of the event to be reported (e.g. a new trade, a modification, or a termination). Tables 1 and 2 are combined into one line of messaging, identifying the lifecycle events of the SFT trades. Reportable events cover:

• New trades
• Modification and correction
• (Early) Termination
• Valuation and collateral update
• Error

which all pertain to a multitude of business events.

Table 3 consists of data elements to inform on the aggregated margin data for cleared SFTs, which is similar to the Collateral report on portfolio level known from EMIR.

The last table, and commonly assumed the most difficult to source data for, is Table 4, which covers reused (security) collateral per legal entity. If, for instance, a bond has been received as collateral in a reverse repo and is used as collateral in a Repo, this needs to be reported, and the underlying data must therefore be identifiable.

What needs to be reported?

Required reporting data

The data sourcing challenge

The challenge of sourcing all relevant static and event data lies not only in the timeliness, i.e. ensuring its availability by the reporting deadline, but also in the volume. Consider for example that bond static data for collateral of Repos must be available for a wide universe of securities. Some of the data, specifically UTIs, requires trade by trade communication between the counterparties to exchange the identifier before the reporting takes place to ensure the trade can be paired and its attributes match.

Firms might therefore be tempted to delegate the reporting to counterparties, agents, or other intermediaries. Nevertheless, the reporting obligation remains with the firm, particularly for the timeliness and correctness of the report. After the other party has taken care of the reporting, the firm itself must on T+1 validate that its report was complete and correct. Its completeness must be checked against the activity not only in terms of new trades and modifications to trades and positions but also collateral movements, etc. The requirement for correctness means that firms must validate the content of the report sent, in other words check the value of specific reporting fields. This obligation might turn out to be as big a challenge as doing the actual reporting yourself.

Regulatory solutions

With the SFTR go-live in April 2020 (after EMIR and MiFIR), the triangle of European transaction reporting regimes will be complete. Despite their differences, the three regimes adhere to similar operational concepts and data requirements, giving firms the opportunity to leverage synergies on an operational level. At the very least, firms should be able to use the same technology stack for complying with these three regimes. Ideally, firms can also apply operational processes that leverage existing post-trade operations teams, rather than having segregated teams for operations and regulatory reporting.

Cloud-based solutions

Going forward, full-service cloud solutions will play a pivotal role in helping firms to achieve a low Total Cost of Ownership (TCO) for regulatory reporting. Each new regulation requires a significant upfront investment to adapt in-house systems and processes to comply with the new regulatory rules. At the same time, the technical details of each regulatory regime change frequently. Under EMIR, for example, there are changes to the reporting every 8-12 weeks, due to new guidance from ESMA, additional validation requirements implemented by trade repositories, or evolving industry best practices. Unless firms invest in solid and expensive in-house regulatory expertise, it is impossible to digest this information and update systems and processes timely. Dedicated, full-service cloud solutions allow firms to subscribe to an “always compliant” regulatory solution. Here, the solution vendor takes ownership of defining, operating, updating, and testing the regulatory reporting solution. Such a subscription model for regulatory compliance solutions is becoming more and more popular among firms, but also among the regulators.

SimCorp has developed a cloud-based SFTR solution for buy-side firms in order to offer a simplified implementation ahead of the 2020 deadline, including ongoing regulatory guidance.⁴ The solution is fully integrated with SimCorp Dimension’s Investment Book of Record (IBOR), but also allows for external data to be sourced into the solution from e.g. agent lenders or 3^rd party agents. It provides automated daily reporting to the Trade Repository, validation of trade data against the regulatory rule set, and a consistent overview across all business processes – all in order to achieve a high reporting quality. The solution leverages SimCorp’s global regulatory expertise, de-risking the implementation of this new reporting regime and reducing clients TCO for the reporting process.

What should firms do next?

Given the fast-approaching go-live of SFTR in April and the complexity of the reporting, what should firms focus on? For sure, it’s worth starting up an internal SFTR project in your organization to assess your reporting requirements. Amongst the key considerations for every firm are:

• Which category does your firm and its units fall into, e.g. investment firm or pension fund?
• Which parties do you trade with and what kind of SFTs are you active in?
• Which volumes (notional and number of trades) do you execute on average per annum?
• Which SFT types and flavors do you trade?

The following unordered list provides a few relevant dimensions to consider:

• Repos/Reverse Repo
  • Bilateral, Cleared, 3^rd Party
  • Fixed, Open term
  • Fixed, variable, floating rate
  • Single (initial) collateral (e.g. Bond), Baskets
  • Clearing models used
  • Documentation (Master agreements)

   

• Sell-Buy-Back / Buy-Sell-Back
  • Documented, undocumented
  • Fixed, Open term
  • Fixed, variable, floating rate
  • Single (initial) collateral (e.g. Bond), Baskets

   

• Security lending
  • Bilateral, Cleared, 3^rd Party, Agency
  • Fixed, Open term
  • Security, Commodity underlying (lent/borrowed Security)
  • Clearing models used
  • Documentation (Master agreements)

   

• Is collateral re-used, both related to initial collateral and rehypothecation of pledged margin collateral?
• Which Trade Repository do you plan to report to?

It’s worth remembering that whilst SFTR is related to EMIR, its individual complexity and especially its (static) data requirements should not be underestimated. Also, the market for SFTs is much more fragmented with many more different actors involved than the market for derivatives, which makes the reporting setup and daily operations more complex. Leveraging available cloud solutions leveraging regulatory expertise makes it easier to overcome those challenges.

1. http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32015R2365&from=en

2. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L:2019:081:TOC

3. A list of the 155 fields can be found here: https://www.esma.europa.eu/system/files_force/library/esma70-151-1019_consolidated_sftr_validation_rules.xlsx

4.Find fact sheet on SimCorp’s SFTR solution at the bottom of the Regulatory Compliance section.