KYC and onboarding automation

Start by measuring the queue, not the model

Nearly every onboarding automation project we are asked about starts in the same place: someone has been told that a model can decide who to approve, and they want to know what it costs. That is almost never the constraint. In a consumer program, the verification vendor already returns a clean pass on the large majority of applicants within a few seconds. The pain is concentrated in the minority who fail, and in a manual review queue staffed by people who spend most of their day re-reading a driver's licence photograph taken in a parked car. The model is not the bottleneck. The exception path is.

So before anything else, get four numbers for the last full quarter. How many applications started. How many completed. How many cleared automatically. How many landed in manual review, and how many analyst minutes each of those consumed. Most teams can produce the first three from the application platform in an afternoon. The fourth is usually a guess, because review work happens in a case tool that records when a case opened and closed but not what happened in between, and because analysts hold several cases at once. If you cannot state your review minutes per case within a factor of two, you cannot evaluate an automation proposal, because every claim it makes is denominated in that number.

The ranges we see are wide and worth stating plainly. Consumer digital account opening loses a meaningful fraction of starts before submission, commonly a fifth to more than a third depending on how much the form asks for and whether a document upload is required. Automated clearance on first pass for a general consumer population usually sits somewhere in the high eighties to mid nineties. Manual review typically catches five to twenty percent of submitted applications. A review case runs ten to forty minutes of analyst attention, more when a document has to be re-requested and the clock restarts. Your numbers will differ. The point is that they exist and that nobody has looked at them recently.

Three decisions live in onboarding, and only one is a model

Teams talk about onboarding as a single decision. It is three, they have different owners, and conflating them is how projects end up unshippable.

Is this person who they say they are. An identity assertion, checked against records and documents. Largely mechanical, largely already automated, and the place where vendor selection matters more than anything you build.

Is this person someone we are prohibited or unwilling to serve. A screening and policy decision. Name matching against lists, plus whatever your own policy excludes. Automatable in the matching step, never automatable in the disposition step, because clearing a possible match is a judgement your compliance function owns and must be able to defend years later.

How much risk does this relationship carry, and what do we do about it. A rating that drives monitoring intensity, refresh cadence and sometimes pricing. This is the one that looks most like a model and is the one where automation buys the least early value, because the rating rarely changes what happens on day one.

Decision	What automation can own	What it cannot	Who signs
Identity Is the applicant real and themselves	Document capture, data extraction, cross-field agreement, retry guidance	Accepting a document that is genuinely unreadable	Nobody. It clears or it escalates
Screening List and policy exclusions	Matching, scoring, deduplication, grouping repeats of the same alert	Disposition of a possible match	A named reviewer, on the record
Risk rating Monitoring intensity and refresh	Assembling inputs, applying the written policy consistently	Changing the policy because the data suggests it	Compliance, under a documented methodology
Business ownership Who ultimately controls the entity	Reading formation documents, building the ownership graph, flagging gaps	Deciding a chain is complete when a layer is offshore and opaque	A reviewer, with the graph attached

Write those four rows for your own program before you write a specification. In our experience the exercise reassigns about half the scope, usually away from the risk model and toward capture and evidence.

The document is the problem, and it is fixable

Follow ten stalled applications end to end and most of them stall on a document. A photograph of an identity card with the flash reflecting off the hologram. A utility bill in a spouse's name. A bank statement uploaded as a screenshot of a phone screen. A formation certificate scanned as a fax from 2011. Each one becomes a request back to the applicant, a two to five day wait, and a real chance the applicant never returns.

The intervention that pays is not a better extraction model at the back. It is a capture step at the front that refuses a bad image while the applicant still has the document in their hand. Check focus, glare, corner detection, resolution and whether all four edges are inside the frame, and say what is wrong in one plain sentence. Retake now costs the applicant eight seconds. Retake tomorrow costs you the applicant. Every serious mobile capture library does this and the difference between a program that uses it and one that does not shows up immediately in completion rate.

Behind capture, extraction should be boring and checkable. Read the fields, then check them against each other and against what the applicant typed: does the name on the document agree with the application, does the expiry date fall in the future, does the address parse. Disagreement is information. It routes to review with a specific reason rather than a general one, which is the difference between a two-minute case and a twenty-minute case.

Note what that shape implies. The work an executive imagines buying a model for is the smallest slice. The three larger slices are all mechanical, and mechanical work is what software is good at.

Screening: you are paying for the false positives

Name screening against sanctions and watch lists is a matching problem with an unusual cost structure. A missed true match is unacceptable, so thresholds are set loose, so the alert volume is enormous and nearly all of it is noise. Programs routinely clear the overwhelming majority of alerts as not-the-person, and it is common for that figure to sit above ninety percent. Nobody wants to tighten the threshold, because the person who tightens it owns the miss.

That means the honest goal is not fewer alerts. It is fewer analyst minutes per alert, with the same recall. Four things do that, and none of them require touching the matching threshold.

