KYC backlogs are rarely a staffing problem
Imagine an e-money firm with 3,000 applications in its onboarding queue and a median of nine days from submission to decision. The request that reaches the COO is for six more analysts, and it will probably be approved.
Before signing it, take one week of decided applications and work out how long each one was actually being worked on. In a queue like this the answer is often measured in minutes: perhaps 40 minutes of analyst time spread across nine days of elapsed time. The rest is waiting. The numbers here are illustrative, but ask your own case management system and you may find something close.
More analysts shorten the queue only if analyst time is what applications are waiting for. Usually they are waiting for something else, and adding people makes several of those waits longer.
Where the nine days go
Follow one application. It arrives on Monday evening with a passport photo that cuts off the machine-readable line and a bank statement dated four months ago as proof of address. It sits in the queue until Wednesday. An analyst opens it, spends eight minutes and sends a request for information that says "proof of address insufficient". The customer reads it on Thursday, can't tell what is wrong with the statement and uploads the same one again. The case rejoins the queue. On Monday a different analyst picks it up, spends ten minutes re-reading the file to work out what the first one wanted, and sends a clearer request. The new document arrives Tuesday. A screening alert on a common name goes to a second reviewer, who clears it a day and a half later. Decision on day nine.
Total analyst time: around 40 minutes, and roughly half of it was rework. Re-reading a case somebody else started, writing a second request because the first one was too vague, re-checking a document that was wrong the first time.
Now add six analysts to that process. New people are less sure of themselves, so they send more requests for information and escalate more cases for a second opinion. The experienced analysts who would have closed cases spend their week answering questions and reviewing other people's work. Six people also interpret "insufficient" six ways, so two similar applicants get different answers and one of them complains. For the first few months the queue can grow.
It helps to count open cases by how long they have been waiting and on whom, the same way we would age unmatched reconciliation items. A case waiting on a customer is a communication problem. A case waiting on you is a capacity or routing problem. Most systems record both as "pending", which is why the distinction gets lost.
Hiring into a queue full of rework mostly gives you more people doing rework.
What to change before you hire
-
Stop incomplete applications at submission
Check document type, expiry date and image quality while the customer is still in the flow, and don't let the form submit without the documents your policy requires. Every problem caught at this point is one round trip that never happens.
-
Write requests and rejections a customer can act on
Keep a short library of reasons, each naming the document that would resolve it. "Please upload a utility bill or bank statement dated within the last three months, showing the address on your application" is far more likely to get a usable reply than "proof of address insufficient".
-
Triage by risk when the application arrives
Clean, lower-risk applications go to a fast lane with the level of review your risk policy allows for them. Corporate structures, higher-risk jurisdictions and screening matches go straight to experienced analysts. Agree the rules with your MLRO and write them into the policy, so the fast lane is a documented decision with a control behind it.
-
Cap the cases an analyst can have open
Set a limit, then hold to it. A case waiting on the customer doesn't count against the cap, and when the reply comes it returns to the same analyst, so nobody re-reads a file from the beginning.
-
Record waiting and working as separate statuses
Split "pending" into waiting on customer, waiting on us and in review. Report the median of each next to the queue size every week, and watch which one moves when you change something.
If your case tool can't hold those statuses, a manual sample works. Take 50 decided cases, put the timestamps in a spreadsheet and add a column for who the case was waiting on at each step. Two weeks of that is enough to see the shape of the problem, and it costs one analyst a few hours.
When the number does justify hiring
Give the changes a month or two and look again. If analysts are now busy for most of the elapsed time, the queue is a capacity problem and you have a much better case for headcount than you had before. You can say how many cases an analyst closes in a day when work arrives complete, what that rate does to the median decision time, and how many people a forecast of 4,000 applications a month would need.
Rework has one more cost that never appears in the staffing model. Every extra round trip is a day the customer spends wondering whether to try a competitor, and the applications that drop out are rarely the risky ones. The analyst who has been on that queue longest can usually tell you which of the changes above would matter most. Ask them before you write the job specs.
Discuss your operations
