A remediation programme can have an orderly timetable, completed milestones and a new application, yet still leave uncertainty about whether the original risk has decreased. In a data programme I would distinguish delivery from a verified outcome. A new control, updated documentation or training may be necessary outputs. On their own they do not establish that an error stops occurring or that the bank detects it early enough.
The documented case: supervisory action involving Citi
In October 2020 the US OCC acted against Citibank over risk and data governance weaknesses. On 10 July 2024 it announced further action and a $75 million penalty, referring to remediation progress and monitoring data-quality effects on regulatory reporting. The Federal Reserve separately announced a $60.6 million Citigroup penalty that day concerning data-quality remediation and compensating controls. These were related actions against different legal entities, the bank and its holding company.
I do not infer the present status of every Citi programme or the technical cause of individual errors from these announcements. My starting point is the documented distinction between transformation activity and effective remediation. The approach below is my proposed analytical method, not a reconstruction of an internal project at the bank.
Define the weakness so it can be checked again
Rather than accept a goal such as “improve data quality”, I would identify the affected fields, processes and outputs, the observable discrepancy and the decisions that might rely on incorrect information. A precise description allows business owners, data specialists, IT and control functions to agree what improvement means.
I would separate repairing the past from changing the process. Correcting a report removes one consequence. A validation rule may detect the next occurrence. Changing data capture may prevent it. Each layer serves a different purpose and needs different evidence. Delivering one should not hide the absence of the others.
A hypothetical example: a new script, an old risk
Imagine a monthly report containing ten thousand records, two hundred of which lack the valuation date for collateral. The team repairs the latest output and introduces a script to identify empty values each month. That is progress, but it does not establish that missing dates cannot affect a decision before the monthly check runs.
I would examine the next cycle from its source. If fifty new records still lack the date, the historical population has been fixed while the cause remains. A script checking only empty fields could also miss a placeholder such as 1 January 1900. The count of empty fields might fall to zero without improving the meaning of the information. These numbers are illustrative, not Citi data.
I would define success through combined conditions. Historical corrections have an evidenced source, new records receive completeness and validity checks, exceptions reach an accountable owner, and the use of uncertain information is controlled. Testing should include valid inputs and cases that must be rejected or flagged. Without negative cases, we may fail to notice that a control does nothing.
How I would establish effectiveness
For each action I would connect the original finding, its cause, the proposed change, the expected effect and the verification method. I would call a cause confirmed only when supported by evidence. If it remains a hypothesis, the plan needs a test of that hypothesis. Otherwise we may carefully validate a solution to a misunderstood problem.
Closure evidence should come from the actual workflow as well as a test environment. A technical test can establish a property of a programme; an operating sample can show whether it runs at the right time and whether someone responds. Both are useful, but answer different questions. Evidence should therefore identify its environment, version, reference period and sampling limitations.
An independent review should not simply repeat the project presentation. The reviewer needs the requirements, data and criteria in a form that permits their own check. If a green dashboard is offered as evidence, I would ask how that status was calculated. An action owner and verifier can cooperate without treating their conclusions as interchangeable.
Measures that reveal progress
Besides error counts, I would track detection time, resolution time and recurrence. Each measure needs a relevant denominator and segment. A hundred exceptions among a million records differ from a hundred among two hundred. Low frequency also does not exclude severity where a significant exposure or important decision is affected.
I would avoid incentives concerned only with reducing reported exceptions. A sudden improvement may reflect a changed filter, definition or population. For an unusual movement I would check the denominator and calculation rules. A companion list of excluded items and unresolved uncertainties helps make improvement explainable rather than merely reportable.
Temporary controls need a clear lifecycle
Where a permanent solution takes time, I would examine the interim protection. Who performs it, what does it cover, when might it fail, and how will an omitted check be detected? Manual reconciliation may be proportionate for a limited population, but effectiveness depends on capacity and staff knowledge. Absence, turnover or higher volumes should not remain untested assumptions.
Every temporary procedure should have a review date and an exit condition. Otherwise an emergency response can become a permanent dependency with unclear ownership. When automation replaces a manual check, I would compare the results in parallel on an appropriate sample rather than switch off the old control as soon as the software is installed.
Review the decision, not just the file
I would also ask whether remediation changes the information available to a decision-maker. A corrected field that never reaches the relevant report may deliver little practical protection. Conversely, an exception flag without an agreed response can produce more alerts without a safer process. The review should follow the issue from source through processing to use.
For example, if a credit committee receives an uncertain collateral date, the response might require clarification before a particular decision rather than a general prohibition on all activity. The appropriate action belongs to the competent business and risk owners. My analytical task would be to expose the uncertainty, trace the evidence and record the agreed treatment, not substitute a technical rule for their judgement.
Summary and recommendations
A completed task and effective remediation are different conclusions. I would recommend closure only after demonstrating an effect on the original risk, testing relevant exceptions and confirming operating ownership. Larger changes also need observation over more than one cycle so that a single clean file does not stand in for a sustainable process.
My contribution would be to connect the requirement, data evidence and a clear conclusion. What can the bank now do better, and how do we know? If the answer contains only the number of training sessions, documents or delivered code changes, I would return to the verified outcome for a specific output and its users.