TL;DR: European banks face a converging set of EUDI wallet obligations under eIDAS 2.0, AMLR and the emerging PSR/PSD3 text, with voluntary wallet acceptance for strong customer authentication due by 24 December 2027, according to OneSpan. The unresolved issue is not whether banks must adapt, but how they will govern authentication assurance, outsourcing boundaries and fraud accountability as wallet diversity expands.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on OneSpan's blog post: eIDAS 2.0, AMLR and PSR/PSD3 are pushing European banks toward EUDI wallet support for onboarding and strong customer authentication, while leaving important governance questions unresolved.
Why it matters: It matters because identity teams must align customer onboarding, authentication assurance and third-party accountability before wallet support becomes a regulatory expectation rather than an implementation choice.
Context
European banking identity is moving from document-centric onboarding and app-based authentication toward wallet-mediated identity assurance. The key question is no longer whether EUDI wallets will appear in customer journeys, but how banks will govern trust, assurance and responsibility across onboarding and strong customer authentication.
For IAM and fraud teams, the difficult part is the regulatory overlap. eIDAS 2.0, AMLR and the evolving PSR/PSD3 text all point toward wallet support, but they do not yet resolve the operational boundary between bank-controlled authentication and wallet-provider participation.
Key questions
Q: How should organisations prepare to accept the EUDI Wallet in onboarding flows?
A: Start by identifying every onboarding journey that will depend on wallet acceptance, then map the assurance threshold each journey actually needs. Treat biometric proofing, document checks, and fraud controls as one decision path. If the flow cannot withstand synthetic input or device tampering, it is not ready for production acceptance.
Q: Why do EUDI wallets create outsourcing and accountability questions?
A: Because wallet-based identity flows may involve external providers in steps that banks still need to govern, even when the bank keeps the final decision. That creates ambiguity over who owns assurance evidence, incident response, audit scope and fraud responsibility, especially if the control boundary is not written into contracts.
Q: What breaks if banks treat wallet acceptance as only a front-end change?
A: The control model breaks first. Onboarding evidence, strong customer authentication and fraud response all depend on where trust is established and who can prove it, so a front-end-only view leaves policy gaps, inconsistent approvals and unclear ownership when disputes arise.
Q: What is the difference between wallet-based authentication and bank-issued login controls?
A: Bank-issued login controls are managed end to end by the institution, while wallet-based authentication depends on externally issued identity evidence that the bank accepts and verifies. That distinction matters because assurance, audit evidence and accountability are shared differently, even if the bank still makes the final accept or reject decision.
Technical breakdown
EUDI wallet support changes customer authentication assurance
EUDI wallets are digital identity wallets intended to hold and present trusted identity attributes for use by public and private organisations. In banking, the important change is that the customer may present assurance from a wallet rather than only from bank-issued login methods or document checks. That affects how assurance is established, how evidence is collected, and how strong customer authentication is interpreted across channels. The article also notes the unresolved relationship between SCA and SUA terminology, which matters because implementation teams need a precise control model before they can automate policy decisions. Practical implication: map wallet acceptance to the bank's assurance model, not just its login flow.
Practical implication: map wallet acceptance to the bank's assurance model, not just its login flow.
AML onboarding shifts from document capture to attribute attestation
The article describes a move from scanned identity documents and selfies toward qualified electronic attestations of attributes, or QEAA, issued by qualified trust service providers. That matters because QEAA changes the control evidence available to banks during customer due diligence: identity claims can arrive as digitally signed attestations rather than ad hoc images or manual review artefacts. The governance question is whether those attested attributes are accepted consistently across onboarding workflows, risk scoring, and record retention. Practical implication: treat QEAA as a structured identity evidence source and define where it is sufficient, where escalation is required, and where manual review still applies.
Practical implication: treat QEAA as a structured identity evidence source and define where it is sufficient, where escalation is required, and where manual review still applies.
Outsourcing boundaries are unclear when banks depend on wallet ecosystems
The article highlights a live ambiguity in PSR drafting: if a bank relies on external wallet providers for elements of authentication, does that create an outsourcing relationship or not? That is more than a legal wording issue. It determines ownership of controls, contractual obligations, audit scope, and fraud accountability. The bank may retain final authentication decisioning, but it still depends on external identity presentation and verification paths. Practical implication: inventory every dependency in the wallet flow and classify which parties actually control credential issuance, verification and dispute handling.
Practical implication: inventory every dependency in the wallet flow and classify which parties actually control credential issuance, verification and dispute handling.
NHI Mgmt Group analysis
EUDI wallet adoption is an IAM governance problem before it is a channel upgrade. The article is not really about a new login method. It is about how banks reclassify trust when identity evidence comes from a wallet ecosystem rather than from a bank-owned registration flow. That changes assurance, evidence quality, and operational ownership across onboarding and authentication.
Wallet diversity will expose policy inconsistency faster than technology gaps. The article points to at least 27 wallets, which means banks will need to decide which parts of the journey are invariant and which can vary by provider. If those decisions are not normalised, the same customer journey will produce different risk outcomes across channels and jurisdictions. Practitioners should expect governance drift unless policy, assurance and exception handling are codified early.
Authentication assurance cannot remain a purely bank-internal control once wallets become part of the trust path. eIDAS 2.0 and PSR together push identity acceptance into a shared ecosystem, but the accountability model is still unsettled. That means fraud responsibility, dispute handling and evidence retention all need explicit ownership, not implicit assumptions.
Outsourcing language may become the proxy battle for control. The article shows that regulators and banks may disagree on whether wallet participation creates outsourced authentication. That distinction matters because outsourcing rules shape vendor oversight, due diligence and exit planning. The practitioner conclusion is simple: if the control boundary is unclear, the governance model is already incomplete.
EUDI wallet readiness will depend on aligning identity assurance with payment and AML control design. The strongest posts in this category are the ones that connect onboarding, strong customer authentication and fraud accountability into one programme view. Banks that treat those as separate workstreams will create duplicate evidence models and inconsistent control ownership.
What this signals
Wallet acceptance will force banks to separate identity assurance from channel design. Once EUDI wallets become part of the customer journey, the control question shifts from 'Can the user log in?' to 'Which party can prove the identity claim and under what assurance level?'. Banks that do not separate those questions will struggle to keep onboarding, authentication and fraud controls consistent.
Assurance portability is now the pressure point. EUDI wallets only become operationally useful if banks can accept them without recreating bespoke exception handling for every wallet provider. That means the real programme risk is not technical connectivity, but whether policy can absorb multiple wallet sources without fragmenting the trust model.
Identity trust in banking will increasingly depend on control boundaries, not just verification steps. The programmes that succeed will document where the bank retains decision authority, where a wallet provider contributes evidence, and how fraud accountability is assigned when a claim is disputed.
For practitioners
- Define the wallet trust boundary Map where the bank issues, verifies and relies on wallet-presented identity attributes, then document which steps remain under bank control and which depend on third parties.
- Rework onboarding evidence rules Specify when QEAA can replace document capture or selfie review, and when the journey still requires escalation, manual review or additional fraud checks.
- Test strong customer authentication governance Validate how wallet-based authentication fits the bank's SCA model, including evidence retention, dispute handling and consistency across channels.
- Prepare outsourcing and accountability clauses Review contracts and control ownership so wallet-provider dependencies do not leave fraud responsibility, audit scope or exit rights ambiguous.
- Align AML and payments teams early Bring onboarding, AML and payments owners into the same control-design discussion so wallet support does not fragment across separate governance tracks.
Key takeaways
- EUDI wallet support is driving a governance shift in banking identity, not just a new authentication option.
- The main operational pressure is the overlap between onboarding evidence, strong customer authentication and third-party accountability.
- Banks that do not define control boundaries early will face inconsistent assurance, contract ambiguity and harder fraud attribution.
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 NIST CSF 2.0 set the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63C — Federation | Wallet acceptance hinges on trusted identity assertion and federation-style acceptance of external evidence. |
| Recommendation — Align wallet acceptance with federation trust rules and define how external identity assertions are accepted. | ||
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | EUDI wallets authenticate banking customers who are external users, not organizational staff. |
| Recommendation — Apply IA-8 to govern how external users authenticate through wallet-presented identity evidence. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about how banks grant access based on stronger and externally sourced identity assurance. |
| Recommendation — Tie wallet-based access decisions to PR.AA-05 so authorisation follows verified identity assurance. | ||
| GDPR | Art.32 — Security of processing | Wallet-based identity data and assurance records require processing security and confidentiality controls. |
| Recommendation — Protect wallet-derived identity data under Art.32 with security, confidentiality and integrity controls. | ||
Key terms
- Eudi Wallet: A digital identity wallet is a user-controlled container for identity credentials, attributes, and presentation proofs. In regulated environments, it becomes part of the trust chain because relying parties may accept its claims for authentication, onboarding, or transaction approval.
- Qualified Electronic Attestation Of Attributes: A QEAA is a digitally issued, high-assurance statement about a person’s attributes, such as identity-related facts needed for onboarding or verification. It matters because it can replace lower-trust document scanning with verifiable evidence from a qualified trust service, provided the bank can audit the provenance and validation path.
- Strong Customer Authentication: A regulated authentication requirement that demands more than a single password or code. Under PSD2, it requires at least two factor types and must support the payment context, so the approval is tied to the specific transaction rather than a reusable login event.
- Outsourcing Boundary: An outsourcing boundary is the line where a bank’s internal control responsibility may become a formally contracted third-party service relationship. For EUDI wallets, the ambiguity is whether reliance on an external wallet ecosystem is merely an assurance dependency or crosses into regulated outsourcing that changes oversight and contractual duties.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org