The idea of delegated reporting is that a firm can submit reports to a Trade Repository (TR) under SFTR on behalf of another firm, but applying this concept to an operational reality requires some close attention. Which side of the fence has an easier task ahead? A guest post from Catherine Talks and Maryse Gordon of LSEG UnaVista.
Outsourcing is a well-known mechanism in capital markets, and occurs across a wide range of regulatory reporting, clearing and client service functions. The Securities Financing Transactions Regulation (SFTR) is yet another regulation that has unearthed the subject of delegated reporting, highlighting the important notion that no matter what data is submitted, the reporting and accuracy of data remain the responsibility of the reporting firm. Unlike other regulations, SFTR covers products that have not been previously subject to a transaction reporting obligation like the European Market Infrastructure Regulation (EMIR) or the Markets in Financial Instruments Regulation (MiFIR). Many data elements in the SFTR regulation are typically not maintained by the client. There is an extra reliance on third-party data providers and the firm conducting the actual reporting to make sure the data is available and reported in a timely manner.
Over the years, we have had many discussions surrounding delegated reporting: is it feasible, what level of visibility is required for the delegated entity, who owns the process, who is responsible for the output, and is it worth it? While the answers to these questions depend on the firm offering the service, the regulation, and the whereabouts of the data that need to be reported, we are now seeing a more interesting debate on the subject and a feasible, and creative, set of implementation options. UnaVista has developed a number of standard processes that provide options for firms facing this requirement.
Reporting and the delegated relationship
Unlike other reporting obligations, in SFTR there is a mandatory delegation requirement enforced upon some firms. Where a small Non-financial Counterparty (NFC) firm has a reporting obligation, they may not have the infrastructure or the resources to implement a regulatory reporting function. In these instances, the trading counterparty must provide delegated reporting on behalf of the NFC. Some banks take this a step further and are seeking to implement delegated reporting on behalf of their trading and custodial clients, not just their NFC clients. In doing so, banks are beginning to explore the many forms of delegated reporting available for implementation.
The feasibility of outsourcing very much depends on the business models of both banks and their smaller clients. Many asset managers have already evaluated the outsourcing of middle- and back-office functions and decided whether or not to pursue that route based on factors such as cost, visibility, availability of data and of course liability. Outsourcing of data services in general is popular, although larger firms recognize that control of data is an important factor in their business systems and prefer to keep management in-house when possible.
For SFTR, with such a large data requirement placed on firms, the central collation of this information for reporting purposes is set to be a challenging task. There are three distinct message types covering transactions, collateral and collateral re-use that need to be reported. Many firms have highlighted that they have specific data challenges such as gathering collateral information from multiple outsourced providers or obtaining correct allocation information from brokers. The process will most likely involve different data formats, different submission methodologies and varying distribution frequencies, all of which need to be consolidated and transformed into SFTR reporting format requirements.
A unified approach to enhance operational workflow
One result of SFTR has been the extensive amount of intra-industry coordination and collaboration that has occurred to get the regulation off the ground. Specific securities finance projects in the past have required firms to work together, for example Agent Lender Disclosure rules, and SFTR is no different as competitive vendors form working groups to agree on standardised formats, agent lenders and borrowers agree on how to source data, and trading venues offer to generate additional required data fields. This work will hopefully lead to a standardisation in the reports generated by firms, which will make delegation easier, and other aspects of reporting more efficient and accurate, for example the inter-TR reconciliation process.
Inter-TR reconciliations is one of the reporting stages that has been challenging to manage within dual reporting obligations. One benefit we see with delegated reporting in this environment is the dissemination of the Unique Transaction Identifier (UTI). If one firm is providing reports on behalf of both itself and the other party in the transaction, then there will be much fewer instances where the UTI does not match within the Trade Repository. This has been one of the challenges in EMIR where differences in the generation logic and often in the structure of the UTI has seen market-wide breaks in the TR pairing and matching process. This should be reduced in SFTR where the mechanism for UTI generation was published by ESMA in the final report on Technical Standards under SFTR in 2017, and it can be reduced even further with effective delegated reporting procedures.
Learning from EMIR and MiFIR
Working with different members of the SFTR market – vendors, CCPs, investment firms, agents and smaller reporting firms – we have begun refining the different models we feel satisfy market requirements for delegated reporting. These models are based on the lessons we have learned from implementing a variety of delegated reporting models for EMIR and MiFIR reporting.
This is not the first time the topic of delegated reporting has been proposed to the industry, which leads to the question, why is this still such a challenge? Previous experiences may be causing some firms to be wary. For EMIR, when some smaller firms chose to take up the delegated reporting offered by their counterparties, they encountered issues. For example, if all the transactional activity is with one counterparty, then managing that data and ensuring that the transactions are reported correctly on their behalf is straightforward. However, where there are multiple trading counterparties or multiple brokers involved, suddenly the due diligence it takes to reconcile against each report, often with the data residing on different trade repositories, becomes a complex task.
In EMIR we saw firms looking to take on more reporting obligations as their own and manage reporting breaks themselves. In many instances the firm with the reporting obligation did not want a view of the data directly. This led to problems months down the line when some firms realised they had insufficient oversight of their own reports. This issue was compounded when reports were sent by a number of different investment firms to different TRs. Collating this data internally from reports or manually extracting the data from various TRs was an arduous process.
Another example can be seen in MiFID I reporting where reports were submitted on behalf of a counterparty or client, yet the reporting firm had no visibility of what had been submitted. With some reporting systems unable to give relevant reports or have adequate functionality to provide read only access to the reporting firm, clients were often in the dark as to what data regulators were assessing and using as the basis for regulatory investigation.
In MiFIR we saw more firms looking to offer delegated reporting with a client view of the data, and many clients sought to get access to the data reported on their behalf from go-live. There is a greater emphasis in MiFIR on data completeness that led to the rise in the reconciliation of reported data. MiFIR also saw the development of a different reporting model known as assisted reporting. In assisted reporting, whilst some of the trading data came from the investment firm acting as a delegated reporting provider, the report was held by their client (the reporting firm) and enriched before being sent to the Approved Reporting Mechanism (ARM) to fulfil the MiFIR reporting obligation. This gave the investment firm’s client much more control over the data that they report and along with the requirement to submit sensitive data elements, it also gave them the security and ownership of the reports. Due to the wide pool of firms caught by the reporting obligation, more third-party data providers sought to provide client details to the ARM while trying to avoid any additional regulatory burden. This requirement saw the introduction of the technical router model.
Delegated reporting models in SFTR
For SFTR, we see the need to continue to support a number of different reporting models. Each one gives firms a flexible approach to meeting different needs within the market:
- Direct reporting: one firm is reporting to the TR to satisfy its own reporting obligation. This may be on behalf of one LEI (Legal Entity Identifier) or on behalf of a number of LEIs depending on the firm’s legal structure.
- Delegated Reporting: this has been the most popular model, enabling one firm to report on behalf of the other party in the transaction. The other party can get a ‘read only’ view of the data within the TR, allowing them to see the transactions reported on their behalf by one or many firms.
- Technical router: one firm is seeking to provide data directly to the TR on behalf of a firm with a reporting obligation. These are often vendors or OMS providers, and they do not have responsibility over the reporting process. The technical router may pass responses back to the client or may display the data in their own Graphical User Interface (GUI).
- Assisted reporting: one firm may provide part of the data of a transaction to the solution and the firm with the reporting obligation completes the report and sends it to the TR. This was seen as necessary under MiFIR where part of the data was deemed sensitive and not to be made visible outside of the reporting obligation, but this may not be a model required for SFTR. The appetite will depend on the data elements and their sensitivity classification by the reporting firm.
Delegated reporting often fulfils both the reporting firm’s and the client’s reporting obligation at the same time by allowing multiple submissions of the same data. Often, reporting firms will resolve exceptions on behalf of their clients. They may wish to send reports to their clients to show the messages reported on their behalf or they may wish for their clients to have a view (only) of the data.
In the delegated model, both the reporting entity and the submitting entity have their own workflow, but it is the submitting entity that takes on the responsibility of interacting with the TR. In its relationship with the client, the submitting entity agrees to: send data on their client’s behalf and produce data based on the ISO20022XML Template; be fully responsible for report completion, submission and exception management; and create export reports per client for onward service management. The client will direct all further inquiries to the submitting firm.
SFTR is a complex regulation and, thankfully, technology is heavily assisting the implementation of the requirement and its support framework. Delegated reporting models will be a key addition to the data workflow and operational management for SFTR submissions and is manageable with the right support for both submitting and reporting firms. The critical factor is to ensure that whatever implementation method is chosen, the submitting entity can support the reporting firm, and the reporting firm has the access and visibility they need to ensure compliance with the regulation.
Catherine Talks
Product Manager, UnaVista, London Stock Exchange Group
Catherine is a product manager at UnaVista, the London Stock Exchange’s award-winning regulatory reporting solution.
Catherine’s current responsibilities are focused on the product development of the SFTR Repository, engaging with clients and regulators and go-to-market planning. Catherine has previously worked on various UnaVista regulatory platforms including the MiFIR transaction reporting platform. Prior to her role at UnaVista in 2014, Catherine held roles in both buy- and sell-side firms focused on derivative products.
Maryse Gordon
Senior Pre-Sales and Business Development Manager, UnaVista, London Stock Exchange Group
Maryse has worked with financial software for 10 years and gained a wealth of knowledge and experience ranging from product development and support, to product management and pre-sales. Starting her career at Hewlett Packard and progressing onto Logica, Maryse now represents UnaVista as a senior pre-sales and business development manager covering the Regulatory Compliance, Risk and Controls, and Data Solution offerings. Alongside being responsible for driving revenues across the US, leading market, industry and product research around regulatory compliance, Maryse actively contributes to the growth of the business, providing thought leadership and ensuring solutions are inline with industry appetite.