Securities Finance Transaction Regulation (SFTR)
The European Union has introduced 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:
- A buy-sell back or sell-buy back transaction
- Securities lending and borrowing
- Margin lending (prime brokerage)
The SFTR is very 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.
Reporting starts on 11 April 2020 for investment firms and credit institutions (see more under Timeline).
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 II 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)
- Margin data report for CCP margins in relation to cleared SFTs
- Collateral Reuse, Cash Reinvestment and Funding Sources Reports
Like EMIR and MiFID, 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
ESMA has come up with a gradual approach to the SFTR consisting of four phases.
Starting on 11 April 2020 phase 1 includes EU-based investment firms and credit institutions.
Phase 2, starting on 11 July 2020, includes Central Clearing Counterparties (CCPs) and Central Securities Depositories (CSDs) and non-EU investment firms and credit institutions.
Phase 3, starting on 11 October 2020, adds UCITS funds and AIF funds, insurance companies and pension firms to the reports, and lastly
Phase 4 includes Non-Financial companies (NFCs) with reporting starting on 11 January 2021.
For Nordea the reporting requirements start in Phase 1 while many of our clients will not start to report until three, six or nine months later.
The regulatory technical standards operate with a backloading requirement for SFTR trades that were done before go-live (11 April) and still live 180 days after go-live to be reported 180-190 days following go-live. During consultancy ESMA opened up for different approaches, and clarification is expected with the release of the final report expected in December 2019. Trades opened before go-live but closed before the 180 days are not to be reported.
Nordea expects to do backloading according to the RTS (the 180 days after go-live) to allow for focus on new trades during the go-live phase and because many of the parties to the trades will not start reporting until three or six months after the go-live point. If clients have a strong wish to do backloading earlier Nordea supports backloading on a case by case basis.
LEI is mandatory
As of April 2020 Legal Entity Identifier (LEI) will become 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.
Issuer LEI is mandatory
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.
Mandatory static data
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.
Nordea’s offerings and support of the SFTR
Mandatory and voluntary delegation
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. Mandatory delegated reporting will commence with the January 2021 Phase 4 (Timeline)
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 will support both mandatory and voluntary reporting from April 2020. 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.
Under assisted reporting the reporting party, typically a Financial or a Financial Service Provider, offers to build the ISO20022 structure of the messages using the information that is available to the reporting party and making the files available for the client to add any additional information that the reporting party is missing to complete the reporting. Assisted reporting could include support for delivering the completed files to a trade repository. However, this is less likely as clients would opt for the assisted reporting model to be in control of the reporting process and possibly to avoid having to disclose information like reuse percentages, instruments in which a client has holdings etc to a financial counterpart.
Nordea will not offer assisted reporting under the SFTR at go-live in April 2020.
Trade Repository (TR) pairing and matching processes
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. The implementation of the matching is phased, starting with the basic information. The phasing of matching extends over several years.
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 has opted to sign up for 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.
UTI exchange processes
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 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)
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.
Client outreach and data gathering
A key to a smooth go-live of SFTR reporting is that the parties have aligned expectations and shared relevant static data prior to the go-live. In order to achieve the desired smooth go-live, Nordea will reach out to its clients, asking them to provide necessary information so that accurate transaction reporting can commence when the relevant transaction reporting obligation under SFTR comes into force from 11 April 2020.
Please contact email@example.com if you have any questions about any of the above
The information provided within this website is intended for background information only. The views and other information provided herein are the current views of Nordea Markets as of the date of publication and are subject to change without notice. The information provided within this website is not an exhaustive description of the described product or the risks related to it, and it should not be relied on as such, nor is it a substitute for the judgement of the recipient.
The information provided within this website is not intended to constitute and does not constitute investment advice nor is the information intended as an offer or solicitation for the purchase or sale of any financial instrument. The information provided within this website has no regard to the specific investment objectives, the financial situation or particular needs of any particular recipient. Relevant and specific professional advice should always be obtained before making any investment or credit decision. It is important to note that past performance is not indicative of future results.
Nordea Markets is not and does not purport to be an adviser as to legal, taxation, accounting or regulatory matters in any jurisdiction.
The information provided within this website may not be reproduced, distributed or published for any purpose without the prior written consent from Nordea Markets.