The clock on the Securities Financing Transaction Regulation (SFTR) is steadily ticking down and firms should be looking to build a clear roadmap for SFTR compliance. A lot has been said around the implementation hinging on the data being captured. In this blog Amrita Sawhney and Hussain Abdullah, Senior Managers from Deloitte’s in Risk Advisory practice, discuss the challenges and issues of the data requirements under SFTR.

Implementation – Where to start? 

The data that needs to be collected for SFTR is vast. Understanding what data firms will need to meet their obligations and from where they can source that data is a key starting point. The required data could include counterparty data from agent lenders, custodians, firms, or trading systems; loan and collateral data from legal databases, trade blotters, instrument reference databases, or trade risk systems; margin data from internal systems, CCPs, and Clearing Members; and re-use of collateral data from omnibus accounts and other group entities. This latter set has been highlighted by many firms as being the most difficult data set to source. Once you have understood where that data can be sourced, consideration will need to be made of how to obtain, capture, store and feed that information into the firm’s reporting architecture.

What are the key data challenges? 

Timing: Reporting requirements come into effect very soon, 11 April 2020 for credit institutions and investment firms as well as all third-country regulated firms. Three months later, on 11 July 2020 for central securities depositories and central clearing counterparties. All other financial counterparties have until 11 October 2020 and non-financial counterparties have until 11 January 2021. While many counterparties, especially banks and central securities depositories, have done considerable preparation to be ahead of their upcoming requirement, some still report they have work to do to meet their obligations on time.

Volume: The repo, buy-sellback, Securities Lending and Margin Lending market sizes coupled with the short term nature of the contracts involved add up to a considerable volume of dynamic data being covered. In repo markets alone, contracts worth EUR 7.761 trillion were recorded as outstanding within the scope of the ICMA repo survey in June 2019. There are 155 reportable fields in total covering counterparty data, loan and collateral data, margin data, re-use, cash reinvestment, and funding sources data. The sheer scope of data that is required to be pieced together adds to the overall complexity of sourcing and capturing correctly.

Scope: Much of the information required to be reported (e.g. type of collateral component, reference periods, reset frequencies, security quality, estimated value of reused collateral/reinvestment rate, etc.) is either not currently captured, held within other areas or systems within the firm (or even with external parties), or may not be available at the level of granularity required (e.g. excess collateral, source of funds, etc.). This may require new solutions to store, maintain, extract and flow information to the reporting systems. Firms should ensure that they understand all current relationships in relation to SFTs in order to understand where the data currently resides, how it can be captured and whether any third party reliance exists in order to establish how reporting can be achieved.

Data management: Each individual SFT will be reported to a trade repository. This will require accurate and consistent data management over and above the economic information required for trading and settlement. Consistency within a reporting entity and ownership of authoritative sources for data derivation within a high volume market is proving a challenge for many system set-ups. This is particularly noted where firms have legacy systems or have had partial migrations, data may be flowing from disparate sources, resulting in multiple versions of the truth. Further, fragmentation of data from multiple systems, similarly named fields with bespoke nuances and lack of reliable data governance can change the appropriateness of field usage, resulting in inaccurate reporting.

SFTR requires that reporting firms not only provide the common reporting standards (ISINs for collateral, LEIs for counterparties and collateral issuers, MIC codes for venues, CFI codes for collateral classification and unique trade identifiers (UTIs)) but also additional classification and derivations. Many of the required fields are not properly covered in many booking and settlement systems and are presenting data sourcing difficulties for some counterparties.

Entirely new data: The UTI (Unique Trade Identifier) is an entirely new field and data management process for the SFT industry and it will be essential, not only for trade booking and allocation but also for accurate reporting of collateral and lifecycle events. Additionally, new data is required, such as information on collateral reuse (i.e. whether the collateral is available for reuse or has been reused with the corresponding proportion) resulting in systems requiring updates to only to capture this data and establish robust data management delivering fit for purpose data.

Internal Quality Assurance (QA) processes: Even once firms have gone through the arduous process of collecting, organising and formatting their data to be ready for SFTR reporting, checking the accuracy of previously untested reporting procedures is proving difficult for many with no background or benchmark for reporting of similar transactions within the securities financing markets. Internal QA therefore is being performed in an isolated way, with firms at risk of “marking your own homework” that often results in underlying issues not arising until later dates when the corresponding scenarios are tested. Even though most firms will have put in some QA in place while implementing MiFID II transaction reporting requirements, the FCA has already noted that not enough has been done in this space.

Delegated Reporting: Many firms are considering delegation of reporting to their agent lenders, triparty agents or custodians as these entities often have much of the data required for reporting under SFTR. Firms that are leveraging this approach face a distinct set of risks and challenges around the oversight and governance of the delegated relationship and the oversight of their data and reporting performed on their behalf. Controls can often be lax when dealing with delegated reporting as multiple entities are involved in the end to end process, rather than a single point of control. Historically, lack of communication, documentation and governance has meant that issues lay unidentified until after significant reporting failures have occurred. While firms may introduce initial testing, this once again calls for extensive QA practices to be in place as a part of business as usual activities. Further, end to end testing is also often difficult when updates may be made to the reporting process outside of your organisation, and outside of your decision making process. Often updates/fixes put in place for one firm may have impact on others through shared infrastructure or coding.

External reconciliation: The requirement for daily, two-sided, trade and lifecycle event level reporting will enable the accuracy of data to be closely watched by regulators following the implementation dates. The data reported to authorised trade repositories will be reconciled by regulators, to give them a better understanding of risks that may be hidden in the financial system. In order to have reports that are the same on both sides, communication will need to exist between counterparties of how transactions should be reported. If an industry consensus isn’t reached, multiple agreements will need to take place between counterparties, which will mean reporting infrastructure will need to be built with multiple different rules/data sources depending on the counterparty. This will not only be difficult to implement but also could potentially be a source of unnecessary complexity which lends itself to reporting failures.