They ask the customer to do the hard part of verification themselves. That means finding a document, photographing it clearly and passing a facial scan, each of which can fail for ordinary reasons such as lighting, framing or retries. Every failure adds friction at the point where the applicant is most likely to quit.
Why the user has to do the work
Document and selfie checks shift part of the verification burden onto the applicant, which is where abandonment often starts. The user has to find the right document, capture a usable image, and complete a face match under whatever device, lighting, and environment they happen to have at that moment. Each extra step increases the chance of failure before the user reaches approval.
That friction is structural, not accidental. A check that depends on camera quality, document condition, scan quality, and user patience will always be more fragile than a passive signal such as an existing account or previously trusted device. When the process forces retries, it turns verification into a task the customer experiences as work rather than progress.
Why small errors become drop-off
The abandonment problem is rarely caused by one dramatic failure. It is usually the accumulation of ordinary ones: glare on the document, cropped edges, mismatched names, a face that does not align on the first attempt, or a session timing out while the user looks for better light. Those failures are common enough that they should be treated as expected friction, not edge cases.
Good teams watch for where the process breaks, not just whether it succeeds. If most drop-off happens during capture, the problem is usually usability and instruction quality. If it happens after a failed match or repeated retry, the issue is often tolerance settings, device compatibility, or a workflow that gives the user too little feedback to recover quickly.
How to reduce abandonment without weakening verification
The best fix is usually to reduce the amount of effort demanded at the hardest moment. That means telling users exactly what document is acceptable, showing clear capture guidance before the camera opens, and limiting unnecessary retries that make the process feel broken. If the flow cannot be shortened, it should at least be predictable and forgiving.
Verification also works better when organisations treat fallback as part of the design. If a selfie check fails, there should be a path that does not force the user to restart from zero, such as a different verification method or a support-assisted recovery path. In practice, a shorter, clearer journey often improves completion more than a stricter one.
Risk and Threat Considerations
High abandonment creates a business risk because it removes legitimate users before they finish onboarding, but it can also distort the control itself. When a process is too frustrating, users may reuse poor images, rush through prompts, or seek workarounds that reduce assurance quality.
Failure mechanism: The check depends on user performance at a sensitive point in the journey, so ordinary capture errors, device limits, and repeated retries cause friction that compounds until the user leaves.
Impact: Organisations lose conversions, push users toward support channels, and may end up trading away assurance if the flow is loosened too much in response to drop-off.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL — Identity Assurance Levels | User-facing identity proofing flows depend on assurance level and recovery design. |
| Recommendation — Match the verification journey to the assurance level you actually need. | ||
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Document and selfie checks authenticate external users during onboarding. |
| IA-12 — Identity Proofing | The flow is an identity-proofing exercise, not just a login step. | |
| Recommendation — Use suitable external-user authentication controls that minimize unnecessary friction. Document acceptable proofing evidence and recovery paths before users begin. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Verification gates access to a service and should be controlled consistently. |
| A.5.16 — Identity management | Onboarding checks establish who the user is before access is granted. | |
| Recommendation — Define and enforce access conditions that are clear to applicants. Align onboarding checks with the identity lifecycle and recovery process. | ||
Practitioner Guidance
What to prioritise: Measure where users abandon the flow, then separate capture failure, match failure, and timeout failure. Those are different problems and they usually need different fixes.
What to verify: Confirm that the instructions are understandable on a small screen, the acceptable-document rules are obvious before capture begins, and error messages tell the user what to change instead of merely saying the check failed.
What good looks like: A user can complete the check in one pass on a typical phone without needing support, with a fallback path available when the primary method fails.
Practitioner takeaway: The goal is not to make verification effortless, it is to make the necessary friction precise, explainable, and recoverable enough that honest users do not quit midway through it.
Related resources from NHI Mgmt Group
- Why does document plus selfie verification create stronger assurance than simpler age checks?
- Why do fragmented identity, device, and application records create so much risk during compliance checks?
- When should organisations use digital credentials instead of document capture and selfie checks?
- Why do missing token audience and object ownership checks create so much risk in API flows?