A report is where a problem becomes visible, but its origin may be elsewhere. My experience in integration and data process analysis makes me consider the connections between systems as well as the final output.
Map the transitions
A data item may pass through capture, transfer, transformation, classification and aggregation. I would record the input, operation, output and responsible system at each step.
In its January 2026 publication, the Basel Committee identifies traceability from origin to final use as important for confirming data quality, while recognising the challenges of maintaining it. The following is my illustrative analytical approach.
A hypothetical classification change
After a reference table changes, records move into a different category. The overall volume is unchanged, but a breakdown shows an unusual movement. I would check the reference table version, effective date and treatment of historical records before interpreting the change as business activity.
A focused investigation
- Define the affected periods, categories and records.
- Trace the same sample from source to report.
- Find the first transition where actual and expected results differ.
- Check whether the rule affects other outputs.
- Validate the correction and previously working cases.
Shared understanding
A simple data journey map connects business meaning with technical processing. An analyst can capture both while keeping verified facts separate from assumptions. A useful outcome would include the correction, a documented rule and a check that helps identify recurrence.
Break the journey into testable transitions
A useful lineage map shows more than systems. It captures meaning: where identifiers originate, where the latest valid record is selected and where currencies are converted. Each transition can have different rules and processing times. Without that context, differences between outputs remain difficult to explain.
I would start with a specific case and work backwards from the report. At each boundary, compare value, time and record key. The first unexpected change usually narrows the investigation more effectively than inspecting every table indiscriminately.
Why fixing the output may not be enough
A report-only correction can leave the same inconsistency in other downstream outputs. After identifying the cause, determine who else uses the source or transformation. Impact analysis should be proportionate without stopping at the first visible screen.
Retest the original case and comparable records. The objective is to establish that the rule works across its relevant scope, not simply that one number changed. Distinguish correction of historical data from changes to future processing.
A real case: the first action does not close the problem
On 10 July 2024, the US OCC announced further action against Citibank and a USD 75 million penalty. Its explanation included weaknesses in monitoring the effect of data-quality concerns on regulatory reporting. This does not establish a particular transformation error; it illustrates the importance of tracing consequences across outputs.
My own interpretation is that a list of corrected fields does not demonstrate a reliable process. The team needs to know who originates the information, which rules change it and where it is consumed. A successful check in one branch can coexist with an unresolved problem elsewhere. I would connect the cause with a map of affected outputs rather than stop at the name of the principal database.
A hypothetical example: original and reporting currencies
Consider an invented contract for EUR 100,000. Its source correctly stores amount and currency. An intermediate step converts it to CZK 2.5 million using an illustrative rate of CZK 25 per euro. A later interface passes only the number, dropping the currency, and the receiving process converts it again. The multiplication itself is not wrong; the problem is lost meaning and an unclear boundary contract between systems.
I would follow the same contract identifier through every step, recording value, currency, rate and rate date. This would identify the first point where an expected attribute disappears. However, I would not immediately claim that every foreign-currency product is affected. Scope would need examination by interface version, contract type and the period during which the problematic mapping was used.
If somebody had manually corrected the final report, I would record that too. A reconciled total can hide a broken automated path. The following monthly batch could recreate the problem with a different impact. Recommendations would distinguish a permanent interface correction, one-off historical reprocessing and a temporary control that detects recurrence during the transition. Each action addresses a different part of the exposure.
How I would validate the map with different teams
The business owner explains what an item should mean, a data specialist demonstrates its origin and a developer explains the transformation. None of those views is complete by itself. In a joint walkthrough I would compare explanations with an actual record. A mismatch between documentation and observed processing calls for investigation, rather than automatic preference for whichever document happens to have the latest date.
The map should support decisions without displaying every temporary table. I would prioritise changes of meaning, population selection and reference date. Significant rules need a named owner and version. When a reference table or exchange-rate source changes, the team can then identify the checks that need to be repeated and the person who should confirm the business result.
Testing remediation and describing uncertainty
After a correction I would trace the original failing record, a valid case in another currency and a case with a missing rate. I would also repeat the same batch to examine repeat-processing behaviour. A change may remove double conversion while accidentally stopping a necessary conversion elsewhere. Regression checks should therefore protect legitimate variants of the shared rule as well as the original defect.
My conclusion would remain limited to what was actually reviewed. Following three interfaces for one product does not establish the quality of the entire banking data architecture. The finding may nevertheless be significant if the same component serves other processes. The record should identify that possibility and allocate further investigation rather than present an unverified institution-wide scope as an established fact.
Summary and recommendations
I would map the data journey through real records and changes of meaning, not just system names. A material discrepancy needs an explanation of origin, impact and remediation verification. A useful map connects the people who understand different parts and gives them a shared basis for a decision. Its practical value is the ability to trace another case without reconstructing the whole path from scratch.
Sources and links
- OCC — Amended action against Citibank, 10 July 2024
- Basel Committee — Implementation of BCBS 239 Principles, 6 January 2026
Foreign cases provide analytical lessons; their legal frameworks and measures are not automatically applicable to Czech banks. Hypothetical examples and proposed methods do not describe inspections I personally conducted.