Correcting one cell does not establish data quality
A mistake in a risk report often prompts a sensible immediate response: correct the figure and send a new version. That may restore one output without removing the mechanism that generated the error. Where the same information serves several processes, inconsistencies can continue elsewhere. I would therefore examine the data's origin, meaning, owner and downstream uses as well as the visible number.
I would not define the significance of 2026 solely through a new document or technology. The practical question remains whether an institution can obtain and explain the information needed for an important decision in time. A tool can support checks, but it cannot independently reconcile business definitions or decide ownership of a disputed exception. Those relationships must be understood before the final table is presented.
A verified 2026 development
On 6 January 2026, the Basel Committee published a newsletter on implementing BCBS 239. It discusses continuing risk data aggregation and reporting challenges and explicitly does not introduce new supervisory guidance. I therefore use it as a current analytical prompt rather than describe it as a new legal requirement taking effect in January. [1]
A documented case: Citigroup, United States, July 2024
On 10 July 2024, the Federal Reserve penalised Citigroup for insufficient compliance with its 2020 enforcement action. Its announcement identified continuing data quality deficiencies and ineffective compensating controls. These are the American regulator's documented findings, not my assessment of the bank's present condition. [2]
For my proposed approach, the useful distinction is between a declared remediation programme and demonstrated control effectiveness. Even a substantial transformation project does not by itself show which decision is now better protected. I would complement completed-task counts with evidence of which risks stopped arising, which exceptions remain and how those exceptions are managed while the permanent changes are implemented.
A hypothetical client-grouping difference
Imagine a fictional loan portfolio of CZK 12 billion. Five facilities worth CZK 240 million appear under separate companies in one report and under their common economic group in another. Both reports can have the same overall total. The discrepancy emerges in concentration analysis because the classification changes the distribution, not the portfolio's total value.
Correcting five rows in the final file may support today's meeting. If the source relationship remains incorrect, the discrepancy can return tomorrow. I would ask whether the same relationship feeds limits, internal segmentation and other reports. These illustrative amounts do not establish a regulatory limit breach; that conclusion would require the applicable legal definitions and additional data.
I would also examine the timing of the relationship. A group structure can change, and historical reporting may need the relationship valid at the reference date rather than today's version. Without an agreed temporal rule, two teams can each apply internally consistent logic and still produce incompatible answers. The difference needs explanation before either output is labelled wrong.
Map the journey of a critical field
For a selected critical field, I would record the source, transformation rules, reference dates and points at which its meaning changes. A system's technical administrator and the owner of the business definition are different roles. An administrator may ensure that a value transfers correctly without being authorised to decide which companies should be assessed together.
Manual adjustments belong in the map as well. They are not automatically inappropriate, but an undocumented intervention weakens reproducibility. I would ask who can change the value, what evidence supports the change, who approves it and whether the original state remains recoverable. A correction must not silently rewrite the meaning of every historical output.
I would keep the initial scope manageable. Mapping every field in every application at once can delay useful improvement. Selecting a small set with material decision impact creates a practical starting point. The selection itself should be documented so that omitted areas are recognised as outside the review rather than assumed to have passed it.
Make each check's purpose explicit
I would connect every data control to the question it protects. A non-empty field can still be wrong. A matching total does not verify the distribution, and a valid format does not establish currency. For important attributes, a clearly explained combination of checks can be more informative than a long list of technical tests with no stated decision relevance.
When reviewing exceptions, I would distinguish justified special cases, confirmed errors and unresolved situations. An unexplained difference needs an owner and a review deadline. Moving an exception into another category can reduce the open-defect count without increasing reliability. Management information should therefore reflect the age and significance of unresolved cases as well as their number.
I would also ask whether a control runs at the right point. A late check may identify an error after the report has already influenced a decision. Moving detection earlier can help, but only if someone can resolve the exception in time. Faster technical detection without a workable escalation path may simply create a longer queue of unattended alerts.
Demonstrate the correction's reach
I would verify remediation from the original record through the affected outputs rather than accept a replacement number in one spreadsheet. The source definition, transformation and exception handling should together support an explainable result. Testing would include previously correct cases, different reference dates and other relevant customer categories to identify unintended effects.
Where the permanent correction takes time, an interim control should have a clear purpose, boundary and end date. An unmanaged long-term workaround can become another unreliable data source. Reporting to management should distinguish the protection available now from the intended solution. Treating those as equivalent would obscure the risk that still needs attention.
Summary and recommendations
Reliable risk data require agreed meaning, complete transfer, clear ownership and checks on actual use. I recommend starting with a limited set of decision-critical fields, documenting their journey and verifying corrections across downstream outputs. Completed tasks and an overall green score are insufficient substitutes for evidence about the risks addressed.
My analytical contribution would connect the business definition, technical processing and inspectable evidence. I would also be precise about sources: a newsletter, supervisory guide and binding rule are different documents. Correctly identifying their status supports proportionate conclusions and clearer communication with the specialists who make the relevant decisions.
Test normal operation, not a corrected snapshot
For the fictional client-grouping correction, I would select fresh records as well as historical ones and check the ordinary processing route. A correct report produced only after manual intervention does not demonstrate that the original mechanism has changed. Success must also occur before the information is used for the decision; a late correction can leave the practical risk intact.