155 Reasons to Worry About SFTR Reporting

Adding to our conversation on SFTR and with thanks to a Data Management Insight reader and SFTR expert, here is more information on the four phases of SFTR go live, and matching data fields required across the four phases:

These are the four phases in terms of institutions that are due to go live:

• Phase 1: Banks and investment firms are to comply one year after go live
• Phase 2: Central counterparties (CCPS) and Central securities depositories (CSDs) are to comply 15 months after go live
• Phase 3: Insurance / reinsurance, pension funds, UCITS and alternative investment fund (AIFs) are to comply 18 months after go live
• Phase 4: Non-financial counterparts are to comply 21 months after go live

These are the 96 matching fields across the four phases (with various tolerances) post European Commission endorsement on December 13, 2018.

• SFTR Article 4 reporting includes 155 fields in total
• There are 96 matching fields in total over the four phase in periods
• April 2020: Total fields 57 (3 counterparty data fields, 36 transaction data loan fields and 18 transaction data collateral fields)

o          Article 33(2)(a)(i) reconcilable from day 1 of the first phase of reporting

• Jan 2021: Total fields 5 (5 transaction data loan fields)

o          Article 33(2)(a)(iv) reconcilable as soon as the fourth phase of reporting goes live

• April 2022: Total fields 4 (4 transaction data collateral fields)

o          Article 33(2)(a)(i) +24 months or reconcilable two years after the first phase of reporting goes live

• Jan 2023 Total fields 30 (27 transaction data loan fields and 3 transaction data collateral fields)

o          Article 33(2)(a)(iv) +24 months or reconcilable two years after the fourth and final phase of reporting

155 reasons to worry about SFTR reporting

With Securities Financing Transactions Regulation (SFTR) reporting just a year away, firms within the scope of the regulation need to ensure they can fill up to 155 data fields, including a unique transaction identifier (UTI) for all transactions, legal entity identifiers (LEI), and a master agreement for each trade on a daily basis. They must also deliver 32 different reports in ISO 20022 format to approved EU trade repositories. With such a large amount of data required to report under SFTR and some data fields never previously required by regulation, data management projects for compliance should already be underway.

SFTR is an EU regulation designed to mitigate the inherent risks of shadow banking and increase transparency in the use of securities lending and repurchase. Securities financing transactions (SFTs) are usually transactions where securities are used to borrow cash, or vice versa, and include repurchase agreements (repos), securities lending activities, and sell/buy-back transactions. In each of these, like collateralised loans, ownership of the securities temporarily changes in return for cash temporarily changing ownership. At the end of an SFT, the change of ownership reverts, and both counterparties are left with pretty much what they possessed originally.

Reporting fields

The problem presented by the reporting fields is that while firms within the scope of SFTR are expected to be able to source about 60% of the data, 40% of the data is not readily available. The data falls into the categories of counterparty, loan and collateral, margin and re-use data. The 40% of missing data has not previously been required by regulators, has not been recorded consistently as it is not a risk to firms or counterparties, or a means of making money. The data is likely to be fragmented, with no single entity or system holding all the reportable data, and in some instances, the reportable data is not currently captured, for example, margin data within the reporting deadlines. The challenge is pulling together, harmonising and controlling the full set of data to be reported.

Fabien Romero, securities finance SFTR at IHS Markit, remarks that regulators will put an emphasis on these ‘not very well looked after’ fields. He adds: “Firms could source all the data fields themselves, but they will need very good access to all the required data and this will be pricey.”

Reconciliation

A second challenge is data reconciliation as part of the two-sided reporting requirements. Data sent to a trade repository by two counterparties must be reconciled within narrow tolerances defined by the European Securities and Markets Authority (ESMA). Any breaks will be sent back to the counterparties to resolve.

Romero points out that it is unlikely that 100% of the fields will ever be matched and cites simple discrepancies such as pricing fields where one counterparty uses Refinitiv pricing data and the other Bloomberg data. He says: “Regulators don’t expect everything to match, but as much as possible should be matched so market participants can be seen to be making best efforts. We don’t expect fines to start with and there will be some tolerance, but if one counterparty fills 50% of the fields and the other 80% there will be questions.”

Exacerbating the problem, reporting time is tight, with all new SFTs and any modifications and terminations of existing SFTs reported daily, transactions by T+1, collateral known at the point of trade at T+1, and collateral known at settlement at S+1.

Considering the amount of SFTR data required for reporting, difficulties in sourcing some of the data and tight timelines, IHS Markit is working with Pirum Systems, which provides the data reconciliation element, and collaborating with more than 40 financial institutions to build a reporting solution that is fit for purpose.

The end result will be software-as-a-service that ringfences SFTR data from both IHS market and clients, enriches the data, matches data fields, and flags any mismatches to clients so that they can be resolved. Data is then matched again and submitted to a trade repository.

Romero concludes: “The higher the data quality, the better the chance that it won’t be returned. Our value is in pre-submission reconciliation.”