Every institution that has operated for more than a few years carries a back book: client files opened under an older policy, with evidence that no longer meets the current standard. Sometimes the gap is discovered internally. More often it is discovered by an auditor, a regulator, or a correspondent bank asking a question that cannot be answered quickly.
What follows is almost always called a remediation programme, and remediation programmes have a poor record. They run long, cost more than budgeted, exhaust the people assigned to them, and — the detail that should worry management most — frequently need to be repeated within a few years.
The reasons are structural rather than a matter of effort. This article sets out why remediation programmes fail, how to scope one that does not, and what has to change so that the same book never needs remediating twice.
1. Why remediation programmes fail
They are scoped as projects rather than as corrections of a process. A project has an end date, a budget and a closing report. A back book is the accumulated output of an operating process. If the process that produced the gap is unchanged, the book begins re-accumulating from the day the programme closes — and the second remediation is typically scoped from scratch, because the first produced a report rather than a capability.
They are sequenced by convenience instead of by risk. Alphabetically, by portfolio, by relationship manager, by account opening date. Any of these is defensible operationally and indefensible to a regulator, because none of them processes the riskiest files first. A programme that remediates ten thousand low-risk files before reaching its first high-risk structure has spent its budget in the wrong order, and will be asked why.
They are measured in files closed. The metric drives the behaviour: analysts close what closes easily. The difficult files — complex structures, unresponsive clients, missing source-of-wealth evidence, deceased signatories — migrate to the end of the queue, where they arrive with the budget exhausted and the deadline imminent. Every remediation has a long tail, and the tail contains most of the actual risk.
They treat client contact as a formality. Experience is consistent: a substantial share of a back book cannot be remediated without asking the client for something, and a substantial share of those clients do not respond to a first request. If the programme plan assumes a high response rate, the plan is wrong, and the discovery comes late.
They produce documents, not data. The programme collects what is missing, files it, and marks the client compliant. Three years later the same questions require the same manual reconstruction, because what was produced was an archive rather than a structured record.
2. Scoping: the three questions to answer first
What exactly is deficient? "The KYC is old" is not a scope. A usable scope names the specific gaps: missing or expired identification; beneficial ownership not verified to the current standard; no source of wealth evidence above a threshold; risk rating produced under a superseded methodology; screening not re-run since a given date. Each of these implies different work, different client contact and different effort — and files typically carry more than one.
Which population, on what criterion? The scope decision that matters most is not how many files but which. Risk-based segmentation — jurisdiction, structure complexity, PEP exposure, product, transaction profile — is both the regulatory expectation and the practical one.
What is the target state? Remediating to today's policy is the obvious answer and often the wrong one. If a policy revision is underway, remediating to the outgoing standard guarantees a second pass. Pin the target to where the policy will be, not where it was.
3. Sequencing: risk first, and prove it
Sequencing by risk sounds obvious and is rarely done, because the risk rating in the system is itself part of what is deficient. If ratings were produced under a superseded methodology, sorting by them sorts by an unreliable key.
The way through is a triage pass: a lightweight re-scoring of the whole population on data already held — jurisdiction, entity type, structure depth, product, screening status, transaction behaviour — producing a provisional priority ranking. The triage is not the remediation. It is cheap, it runs on existing data, and it tells you where to start.
Three things make triage defensible: it must be documented as a methodology, applied uniformly, and retained. A regulator reviewing a programme in progress will ask why a given file had not yet been reached. "We were working alphabetically" is a bad answer. "It scored in the lowest risk decile under the triage methodology dated March, and was scheduled for phase three" is a good one — see customer risk scoring and the risk-based approach.
4. The client contact problem
This is the part that determines the programme's real duration, and it is routinely underestimated.
Batch the asks. The single most expensive pattern is contacting a client three times for three documents. Resolve the full requirement set per client before the first contact, even where that delays the first contact by a week. Each avoided round trip saves more elapsed time than it costs.
Route through the relationship, not around it. A request arriving from a compliance address with a deadline reads as an accusation. The same request from the relationship manager, with context, converts far better. This costs relationship-manager time, which means it has to be planned and agreed — not assumed.
Design the non-response path before you need it. A proportion of clients will not respond, and the policy for that case — escalation, restriction, exit — must exist in writing before the first non-response, with a clear owner. Programmes that improvise this find themselves making exit decisions under deadline pressure, which is the worst condition for making them.
Exploit what you already hold. A meaningful share of apparent gaps are not gaps at all: the evidence exists in another file, another system, or a sister entity's record. Searching before asking is faster than asking, and it preserves client goodwill for the requests that genuinely need making — one of the strongest arguments for a unified client lifecycle record.
5. What to measure
Replace "files closed" with four measures that cannot be gamed in the same way:
- Risk-weighted completion. Progress through the high-risk population, reported separately. A programme 80% complete overall and 30% complete on high risk is behind, not ahead.
- Tail age. The age of the oldest unresolved file, and the size of the set older than a threshold. This is the single best early indicator that difficult files are being deferred.
- Client response rate by contact method and segment. Measured from the first contact, this tells you within weeks whether the plan's assumptions hold — while there is still time to change the approach.
- Rework rate. Files reopened after being marked complete. A rising rework rate means the completion standard is not being applied consistently, and every file closed before the discovery is suspect.
The financial framing that makes these land with a steering committee is covered in the ROI of KYC/AML automation.
6. Remediating once
The test of a remediation programme is not whether it closes. It is whether the institution needs another one.
A programme that produces a folder of completed files and a closing report has not changed the conditions that created the back book. A programme that leaves behind the following four things has:
A structured record, not an archive. Beneficial ownership held as a graph; risk rating as a computed attribute with its inputs; documents linked to the assertions they evidence. Then the next policy change is a re-computation across a known population — hours of analysis — rather than a manual review of ten thousand folders.
Event triggers instead of calendar reviews. The back book exists because files were correct when opened and nothing watched them afterwards. Fixing the files without fixing that produces a new back book on the same schedule. This is the core of the perpetual KYC argument, and remediation is where its absence becomes quantifiable.
A policy version attached to every decision. Each file should record which policy version it was assessed under. With that, the next policy change identifies its own remediation population automatically. Without it, every future change requires a full-book review to find out who is affected — which is how institutions end up remediating the same clients repeatedly.
The remediation capability retained, not disbanded. The ability to define a population, triage it, batch client contact and track risk-weighted completion is operationally valuable well beyond one programme. Institutions that keep it treat the next regulatory change as a routine run. Institutions that disband it buy the capability again, at project rates, every few years.
7. Where a CLM platform changes the arithmetic
Remediation is expensive in proportion to how fragmented the client record is. Where the record is one structured object, most of the programme is computation: identify the population, compute the gaps, generate the batched client requests, track completion by risk band. Where it is a folder per account across several systems, every one of those steps is manual, and the cost scales linearly with the number of files.
Wecan's CLM platform holds the client as a single record with structured beneficial ownership, computed risk, event-driven review triggers and a policy version on every decision. For an institution facing a back book, that changes what remediation is: not a project to be survived, but a query to be run, a population to be worked through in risk order, and a state that the platform then maintains.
The institutions that remediate once are not the ones with the largest programme teams. They are the ones that fixed the record at the same time as the files.
This article is provided for information purposes and does not constitute legal or regulatory advice.
