Because mandatory wallet acceptance does not make the wallet the only usable route. QTSP-led document verification is a valid compliant path in its own right and often the one customers will actually use. Teams that treat it as a fallback only are building a narrower control than the regulation allows.
Why the wallet mandate does not collapse AMLR onboarding into a single path
Wallet-based onboarding can be mandatory at the point of acceptance without becoming the only compliant identity route in practice. Under AMLR, the control question is whether the provider can complete reliable customer due diligence, not whether every applicant must use one specific front door. QTSP-led identity verification matters because it remains a regulated, evidentiary path that can satisfy the verification need when the wallet is unavailable, unsuitable, or simply not the route the customer can complete first.
That distinction matters operationally. A wallet-first design often assumes universal uptake, but regulated onboarding usually has to handle people who lack a compatible wallet, struggle with setup, or need a different trust service to complete proofing. If teams hard-code wallet acceptance as the only route, they create avoidable drop-off and a narrower control than the rule actually requires.
QTSP-led verification also changes the assurance discussion. Wallet presentation may prove a usable identity credential, but the onboarding decision still depends on how the provider validates the person, the document, and the evidence chain behind that verification. In a regulated onboarding flow, the method matters less than whether the method produces defensible, auditable assurance that supports the AML/KYC decision.
For an operationally useful overview of the identity proofing side of this problem, see Identity Proofing and KYC Guide. For teams comparing identity routes and evidence quality, the Identity Verification Buyer’s Guide helps frame what document checks, liveness checks, and fraud signals contribute to a compliant onboarding decision.
Where QTSP evidence fits in the onboarding control stack
QTSP-led verification sits in the evidence layer of onboarding, not as a convenience feature. It is one way to establish the customer identity that the AML/KYC process needs, especially when the wallet is only the delivery mechanism for credentials or attributes rather than the whole compliance process. That is why the control design should separate “wallet required” from “wallet exclusive”.
This is also where document verification, identity proofing, and trust services converge. A QTSP can support higher-confidence verification because the provider is operating within a recognised trust-services model, which is useful when the onboarding decision must stand up to audit, disputes, or later review. The practical question is whether the organisation has mapped each acceptable evidence path to the same standard of recordkeeping and reviewability.
For the regulatory backdrop, the eIDAS 2.0, EU Digital Identity Framework shows why wallet ecosystems and trust services have to be treated as complementary parts of the same identity fabric. On the AML side, the FATF Recommendations, AML and KYC Framework remains the clearest baseline for customer due diligence, verification, and ongoing risk-based controls.
How to avoid turning a compliant option into a broken journey
The main implementation mistake is to treat “wallet-based onboarding mandatory” as a product decision that overrides the compliance model. In practice, the onboarding policy should define which evidence paths are acceptable, what fallback is allowed, and how the system records that the verification was completed through a permitted route. If the QTSP path is available but hidden, or the customer journey silently rejects it, the organisation may be compliant on paper and brittle in production.
There is also a governance issue. If wallet and QTSP paths produce different internal handling, teams should be able to explain why, and they should test that both paths land on the same customer-risk decision rule. The control should not depend on whichever route a customer happened to choose first. It should depend on whether the identity evidence is sufficient for the regulated onboarding outcome.
For teams building the policy and control logic, the EBA AML/CFT Guidance is the right external reference for the supervisory expectations around AML controls, while the Digital Identity, eID and Identity Wallets Guide is useful for understanding how wallets, verifiable credentials, and trust frameworks interact in real onboarding flows.
Risk and Threat Considerations
When organisations collapse the onboarding journey into one mandatory wallet path, the main risk is control fragility. Customers who cannot complete that path may be blocked unnecessarily, or they may be pushed into manual workarounds that are less consistent and harder to audit. A second risk is assurance drift, where teams assume the wallet itself guarantees identity quality and stop distinguishing between credential presentation and identity verification.
Failure mechanism: The organisation treats wallet acceptance as the only valid evidence path, so valid QTSP-led verification never reaches the onboarding decision or is handled ad hoc outside the intended control design.
Impact: Onboarding becomes narrower than the regulation allows, conversion drops, exceptions proliferate, and the provider may lose the ability to demonstrate a clear, repeatable due diligence process.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS, NIST SP 800-63 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | QTSP-led onboarding verifies external customer identity evidence. |
| Recommendation — Use IA-8 to require approved identity evidence before account creation. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Wallet-based onboarding commonly depends on federated identity flows and credential presentation. |
| Recommendation — Validate wallet-facing authentication and federation flows under V10. | ||
| NIST SP 800-63 | IAL2 — Identity Assurance Level 2 | QTSP-led proofing is an assurance-level question about verified identity. |
| Recommendation — Map onboarding evidence to the required assurance level before acceptance. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The question is about choosing acceptable identity proofing and access-entry routes. |
| Recommendation — Define which onboarding evidence paths satisfy identity proofing and access control. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | The onboarding choice affects how identities are established and governed. |
| Recommendation — Document approved identity establishment paths in the ISMS. | ||
Practitioner Guidance
What to verify: Confirm that policy, customer journey, and case-handling rules all recognise QTSP-led verification as an approved route, not a manual exception. Then verify that both wallet and QTSP evidence are mapped to the same onboarding decision criteria and audit record.
Decision rule: If the wallet is mandatory for delivery or convenience, keep it mandatory there, but do not make it the sole acceptance gate unless the regulation or your own policy explicitly requires that narrower design.
Practitioner takeaway: The compliant design is the one that preserves multiple acceptable proofing routes while keeping the assurance standard consistent, not the one that forces every customer through the same front end.
Related resources from NHI Mgmt Group
- What is the biggest onboarding mistake with wallet-based identity verification?
- How should e-signature providers prepare for wallet-based identity verification under eIDAS 2.0?
- Which compliance controls matter most for digital identity verification under eIDAS 2.0?
- Why do phone-based identity signals matter in challenger bank onboarding?