The Current State of Play in Transaction Reporting: Herding Cats in a Hurricane

Regulated firms trading in markets globally are bracing themselves for what’s been termed a ‘sea change’ in regulators’ approach to transaction reporting. Having introduced the requirement to provide detailed transaction reports to market through prescribed reporting vehicles over the past few years, some key regulators – including ESMA, CFTC and MAS – are reviewing their requirements, creating a decision point for market participants, many of which now see an opportunity to upgrade from the solutions they put in place first time around.

This time firms are better equipped, having digested several years’ experience in gathering the data they need for their reports, integrating the data into a coherent format, and delivering the reports to the approved reporting mechanisms. Some have found that the systems they initially adopted aren’t optimized for the incoming adjustments, and as a result are looking to modify or simply replace what they have. For many firms, commercially available solutions represent the most sensible approach, offering broad functionality at lower ongoing operating costs than custom systems.

Charlotte Longman, director and co-lead of regulatory reporting monitoring and assurance at ACA Group, which provides a transaction reporting facility for regulated firms, says the concept of transaction reporting was solidified in the European marketplace by the EU’s original Markets in Financial Instruments Directive (MiFID) in 2007. “Due to the portfolio managers exemption which existed under that regime, the focus on timely and accurate submission of reports was limited to the sell side,” she says. “For the majority of the buy side it became a focus during the MiFID II implementation, as there was no longer the ability to reasonably rely on the sell side for the submission of reports.”

Indeed, Appleton notes that the January 2018 MiFID II expanded the scope and complexity of reporting. “The number of reportable fields was extended to 65 plus control fields and additional complexity was introduced through a variety of rules intended to extend the scope of activity and asset classes that were deemed in scope for reporting,” he explains.

Meanwhile, the European Markets Infrastructure Regulation (EMIR) was introduced in 2014. It has been subject to multiple changes since then, including as a result of the refit which introduced changes in 2020 and is currently undergoing further consultation for changes due to come into force between 2023 and 2024 with different implementation dates expected for UK-EMIR and EU-EMIR.

Today, firms looking to implement a new transaction reporting solution need to be cognisant of the scope of the solution and whether it can be configured based on specific activities and requirements of the jurisdiction in question, while ensuring that review processes are independent of the reporting processes.

The difference between trade reporting and transaction reporting

Unlike trade reporting, which under MiFID II for instance requires near real time reporting of trades to an Approved Publication Arrangement (APA) to ensure market transparency, transaction reporting is aims to identify counterparties and transaction details, in part to detect market abuse.

The majority of transaction reports in Europe are submitted to regulators via Approved Reporting Mechanisms (ARMs). The process remains an expensive and costly exercise that offers no significant competitive advantage for many industry practitioners, as no-one wants to cut corners on compliance given the financial penalties and potential for substantial damage to a firm’s reputation of getting it wrong. Appleton notes that it’s a mistake to assume that because a transaction report has passed ARM validation it means the data is accurate.

Similar components are required by end-to-end reporting solutions regardless of the jurisdiction or regime says Philip Flood, business development director Gresham Technologies. “The aim is to provide assurance that the reporting is complete, timely and accurate,” he adds. “Typically, these components can be split across internal and vendor solutions and this is what usually creates data fragmentation, reporting and reconciliation issues.”

Key components of an end-to-end reporting solution

He highlights the following components:

• Data capture – ingestion of data from different sources in different formats in both batch and real time
• Data validation – checking that fields and values meet the reporting requirements prior to submission and after submission
• Data enrichment – reference data is required to enrich post-trade data with data elements such as trader information, legal entity identifier and unique transaction identifiers needing to be mapped to reportable transactions
• Reporting logic – programmatic representation of the reporting and business rules required to submit data
• Submission – different regulations have different requirements for when and how to submit
• Exception management – if there is a failure or a rejection a method is required to catch the exception and highlight this to the operations and compliance team who can investigate and if necessary, take corrective action
• Reconciliation – many regulations require the market participant to reconcile their trading activity

The key features of a transaction reporting solution can be divided between report generation, submission, and quality assurance, according to Appleton, who believes it is important to segregate quality assurance from the reporting process to ensure independence and optimisation of reporting quality through a universal, broad and deep testing approach. “This three-way separation also ensures firms retain flexibility over their reporting and do not get too baked into a single solution,” he says.

In the US, consolidated audit trail reporting is used by regulators to track all order and trading activity throughout the US markets for listed and OTC equities and options. In addition, OTC derivative trading activity is overseen by the CFTC and the SEC under the Dodd-Frank Act.

In Asia, the Monetary Authority Singapore implemented the ‘Securities and Futures (Reporting of Derivatives Contracts) Regulations 2013’ as part of Singapore’s response to the G20 agreement to mandate reporting of all OTC derivatives.

Other regulations have transaction reporting obligations built in. For example, the reach of the EU’s Securities Financing Transactions Regulation (SFTR) means that any firm engaging in securities financing transactions has to review their workflows and upgrade data management systems to fulfil the transaction reporting obligation.

“What is noteworthy is the proposal to expand the MiFIR transaction reporting requirements to those firms authorised under AIFMD, but who also have MiFID permissions,” says ACA Longman. “This would present its own operational challenges for these firm types in respect of having to effectively split their business and report only transactions arising from one half. It remains to be seen if the FCA will follow suit and if so, how and when.”

Regulators seeking harmonisation and standardisation

Gresham’s Flood refers to harmonisation and standardisation as the next significant stage in the evolution of transaction reporting. “After a long period of global regulatory reform firms have contended with mixed data definitions, overlapping rules and requirements across jurisdictions that have increased complexity and therefore added cost and risk to regulatory reporting,” he says. “There is a clear direction of travel towards harmonisation and standardisation from regulators and trade associations, spurred on by low data quality issues that have been reported by ESMA with older regulations such as EMIR.”

Regulators are now adopting ISO 20022 and have standard approaches to identifiers. “As we have witnessed with SFTR and the CFTC rewrite, firms can re-use existing framework and processes without building something brand new each time,” says Flood.