MiFIR Incident Reporting: Why The AFM’s Expectations Are Back In Focus

Regulators have not paused on data quality

With the recent hiatus in major regulatory change across Europe, firms would be mistaken for thinking regulators have taken their eye off the ball when it comes to data quality, controls and the remediation of reporting errors.

But market feedback suggests that supervisory focus on reporting errors, incident notification and remediation remains very much alive.

Earlier this year the AMF in France and CSSF in Luxembourg both released detailed papers outlining how they are using, monitoring and challenging firms on the quality of their reported data.

Now, firms active in the Netherlands appear to be facing greater scrutiny around MiFIR reporting incidents.  Against that backdrop, the AFM’s published expectations are worth reviewing. While not a new requirement, they are a timely reminder of what firms need to evidence when errors are identified: prompt assessment, clear notification decisions, documented root cause analysis, effective remediation and back-reporting.

What does Article 15(2) of MiFIR require?

Since January 2018, firms have debated the practical consequences of Article 15(2) of MiFIR, which states:

Where a trading venue or investment firm becomes aware of any error or omission within a transaction report, any failure to submit a transaction report including any failure to resubmit a rejected transaction report for transactions that are reportable, or of the reporting of a transaction for which there is no obligation to report, it shall promptly notify the relevant competent authority.

Two words in this otherwise straightforward requirement have generated more discussion than perhaps any others: “any” and “promptly”.

This is a question we are asked regularly at Kaizen. What exactly do regulators mean by “any”? And what constitutes “prompt” notification?

As this is law, and I am neither a lawyer nor likely at this late stage to become one, I will avoid attempting to provide a legally watertight interpretation. What we can do, however, is draw on the guidance provided by both the AFM and the UK regulator, the FCA, to identify best practice.

Why “any” and “promptly” still matter

The AFM is relatively clear on what it considers “promptly”, while still leaving the interpretation of “any” largely in firms’ hands:

“Whether an incident must be reported is a decision you must always make yourself.” 

That may sound unhelpful, but Principle 11 of the FCA’s Principles for Business provides useful context:

“A firm must deal with its regulators in an open and cooperative way, and must disclose to the FCA appropriately anything relating to the firm of which that regulator would reasonably expect notice.”

The phrase we often use to summarise this is: appropriate to the scale and complexity of your firm. 

This means defining what “notification” means within your organisation, agreeing it, documenting it, governing it consistently.  And most importantly, being able to demonstrate it when asked.

Much of what the AFM articulates simply reflects the stronger control environments we already see among firms during data quality assessments and control framework reviews.

What is clear, however, is that regulators rarely publish guidance unless they feel the need to. By laying out these expectations so explicitly, the AFM is signalling dissatisfaction with how some firms are currently identifying, assessing and reporting incidents.

Public reminders are generally preferable to private conversations. It is better to take notice of the road sign than to wait for the flashing lights in the rear-view mirror.

Areas of focus when reviewing reporting incident processes

1. Treat discovery as the trigger – Log the issue immediately when discovered, including date and time, reporting regime, impacted population, suspected cause, owner and severity. The AFM treats discovery as the incident point, meaning historical issues should be reported as soon as they are identified.

2. Triage within days, not weeks – Determine quickly whether the issue relates to non-reporting, over-reporting, rejected reports, incorrect submissions or failures to resubmit. The AFM expects unresolved incidents to be reported by T+4 if not resolved by T+3, with immediate notification required for more serious cases.
3. Do not wait for perfect information – Notify regulators based on what is known at the time. Explain assumptions, identify uncertainties and provide a timetable for completing the impact assessment. The FCA has been explicit that incomplete impact data should not delay notification.
4. Make the issue description regulator-readable – Avoid internal system jargon and technical shorthand. Clearly explain whether the issue involves under-reporting, misreporting, late reporting, over-reporting or rejected submissions.
5. Perform genuine root cause analysis – “Human error” and “vendor issue” are rarely root causes. Ask what control weakness, governance failure, process deficiency or oversight gap allowed the issue to occur.
6. Quantify the scope – Provide transaction volumes, affected fields, impacted entities, instruments, venues and reporting periods. Where estimates are used, explain the methodology and confidence level.
7. Separate remediation from correction – Fixing the source of an issue does not automatically remediate the regulatory breach. Historic reports often still require correction and resubmission. The FCA has repeatedly emphasised that firms remain non-compliant until affected reports have been corrected.
8. Set realistic remediation timelines – Document target dates for root cause resolution, back reporting, testing and governance approval. The AFM expects solutions within three weeks and historical remediation within three months unless a justified alternative timetable has been agreed.
9. Escalate to named governance – Identify the accountable individual, committee or forum responsible for oversight. Regulators increasingly expect evidence of decisions, challenge, approvals and resource allocation rather than statements that an issue has simply been “escalated”.
10. Resource remediation separately from BAU – One recurring FCA observation is that firms can degrade ongoing reporting quality while attempting to fix historical issues. Dedicated remediation resources and workflows help avoid this outcome.
11. Keep regulators informed – Update regulators when facts change, impact assessments are refined or remediation is completed. Transparency and demonstrable progress matter.
12. Maintain a complete audit trail – Even where firms conclude an incident is not reportable, they should retain evidence of investigation, impact assessment, root cause analysis, decisions taken and remediation completed. The AFM has been clear that firms should be able to provide this history upon request.

What this means in practice

Perhaps the most important message in both the AFM and FCA guidance is that regulators are usually looking beyond the error itself.

There will always be issues in every reporting environment but what matters is whether firms can demonstrate a robust process for identifying, managing and remediating those mistakes.

This is increasingly where firms are focusing their attention. Alongside our established regulatory reporting testing programmes, Kaizen now provides targeted on-demand testing of specific concerns, rapid investigation of suspected incidents and independent control framework reviews.

Whether supporting ongoing data quality assurance or helping firms respond to newly identified issues, the objective is the same: identify problems early, understand their root cause and evidence that remediation has been completed correctly.

To discuss how Kaizen can support your MiFIR reporting assurance, please get in touch for a demo of our platform or a conversation with one of our regulatory specialists.