Banks should design one verification architecture that serves both AMLR customer due diligence and eIDAS 2.0 wallet acceptance. That means aligning data models, evidence provenance, and assurance rules before implementation begins. If those controls are built separately, the institution usually pays twice in integration, testing, and change management.
Why one verification architecture beats two parallel programmes
Banks should treat AMLR customer due diligence and eudi wallet acceptance as two uses of the same trust decision, not as separate operating models. The practical question is whether the institution can verify a person, retain evidence of that verification, and rely on it consistently across onboarding, re-verification, and wallet-based journeys. If the answer is yes, the architecture can usually be shared.
The common mistake is to separate the policy layer from the evidence layer. AMLR asks for defensible customer due diligence, while wallet acceptance asks the bank to trust external identity assertions under eIDAS 2.0. Those are different regulatory drivers, but they converge on the same design problem: how the bank validates identity, records provenance, and decides what level of assurance is sufficient for a given transaction or relationship.
That is why banks should design the trust model first and the channel second. If the institution defines one evidence schema, one provenance model, and one assurance policy set, it can map both AMLR and wallet inputs into the same verification service instead of duplicating controls in separate programmes. The wallet then becomes one acceptance path into the broader customer due diligence architecture, not a parallel stack with its own bespoke logic.
Where integration usually breaks down
Separate programmes tend to diverge in the places that matter most: attribute normalization, evidence retention, exception handling, and control ownership. A wallet journey may produce high-quality assertions, but if the bank cannot reconcile those assertions with its KYC records, transaction monitoring triggers, and case management workflow, the result is extra manual work rather than real simplification.
This is also where external legal and technical references need to line up. The EU’s eIDAS 2.0, EU Digital Identity Framework sets the wallet context, while the bank’s customer due diligence programme must still satisfy its own verification and recordkeeping duties. A single architecture should therefore preserve the source, timestamp, and assurance basis for each identity event so auditors can see why a bank accepted a credential or rejected it.
Implementation pain usually appears when teams build two distinct evidence stores, two rule engines, or two reviewer queues. That creates duplicated integration with onboarding systems, duplicated testing of edge cases, and two change calendars whenever a rule changes. A unified design reduces those collisions because the same evidence can be consumed by both fraud and compliance workflows.
What the target operating model should look like
Start with a shared decision layer that answers three questions: who was verified, how they were verified, and what the bank is permitted to rely on from that proof. Once those questions are common, AMLR and wallet acceptance can differ only at the policy threshold level, not in the underlying mechanics. That is the design pattern that prevents two programme teams from solving the same problem twice.
In practice, banks should align data models around stable identity attributes, assurance metadata, and provenance markers. They should also define which evidence can be reused, which evidence must be refreshed, and which scenarios force a new check even when the wallet is present. The goal is not identical treatment of every journey, but consistent treatment of the same underlying identity fact.
That alignment becomes easier when the institution treats wallet acceptance as a controlled verification channel rather than a shortcut around due diligence. The bank still owns the risk decision, even if the wallet supplies the proof. For that reason, the control design should keep human review available for exceptions, high-risk customers, and ambiguous evidence chains.
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, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 and GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL — Identity Assurance Levels | Wallet acceptance and customer due diligence both depend on assurance strength. |
| Recommendation — Map both journeys to a shared assurance scale before accepting reusable identity evidence. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The bank must define consistent authorization and reliance rules for identity evidence across programmes. |
| Recommendation — Set one access and reliance policy for identity evidence used in AMLR and wallet acceptance. | ||
| GDPR | A.5.1 — Lawfulness, fairness and transparency | Identity verification architectures process personal data and need clear lawful, transparent handling. |
| Recommendation — Document how identity evidence is collected, used, and retained across both journeys. | ||
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Banks must verify external customers and rely on proofing evidence from outside the institution. |
| Recommendation — Use one external-user authentication and proofing control path for both AMLR and wallet use. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Wallet-based verification flows typically depend on federated identity and token handling. |
| Recommendation — Verify that wallet-based login and assertion flows share one tested federation design. | ||
Practitioner Guidance
What to prioritise: Build the identity proofing, evidence provenance, and assurance policy layer once, then map both AMLR and wallet use cases onto it. If those pieces are designed separately, the bank will spend more time reconciling records than improving customer experience.
What to verify: Confirm that one evidence record can support onboarding, refresh, audit, and exception handling without rekeying data into a second programme. If a reviewer has to compare two incompatible versions of the same identity fact, the architecture is already too fragmented.
Decision rule: If a wallet assertion can be represented in the same evidentiary format as other KYC inputs, reuse the control path; if not, treat the gap as a modelling problem to fix before rollout, not as a reason to create a separate programme.
Practitioner takeaway: The bank should optimise for one trust fabric with multiple entry points, not two policy islands that later need costly reconciliation.
Related resources from NHI Mgmt Group
- How should banks design EUDI Wallet programmes if they want to issue reusable credentials?
- What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
- How should banks prepare for EUDI wallet acceptance in regulated journeys?
- Why do eIDAS and the EUDI Wallet matter for KYC programmes?