The purpose of the Securities Finance Transaction Regulation (SFTR) to enhance the transparency and regulatory oversight of the securities financing market. The regulation covers a reporting obligation for counterparts in connection with:
- Repos
- A buy-sell back or sell-buy back transaction
- Securities lending and borrowing
- Margin lending (prime brokerage)
The SFTR is similar to what was seen under EMIR for the derivatives market: mandate of the European Securities and Market Authority (ESMA) to approve and regulate trade repositories combined with a dual reporting obligation for parties concluding deals in the above-mentioned trade types.
This page briefly describes what Nordea and you as a customer should do to comply with the requirements. It also provides information about Nordea’s status in relation to SFTR.
Scope and regulatory reach
The SFTR is an EU regulation. Trades carried out by parties incorporated within the EU must therefore comply with the regulation. However, the SFTR extends the territorial scope by including trades carried out by a EU branch of a third-country counterpart.
Exceptions: trades with ESCB members are excluded from the SFTR reporting as they are covered by the MiFID/MiFIR requirements and should not be double-reported.
At its core the SFTR is a reporting regime. It mandates parties to a trade to report the trade details to a trade repository at T+1 and subsequently report any changes as well as daily collateral and valuation for the life of the trade. The regulatory foundation outlines a set of tables with details of the information that must be reported (see Regulations for more details). The regulation goes further than EMIR as it also mandates a standard format for how to communicate with Trade Repositories, endorsing the ISO20022 standard for regulatory reporting.
Reporting covers five distinct areas:
- Trade and trade-linked collateral
- Collateral (EOD)
- Valuation
- Margin data report for CCP margins in relation to cleared SFTs
- Collateral Reuse, Cash Reinvestment and Funding Sources Reports
Client types
Like EMIR and MiFID/MiFIR, the SFTR operates with different types of parties to a trade. The parties are classified as Financial (FC) or Non-Financial (NFC). The NFC category is then split into NFCs and Small NFCs.
According to ESMA’s final SFTR technical standards report, a small NFC is one which does not exceed the limits of at least two of three criteria:
- Balance sheet total of 20m EUR
- Net turnover of 40m EUR
- Average number of 250 employees during the financial year
In addition, Central Clearing Parties (CCPs) is considered a special type and has different reporting obligations compared to other parties.
Requirements
Legal Entity Identifier (LEI) is mandatory if you as a client want to do an SFT. Without a LEI it will not be possible to report your side of the trade to a Trade Repository. Please visit the LEI section for more information.
EMSA has specified in its validation rules that LEI of the issuer of the security is mandatory data for any security placed as a loan as well as on securities placed as collateral. This might not be a big issue for European investment grade instruments. However, EU non-investment grade issues as well as non-EU issues have lower LEI data quality. Hence, the SFTR can indirectly limit the list of ISINs that can be used in SFTs or as collateral for an SFT.
Customer classification (client type), sector code, additional sector codes are important for SFTR reporting and needs to be provided to the reporting party if you are opting for delegated reporting.
The client type is especially important as it drives when you need to commence reporting.
Every SFT should be given a globally unique transaction identifier – a UTI. The UTI should be shared between the parties to the trade. The parties should agree who is to generate the UTI. If no such agreement is in place, the regulation describes a waterfall model for who would be the generating party. The generating party is obligated to share the UTI with the counterpart in “an electronic format in a timely manner for both parties to be able to fulfil their T+1 reporting obligation”. Nordea’s approach to the UTI generation process is described in the section UTI exchange processes.
For trades on electronic venues, centrally cleared trades and centrally confirmed trades it is the infrastructure provider that assigns and shares the UTI.
Nordea’s offerings and support of the SFTR
Delegated reporting is when the reporting party (typically the financial counterpart to a trade) does the reporting to TRs on behalf of both parties.
The SFTR regulation operates with mandatory delegation for small NFCs. This means that if a party to a trade is a small NFC then it is the FC that becomes accountable for the SFTR reporting. The NFC is to provide the FC with the static data needed for the FC to do the reporting. This includes obtaining and maintaining a valid LEI code, but the responsibility (and accountability) for the reporting falls on the financial counterpart.
Voluntary delegated reporting is also allowed under the SFTR. Here the parties to a trade agree that one party will do the reporting of all SFTs between the parties. It differs from mandatory delegated reporting as the delegating party has the responsibility and accountability for the correctness and completeness of the reporting, not the reporting party.
Nordea is supporting both mandatory and voluntary reporting. The reporting will be done on a best effort principle (given the high degree of pairing and matching specified in the regulation it is in the interest of the financial counterpart that both sides of a transaction are reported as correctly and completely as possible). Both mandatory and voluntary delegated reporting will be free of charge and the increased regulatory cost is expected to be reflected in the pricing of the underlying trades.
Clients with SFTs with multiple financial counterparts will experience some fragmentation in the reporting. This could, even if different counterparties report to different trade repositories, be the case for both the reporting of trades and of collateral. However, if the client is clearing via CCPs then the margin reporting would need to be done by one of the FCs as assisted reporting or by the CCP. Similarly, if the client is reusing posted collateral, the reuse report needs to be done by one of the financial counterparts. Under delegated reporting a client would therefore need to disclose reuse and, if relevant, CCP margin information to one of their financial counterparts on a daily basis.
The SFTR regulation has high focus on the quality and consistency of the data reported to the Trade Repositories. Clear statements in the regulation point to no over-reporting; parties to a trade need to agree who is generating the UTI. If you are lacking an UTI from the counterparty and you agreed that they are the generating party, you are not allowed to generate your own to comply with the reporting deadlines as this would be considered over-reporting.
Like for EMIR the TRs will try to pair up the two sides of a trade using the UTIs reported. The TR will have pairing both within the TR itself and with other TRs. The TRs will exchange information on unpaired SFTs between the TRs to allow for pairing and matching between the TRs.
Once paired, the TRs will perform the matching according to the specifications laid out by ESMA in the RTS and ITS of SFTR. Up to 100 of the 155 reportable fields have been set out as matching fields with limited tolerance.
While pre-matching is not a regulatory requirement in SFTR, the tight T+1 reporting deadline, the number of matching fields and the narrow matching thresholds outlined by ESMA open a market for solutions that allow parties to deal with matching breaks already at the trade date (T) in order to resolve as many discrepancies prior to the reporting deadline as possible.
Several service providers offer pre-matching services that allow parties to report the details of trades to a central component that then performs matching, UTI assignment and potentially also caters for the reporting to the TR. As there are several of these service providers, we have market fragmentation and some counterparties will be on one platform, others on another, some will support several and some will opt not to do pre-matching at all. The more fragmentation, the lower the value of the pre-matching solutions.
Nordea is using the IHS Markit/Pirum pre-matching platform to do intraday reporting of all SFTs that we are part of during T with periodic feeds (every or every second hour during working hours + end-of-day deliveries of collateral and trade states). This also means that we will set up intraday pre-matching processes to clear out as many pre-matching breaks as possible prior to the T+1 reporting deadline.
One of the key learnings from EMIR was that the exchange of UTIs on voice-brokered trades and other bilateral non-venue generated trades has been the root cause of missed or wrong reporting. Based on this the SFTR regulation outlines more strongly the responsibility for the UTI generation and the exchange. However, there is still no globally endorsed “template” that would allow the parties to a trade to come to the same UTI independently, hence the need to exchange the UTI.
Here we see several solutions and solution providers – the pre-matching described above being one. However, where there are several solutions there will be fragmentation and we have yet to see whether any of these solutions will materialise into de facto standards globally or local/regionally or within certain party networks.
Each party to SFTs need to consider how they will support the UTI process. If they would like to always generate the UTI (also having the “privilege” of sharing the UTI in a timely manner in an electronic format) Or if they would like to consume the UTI from the counterpart or use a pre-matching platform to generate and exchange the UTI, or if they will do the exchange bilaterally with the parties to their trades.
Nordea will use the IHSMarkit/Pirum solution to assign and share UTIs with other participants on the platform. In addition, the platform will via a client portal or SFTP interface give non-reporting parties the ability to obtain the UTIs assigned to their LEIs. Prior to this our reporting solution will consume UTIs generated by electronic trading venues, execution facilities and conformation platforms. For delegated reporting Nordea automatically assumes the UTI generating role.
For the remaining transactions (voice-brokered trades with parties not on same pre-matching platform or on no pre-matching platform at all) the sector is investigating two alternatives relying on a minimum field list for exchanging the UTI and trade details to allow parties to do trade matching and exchange the UTI. Such minimum field list could be used between different matching platforms and bilaterally between the two parties.
Nordea will establish bilateral UTI exchange/chaser processes running at T+1 9 CET and then repeated at intervals until all UTIs have been exchanged/obtained.
The SFTR regulation empowers ESMA to approve and oversee Trade Repositories. A Trade Repository (''TR'') is a central data collector and provider that allows us as parties to SFTs to submit data on these to a central data hub. The TR is then obligated to make these data available to various regulators including the local FSA and ESMA itself.
There are several different Trade Repositories in the market that have been or will be approved as TRs under SFTR, among these:
- DTCC (EU and UK)
- Regis TR (EU and UK)
- UnaVista
With the SFTR the choice of repository is made somewhat simpler than with EMIR because of the standard for sending data to and from the TR (iso20022). Many of the service providers claim to be agnostic to the choice of TR and support routing the trades to the TR selected by the counterpart.
Nordea has signed up to use DTCC (EU) as our main TR for SFTR. For delegated reporting (see Mandatory and voluntary delegation) the reporting of the client side of our transactions will also be send through to DTCC (EU.
As clients to SFTs in scope for reporting you should consider your choice of TR. For transparency and reconciliation purposes we recommend using only one TR. Local FSAs will get data from the TRs that you can be asked to verify and explain. For all but small NFCs we recommend clients to onboard with a TR for SFTR and communicate this to your financial counterparts.
Originating from the post-financial crisis G20 summit where it was agreed to establish better regulatory oversight in the financial markets and from the Financial Stability Board’s (FSB) recommendations for monitoring and regulating what is called “shadow banking”, the EU main SFTR regulation was published in the Official Journal of the European Union on 23 December 2015. Download here.
The European Union in the SFTR regulation empower ESMA to outline the Regulatory Technical Standards (RTS) and the Implementation Technical standards (ITS) of the SFTR regulation. Detailed information from ESMA on this can be found here.