The EU Digital Identity Wallet: what eIDAS 2.0 asks of banks by 2027

What the regulation requires

Regulation (EU) 2024/1183 amends the eIDAS Regulation and establishes the European Digital Identity Framework. Member states issue the wallets. Regulated private services, banks among them, have to accept them. For a bank, five things matter.

• A wallet in every member state. Each member state must provide at least one European Digital Identity Wallet. It holds person identification data and electronic attestations of attributes, shares them under the sole control of the user, and can sign with qualified electronic signatures.
• Banks must accept it. Where a private relying party is required by Union or national law, or by contract, to use strong user authentication for online identification, it must also accept the wallet. The regulation names banking and financial services explicitly. Acceptance applies on the voluntary request of the user, and micro and small enterprises are exempt.
• Registration before reliance. A relying party that intends to rely on the wallet registers in the member state where it is established, stating who it is and which data it intends to request. It may not ask the user for more than it registered.
• Attestations with legal weight. A qualified electronic attestation of attributes has the same legal effect as a lawfully issued attestation on paper. Attributes that used to arrive as a scan can arrive as a signed credential.
• Only what the service needs. The wallet lets the user disclose selected attributes instead of a whole document, and shows them which relying party is asking.

Two other rulebooks meet the wallet inside the bank. The AML Regulation, Regulation (EU) 2024/1624, lets obliged entities verify a customer's identity with electronic identification means under eIDAS and relevant qualified trust services, and AMLA's draft technical standards on customer due diligence point remote verification to eID at assurance level substantial or high. On the payment side, the Commission's wallet specifications describe strong customer authentication under PSD2 carried out through the wallet, backed by an SCA attestation that the payment service provider issues to the wallet.

The dates

The deadlines run from the entry into force of the first implementing acts, adopted by the Commission on 28 November 2024.

The large scale pilots have already tested the banking cases. NOBID piloted the wallet for authorising payments, the EWC consortium demonstrated online payment flows, and opening a bank account online was one of the use cases the pilots explored.

Where banks get stuck

The wallet is well specified. The friction sits in bank processes that were designed around paper, photographs and one way of logging in.

Onboarding built around document scans

Most digital onboarding flows photograph an identity document, check it and match a selfie. A wallet presentation arrives as signed, structured data with no image to inspect. The flow needs a second path that verifies the credential and its issuer, and the bank's risk rules have to treat both paths as equal evidence.

Registration and certificates

Relying on the wallet starts with registration and the certificates that follow it: an access certificate that identifies the bank to the wallet, and where applicable a registration certificate stating what the bank may request. Someone has to own them, renew them, and keep every channel's data request inside the registered scope. This is new operational work, and it has no obvious home in most organisations.

Wallet login next to existing SCA

Banks already run strong customer authentication through their own apps, tokens and biometrics. The wallet becomes a second route the customer may choose. Both routes have to lead to the same session, the same limits and the same audit record, and dynamic linking for payments still has to hold.

Accepting attestations in the case file

A qualified attestation carries legal weight, but only if the bank can show later what it received, who issued it and how it was checked. Case files built to store images and reviewer notes need to store credentials, verification results and the decision taken on them, so an auditor sees the full chain.

What it takes inside the platform

Accepting the wallet touches onboarding, authentication and records at once.

• A verification path for credentials. Onboarding verifies wallet presentations and qualified attestations alongside document and liveness checks, and feeds both into the same risk decision.
• Minimum data requests. Each channel asks the wallet only for the attributes the product needs, and the request matches what the bank registered.
• Certificates under control. Access and registration certificates have an owner, a renewal date and a record of where they are used.
• One authentication model. Wallet login and the bank's own SCA methods end in the same session, the same limits and the same audit trail.
• Evidence the bank can show. Every credential received, every check run and every decision taken sits in one case file, linked to the customer record in the core.

Where ABC Tech fits

ABC Tech Digital onboarding opens accounts for individual customers fully digitally: document and liveness verification run on the Sumsub platform, together with sanctions, PEP and adverse-media screening, the bank's own risk rules decide, and one case file records every check, decision and reviewer before the flow ends with a live account in the core. ABC Tech Digital banking brings strong customer authentication built to PSD2, with biometrics, PIN and the ABC Tech Security Token, to mobile and web on one platform. These are the two places where a bank decides how the wallet enters its customer journey.