AML & fraud / Practical guide
Digital identity in customer onboarding: questions beyond the selfie
Assess what an identity check proves, where it can fail and how its result supports the wider customer due-diligence process.
Define the role of the identity check
Digital identity can support customer onboarding, but a successful screen result is not a complete customer due-diligence decision. Start by defining which part of the process the technology is intended to support and what evidence the organisation needs. Keep the decision about accepting a customer separate from the technical result returned by an identity provider.
FATF's 2020 Guidance on Digital Identity discusses how digital ID can support identification and verification within customer due diligence. It recommends considering the reliability and independence of the system and the relevant risks. [1] This article is a technology-evaluation guide, not jurisdiction-specific legal advice. Have the responsible compliance team confirm current local requirements and the permitted use of the proposed system.
Distinguish proofing from authentication
Identity proofing concerns establishing a person's claimed identity during enrolment. Authentication concerns confirming that a returning user controls the relevant credential. A product may combine these activities in one interface, but the evidence and failure modes are different. Ask the supplier to explain each component and the assumptions behind its result.
FATF's guidance considers assurance at the component level and relates the choice of assurance to money-laundering and terrorist-financing risk. It does not prescribe one universal assurance level for every use case. [1] Avoid accepting a broad “verified” label without understanding the underlying process, coverage, limitations and evidence available to the relying organisation.
Examine evidence rather than demonstration quality
Ask which identity evidence and document types are supported, where the service operates and how unsupported cases are handled. Request information about relevant independent assessments and the scope and date of any claimed certification. Verify that the evidence applies to the product configuration being purchased rather than a different service or historical version.
Evaluate performance with an appropriate, authorised test set that reflects the intended customer population and devices. Look at unsuccessful attempts and manual-review outcomes as well as successful completions. A smooth demonstration with a small selection of easy cases does not establish performance for customers with older devices, poor connectivity or difficult-to-read documents.
Design the exception path before launch
Some legitimate applicants will not complete the standard workflow. Define a supported alternative or review process consistent with applicable requirements. Make the reason for referral understandable to the staff handling it, without exposing sensitive security logic unnecessarily. Record who can override a result and what evidence is required for that decision.
Treat accessibility and customer support as part of the design. Test instructions, retry behaviour and abandonment points with realistic users. Avoid repeatedly collecting the same sensitive material because the application has lost track of a previous attempt. A clear status model can distinguish a pending review from a failed check and prevent accidental duplicate submissions.
Integrate the result into the wider process
Document how an identity result is associated with the correct application and customer record. Validate callbacks and other provider messages according to the integration design, and handle retries safely. A late response should not silently overwrite a newer decision. Preserve enough context to understand which provider result supported an onboarding action.
Map the remaining due-diligence steps with the compliance owner. Depending on the customer and applicable requirements, other information and checks may be necessary. Do not allow a technical identity status to bypass those steps automatically. Make the final decision, relevant evidence and unresolved issues visible to the authorised reviewers who are accountable for the process.
Govern data and ongoing supplier changes
Decide what information must be retained, where it will be stored and who may access it. Confirm applicable privacy, retention and cross-border handling requirements with the responsible specialists. Assess the supplier's use of subprocessors and the practical process for deleting or exporting data when the relationship ends.
Monitor changes to coverage, configuration and assurance evidence. Reassess the workflow after a material provider change or a pattern of unexplained failures. Evo's AML Consultation service can help connect technology selection with a structured due-diligence workflow. Bring the customer types, jurisdictions and existing onboarding process so the discussion addresses the actual decision the organisation needs to make.
Frequently asked questions
Does a successful identity check complete AML due diligence?
No. Its role must be assessed within the wider due-diligence process and the requirements applicable to the customer and jurisdiction.
Should every failed automated check mean rejection?
Define compliant referral and alternative processes with the responsible team. A failed automated attempt can have several causes and should be handled under an approved policy.
Sources & further reading
Primary sources checked on 2026-10-18. The implementation checklists are editorial recommendations; source publications retain their original dates.
