Market Watch 82

Newsletters Published: 23/07/2025 Last updated: 23/07/2025

Newsletter on market conduct and transaction reporting issues

July 2025

About this edition

In this Market Watch, we describe recent observations from supervising the UK MiFID transaction reporting regime. These cover remedial timelines, back reporting, and transaction reporting errors and omissions notifications (ie breach notifications). Firms should consider integrating these into their existing processes to support efficient transaction reporting. We do not expect this to create any additional burden for firms.

This work will be of interest to firms subject to UK MiFID transaction reporting requirements. It will also be of interest to firms subject to UK EMIR and SFTR reporting requirements. 

Transaction reporting

Firms should have processes for identifying, addressing and disclosing regulatory reporting issues in a timely and accurate manner. These processes should have evolved and matured since the MiFID transaction reporting requirements entered into force. However, we have seen persistent inefficiencies which suggest some firms must improve their operational frameworks.

Remedial timelines

Remediation is the process by which firms address deficiencies, errors or non-compliance identified in their transaction reporting data, systems or processes. Remediation plans vary based on an issue’s scale and complexity, and the firm’s operational setup. We assess the appropriateness of a remedial timeline on a case-by-case basis. While some issues may take time to remediate due to their complexity, others should be addressed swiftly to prevent prolonged risk exposure. We expect firms to be proactive and transparent throughout the process. 

We have seen remedial exercises extending beyond reasonable timelines due to:

  • Taking excessive time to present a remedial plan or implement corrective actions.
  • Missing deadlines set by internal governance bodies or the FCA.
  • Requesting extensions without justifiable reasons.
  • An absence of measurable progress between regulatory check-ins.
  • Repeatedly revising root causes or impacted volumes of transaction reports. 

We have identified common themes in the root cause(s) for delayed remedial work: 

  • Internal processes: Siloed teams, fragmented ownership of tasks and lengthy approval chains slow down decision making.
  • Resourcing: Assigning insufficient resource to resolve issues effectively and competing business priorities result in slower response times.
  • Difficulty in tackling the root cause: Focus on fixing the symptoms rather than the root cause leads to issues resurfacing.
  • Compliance culture: Reactive culture results in firms addressing issues only when prompted.
  • Governance: Weak structures and lack of accountability lead to loss of momentum as remedial work is not managed centrally or treated with urgency. 

Back reporting

Back reporting is the process by which firms correct inaccurate and incomplete transaction reports. Delays in back reporting leave us unable to trust data and potentially limit our ability to detect and investigate market abuse.

We distinguish between protracted remediation of an issue and delayed back reporting as each presents a different set of operational and compliance risks. The following case studies give an overview of common causes for delayed back reporting.

Case study 1: Crystallised compliance risk

A firm deploys a fix for an issue but fails to identify and correct all affected historical reports. Even though the root cause has been resolved, the firm remains non-compliant until it has completed back reporting. This indicates ineffective compliance oversight. It suggests the firm lacks internal processes to ensure timely corrections, raising concerns about accountability and non-financial risk management.

Case study 2: Internal governance weakness 

A firm has a complex book of remedial work involving a range of issues, each at a different stage of its resolution lifecycle. The firm is not demonstrating a risk-based approach to sequencing actions and directing resources, such as prioritising back reporting for the waiver indicator over submitting transaction reports for unreported exchange traded derivative transactions. This raises concerns about the firm’s internal governance, particularly its operational risk management and compliance delivery.

Case study 3: Data access and infrastructure limitations

A firm is facing significant delays in back reporting due to inaccessible historic data. This is because data was archived incorrectly following a system migration. This raises concerns about data governance, record keeping controls and data retention as part of change management. Without accurate and accessible past records, the firm may potentially be left exposed to unresolved reporting failings. 

Case study 4: Impact on BAU

A firm began a large back reporting exercise but underestimated the impact on BAU processes. As compliance and operational teams diverted resources to data retrieval, validation, testing and regulatory engagement, the day-to-day reporting accuracy declined as exception management was deprioritised. The firm subsequently created an independent back reporting workflow with dedicated resource, allowing tasks to be reprioritised and addressing individual workflow needs without crossover.   
 

Breach notifications

Breach notifications play a critical role in data quality. In line with observations in Market Watch 70, we expect breach notifications to clearly describe the issue, its root cause, and highlight any gaps or weaknesses in reporting processes, data governance and controls. 

We received 241 breach notifications in Q1 2025. The table below (Table 1) summarises our supervisory observations and best practices from our review of these notifications. 

Table 1

SectionAnalysis ResultsBest Practice
Issue description83% of notifications provided a clear description of the issue identified
  • Specify the nature of the issue: misreporting, under reporting, late reporting.
  • Provide detail that can be understood without firm context, avoiding references to internal systems.
  • Make the description relevant and succinct.
     
Root cause description76% of notifications provided a clear account of the root cause(s)
  • Consider how your root cause relates to the common root causes we discussed in Market Watch 81 and link the description.
  • Example: In cases where a firm is inclined to attribute the root cause to human error, consider whether improvements in process, controls or oversight would have prevented the issue before it happened.
Impacted transactions
  • 85% of notifications provided the exact volume of transactions impacted
  • 8% provided an approximate volume
  • 7% did not provide a figure (2% without justification)
  • Where this information is not available at the point of submission, explain this in the notification and do not delay submission.
  • Where the impact assessment is ongoing, indicate when it will be completed.
  • Clarify whether the impacted volume and relevant period provided is exact or approximated.
Relevant period
  • 74% of notifications provided a precise relevant period
  • 21% offered an approximation
  • 5% did not provide a relevant period (3% without justification)
Back reporting planning
  • 76% of notifications specified a date for back reporting commencement
  • 9% offered an indicative date
  • 15% provided no indication on back reporting planning
  • Provide insight to work required to determine back reporting timelines rather than leave the section blank.
Details relating to weaknesses in systems and controls
  • 66% of notifications provided clear and relevant information on weaknesses in systems and controls
  • 31% provided inadequate details
  • 3% left this section blank
  • Demonstrate the link between the reported issue and the root cause. If an issue has crystalised it is likely due to a weakness in systems and controls.
  • Provide information specific to the reported issue and avoid generic comments on overall improvement of transaction reporting processes and controls.
  • Provide rationale where this section is deemed not applicable.
  • Example: In cases where a firm is inclined to attribute the weakness to a third-party vendor, consider whether vendors specific controls and oversight would have prevented the issue before it happened.
Details of plans to address issue
  • 75% of notifications provided clear and relevant information regarding details of plans to address weakness
  • 16% provided inadequate information
  • 9% left this section blank
Details of governance committee aware of the issue
  • 80% of notifications provided sufficient information
  • 18% provided inadequate information by indicating escalation but not specifying the relevant forum
  • 2% left the section blank
  • Provide details of the committee, forum or individual to which the issue has been escalated.

We will continue to monitor the quality of breach notifications closely and to that end we introduced a quality flag as part of our case management and record keeping.

Our transaction reporting page gives further information. Please direct any questions about transaction reporting and instrument reference data to [email protected]