These analytical notes explore a field I want to develop in. The examples are hypothetical and do not describe inspections I have carried out.
Connect the remedy to the cause
Adding a missing document repairs one file. If the cause was unclear ownership or a weak system rule, the problem may persist. Define the target condition, owner, deadline and method for checking effectiveness.
Two different checks
Implementation testing establishes whether a policy, feature or training exists. Effectiveness testing examines new cases and actual results. A well-written policy without changed working practices may satisfy the first test but fail the second.
Hypothetical example
A bank introduces a mandatory field explaining exceptions. Follow-up finds that the field contains only a dash. The technical change works, but the information objective is unmet. Review the rationale’s substance and responsibility for checking it or requesting clarification.
Defining an observable target
“Improve monitoring” is difficult to close objectively. Describe what should change: which cases receive owners, how reviews are documented and who handles overdue actions. A concrete target makes it possible to design effectiveness testing before implementation finishes.
Distinguish temporary workarounds from lasting remediation. Manual checks may bridge system development, but require capacity and records. If a temporary approach persists, reconsider its reliability and ownership.
What to check after implementation
For mandatory exception rationales, select new cases created after the change and compare their content with the objective. A non-empty field is not enough: does it contain a case-specific argument, and does anyone challenge an inadequate entry? Testing should reflect ordinary working conditions, not just a prepared demonstration.
A real case: Wells Fargo and control remediation
On 12 September 2024 the US Office of the Comptroller of the Currency entered a formal agreement with Wells Fargo Bank concerning financial-crime risk management and anti-money-laundering control deficiencies. The public notice required comprehensive corrective action. This establishes a US regulatory intervention, not the status of a particular internal task or a Czech supervisory procedure. The useful analytical question is how a finding becomes a demonstrable improvement in control operation.
The announcement does not reveal the number of internal remediation tasks or the effectiveness of each change. I would not invent those details. My general interpretation is that a completed action register and a functioning control environment are different things. Management needs to know whether the original weakness has stopped occurring and whether the solution survives ordinary workload and staff absence, rather than merely whether a revised policy document exists.
Hypothetical example: a mandatory field is not a reasoned decision
Suppose a bank cannot evidence the rationale for exceptions in twenty of fifty selected credit files. It adds a mandatory text box to the system and trains employees. Both tasks can be completed. If staff enter “approved by manager”, however, the record still fails to explain the risk accepted or the reason for acceptance. These numbers are fictional and do not describe Wells Fargo or another real institution.
I would define the target behaviour: every exception should have a substantive rationale, an authorised decision-maker and links to supporting evidence. The technical change is a means rather than the outcome. Effectiveness testing would examine files created after implementation, including complex cases and periods when the principal approver was absent. A solution that works only under ideal conditions is not a dependable resolution of the underlying issue.
Separate implementation from effectiveness
For each action I would ask two questions: was it introduced, and does it work? An approved policy, deployed software version or training record can demonstrate implementation. Effectiveness requires evidence from actual outcomes. The owner should know in advance what evidence is expected and who will independently assess it. This avoids negotiating closure criteria only when a deadline is about to expire.
For the exception example I would not stop at checking whether the box is populated. I would compare the stated reason with the file, verify the approver’s authority and examine whether the exception affects subsequent customer monitoring. A reason such as “temporary reduction in income” needs a basis for considering the reduction temporary and a point at which that judgement will be reassessed.
New cases and historical cases need separate plans
Repairing the future process does not automatically fix older files. I would distinguish preventing further occurrences, determining the existing population affected and correcting historical information where required. These workstreams may have different owners and deadlines. Otherwise the new system may function correctly while old, unreliable outputs remain in use as inputs to later decisions, making a closed task misleadingly reassuring.
If the historical population cannot be fully reconstructed, I would make that uncertainty explicit and explain the substitute approach. A limited sample is not a correction of the whole population. It may support scoping, indicate a possible pattern or guide further investigation, but the conclusion must match the evidence. It is better to define a bounded result honestly than imply certainty the investigation cannot provide.
How I would respond to a failed effectiveness test
If a new sample reveals the same weakness, I would revisit the assumed cause rather than merely extend the action deadline. The problem might be unclear authority, an unusable form or incentives that favour rapid completion over meaningful assessment. More training may help, but it should not become the default answer when system design continues to encourage the problematic behaviour.
The handover would describe what changed, which population was tested, which exceptions remain and who accepts any residual risk. I would arrange a proportionate repeat check after the new process has operated for a meaningful period. Controls do not all need permanent testing at the same intensity, but the chosen coverage should follow the risk’s significance and the results already observed.
I would also check dependencies between actions. For example, updating an approval workflow before repairing the permissions register might leave the right process assigned to the wrong people. A dependency map can show which steps must precede others and which evidence belongs to more than one action. That is particularly useful when different teams report progress using separate trackers with different definitions of completion.
Summary and recommendations
Close remediation against the original risk, not just an activity list. Agree evidence of implementation, evidence of effectiveness and an independent reviewer early. Separate future prevention from historical correction, test realistic exceptions, and revisit root causes after an unsuccessful test. My analytical contribution would be to connect the finding, intended change and observed outcome, so that closure represents an explained improvement rather than a change of status in a tracker.