Regulators have made a call for substantial transparency in the form of the Securities Financing Transaction Regulation (SFTR). The data that must be delivered to trade repositories is comprehensive, patchily available, and requires a new level of internal data management that has not yet been considered at the majority of firms. A guest post from NEX Regulatory Reporting.
SFTR is intended to implement the industry’s need for oversight within Securities Financing activities and of shadow banking. Its justification, workings, and outcomes have all been questioned, often with legitimate concerns about the data to be submitted and its ultimate usage. There is uncertainty around how the regulators will interpret the data in its initial form upon go-live, as well as any actions that they may take in response. These considerations have done nothing to change or delay the go-live date of early 2019 for SFTR however, and the industry is doing its best to get ready.
One often overlooked implication of SFTR is its requirement that submitters ensure their data is accurate. While seemingly innocuous, this aspect of process control can often be missed, making data submitted at Point A different than data received at Point B. Ensuring accuracy requires a new level of data transparency that requires buy-in from across the organization.
What regulators want
Financial markets need to be transparent and, so far, regulators have taken a broad-brush approach to figuring out the details of SFTR. To get there, and to ensure that trades can be matched between counterparties, they have proscribed 152 data fields that must be submitted to a trade repository for every transaction.[1] While 15-20 fields are likely sufficient to capture matching and accurate risk information, these 152 fields are nevertheless required by the regulation today.
A key component of the data regime is Legal Entity Identifiers (LEIs). The concept of the LEI is simple: entities should be identified by a number that tracks back to their underlying branch or subsidiary. However, ensuring that counterparties have LEIs is not so straightforward. LEI adoption has been slow globally and in Asian markets, very slow. Other fields that describe counterparty or reference data can be equally scarce or, more likely, inconsistent.
Managing the process
The first problem in complying with SFTR is identifying the required data. Often the data is stored in systems not associated with the trading technology, so the covered firm or its vendor must pull the information from multiple sources and enrich the dataset being sent to the repository. This may require accessing new information sources that were never intended to provide consistent reporting to outside venues, much less communicate with other internal platforms.
There are complexities around collecting data for SFTR and regulators have added a new requirement: they want to know where the data comes from and explanations from the submitting dealer. In their “Principles for effective risk data aggregation and risk reporting,” the Basel Committee on Banking Supervision mandated that “a robust data framework will help banks and supervisors anticipate problems ahead. It will also improve the prospects of finding alternative options to restore financial strength and viability when the firm comes under severe stress.”[2] But for every new disassociated source amid differing levels of processing, ensuring data quality can be difficult. In practice, dealers may not be able to reconcile their submissions back to the original data. The inability of accurate data tracking means that regulators are not getting the transparency they have mandated.
The inability to track data back to its source – often referred to as data lineage – gives rise to a possible regulatory failure: regulators would not be able to identify what data is associated with what transaction and counterparty. Further, if there is little confidence that dealers delivering the data can explain where it all came from, then the problems start to multiply as regulators start to doubt that dealers have a clear handle on their process control. Inconsistent data interpretation makes trade matching in the TRs – a core objective – very challenging.
Even with all the fields completed, matching transactions across many SFTR vendor platforms will be difficult. The experience of EMIR shows that matches can be extremely rare, belying the regulatory objective of being able to track system risk. With current data quality, institutions must match transactions using a number of potential vendor matching platforms and, if a counterparty decides to use a different matching platform, it ends up with the need for a “go fish” methodology.
The feedback loop continues, in that data submitted to regulators may not line up with data from trade creation, books and records, P&L management, and risk management. As part of the SFTR mandate, firms need to ensure that what they are sending in lines up with their internal data systems and records. This is an important way for firms to avoid fines or other penalties associated with the regulation.
The need for standardisation
SFTR is a regulation that relies on standardisation, and yet that standardisation is inherently lacking in the data that firms need to submit. As we have seen historically, regulation will drive innovation; and regulators are asking for something that doesn’t yet exist and telling the industry to figure out how to produce it. As a response, firms are working to figure out a) what standardisation looks like, and b) how they achieve it. No wonder then that calls to reduce the 152 required fields are common; any reduction to the complexity of achieving standardised reporting fields would be welcome.
There is some optimism that, with successful dialogue, regulators will find a reasonable number of fields that can support transparency objectives while not being onerous, or even supercilious for the industry. Finding a balance will require data standards that go across all constituent groups including regulators, dealers, clients, technology, compliance, and middle and back office. This will also require compromise. If there is one clear benefit to SFTR, it is that the forced move towards standardisation may create better efficiencies across the industry.
Successfully delivering on SFTR
Whether the ultimate number of required fields is 152 or 15, successfully meeting SFTR obligations requires a robust internal data reconciliation process. Firms must understand what is being sent to the regulator, and how enrichment occurs with LEIs, counterparty and reference data. This is where problems occur and where they can be avoided.
There are three legs to creating a system-wide solution: compliance, business engagement, and technology. On the compliance and business side, there must be an understanding that hardcoding a specific reporting template is unrealistic; it is all but certain that SFTR reporting parameters will change over time and that these changes will be nuanced and difficult to understand. Executing on SFTR is going to require an investment from nearly all firms under scope, and may require reevaluating core business processes and counterparties.
Technology managers and vendors must be regulation driven and have a deep understanding of the trade lifecycle, while still being business agnostic. Installing a system that can only service one market when this is a process that will have to be repeated over and over again for other markets is going to be costly. Vendors must also understand that system requirements evolve over time; the flexibility to adapt to these changes must be part of the DNA of not only the system but also the systems provider.
A successful SFTR implementation will first require understanding what regulators are asking for and the parts that need clarification. Second, firms will need a process control that allows for simple, straightforward reconciliation between what is delivered to regulators and where that data is coming from. Third, participating in a push toward industry standardisation will help all parties, including submitting dealers and regulators, to achieve a high-quality outcome. This includes eliminating superfluous or redundant fields, using consistent reference data for instruments, and streamlining data transparency inside and outside the firm. Fourth, a strong feedback loop from collected data, to submitted data, back to verification of the internal data elements, will be critical. These are bigger tasks than initially imagined when SFTR emerged, but they can be done. The benefits will be improved business efficiency and regulatory comfort in the oversight of important financial market activities.
Mark Ellis, Commercial Development Manager, NEX Regulatory Reporting, has over 15 years’ experience working in post-trade technology and advising investment firms on strategic and operational efficiencies in the OTC and derivatives space (Citi, DTCC, IHS Markit).
Since joining NEX Regulatory Reporting, Mark has been responsible for managing clients through EMIR, MiFID, and MiFID II implementations. He is well-versed in regulatory obligations for trading and broking firms under international regimes, including SFTR.
[1] “Technical standards under SFTR and certain amendments to EMIR,” European Securities and Markets Authority, 31 March 2017, available at https://www.esma.europa.eu/sites/default/files/library/esma70-708036281-82_2017_sftr_final_report_and_cba.pdf
[2] “Principles for effective risk data aggregation and risk reporting,” Basel Committee on Banking Superivision, January 2013, available at https://www.bis.org/publ/bcbs239.pdf
