Ensuring accurate, complete and timely reporting in the era of data-driven supervision
Keynote speech by Andrew Pinnington, Novatus’ Chief Customer Officer, at the RegTech Summit London 2026, hosted by A-Team Insight.
For years, regulatory reporting has been treated as a production problem:
• Can we get the data?
• Can we populate the fields?
• Can we create the file?
• Can we get the regulator, ARM or TR to accept it?
• And can we meet the differing expectations of 10 global regulators that want to see it?
Ideally, this will be done without Compliance sending an email at 17:47 on Friday afternoon entitled: “Potential material reporting issue – urgent”.
That was basically success. But times are changing.
The biggest change in regulatory reporting today isn’t what firms are sending to regulators. It’s what regulators can now do with the data once they’ve got it.
Historically, firms had the information advantage. You knew your business. You knew that Field 17 came from System A, unless it was an equity swap through that one workflow – in which case, someone enriched it manually in a spreadsheet built in 2014.
The same person, obviously, is your data lineage strategy. The regulator just saw the output.
Today, regulators have huge datasets across firms, instruments and venues. They can identify outliers. Compare firms. Analyse distributions. Spot changes in reporting behaviour.
They can also cross-reference datasets, particularly where they are receiving more than one report for the same trade. And increasingly, they are using advanced analytics to decide where to start asking questions.
So the supervisory conversation changes from: “Please explain your reporting process.” to: “We’ve identified something unusual in your data. Explain it.”
That is a very different meeting. One allows you to bring a 70-page PowerPoint about your controls. The other starts with: “Why are you different from everybody else?”.
Slide 43 on your three lines of defence strategy is probably not going to save you.
Beware of regulatory simplification
At the same time, regulators are simplifying some reporting obligations. That is good news, but less reporting does not mean less scrutiny. The direction of travel is less data regulators don’t need, and more sophisticated use of the data they do need.
That creates an important question: can your control environment identify problems before the regulator’s analytics do?
The regulator increasingly has data-led monitoring, benchmarking, advanced analytics and more timely supervision. They can compare data within the multiple reports received for the same transaction.
Inside the firm? Multiple source systems. Divergent reporting logic. Periodic reconciliations. Manual workarounds. Three people who understand it. And they’re busy.
That gap is the problem. If you cannot explain where a field came from, why it was populated that way, what transformation happened, and whether that behaviour is unusual across millions of records, another spreadsheet reconciliation at quarter-end isn’t going to help.
AI in regulatory reporting
There are some genuinely useful applications of AI in regulatory reporting. Not: “ChatGPT, please submit my EMIR report.” I would not recommend that control framework.
The interesting use cases sit around assurance. A counterparty suddenly being classified differently. A field distribution moving outside its historic range. Rejections increasing after a technology release. The same issue appearing across multiple regulations.
Traditional controls may find some of this. AI can help connect it.
Anomaly detection. Root-cause analysis. Exception classification. Cross-population analysis. Prioritising where humans should spend their time.
Nobody looks at 47,000 reconciliation breaks and thinks: “Excellent. I’m going to find the strategic insight hidden in this.” You normally think: “Can I export it to Excel?”
But there is an enormous caveat. AI cannot compensate for data you do not understand. If you have weak lineage, inconsistent definitions and unclear ownership, AI doesn’t magically create control.
It lets you be wrong faster, at scale, and with tremendous confidence. Transparency matters: what data went in? What decision was made? Why? What evidence supports it? Can a human challenge it?
That is where AI becomes a control enhancement, rather than another model-risk problem.
Build a reporting system that can explain itself
What should firms actually do?
Source. Transform. Report. Reconcile. Explain. Remediate.
Most firms are reasonably good at the first three. If you fail at those, nothing gets reported, and somebody notices. The harder question is what happens afterwards.
For me, it comes down to four things:
1. Prove it. Can you reconcile source to report? Prove completeness? Prove accuracy? Demonstrate genuine lineage? If the regulator asks where a value came from, the answer cannot be: “We think it came from here”. That is not lineage. That is a hypothesis.
2. Find it. Can your controls identify unusual behaviour? Not just: Did the record pass validation? But: Does the population look right? Has something changed? Is this distribution unusual? Schema validation is a very low bar. It does not mean the report is correct. It means you have successfully submitted something shaped like a report.
3. Explain it. Can you trace an issue backwards through the report, transformation, reporting logic and underlying data? Can you explain the cause clearly? Because: “Here is what happened, here are the affected transactions and here is the control failure” is a much better regulatory conversation than: “The model said so.”
4. Fix it. Once you find the problem: Who owns it? Who is investigating it? What else is affected? Does it require back-reporting? Has it happened before? How is it escalated? And where is all of that tracked? The goal must be continuous assurance. Not quarterly reconciliation, meeting, spreadsheet, another meeting, risk acceptance, forget about it.
Underneath all this sits people. The reporting professional of the future cannot only understand regulation. They need enough understanding of data to challenge lineage, enough understanding of technology to challenge architecture, and enough AI literacy to know what it can do – and what it can’t.
Every firm should be asking simple questions
How deep is the expertise behind the rules? Can you trace issues back to the data and logic that created them? How quickly? Can you move from identifying an issue to fixing it? Are controls continuous, or are they periodic? And where are you investing in regulatory expertise, product and engineering?
If your answers still depend on spreadsheets, data samples and a handful of people who “know how it works” – your control framework may not have caught up with the regulator.
Ultimately, the key question is simple: Why do you believe this report is correct?
Not: “It passed validation.” Not: “The ARM accepted it.” Not: “Someone checked the spreadsheet.” But:
• Here is the data.
• Here is the lineage.
• Here are the controls.
• Here are the exceptions.
• Here is how we fixed them.
• And here is the evidence.
In a world of data-driven supervision, producing the report is increasingly just the beginning. Being able to prove why it is right is the real control.
