AMLR onboarding: are your identity checks actually fail-safe?

TL;DR: AMLR remote onboarding can be completed through recognised eID schemes, the EUDI Wallet, or QTSP-led document verification, according to IDnow, and single-route flows create avoidable failure points when one method is unavailable. The governance problem is not choosing one path over another, but keeping compliant routes open so verification can continue when device, document, or risk conditions change.

Editorial analysis by NHI Mgmt Group, based on content published by IDnow: “How adding versatility in your user onboarding flow can help in the context of AMLR identity verification”.

Key questions

Q: How should organisations design AMLR onboarding flows that do not fail when one identity method is unavailable?

A: They should build orchestration around multiple compliant routes, not a single verification method.

Q: Why does QTSP-led identity verification matter under AMLR if wallet-based onboarding is mandatory?

A: Because mandatory wallet acceptance does not make the wallet the only usable route.

Q: What breaks when an onboarding flow depends on one verification option only?

A: The flow becomes brittle.

Practitioner guidance

• Map every remote onboarding route Document the accepted eID, EUDI Wallet, and QTSP-led IDV paths, then define when each path is eligible and who approves exceptions.
• Design failover between IDV methods Ensure the same onboarding session can move from NFC to optical review or video without restarting the process or losing evidence.
• Set assurance rules by risk segment Use device capability, document type, and session risk to decide when to keep automation and when to escalate to human review or video.

Bottom line: AMLR remote onboarding should be built as a multi-route identity flow, because a single verification method creates avoidable failure points.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →