In a Q&A with DerivSource, Valentino Wotton, Managing Director, DTCC’s Deriv/SERV, answers our questions about the trade reporting requirements under Securities Financing Transactions Regulation (SFTR) and shares with us his views on how firms can address common operational and data challenges. Learn more about SFTR in our upcoming webinar Jan 18th.
Q. What are the main differences between SFTR and reporting requirements under EMIR and MiFIR?
A. Aside from the obvious product scope differences, structurally the European Market Infrastructure Regulation (EMIR) and SFTR are well aligned. Both require reporting to a Trade Repository (TR) supervised by the European Securities and Markets Authority (ESMA) and have the same underlying supervisory objective, albeit with different underlying products in a market that trades differently to derivative markets. As EMIR mechanics form the basis for reporting under SFTR, this brings numerous challenges in the reporting of securities financing trade details in line with derivative market mechanics. Additionally, for the first time ESMA is mandating reporting formats as well as prescribing the matching fields and tolerances in the regulation. SFTR also introduces a new entity classification and mandatory delegated reporting for this new classification of small non-financial clients.
The Markets in Financial Instruments Regulation (MiFIR) is actually quite a different set of requirements from both from the perspective of regulatory objective and regime mechanics as it is event reporting, whereby the focus of information to be reported focuses on the actors involved in a given transaction execution scenario. Structurally, there is delineation between the authors of the (pan-European) regulation and National Competent Authorities (NCAs) supervising firms and enforcing the regulation at a national level.
Please see comparison below which further explains the differences between the requirements of each regulation.
| EMIR | MiFIR | SFTR (proposed) | |
| Number of fields: | 85 (129) | 65 | 153 (total for all products. Will be around 117 for a securities lending trade) |
| Reporting Type: | Trade / Position | Transaction | Trade / Position |
| Regulatory Objective: | Systemic Risk | Market Abuse / Market Surveillance | Systemic Risk |
| Legal Form: | European Regulation | European Regulation but also subject to national implementing variations of the Directive | European Regulation |
| Reporting to: | Trade Repository (TR): Obligation is met once a report has been accepted by a TR, who then report to NCAs, ESMA and central banks | National Competent Authority (NCA) either directly or via and Authorised Reporting Mechanism (ARM) | Trade Repository (TR): Obligation is met once a report has been accepted by a TR, who then report to NCAs, ESMA and central banks |
| Product Scope: | Derivatives (OTC & ETD) | All “Financial Instruments” (broadly meaning most derivatives and cash products) | Securities financing transactions |
| Message Standards | Input – none
Output – ISO 20022 |
Input – none
Output – ISO 20022 |
Input – ISO 20022
Output – ISO 20022 |
Q. What is the timeframe for SFTR? Why should firms be starting implementation now?
A. SFTR will come into effect in a phased approach based on entity classification. Whilst the final Regulatory Technical Standards (RTS) have yet to be approved, SFTR is expected to come into force for investment firms in Q2 2019.
Q. What are the main data challenges firms face?
A. There are two main challenges under SFTR and data is the first of these. SFTR brings reporting requirements to an industry unfamiliar with trade reporting. EMIR had a secondary effect of forcing firms to think about their data management. SFTR will have the same effect on securities markets. Securities markets’ systems and processes will now be subject to enhancement or perhaps even more fundamental changes to ensure they are able to source and manage data types and histories in line with the new regulatory requirements.
Data readiness should be a key focus of firms in the short term to ensure that all gaps in data are identified and remedied in advance of reporting. Whilst it may not feel like it, ultimately firms should embrace the changes mandated by SFTR as they mark a significant opportunity to collate and organise data internally and provide more detailed and accurate information to inform book / risk management.
Q. Are there reconciliation challenges?
A. This is the second major challenge, but one to which the industry is giving lots of thought. Discussions have included where and when the Unique Trade Identifier (UTI) should be generated, as well as any possibility to pre-match the trade prior to reporting, in order to ensure high levels of pairing. Ultimately however, TRs will provide the pairing and matching status, enforcing the requirements specified in the RTS. Firms should have processes in place to absorb and remedy such pairing and matching breaks.
Despite a high degree of focus thus far from the industry, under SFTR significant challenges are likely to exist in reconciling reports, especially in the months following go-live, due in part to the fact that such requirements and processes are new and unfamiliar to this industry, as well as due to the nature of the products. For example, evergreen trades will likely have trade details changing daily and therefore may entail daily amendments to existing reports. This will make successful reconciliation incredibly difficult on an on-going basis.
Q. What are the main questions firms face when deciding to delegate reporting or keep in house?
A. For one classification of client, this is an easy answer – delegated reporting is mandatory on behalf of small non-financial counterparties. This new construct, also currently under consultation for use in EMIR 2, comes with its own set of challenges. Investment firms reporting on behalf of clients need to be provided all relevant party information (from the client for whom they are reporting) in order to make an accurate report. When delegated reporting becomes mandatory, investment firms have a regulatory obligation without necessarily having a means of obtaining such information from the client in a timely manner. This creates an awkward legal paradigm for the firm providing the delegated reporting. In general, delegated reporting does have some benefits by removing the reporting burden from small firms where the cost of compliance can be particularly punitive. Additionally, DTCC’s GTR effectively provides firms a matched trade where submissions are made for ‘both’ parties to the trade in one report. This circumvents some of the post-reporting reconciliation that would otherwise be necessary. Whilst delegated reporting also removes significant administrative and system implementation requirements, it does not remove the obligation for firms to ensure the accuracy of trades reported on their behalf. Therefore, whilst there are benefits, it does not absolve firms from their obligation to check for the completeness and accuracy of data and reconcile this to their own internal books and records. Recently, under EMIR regulators have demonstrated through enforcement action the seriousness with which they regard completeness and accuracy of reporting, so firms should ensure that proper processes and procedures are in place from day one.
Q. How are TRs preparing?
A. From DTCC’s perspective, we have been engaged for around 18 months already on SFTR. As an industry-owned firm, we always seek to design solutions that benefit the market. Whilst DTCC as a firm has a large footprint in securities markets through various business lines, the GTR has to date, provided regulatory solutions to derivative reporting requirements. In preparation for the upcoming requirements, DTCC’s GTR has been working with clients and industry bodies to understand the needs of market participants and work in collaboration to develop a trade reporting solution to add value to clients. Additionally, as the largest TR under EMIR, DTCC has been heavily engaged with the regulator, ESMA, to ensure the process for approval as a Trade Repository under SFTR is clearly understood in anticipation of our application, when the window opens.
