SFTR regulation came into force january 2016.
SFTR - Securities Financing Transaction Regulation
SFTR aims to reduce systematic risk in the market for securities financing transactions (SFTs).
The photo is of the Acrobat bridge that is situated between the areas Grønland and Bjørvika in Oslo. DNB is on the left hand side.
European Parliament and Council Regulation (EU) 2015/2365 of 25 November 2015 on transparency of securities financing transactions and reuse (SFTR Regulation).
SFTR came into force in January 2016 and aims to reduce systemic risk in the securities financing transactions (SFTs) market through increased transparency and monitoring. Transaction reporting of SFTs started on 11 July 2020 with a step-by-step phasing in of the reporting commitment based on counterparty categories.
* 11 july 2020 (exposed from april 11, 2020 due to Covid-19) ** 11 october 2020 *** 11 january 2020
The Financial Stability Board (FSB) and the European Systemic Risk Board (ESRB) initiated in the wake of the financial crisis and increased focus on regulating financial markets work to map risks associated with "shadow banking" activities, or credit-related activities outside the mainstream banking system.
Securities financing transactions (SFTs) and reuse of collateral provided in connection with SFTs were identified as a source of funding in need of regulation. The work eventually led to an FSB policy supported by the G20 and SFTR is the European Commission's response to this.
SFTR was published in the Official Journal of the European Union on 23 December 2015 and authorized the EU ESMA to develop the regulatory technical standards (RTS) and the implementing technical standards (ITS) for the SFTR Regulation.
The SFTR Regulation sets out rules on transparency for securities financing transactions and reuse of collateral.
The SFTR Regulation is similar in nature to the EMIR Regulation for the derivatives market.
A key purpose of the Regulation is to provide the authorities with information about risks related to the use of SFTs through reporting SFTs to trade repositories (TR).
The Regulation sets out three main measures in order to achieve this:
What products are included in SFTR?
A securities finance transaction or SFT is defined in SFTR Art. 3(1) (11) as:
Who does SFTR apply to?
SFTR basically applies to all counterparties incorporated into the EU, including all branches regardless of where they are located. SFTR also applies to counterparties in a third country if the SFT is entered in the course of the operations of a branch located in the EU. Both EU counterparties and counterparties in third countries who are not directly covered but trade with an EU counterpart must be classified in order to determine when the reporting obligation occurs (Phases 1-4).
SFTR operates with the following customer classification:
SFTR in Norway
The SFTR Regulation is not currently incorporated into the EEA Agreement, but has been deemed EEA relevant. The Norwegian Ministry of Finance on 27 June issued a hearing on the Financial Supervisory Authority of Norway's proposal for the implementation of the SFTR. The hearing deadline was 1 October 2019. In accordance with EU/EEA law, regulations shall be incorporated into Norwegian law as they are. No amendments are expected in the EEA Joint Committee's decision except for changes to the dates of entry into force and clarifications on the authority and duties of ESMA.
Until SFTR is incorporated into the EEA agreement and made into Norwegian law, SFTR will not have direct application to DNB. This means that DNB for the time being is not subject to the reporting obligations under SFTR. DNB would be classified as a Phase 1 counterparty if SFTR had been in force in the EEA at the same time as in the EU.
Requirements under SFTR
From the entry into force of the reporting obligations under SFTR (originally April 2020 but postponed until July 2020 due to covid-19), it is required to obtain a Legal Entity Identifier (LEI) when entering into an SFT. Without LEI, it will not be possible to report the transaction to a trade repository (TR).
There are several authorized providers of LEIs. See GLEIF for more information on how to obtain LEI.
2. Trade repositories, pairing and matching.
A trade repository (TR) is a central database that will receive information about SFTs and then publish this information at an aggregate level. TRs shall at the same time make the same information available in detail for local supervisory authorities and ESMA. The reporting has similar characteristics to the corresponding reporting obligation for information on derivative contracts under the EMIR. TRs shall be approved and registered by ESMA and are subject to the ESMAs supervision.
There are currently four TRs registered in accordance with SFTR:
DNB has chosen DTCC as our TR for SFTR purposes. DTCC has also been selected as the TR for delegated reporting, both voluntary (Phase 3) and mandatory (Phase 4).
Where both parties are subject to reporting obligations under the SFTR, both parties to an SFT are obligated to report the transaction to a TR. The TR will attempt to pair the two sides of the transactions based on a so-called UTI code. The TR will pair the transaction against its own register and with other TR registers. When an SFT is paired, the TR will then perform matching in line with ESMAs technical standards. A majority of the 155 reportable data fields under SFTR are subject to matching and there is a low tolerance for deviations when matching data fields.
Any SFT should be assigned a unique global transaction code (i.e. unique transaction identifier or UTI). An UTI shall be exchanged between the parties in advance of reporting the SFT to a TR. Before reporting, the parties must agree who will be responsible for generating and sharing the UTI. In the absence of an agreement, the UTI determination process follows ESMA's recommended waterfall methodology for generating an UTI. The party responsible for generating an UTI shall share this with the counterparty on an appropriate electronic format within a reasonable time so that both parties can meet their reporting requirements of T+1.
DNB will, unless otherwise agreed, generate and share UTIs with our SFT counterparts through IHS Markit. If the counterparty also wants to generate an UTI, we would use ESMA's waterfall methodology.
4. IHS Markit
DNB has entered into an agreement with IHS Markit/Pirum on the generation and sharing of UTIs as well as the ability to read/check/control reporting files before these are handed over to a TR. This also includes the possibility to carry out pre-matching.
When using ESMA's waterfall methodology, DNB will use IHS Markit to receive and share UTIs. For delegated reporting, DNB will assist the counterparty with access to the IHS Markit Non-member solution that provides access even if the party is not a member of IHS Markit
SFTR operates with short deadlines for reporting (T+1). The number of data fields to be matched between the parties and limited matching tolerances has created a need for solutions that can address matching discrepancies between parties on the transaction date (T) and resolve them before the reporting deadline (T+1). There are several service providers that provide such pre-matching services. DNB is using IHS Markit/Pirums pre-matching platform. DNB will submit its reports through IHS Markit/Pirum for pre-matching before it is forwarded to the TR. Pre-matching will help both parties check and control their reports and uncover any discrepancies before reporting SFTs to the TR.
Delegated reporting means that the delegating party (i.e. a party subject to the reporting obligation under SFTR) delegates the reporting of the details of the SFT to the reporting party, typically the financial counterparty in an SFT, which will then report both sides of the SFT for both parties.
SFTR distinguishes between mandatory delegated reporting and voluntary delegated reporting.
Mandatory delegated reporting applies to SME NFC- and means that where the counterparty to a SFT is a SME NFC- the financial counterpart (FC) is both the reporting party and responsible and accountable for ensuring reporting is correct and complete. The SME NFC- shall provide the FC receives the mandatory static data needed for reporting. Mandatory delegated reporting will apply from phase 4 (January 2021).
Voluntary delegated reporting, as opposed to mandatory delegated reporting requires an agreement between the delegating and the reporting party. It allows for the delegation of the reporting obligation, but not the reporting requirement. For voluntary delegated reporting, the legal responsibility and accountability for complete and accurate reporting remain with the delegating party, not the reporting party. DNB will offer voluntary delegated reporting for counterparties in phase 3 and phase 4 from October 2020 (for phase 3). The service will be free of charge and based on standard documentation prepared by ISDA and other industry organizations (i.e. master regulatory reporting agreement).
SFTR requires states to impose sanctions for infringements of Art. 4 (SFTR reporting) and Art. 15 (reuse of collateral). One particularly relevant and highlighted form of sanction is administrative penalties. In Norway, the Financial Supervisory Authority of Norway will be given the power to impose such sanctions. SFTR stipulates maximum penalties of either EUR 5 million or EUR 15 million depending on the provision breached and whether the penalty shall be imposed on natural or legal persons. SFTR allow for the relevant EU/EEA state to set even higher penalty amounts in their local legislation. This has not suggested in Norway.
For infringements of the reporting obligation under Art. 4 a penalty of up to EUR 5 million (NOK 50 million) may be imposed for natural persons. Legal persons in breach of Art. 4 may be penalized with fines of up to EUR 5 million (NOK 50 million) or up to 10 per cent of the total annual turnover, according to the last approved annual accounts. In both cases, the fine could be set at three times the profit earned or losses avoided as a result of the infringement. This applies even if this results in a higher penalty than otherwise.
Mandatory static data
Sector code, additional sector code, and client classifications are three data fields that are important in SFTR reporting which must be provided even if one chooses to delegate the reporting obligation.
Customer classification is, inter alia, used to determine which phase you fall into and from what point the reporting obligation starts.
Please contact us if you have any questions related to SFTR and the information on this page.