Why do EUDI Wallets create liability questions for banks?

Why the liability question is different for banks than for a normal login flow

An eudi wallet changes the trust chain. The bank is not just verifying a familiar username and password path, it is relying on an externally provided assurance event that may be generated, held, or attested by another party. That separation makes liability sensitive to who vouches for identity, who operates the wallet, and who absorbs loss when the assurance result is wrong.

That matters because the bank still owns the customer relationship and the downstream decisioning. If the wallet result is accepted as a basis for account access, onboarding, payment approval, or strong authentication, the bank has to know where its duty of care ends and where the wallet ecosystem’s obligations begin. The legal question is therefore tied to operational trust, not just technology.

Where responsibility can split across the wallet ecosystem

Liability pressure comes from the fact that wallet-based journeys often distribute tasks that were previously concentrated inside one institution. One party may issue or bind the wallet, another may verify attributes, and the bank may rely on the outcome without directly seeing the original proofing evidence. That creates ambiguity over whether a failure was caused by identity proofing, wallet compromise, verifier error, reliance on stale attributes, or a bank-side acceptance decision.

That split is more complex when the bank must act on a trusted assertion rather than re-performing all checks itself. A well-governed design needs clear rules for assurance level, issuer trust, revocation handling, and incident escalation so the bank can show that acceptance was based on a defined control model rather than convenience.

• Digital Identity, eID and Identity Wallets Guide helps map how wallet trust, verifiable credentials, and relying-party decisions fit together.
• eIDAS 2.0, the EU Digital Identity Framework is the core regulatory reference for the wallet model banks are now having to interpret.

What banks need to clarify before they rely on wallet-based authentication

The practical issue is not whether the wallet is useful, it is whether the bank can defend the decision path when something goes wrong. Banks need to define which events they treat as authentication, which events they treat as attribute verification, and which party is accountable for failures caused by issuance, revocation delay, fraud, or compromised device access. Without that separation, disputes become hard to resolve and loss allocation becomes inconsistent.

Current guidance suggests treating wallet acceptance as a governed dependency, not a one-time integration task. Banks should document the assurance threshold for each use case, the evidence retained for disputes, the fallback path when wallet trust is degraded, and the conditions under which the bank will require step-up checks or refuse reliance entirely.

Risk and Threat Considerations

Wallet-based trust can be abused if an attacker compromises the wallet holder, manipulates the verification journey, or exploits weak issuer and verifier controls. The risk is not limited to fraud at login, it also includes downstream exposure when a bank relies on a false assertion for onboarding, recovery, payments, or access decisions.

Failure mechanism: Liability gaps appear when the bank accepts a wallet assertion without a contractually and operationally clear answer to who validated what, against which assurance standard, and with what revocation and dispute process.

Impact: The bank can end up carrying losses, remediation cost, customer harm, and regulatory scrutiny even when the failure originated in a different part of the wallet trust chain.

Practitioner Guidance

What to verify: The bank should verify that every wallet-reliant use case has a named relying-party owner, a documented assurance threshold, and an explicit exception path for failed or stale assertions. If that cannot be shown in writing, the liability model is still immature.

Decision rule: If the wallet result can trigger account opening, recovery, or high-value authorization, require stronger evidence retention and clearer contractual allocation than you would for low-risk profile access. Treat high-impact reliance as a governance decision, not a convenience choice.

What good looks like: The bank can explain, after an incident, exactly which control failed, which party owned that control, and what evidence supports the acceptance decision.

Practitioner takeaway: The central question is not whether EUDI Wallets are secure in principle, but whether the bank can prove where responsibility starts, where it ends, and how losses are assigned when the trust chain fails.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?
• Why do collaboration tools create such a large secrets risk?