A regulator does not want to hear that a number “looked right” when a report was submitted. If an examiner questions a figure in a risk report, the bank needs to show where it came from, how it moved through the organization, what checks it passed, and whether anything changed along the way.
For many financial institutions, that is harder than it sounds. Risk data can pass through core banking systems, calculation engines, spreadsheets, data warehouses, and reporting tools before it reaches a regulator. Each handoff creates another opportunity for something to go missing, change, or arrive late.
That is where a data quality and observability analytics platform is starting to play a larger role. Instead of checking data only when a report is due, financial services firms can monitor its condition as it moves through their systems. The result is a much clearer record of what happened to a number before it appeared in a regulatory filing.
When a regulator asks where a number came from
BCBS 239 put data lineage and risk data aggregation firmly on the agenda for large banks. The underlying expectation is straightforward: a bank should be able to trace important risk information back to its source and demonstrate that the data remains accurate as it moves through different systems.
The reality inside many institutions is less tidy. A calculation may be easy to reproduce but difficult to trace. A reconciliation may depend on a spreadsheet maintained by one person. A data quality check may run immediately before a report is submitted, leaving little visibility into what happened to the underlying data during the rest of the reporting cycle.
These problems do not necessarily point to poor controls. They often reflect years of systems, processes, and reporting requirements being added on top of one another.
Data observability gives financial teams a way to see those movements without relying on someone to piece the trail together manually.
Why quarterly reporting may not be enough
Regulatory reporting has traditionally worked around scheduled submissions and periodic reviews. That model becomes harder to defend when regulators want a more current view of a bank’s risk position.
Recent congressional testimony highlighted this tension. As reported by Banking Dive, a member of the House Financial Services Committee warned that agentic AI could potentially accelerate a bank run from hours to seconds. The argument was that regulators cannot respond effectively to such a scenario while relying on information that may already be months old.
The proposal for standardized, real-time regulatory dashboards may or may not become policy. The broader issue is harder to dismiss. Regulators increasingly want access to reliable information sooner, particularly when conditions can change faster than a reporting cycle.
That puts pressure on the systems behind the report. A dashboard is only as current as the data feeding it.
The gap between policy and what happens to the data
Deloitte’s research on BCBS 239 implementation at large multinational banks points to a familiar problem. Most participating banks had established a risk appetite for data quality, but far fewer had put those standards into day-to-day operation.
The same pattern appeared when banks were asked about the wider benefits of implementation. Many expected better business decision-making from stronger data practices. A much smaller group said they had actually seen those benefits.
A policy can define what “good data” means. It cannot tell a team that a source stopped sending records at 2:14 a.m., that a field suddenly contains unexpected values, or that a transformation changed the volume of records moving downstream.
That requires something watching the data itself.
What data observability adds
For compliance teams, the value of observability is less about another dashboard and more about having evidence when a question comes up.
A well-designed setup can flag a missing or delayed data feed before it reaches a regulatory report. It can track where a figure originated and which systems processed it. It can also record quality checks, exceptions, and remediation activity so the organization does not have to reconstruct that history months later.
The useful checks can include:
- Lineage: Where did a reported figure originate, and which systems changed it along the way?
- Freshness: Did the expected data arrive on time?
- Completeness: Are records or fields missing from the expected feed?
- Anomalies: Has the data moved outside the ranges or patterns normally expected?
- Audit history: What checks were performed, what failed, and how was the issue handled?
The people responsible for risk and compliance still have to decide what those findings mean. Observability does not replace that judgment. It gives them a much better record to work from.
The value goes beyond the next audit
There is a practical problem with building data controls solely around an annual regulatory review. If the monitoring is switched on only when an examiner is expected, most of its value sits unused for the rest of the year.
The underlying data is not used once a year, though. The same feeds support fraud monitoring, AML processes, credit risk, management reporting, and other operational decisions. A stale customer record or a missing transaction can create problems in any of those areas, whether a regulator is looking at the system that day or not.
That makes continuous monitoring useful on an ordinary working day, too. A bank may spot an unusual drop in records from a source system, identify a broken pipeline, or catch an unexpected change in a field before the problem reaches several downstream applications. The regulatory benefit is still there, but it is no longer the only reason to maintain the capability.
Compliance requirements will keep changing
Financial institutions rarely get to treat a regulatory requirement as a finished project. New rules often ask for information that depends on the same underlying data controls, lineage, governance, and reporting processes established for earlier requirements.
That creates two very different experiences for banks.
One may respond to every new requirement with another remediation exercise, another set of spreadsheets, and another round of evidence gathering.
Another may already have the ability to trace data, monitor its quality, identify exceptions, and produce an audit history. For that bank, a new reporting requirement still requires work, but much of the underlying evidence is already available.
That distinction matters as regulatory reporting moves toward more frequent and more detailed scrutiny. The real question is no longer whether a bank can produce a report by a deadline. It is whether the bank can explain the data behind that report whenever someone asks.
For financial services firms, that is where data observability starts to become part of the reporting infrastructure rather than another compliance project.
BayOne helps financial services firms build data foundations that support stronger lineage, quality monitoring, and regulatory reporting as their requirements change.
