Regulatory Strategy

Why KYC Is Broken in Most Banks (And Everyone Pretends Otherwise)

KYC failure is rarely a people problem. It is a design problem — flat effort, drifting standards, and MI that cannot answer the regulator's question. Here is what actually breaks, and how it gets fixed.

Walk into almost any large bank and ask whether its KYC is in good shape, and you will hear a version of the same answer: it is under control, there is a programme in flight, the backlog is being worked. The answer is delivered with conviction because everyone involved is working hard. The files are being processed. The effort is real.

And yet the framework is broken — not because anyone is failing to try, but because the system they are trying within was never designed to work at the scale and standard now demanded of it. The collective pretence that hard work equals a functioning control is the most expensive habit in financial crime compliance.

KYC failure is a design problem, not an effort problem

The instinct when a KYC backlog grows is to add people. More analysts, more contractors, more hours. It almost never works, because the constraint is rarely capacity. It is design. Three structural failures recur across nearly every broken KYC framework, and none of them is solved by throwing labour at the queue.

Failure one: flat effort

In a well-designed framework, effort follows risk. High-risk customers and EDD-eligible cases are triaged first and reviewed most intensively; low-risk, stable customers consume proportionately less. In a broken framework, effort is flat — every customer is worked in roughly the same way and in roughly the order they happen to surface. The result is that scarce specialist attention is spread evenly across a population where the risk is anything but evenly distributed. Dormant low-risk customers absorb the same diligence as complex high-risk structures, and the cases that actually matter wait their turn in an undifferentiated queue.

Failure two: standard drift

Ask ten analysts what a “complete” file looks like and, in the absence of tight templates and quality gates, you will get ten answers. Each is reasonable; none is identical. The consequence is rework — files bounced back, re-opened, re-judged — and a quietly doubling cost that never appears as a line item because it hides inside throughput. Standard drift is invisible day to day and devastating in aggregate, and it is the single biggest reason remediation programmes run over time and over budget.

Failure three: MI that cannot answer the regulator’s question

The regulator’s question is always, in essence, the same three-part test: what was the risk, what did you do about it, and how do you know it worked? A great deal of KYC MI cannot answer it. It counts files closed, alerts cleared, productivity per analyst — operational throughput metrics that describe activity but not risk reduction. When a supervisor asks an institution to demonstrate that its remediation actually addressed the risk in the book, throughput dashboards are not an answer, and the gap becomes a finding.

Why everyone pretends otherwise

If these failures are so common, why does the pretence persist? Partly because the symptoms are easy to misread as progress — files are moving, so it must be working. Partly because admitting the framework is broken implicates a lot of effort already spent. And partly because the people closest to the work are too busy executing within the broken design to step back and question the design itself. The pretence is not dishonesty; it is the natural result of mistaking motion for control.

The regulator, however, does not share the pretence. Supervisors have seen enough broken frameworks to know that a busy programme and an effective one are not the same thing, and they test for the difference.

What fixing it actually looks like

A functioning KYC framework is engineered, not staffed. The work begins not with “how many people do we need?” but with two questions answered once, correctly: where is the risk, and what does a defensible file look like? Everything else follows.

Diagnose before deploying. Baseline the population, sample file quality, and map where CDD is stale, incomplete or wrongly rated. This is what lets effort be aimed at risk rather than spread across a spreadsheet.

Risk-tier the population. Segment by inherent risk so high-risk and EDD-eligible customers are triaged first and review frequencies are set correctly. Risk-tiering is the antidote to flat effort, and it is the highest-leverage decision in the whole programme.

Design the workflow once. Standardised file templates, decision logic, quality gates and escalation pathways — built so that a blended delivery team produces consistent, audit-ready output. This is the antidote to standard drift. Define “complete” precisely, enforce it at a quality gate, and the rework rate collapses.

Run with MI built for the regulator’s question. Completion by risk tier, EDD escalations, SAR triggers, ageing — the evidence that risk was identified and addressed, not merely that files were closed. This is the antidote to MI that cannot defend the programme.

Return to a sustainable BAU. A remediation that does not hand back a perpetual-KYC operating model is a temporary fix; the backlog will rebuild. Event-driven triggers and a risk-based review cycle keep it from silently accumulating again — the subject of why perpetual KYC is an architecture problem.

Scale is a delivery-model question

There is a legitimate objection: even a well-designed framework still has to clear hundreds of thousands of files, and design alone does not produce that throughput. True — which is why scale is a delivery-model question, not a headcount question. The specialist practice leads the parts that require senior judgement — diagnosis, risk-tiering, quality assurance, governance — and integrates vetted delivery resource and client teams to execute file completion at volume, all under one quality framework. That is how Big-4-scale throughput is achieved without the standard drift that flat staffing produces, and it is set out in CCL’s delivery model.

The honest question

The test of whether a KYC framework is genuinely under control is not whether files are moving. It is whether the institution can answer the regulator’s three-part question for any customer in the book, today, with evidence. Most cannot — not because their people are not working, but because the framework they are working within was never designed to let them.

Naming that honestly is the first step. The fix is not more effort. It is better design — and the discipline to build the operating model before mobilising the people. CCL’s KYC remediation at scale practice is built on exactly that order of operations.


To pressure-test where your KYC framework is structurally exposed — and what a defensible fix looks like — book an advisory call.

KYC CDD Remediation Operating Model FCA Financial Crime

Speak to the practice

Before it becomes a regulatory finding, make it a closed action.

A short, confidential advisory call to pressure-test where your KYC, AML, sanctions or risk-classification framework is exposed — and what a defensible fix looks like.