A KYC backlog is a stock of customer files that are overdue for review or fall short of the bank's current standard, and it clears only when the weekly rate of files brought to standard exceeds the rate at which new ones fall behind, for long enough to reach zero. Backlogs build when a new standard is not applied to existing customers, when growth outruns review capacity, or after a merger; they become an enforcement issue when nobody can say how many files are open, how risky they are and when they will be done. Botminds' KYC Remediation clears them on a plan: agents test and search every file first, people approve batches on a stated sample, and a burn-up against the plan line shows the date moving week by week.
The plan on this page is illustrative arithmetic for a 20,000-file backlog, built on the stages and settings of a fictional sample programme at Norrell Federal Credit Union. Replace the rates with your own pilot's.
An illustrative burn-down for a 20,000-file KYC backlog: flat for a month, then steep
What is a KYC backlog, and what causes one?
A KYC backlog is the set of customer files that are past due for review or below the current standard, counted, so that someone owns the number. It is caused by work arriving faster than it is finished, and by work that is never scheduled at all. The second kind is the dangerous one, because it does not show up as overdue: it shows up as nothing.
Enforcement records show four recurring causes. A new standard not applied to existing customers: CommunityBank of Texas added a CDD question in 2019 and never asked it of customers already onboarded (FinCEN, 2021). Customers never processed at all: FinCEN found that TD Bank "allowed millions of high-risk customers to remain unscored" (FinCEN Consent Order No. 2024-02). Growth that outran review, as at banks whose fintech partners onboarded faster than the bank's controls. And acquired books brought in on someone else's standard, which is the sample programme's case.
How to reduce a KYC backlog: scope it by risk first
To reduce a KYC backlog, first sort it by risk and by gap, then clear the higher-risk files and the files the bank can close from its own records first. Clearing in arrival order spends the first months on low-risk files while the riskiest wait; clearing in risk order brings the exposure down fastest even if the count falls at the same rate. The same sort tells the plan which cohorts need customers to answer, and therefore which will make up the tail.
Scoping also means deciding what the backlog is not. Files that fail a policy the bank has since withdrawn, accounts closed during the programme and customers outside the population should be removed with a recorded reason, not worked. A backlog that has never been scoped is usually larger on paper than in fact, and a plan line drawn on the paper number will be wrong.
Week by week: a plan to clear a KYC backlog
A plan to clear a KYC backlog has four phases: scope and connect, pilot, calibrate quality control, then run batches at a stated rate until a tail of customers who have not answered is decided. The first month barely moves the count, which is exactly why it should be shown on the burn-down: a regulator or board that sees the plan in advance does not mistake preparation for delay.
Twenty weeks, four phases: the first month moves almost nothing, and that is the plan
- Scope and connectwk 1–2
- Pilotwk 3
- Calibrate QCwk 4
- Batches at a stated weekly ratewk 5–16
- Tail and decisionswk 17–20
What each week of the plan has to produce
- Weeks 1–2: an approved scope and connected systems
Population, standard per gap, order of work and deadline, approved by the BSA officer; read access to core, loan, imaging and filing records.
- Week 3: a pilot of about 200 files, fully reviewed
From the hardest cohort. Measure how often a proposed closure is right, minutes per file and what customers will be asked for.
- Week 4: quality control calibrated
Sample sizes per batch type, strata, the error definition, and the first search batch approved on its sample.
- Weeks 5–16: batches at the stated weekly rate
One plain request per customer for what the search could not close, paced to contact center caps; batches approved by maker and checker.
- Weeks 17–20: the tail decided
A call first where there are signs of vulnerability; limits only with a reviewed notice and the BSA officer’s approval.
- Every week: the burn-down and its exceptions
Files done with evidence, by cohort and risk, against the plan line, and what is blocking the rest.
Pilot on a few hundred of your own files before you scale
A pilot on a few hundred of the bank's own files is the cheapest way to replace guesses in the plan with measurements. It should come from the hardest cohort, often beneficial owners or nature and purpose, and be fully reviewed rather than sampled, so the error rate of proposed closures is known before sampling starts. It should also measure what customers will be asked for, because that sets the tail.
The five agencies' 2018 statement on innovation makes a pilot safer than it sounds: one that finds the current process missing things is not, by that fact, grounds for supervisory action (joint statement, December 2018). In a backlog, a pilot nearly always finds something, usually evidence the bank already held but had not connected to the file. On the sample programme, the search that a pilot would have tested found signed certifications for 5,222 of 5,614 business files with no work started, in loan files nobody had searched.
How many files a week can a KYC team clear?
A KYC team clears as many files a week as its people can check, once the searching and drafting are not theirs to do. On the sample programme, six analysts and two quality reviewers review about 1,100 files a week against a plan line of about 975. By hand, at the solution's own estimate of 95 people-minutes for one business file without verified owners, one person with 35 productive hours a week would clear about 22 such files; at 21 minutes, with agents searching and drafting, about 100.
Weekly capacity, by hand and with agents, for one kind of file
| By hand | With agents | |
|---|---|---|
| People-minutes per business file without verified owners | 95 | 21 |
| Files per person per 35-hour week | about 22 | about 100 |
| People to clear 1,200 such files a week | about 54 | about 12 |
| Customers asked, if 71% close from the bank’s records | every customer, if no one searches first | about 29 in 100 |
Capacity is not the whole answer, because files that need the customer wait whatever the desk's size. The plan's weekly rate should therefore be set per cohort: files closable from records at the checkers' pace, and files needing customers at the pace the contact center can absorb, which on the sample programme is a cap of 1,200 consumer and 450 business messages a week.
How long does it take to clear a KYC backlog?
Clearing a KYC backlog takes the setup month plus the remaining files divided by the weekly rate, plus the tail of customers who have not answered. Orders give a sense of what regulators consider reasonable for a defined lookback: the FDIC required Sutton Bank to propose a CIP lookback plan within 60 days, and "Within one hundred and twenty (120) days … the Bank shall complete the CIP Lookback Review" (FDIC-23-0110b). Larger books take longer, which is why orders for them set milestones rather than a single date.
The tail is the part plans underestimate. On the sample programme 58% of members answered within 14 days; the rest go through reminders, a final notice and a decision, which takes up to 44 days from the first request before a limit can even be prepared. A plan that ends the week the last request goes out will run late by at least that long.
Report progress the way a regulator reads it
Report backlog progress as a burn-down against an approved plan line, by cohort and risk, with each counted file backed by evidence and a named approver. The Federal Reserve's 2024 order against Evolve Bank & Trust required "a plan, with intermediate timelines and milestones, to remediate deficient due diligence for existing" customers of its partner division (Federal Reserve, Evolve). Milestones are only meaningful if the count behind them is the count in the work queues, not a separate spreadsheet.
The burn-up after one batch decision: 61 days ahead of the plan line

