What is SFTR Regulation?

Securities Financing Transaction Regulation

Securities Financing Transaction Regulation 2015/2365 of the European Parliament and of the Council of 25 November 2015 on transparency of securities financing transactions.

Risco Software created a next module of Cesarz system – titled Cesarz_SFTR – to reporting of the transactions according to SFT Regulation.

Request a proposal

Which entities are subjected?

All businesses irrespective of whether operating directly on financial markets (e.g. banks, investment firms, investment and retirement funds, insurance companies) or operating independently of them but conducting transactions on SFTR-regulated securities and goods. The reporting requirement is imposed on both parties to such a transaction.

When do you have to start the SFTR-imposed reporting?

03/22/2018 – Executives acts were published, it means, that all requirements of the SFTR reporting are finally recognised.

Date of reporting requirement’s entry into force varies depending on a type of an obligated entity:

04/11/2020 – credit institutions and investment firms.
07/11/2020 – banks, CCPs and central securities depositories (CSD),
10/11/2020 – retirement funds and UCITS,
01/11/2021 – nonfinancial entities.

7 pieces of delegated regulation have been adopted, concerning Regulatory Technical Standards (RTS) and procedures (ITS).

REPORTING

Which transactions are to be reported?

A very broad scope of transactions relating to securities and goods will be subjected to reporting:

repo transactions on securities (both: cleared bilaterally and with CCPs),
buy-sell back transactions on securities,
securities lending transactions, secured in an any given way (cash, bonds, goods), as well as ones that were not secured,
goods lending transactions secured in an any given way (cash, bonds, goods), as well as ones that were not secured,
„margin lending” transactions, i.e. secured with bonds.

How should we report?

to the SFTR-authorised transaction repositories,
no later than a day after entering/altering a transaction,
exclusively in the XML format (ISO standard 20022),
using IDs such as LEI, UTI and ISIN,
ensuring report completeness and correctness verification (as the repositories will conduct conciliation
of reports sent by the parties).

Event reporting:

Reporting covers conducting a new transaction, its modification and early conclusion, as well as change in valuation of securities. Every such event may happen in connection with certain types of actions, which will define the precise shape of the report and the scope of information.

Why is SFTR reporting a challenge?

SFT transactions haven’t been so far subjected to reporting. That is why information in the transaction systems and back-office concerning them are often not verified in terms of information standards.

The report has to be formatted in accordance with the SFTR requirements; it will not be possible to send an e.g. csv. file to the repository.

The reporting standards forsee a different set of fields for each of the four kinds of transactions. Additionally, some types of actions will require separate reporting tables.

A lot of the information that is to be reported hasn’t been aggregated or identified by the systems. For instance, the regulation imposes monitoring of the securities reuse and reporting of securities ratings.

In the case of securities reuse, it will be necessary to allocate securities in use to the ones acquired in by an SFT transaction.

The scope of reporting covers newly conducted transactions, as well as some transactions conducted prior to the regulation coming into force (so-called backloading).

Given report tables, corresponding with various elements of a transaction (securities, reuse etc.) will, in most cases, be reported independently. This implies a necessity to generate a few reports for the duration of one transaction.

The requirement will affect entities, which so far haven’t been conducting any similar processes.