SFTR and the need for data integration & management

Background
With the European Union’s Securities Financing Transaction Regulation (SFTR) countdown clock ticking, the industry is awaiting the official publication by International Organization for Standardization (ISO) of the ISO 20022 format for the standardised reporting of securities financing transactions.

The goal of the SFTR is to enhance the transparency of the securities financing markets by requiring firms who enter into Securities Financing Transactions (SFTs) to report them to a trade repository.

The SFTR was developed by both the Financial Stability Board (FSB) and the European Systemic Risk Board (ESRB) to monitor SFTs. They want to supervise SFTs in order to assess the risk associated with those transactions. Time to comply depends on the counterparty type:

• For credit institutions, investment firms, and relevant third country firms, 11 April 2020.
• For Central Counterparty Clearing Houses (CCPs) and Central Securities Depositories (CSDs), 11 July 2020.
• For other Financial Counterparties (FCs), 11 October 2020.
• For Non Financial Counterparties (NFCs), 11 January 2021.

Product Scope
The product scope for SFTR includes:

• Repo or repurchase transactions
• Securities or commodities lending and securities or commodities borrowing
• Buy-sell back or sell-buy back transactions
• Margin lending transactions

 
Internal Standardization
In order to be able to report SFTs to ESMA, firms need first to integrate the required data internally from the different trading systems in scope. This is not an easy task. It requires product and collateral expertise to be able to model and map the data correctly. In addition, it requires regulatory expertise to make sure all data requirements from ESMA are identified in the source systems and captured by the internal data models.

There is some degree of standardization on the Repo products, in which open standards used internally and externally by firms such as FpML and FIX have had product models since years. ISDA CDM has added support for repos recently. However, security lending products is a different case. Not until recently, products model have been created for security lending transactions. FpML is introducing a new securityLending product in version 5.11 and FIX is currently working on it with a specific working group focused on SFTR. In addition, as mentioned above, ISO is finishing the review of the ISO 20022 messages which will be used for SFTR reporting.

However, not only transactional data is in scope, collateral data is also required for SFTR reporting, specifically margin information, collateral updates, and position level information. This is another business area that has not been fully standardized within firms and that requires a significant effort. FpML and FIX are also working on this area to make sure all collateral data required by SFTR has a data representation in the standards.

Based on all the points above, there are some critical data questions in the context of SFTR:

1. Do I know all data that needs to be reported?
2. Do I have the required data identified in the source systems?
3. Do I have product data models for the products in scope?
4. Do I have collateral data models for the data in scope?
5. Is the collateral data consistent with the product data?
6. Can I leverage industry standards for the representation of SFTs if we don’t have an internal representation?
7. Do I have the mappings from the source systems to the internal product models?
8. Do I know the ISO 20022 messages that need to be used for SFTR reporting?
9. Do I have the mappings from the internal product models to the ISO 20022 SFTR reporting messages?

Conclusion
All these questions raise the need for expertise and tooling helping on data mapping, aggregation, transformation, and validation, meaning the integration of SFTs data between the different systems and making sure that the data to comply with SFTR is identified in the source systems and validated before it is sent to the regulator.