Are you ready for SFTR and efficient exchange of UTI?

The reporting go-live is approaching fast
EMIR reform

Michael Schuler

SFTR Product owner, Regulatory Center of Excellence, SimCorp
A strategic data approach to regulatory compliance Gernot Schmidt

Gernot Schmidt

Product Manager for Regulatory Solutions, SimCorp
Linkedin Connect with Gernot on LinkedIn

Read the article and learn about:

  • SFTR background and timelines
  • Impact analysis for different market participants
  • How regulatory solutions can help firms meet the challenges

The Securities Financing Transaction Regulation (SFTR)1 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. The article follows up on our 2019 article on SFTR and now also describes the current market discussions about efficient exchange of UTI.2 Additionally, it comments on the recent ESMA communication regarding mitigation of Covid-19 impacts on the SFTR reporting go-live.

 

SFTR – key requirements and UTI exchange challenges

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.

It has been heavily debated for the last two years how counterparties to an SFT can efficiently and with minimal effort exchange UTI. This represents a bigger challenge then under EMIR, where ETD and most OTC are already traded electronically and UTI exchange is built into the protocol. However, SFT and especially repos and buy sell-backs continue to be traded mostly manually via chat or phone, making the communication and re-keying of long UTI error-prone and not recommended. Two main options for electronic UTI exchange are considered by most firms, but they come with significant costs and operational risks.

  • Exchanging of csv files by email – although cheap, this approach is difficult to automate and requires clear agreements between counterparties about the exchange format and timing. It carries significant operational cost from manual process steps and for exception handling, especially if exchange formats can’t be unified across counterparties.
  • UTI exchange platforms – several vendors are offering such platforms, but connecting is labor intensive and, unless access is sponsored by the sell-side counterparty, expensive. The lack of integrated exception management workflows also carries additional operational costs and risks. Lastly, the market for these platforms is fragmented without interoperability, so one platform will only help exchanging UTI with a subset of counterparties.

However, over the course of the last months an alternative approach has emerged. The Danish Bankers Association and the Danish CSD, VP Securities, have implemented a SWIFT workflow to exchange UTIs between counterparties as part of the collateral settlement process. The latest SWIFT release includes a dedicated field for the UTI and the CSD passes this field on to the counterparties in the SWIFT match confirmation messages for the exchanged collateral.

This solution is very attractive for buy-side firms, since it allows full automation of the UTI exchange at little extra cost. Many counterparties already have SWIFT settlement processes in place and this approach requires only minor changes. But significant engagement of buy-side to with their counterparties and custodians will be required for this protocol to become market best practice. SimCorp is committed to helping their client community to facilitate this change and the discussion with relevant market participants.

 

SFTR – the timeline

On March 22, 2019, the Regulatory and Implementing Technical standards (RTS and ITS) have been published3, while taking effect on April 11, 2019. It describes a phased implementation period with different reporting start dates for four groups of market participants. Taking into account public holidays on Easter and weekends, the first reporting dates are these:

  • Tuesday, April 14, 2020: Reporting start for investment firms and credit institutions
  • Monday, July 13, 2020: Reporting start for CCPs and CSDs
  • Monday, October 12, 2020: Reporting start for UCITS and AIF, pension funds, and insurance companies
  • Monday, January 11, 2021: Reporting start for non-financial counterparties, this includes public entities like some national pension funds

 

On April 19, followed by further clarification on April 26, ESMA published a statement about the delay of reporting obligations and backloading requirements. Essentially, firms should note four key points of relevance:

  1. The legally binding Reporting Start Date for Phase 1 firms (credit institutions and investment firms) has not changed. But local NCAs are asked to not enforce reporting obligations until the Phase 2 Reporting Start Date on July 13. That means that Phase 1 firms are not expected to start reporting before that date.
  2. Trade Repositories will not be able to send reporting data to NCAs before July 13, hence it is unlikely that firms that want to submit reports to their TR before July 13 will be able to do so. Any firm which plans for early reporting should confirm the approach with their TR.
  3. SFT trades concluded between April 11 and July 12 do not need to be back-reported on July 13.
  4. ESMA does not expect NCAs to enforce the back-loading requirement, hence firms effectively no longer need to consider backloading and its operational implications.

 

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.4

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.

SFTR go live and UTI exchange
SFTR go live and UTI exchange
SFTR go live and UTI exchange
SFTR go live and UTI exchange

 

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.5 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 3rd 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, 3rd 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, 3rd 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 and 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. /en/insights/journal/2019/sftr-go-live

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

4. https://www.esma.europa.eu/sites/default/files/library/esma80-191-995_public_statement.pdf

5. 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