Regulators have also written down the end state they expect. The OCC's 2022 order against USAA Federal Savings Bank required that suspicious activity investigations be current and "that any backlogs have been resolved" (OCC EA 2022-008). That order was about alert investigations, not KYC files, but the expectation carries: a backlog plan ends at zero, with a steady-state process that stops it rebuilding. The difference between remediation and periodic review is what that steady state looks like.
Who runs a backlog plan, and what each owns week to week
Today
Tracks the backlog in spreadsheets and finds out the rate slipped at month end.
With agents
Sees the burn-down by cohort every morning, with the day’s next step.
Still theirs: The plan line and the weekly rate.
Today
Reports a number to the board that nobody can trace to files.
With agents
Approves scope, owner batches and limits, and signs a board report drafted from the same numbers.
Still theirs: The commitment to the regulator.
Today
Re-read files after they close.
With agents
Check batches on a stated sample before anything is written.
Still theirs: The error definition.
Today
Learns about a letter wave from the phones.
With agents
Sets the weekly caps the plan’s outreach must fit.
Still theirs: The pace of the tail.
Five ways a backlog plan slips, and the early signal for each
Backlog plans rarely fail all at once; they slip a few percent a week in ways that are visible early if someone is looking at the right number. The useful discipline is to name, before week one, the signal that would show each kind of slip, and who acts on it.
Where backlog plans slip, the signal that shows it first, and the response
| How the plan slips | The early signal | The response |
|---|---|---|
| Checkers become the queue | Batches waiting for a checker for longer than the service level | Rebalance makers and checkers; keep the sample sizes, not the corners |
| Search closes less than the pilot showed | Share of files closed from records falling batch on batch | Find the system or cohort that changed; reconnect or rescope before writing to more customers |
| Customers answer more slowly than assumed | Share answering within the window below plan for two weeks | Simplify the request, change the channel, call before the final notice |
| The contact center saturates | Expected calls near the staffed level | Lower the weekly caps and move the plan line, openly |
| Quality falls | A failed sample, or returned strata in consecutive batches | Stop that cohort, review in full, fix the cause, then resume |
The last row is the one that protects the whole plan. A burn-down that keeps its slope by lowering quality will meet the examiner's sample before it meets its date, and the files will be counted twice: once as done, and again when they are reopened. Moving the plan line openly, with the reason, is cheaper than defending a count that is not true; the QA sampling guide sets out what a failed sample should trigger.
KYC backlog reduction with KYC Remediation: where it fits
KYC Remediation fits a backlog of thousands of existing files whose evidence is spread across systems the bank already runs. Its Gap Finder scopes and sorts the backlog by gap and risk; its Records Searcher closes what the bank's own records support, citing each line; batches go to a maker and a different checker on a stated sample; the Member Request agent paces the remaining requests; the Non-response agent prepares the tail's decisions; and the Program Forecaster keeps the burn-up against the plan line and drafts the board report.
Where the backlog stands today, in four cohorts, with the next step