Deduplicate across time. The same customer generates the same alert on every rescreen. If it was cleared with a documented reason and nothing about the customer or the list entry has changed, it should surface as a previously cleared match with the prior reasoning attached, not as a new alert. This alone often removes a large share of recurring volume.

Group by list entry. Forty customers matching one common name against one list entry is one piece of reasoning, not forty. Present them together.

Put the discriminating fields on the screen. Most alerts are cleared on date of birth, country, or a middle name. If the analyst has to open three systems to find those, that is the cost. Assemble them into the alert.

Write the reason down in a structured field. Not free text. A reason code plus the specific fields compared. This is what makes the next rescreen cheap and what makes the file defensible.

A language model is genuinely useful in one narrow place here: summarising a long adverse media article into a paragraph that says who the article is about and what it alleges, with the sentences it drew from linked. It is not useful for deciding the match. Keep it on the reading side of the desk, never the deciding side.

Business accounts are a different product wearing the same name

Consumer onboarding is a form and a document. Business onboarding is a graph. You need the entity, its formation documents, its control person, and the individuals who ultimately own it, which may sit two or three layers up through holding companies in several jurisdictions. Days to weeks is normal, and the long pole is almost always waiting for a human on the customer side to produce a document their lawyer has and they do not.

What actually helps: a portal that shows the applicant the ownership graph as it is being built, with the gaps marked, so they can see exactly what is still missing and who has it. Ask for everything you can compute from what you already have rather than asking again. Read the formation and operating documents to propose the structure, then have the applicant confirm or correct it, which turns a blank questionnaire into a review task. Confirming a structure someone else drafted is several times faster than describing it from scratch, and the corrections are informative.

What does not help: applying the consumer flow to a business and being surprised. The failure is not technical. It is that a sole proprietor and a fund with a Cayman feeder have been handed the same wizard.

How straight-through rates get inflated

Every vendor quotes a straight-through processing rate and almost none of them define the denominator. Four common inflations, in rough order of how often we find them:

Counting only submitted applications. If a third of starts abandon at the document step, and the abandoners are exactly the hard cases, the rate on submissions flatters the system by exactly the amount that hurt you most.

Counting a pass on the easy population. Salaried applicants with a decade at one address and a thick credit file clear anywhere. The interesting question is the rate on recent movers, thin files, young applicants and applicants whose name does not fit an English-language parser. Ask for the rate on each of those.

Counting cases that cleared after a manual retry. If an analyst re-ran the check with a corrected address and it passed, that is a manual case wearing an automatic label.

Counting a decision that was later reversed. A clean pass that becomes an exit thirty days later is not straight-through. It is a deferred manual review with extra steps and a customer who is now angry.

Ask for the rate with the denominator written out, broken by those populations, over a stated period. A vendor who cannot produce that in a week does not measure it either.

What we would not automate

• The disposition of a possible list match. A person clears it, records why, and owns it
• Declines with no reason path. If the system cannot say what failed, a human has to look
• Anything where the training labels are your own past decisions and nobody has checked whether those decisions were right
• A rating that silently changes monitoring intensity with no record of which inputs moved it
• Document acceptance when extraction confidence is low, dressed up as a pass because the queue is long
• The exit decision on an existing customer. Different stakes, different evidence, different owner

There is also a case for doing nothing. If you open a few hundred accounts a month, your review queue is two people, and neither is drowning, an automation programme will cost more than it returns for several years. Fix the capture step, buy the vendor's alert deduplication if it exists, and spend the money elsewhere. We have told prospective clients this and it remains the correct answer more often than the industry admits.

What a first build actually looks like

Step two is the one that gets cut and the one that determines whether the rest is aimed correctly. Reading a hundred cases takes two days and reliably overturns at least one thing everybody believed. In one common example, a team is certain their queue is driven by address mismatches, and the cases show it is driven by a single document type that their capture step compresses too aggressively before upload.

Before you sign anything

• You can state started, completed, auto-cleared and reviewed for a full quarter
• Review minutes per case are measured, not estimated
• Every vendor rate comes with its denominator and a breakdown by hard population
• The evidence file is specified before the workflow is
• Every automated step can explain the reason it produced, in a field a program can read
• Screening dispositions stay with a named person and the reason is structured
• Policy and rule versions are recorded on every decision
• There is a defined path to switch a step back to manual without a release
• Someone owns re-measuring the four numbers ninety days after go-live

Bottom line

Onboarding automation pays when it is aimed at mechanical work: capturing a usable document the first time, not asking the same question twice, not re-reasoning an alert that was cleared last quarter, and assembling the evidence file as a matter of course rather than as an emergency. It pays much less when it is aimed at replacing the judgement in the middle, both because that judgement is a small share of the minutes and because someone has to own it in a room where the software is not present. Measure the queue, read a hundred cases, fix the capture step, and only then decide whether you need a model at all.

Frequently asked questions