Half your applicants abandon onboarding before they finish. How do you fix that without lowering identity assurance?

Find out what the number is made of

A single abandonment figure is not actionable, and acting on it is how programmes get worse. The first job is to split it three ways at every step: applicants who left of their own accord, applicants the system declined, and applicants routed to a human and never resolved. These are three unrelated problems. The first is a design problem, the second is a policy and model-tuning problem, and the third is an operations problem that usually turns out to be the largest single bucket once you look, because a referral queue with no service level is indistinguishable from a rejection from the applicant's side.

Then instrument by step and by cohort. Time on step, retries within step, device and channel, and completion rate broken down by segment: thin-file applicants with little credit history, recent arrivals to the country, older applicants, applicants on low-end handsets or poor connections, applicants whose names do not transliterate cleanly into your forms. An aggregate rate improves whenever you get better at serving the easiest cohort, which is precisely the population you did not need to help. Reporting the distribution rather than the mean is what turns a conversion project into an access one.

Order the journey by cost and yield

Most onboarding flows are a fixed pipeline: collect everything, then run every check. That guarantees the maximum amount of applicant effort before the first decision, and it spends money on document capture and biometrics for applicants a database match would have cleared in a second.

The better shape is orchestration. Run the cheap, low-friction, high-coverage checks first — a match against independent reference sources, screening, device and network signals — and let their outcome select what happens next. Applicants who clear comfortably finish without ever opening the camera. Applicants with a weaker or partial result step up to a document check and a selfie. Applicants who fail that step up again to a human or to a branch. The assurance requirement never moves; what moves is how much effort each applicant has to spend to reach it, and the aggregate friction falls because most people take the short path.

Cascading matters at the same layer. A single vendor returning no-match is not a fact about the applicant, it is a fact about that vendor's coverage of that population. Retrying against a second source before declining recovers real customers, and the cascade order is a business decision you can tune with evidence: for each provider, coverage by segment, accuracy, latency and price.

Reuse what the applicant has already handed over

Every field an applicant retypes is a chance to leave. Read the address, name and date of birth from the document you already captured and ask them to confirm rather than enter. Where the market has a reusable identity — a state-backed digital identity scheme, a bank-based identity network, a certified private provider, a government data-sharing service — accepting an assertion from it removes the entire document step for the applicants who have one. The available options differ sharply between markets, and so does what the assertion actually covers, which is the important caveat: an identity assertion may satisfy the existence and ownership parts of verification while leaving screening, source-of-funds enquiry and your own risk assessment entirely with you. Treating a reusable identity as "KYC done" is the mistake to avoid; treating it as strong, reusable evidence with recorded provenance is the point.

Resumability is the other half. Applications must survive a closed browser, a switched device and a returning applicant next week, which means saved partial state keyed to something they can re-present, and a resumed session that does not re-collect what has already been verified. Evidence does have freshness rules — a screening result from three weeks ago is not the one you want to rely on at account opening — so the rule is to keep collected artefacts and re-run the cheap, stale checks silently on resumption.

Make the failure paths part of the product

The screens nobody designs are the ones that determine the number. An applicant whose automated checks did not pass should not see a generic decline. They should see what is needed next, in plain language, with a route to provide it — a different document, a video call, a branch appointment, a certified copy by post. Where a regulation constrains what you may tell someone, that constrains the reason you give, not whether you offer a route.

The referral queue is a product surface too. It needs a target time, an owner, a visible position for the applicant, and pre-gathered context for the agent so the case is decided rather than investigated from scratch. A queue whose age profile is not on anyone's dashboard converts silently into lost customers who believe they were rejected.

Where the regime permits it, staged or limited-functionality opening is the strongest lever available: open the account with constrained capability — capped balance, capped payments, restricted counterparties, no international activity — and lift the constraints as verification completes. This turns a binary gate into a gradient, and it aligns the friction with the risk the account can actually carry. Whether it is permitted, and what the constraints must be, varies considerably between markets, so it is a question to ask the compliance function early rather than a design to assume.

Conversion metrics lie unless you pair them

Here is the move that separates someone who has run this from someone who has read about it. Almost any conversion target can be hit by loosening a threshold: lower the face-match score you accept, relax the liveness sensitivity, accept a weaker document result, auto-approve the referral queue when it grows. All of these show up immediately as a conversion win in the same reporting period, and they show up as fraud losses, remediation programmes and regulatory findings one to three quarters later, by which time the change has been attributed to a good quarter and nobody links the two.

So every conversion change ships with a cohort tag and a paired downstream measure on that cohort: confirmed application fraud, first-party fraud, accounts closed for financial-crime reasons, mule indicators, and how many files a later quality review found to have insufficient evidence. The assurance level is the invariant. A change that reaches the same assurance with fewer steps is an improvement; a change that reaches a lower assurance with fewer steps is a deferred loss, and the only way to tell them apart is to keep looking at the cohort after the release notes are written.