Michael Schuler
SFTR Product owner, Regulatory Center of Excellence, SimCorp
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:
- 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.
- 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.
- SFT trades concluded between April 11 and July 12 do not need to be back-reported on July 13.
- 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.
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.
