A correctly calculated total does not automatically make a report correct. Two amounts can reconcile while describing different periods, an incomplete portfolio or different meanings of the same field. I would therefore begin with the decision the report supports, the precise measure it presents and an independent reference against which its contents can be checked. Only after establishing those foundations would I investigate individual calculations or differences between screens.
In banking, this is more than a technical data issue. It affects whether a specialist sees the actual exposure, whether management understands concentration and whether a movement from the previous period can be explained. An analyst does not need to decide whether credit risk is acceptable personally. A valuable contribution is to distinguish verified information from estimates and establish an evidence trail showing how the reported result was produced.
A real case: Citigroup, United States, July 2024
On 10 July 2024, the Federal Reserve announced a USD 60.6 million penalty against Citigroup. It identified insufficient progress in remediating data-quality management and a failure to implement compensating controls following its 2020 action. The announcement concerns a broader control framework; it does not establish that a particular report or column was wrong.
That distinction matters. The release does not tell us which application should have been replaced or which field failed. My question is instead a proposed analytical one: when a source process has a known weakness, how do we stop a recipient treating an insufficiently verified output as reliable? The approach below is my own proposal, not an account of Citigroup’s internal remediation programme or its implementation.
Establish meaning before comparing numbers
I would request the indicator definition, reference date, currency, unit and population. Outstanding drawn exposure is not interchangeable with an approved facility limit. A consolidated group figure cannot be compared with a single legal entity without an explanation. For each important definition I would establish an owner, an approved version and an effective date. Otherwise a technically successful comparison may simply compare two differently defined measures and produce a misleading conclusion.
I would then trace critical data through sources, currency conversion, table joins, contract status changes and manual adjustments. This does not require mapping every system in a bank before starting. I would prioritise fields whose failure could alter the decision and follow their essential transformations. An unexplained transition becomes a documented question, not an assumption that processing must have worked because the report was generated successfully that morning.
An illustrative example: identical totals, different portfolios
Imagine two reports showing CZK 100 million. The new report omits one customer group worth CZK 5 million and duplicates another group for the same amount. The aggregate difference is zero, but the composition is wrong. This is a hypothetical example. The figures do not describe any specific institution or the regulatory case above, and no claim is being made about an actual loss.
A total reconciliation passes. A count of unique contracts might detect the error, but even that can fail if the missing and duplicated groups contain the same number of contracts. I would therefore combine identifier matching, amount comparisons and category breakdowns. The output would distinguish missing, extra and changed records. I would check whether customer-group mapping changed, because overall accuracy and classification accuracy can diverge without producing any net difference.
Next I would trace a small, reproducible sample of contracts from source to aggregation. The aim is to find the first transition at which expected and actual results diverge, rather than inspect every value manually. If a one-to-many join is responsible, deleting duplicates at the final reporting layer could hide the underlying defect. I would investigate other outputs using that join and check that the correction does not remove legitimate records.
Separate responsibilities without losing continuity
The business owner should confirm meaning and scope. Data or IT specialists should explain sources and transformation rules. My contribution would be to document discrepancies precisely, make the comparison repeatable and connect those perspectives. If specialists disagree about a definition, I would not immediately label the disagreement a software defect. An agreed expectation is needed before the implementation can be judged against it and before a fix can be accepted.
A finding would describe conditions, expectation, actual result, supporting evidence and potential impact. “The report is wrong” does not tell someone whether its use should stop. Evidence that one group contains the same twenty contracts twice provides a concrete starting point. I would label an impact estimate provisional until scope has been verified and name the specialist who needs to assess its significance for the relevant decision or downstream use.
Manage the interval before a permanent correction
If the report is needed before remediation is complete, I would propose an interim control. Options could include independent reconciliation of critical fields, explicit disclosure of limitations to recipients or excluding an affected indicator from a decision. The appropriate option depends on purpose and materiality; there is no universal acceptable error threshold. Any temporary control needs an owner, frequency, evidence of execution and an expiry or review point.
For the correction, I would repeat the original check using retained inputs and then test a new reporting period. Success for one sample proves only that sample. A suitable automated check would monitor later runs and route exceptions to an identified person. I would track time from detection to explanation and recurring discrepancies, rather than use the number of validation rules as the principal indicator of whether information is becoming more dependable.
I would also distinguish defective data from an outdated check. A new product may legitimately violate an old validation assumption. The objective is not to change correct data until a test becomes green. I would return to the approved definition, record whether the data, implementation or checking rule needs adjustment, and identify who maintains that rule when business requirements change again.
Summary and recommendations
Trustworthy reporting depends on clear meaning, completeness, traceability and demonstrable checks. I would start with one decision and one critical indicator, agree the definition and follow its data journey. Reconcile totals but also compare records and classifications, communicate known limitations and verify whether remediation remains effective in later runs. The analyst’s practical value is an output that another person can understand, challenge and reproduce instead of accepting it solely because a familiar dashboard displays it.
Checks after publication
Approval should not end the review cycle. I would retain a log of subsequent corrections and periodically compare it with the original controls. If the same explanation is missing month after month, another manual footnote is unlikely to solve the underlying problem. Data and methodology owners should decide together whether to change the input, transformation rule or presentation. This separates a one-off correction from a recurring weakness and creates evidence for the next reporting cycle.