It is not the right tool for a backlog of a few hundred files, where a skilled team can finish faster than any systems can be connected, or for a backlog whose evidence does not exist anywhere in the bank, where the work is almost all outreach. And it does not set the plan: the scope, the weekly rate and the commitment to the regulator are the bank's. To see the programme page, the batches and the burn-up together, start from KYC Remediation; to price the plan by the month, see an AML remediation plan priced by the month.
A batch approved: the count moves only when evidence is written

Questions people ask
What is KYC backlog reduction?
It is the work of bringing the number of overdue or below-standard customer files down to zero on a plan, and keeping it there. It combines scoping by risk, searching internal records before asking customers, batch approvals on a sample, and a decision for customers who never answer. The result is reported as a burn-down against a plan line.
Should we hire more analysts to clear a KYC backlog?
Only after measuring where the time goes. If most minutes are spent searching systems and writing letters, more analysts scale the slowest part of the work; agents can take those tasks. If the tail is customers who have not answered, more analysts will not shorten it at all.
How do we stop a KYC backlog from coming back?
Fix the front door first, so new customers are onboarded to the current standard, then keep files current as events happen. FinCEN's FAQs say there is no categorical requirement to update customer information on a schedule; the duty is risk based. The OCC's orders for TD and USAA both required event-driven updates.
What should the first week of a backlog plan produce?
An approved scope: which files are in, what evidence closes each gap, the order of work and the deadline. Without it, the pilot cannot be measured and the plan line cannot be drawn. On the sample programme the scope is versioned, and every closure cites the version it was tested against.
Can we clear a KYC backlog without contacting customers?
Partly. Files the bank's own records support can close without contact; on the fictional sample programme one search closed 3,982 business files that way. Files missing information nobody holds still need the customer, asked once, in plain words.