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.
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 published2, 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.3
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.
deltaconX is a full service provider offering a unique software & support package catering for European financial-, energy- and commodity trading organizations enabling them to meet their various regulatory reporting and market surveillance obligations such as EMIR, MiFIR/MiFID II, SFTR, FinfraG, REMIT and MAR within a unified platform. Manual efforts and the total costs of ownership are therefore reduced to a minimum.
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 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.
For more information on how deltaconX can advise you on your SFTR decision to adopt delegated or self-reporting, and on the implications of this decision for your business, please contact us at office@deltaconx.com .
