eIDAS 2 for Financial Services

eIDAS 2 (Regulation (EU) 2024/1183) requires banks, fintechs, and payment institutions to accept the EU Digital Identity Wallet (EUDI Wallet) for customer authentication by the end of 2027. For financial services this goes further than a new login method: the European Commission has published a dedicated specification — TS12, released in December 2025 — that defines how the wallet performs Strong Customer Authentication (SCA) under PSD2, and the EU's new anti-money laundering rules recognise wallet-based identification for customer due diligence. This guide covers the deadlines, the three roles financial institutions play, how wallet-based SCA works, reusable KYC, qualified e-signatures for contracts, and how to build a compliant solution.

What eIDAS 2 changes for financial services

eIDAS 2 entered into force on 20 May 2024 and obliges every EU Member State to provide at least one certified EUDI Wallet to citizens and residents by the end of 2026. For financial institutions, four changes matter most:

1. Mandatory wallet acceptance. The regulation explicitly names banking and financial services among the sectors that must accept the EUDI Wallet for strong user authentication — for sign-in, step-up authentication, and onboarding — by the end of 2027.
2. Wallet-based SCA under PSD2. A dedicated specification (TS12) defines how the EUDI Wallet handles Strong Customer Authentication for payments, logins, account access, and direct debit mandates — so the wallet can stand in for a bank's own authenticator app.
3. Reusable KYC. The core identity credential, also known as PID, in every certified EUDI wallet is verified at the EU's strictest assurance level, and the new Anti-Money Laundering Regulation recognises it for verifying customer identity. Identity verification that today costs a document check and a video call becomes a single PID credential presentation.
4. A new issuance channel. Banks can issue their own credentials — SCA attestations, account ownership confirmations, KYC attestations — directly into customer wallets, turning verified customer data into a reusable asset.

The compliance timeline is compact:

Micro and small enterprises (fewer than 50 employees and at most €10 million in annual turnover) are exempt from the acceptance obligation.

The three roles banks play under eIDAS 2

Every digital identity ecosystem has three actors — and a typical bank will end up playing at least two of them.

Verifier: the mandatory role

As a verifier, a bank requests and checks credentials (e.g. PID, SCA) from customer EUDI wallets. This requires the bank to register as a relying party with a national registrar, declaring which customer data it will request, and implementing the technical solution that requests and validates that every credential received from EUDI wallets is genuine, still valid, and actually belongs to the person presenting it. This is the role the end-of-2027 deadline attaches to.

Issuer: required for SCA, strategic beyond it

As an issuer, a bank places credentials into customer EUDI wallets. The role is often framed as optional, but for Strong Customer Authentication it is not: wallet-based SCA only works if the customer's bank has first issued an SCA attestation into the wallet. Beyond SCA, banks can issue credentials such as account ownership or KYC confirmations that customers could reuse with other services.

Wallet provider: the optional role

As a wallet provider, a bank offers the wallet itself. The certified path means meeting the EU's highest security requirements and passing a formal certification audit. Banks that pursue it keep the entire authentication experience — including SCA — inside their own app, which is where many customers already manage their finances daily.

Core eIDAS 2 Banking use cases at a glance

The table below summarises the core banking use cases under eIDAS 2; the sections that follow cover them in detail.

Strong Customer Authentication with the EUDI Wallet

SCA has been mandatory for electronic payments since PSD2 took effect: customers must approve payments and account access with two independent authentication factors. What is new is the how. In December 2025 the European Commission published Technical Specification 12 (TS12), the official specification for performing SCA with the EUDI Wallet. It is binding for wallet providers — and it is the leading guideline banks should plan against. In addition to the specification, there will be dedicated playbooks published that further specify the SCA usage patterns and standards.

How the wallet meets the PSD2 requirements

PSD2 Article 97 requires SCA whenever a customer initiates an electronic payment, accesses a payment account online, or does anything else that carries a fraud risk. SCA means combining at least two of three factor types: something the customer knows (a PIN or passphrase), something they have (a device holding cryptographic keys in certified secure hardware), and something they are (biometrics such as fingerprint or face). The EUDI Wallet covers all three, and every approval records which two factors were used — giving payment service providers the audit trail required.

The SCA attestation: a credential from the bank

Wallet-based SCA starts with the bank, not the wallet. Before a customer can approve anything, their bank issues an SCA attestation into the wallet — a credential proving that this wallet belongs to this customer and, where relevant, to a specific account or card. A bank can issue one per customer, per account (carrying the IBAN), or per card (carrying the card scheme and digits). TS12 specifies the SD-JWT VC credential format for these attestations.

Two properties matter for fraud and risk teams. The attestation is bound to the wallet's secure hardware, so it cannot be copied to another device. And its validity is tied to the wallet itself — if the wallet is revoked, the bank's attestations in it automatically become invalid. Banks can additionally restrict which parties are allowed to request the attestation at all.

Dynamic linking: what the customer sees is what gets approved

For remote payments, PSD2 requires dynamic linking: the customer must see the amount and the payee, and the approval must be tied to exactly those details. TS12 builds this into the protocol. The approval request — sent to the wallet over OID4VP, the standard presentation protocol — carries the real transaction details: amount, currency, and who is being paid. The wallet displays them prominently on the confirmation screen, the customer approves with two factors, and the wallet returns a response that is cryptographically tied to the exact details shown, along with a fresh one-time code that serves as the authentication code PSD2 requires.

If anything changes after approval — the amount, the payee — the approval no longer matches and the authentication fails. Dynamic linking is enforced by the protocol.

Four situations, one consistent experience

TS12 defines four standardised transaction types, covering the situations in which PSD2 requires SCA. Each has fixed display rules, so every wallet presents them to customers consistently:

The wallet also keeps a log of every SCA approval — successful or failed — giving customers an auditable history and banks a consistent evidence trail.

Two ways customers will use it

TS12 distinguishes two setups, based on who asks for the authentication:

• In the bank's own channels. The bank requests the SCA attestation back from the wallet.
• Through third parties. A merchant or payee collects payment consent directly (comparable to today's commercial pay wallets), or an open banking provider embeds the authentication in its own flow, in line with PSD2's existing provisions.

TS12 lets banks issue separate attestation types for the two scenarios, so stricter rules can be applied to attestations exposed to third parties. Sector rulebooks, developed by the financial industry on top of TS12, will refine the details further.

What this means for an SCA roadmap

The practical consequence: to offer wallet-based SCA, a bank acts as issuer and verifier at the same time — issuing SCA attestations into wallets, requesting approvals with transaction details, validating the responses, and revoking attestations when needed.

Reusable KYC and customer onboarding

Customer onboarding is where eIDAS 2 delivers the most immediate measurable value. Today's remote onboarding chains together document capture, liveness detection, video identification, and manual review. With the EUDI Wallet, the same result is a single credential presentation: the customer shares their government-issued identity credential (PID) — verified at the EU's strictest assurance level — and the bank validates it cryptographically in seconds.

The regulatory groundwork is in place. The new Anti-Money Laundering Regulation (Regulation (EU) 2024/1624) recognises eIDAS-based digital identification as a valid way to verify customer identity.

Selective disclosure strengthens the compliance position further: the wallet lets customers share only the data a process actually requires — date of birth without the full address, for instance — which aligns directly with GDPR data minimisation.

What the wallet does not replace is the bank's wider due diligence: sanctions and PEP screening, risk assessment, and ongoing monitoring remain the institution's responsibility.

Issuing credentials: the bank as a trusted data source

Banks hold some of the most rigorously verified personal and financial data in the economy — and under eIDAS 2 that data becomes issuable. Using OID4VCI, the standard issuance protocol, a bank can deliver credentials into customer EUDI wallets:

• SCA attestations — the prerequisite for wallet-based authentication, covered above.
• Account attestations — proof of account ownership that customers present to employers, landlords, or other payment services.
• KYC attestations — confirmation that due diligence has been completed, reusable across the bank's own group entities or, subject to the applicable rulebook, with partners.

Most bank-issued credentials fall into the standard attestation category that any registered business in the eIDAS 2 framework can issue. Where a credential needs the same legal standing as a paper original, banks can work with a Qualified Trust Service Provider to issue it as a qualified attestation. Either way, issuers register in the trust ecosystem, issue in the mandated formats, and operate a revocation mechanism so credentials can be invalidated when circumstances change.

Qualified e-signatures for contracts

Banking runs on signed agreements — loan and mortgage contracts, account-opening documents, payment mandates, securities paperwork. Today these are often signed in a branch, by post, or through a separate e-signature provider. eIDAS 2 collapses that into the wallet.

Every certified EUDI Wallet must let its holder create a Qualified Electronic Signature (QES) — the only form of electronic signature that carries the same legal effect as a handwritten signature across all EU member states. For natural persons signing for non-professional purposes, the regulation requires this to be available free of charge, so a retail customer signing a mortgage incurs no separate signing fee.

How wallet-based signing works for a bank

The signature is produced by a Qualified Signature Creation Device (QSCD) that the wallet integrates, using a qualified certificate from a Qualified Trust Service Provider (QTSP). Crucially, the bank does not need to become a trust service provider to use this. As the relying party, the bank presents the document to be signed; the wallet creates the QES; the bank receives a signed document — in one of the required formats (e.g. PAdES) — whose qualified signature it can validate cryptographically against the QTSP's certificate.

Because the signer's identity is already proven at Level of Assurance High by the PID in the wallet, there is no separate identity check for each signing event required.

Build vs buy: how to build a compliant solution

Whether acting as verifier, issuer, or both, a bank faces the same decision as every other organisation in the ecosystem: how much of the solution to build, and how much to buy. The customer-facing applications — onboarding flows, the banking app, the approval screens — are where a bank differentiates and will always be built in-house or with existing partners. The identity layer underneath — credential formats, exchange protocols, trust checks, key management, revocation — is standardised by definition and changes every time the EU specifications evolve. For that layer, there are three possible implementation paths:

• Build apps, buy infrastructure (recommended) — build only the customer-facing applications and use a proven, standards-compliant provider for the identity layer. Fastest time to market, lowest regulatory and technical risk.
• Build apps, own infrastructure — use open-source identity infrastructure to retain full control of the stack, while still avoiding implementing the credential formats, protocols, and trust validation from scratch.
• Build everything in-house — implement and maintain the full stack internally, and keep it current as the specifications evolve. Viable only for institutions with a dedicated identity engineering team.

Most organisations choose one of the first two paths. The deadlines are fixed, engineers with deep experience in these protocols are scarce and the underlying specifications are still moving.

The walt.id solution

walt.id covers both of the first two paths. The walt.id Community Stack provides open-source issuer, verifier, and wallet infrastructure for institutions that want to own their stack; the walt.id Enterprise Stack is the managed offering on top of it — built on open-source technology used by more than 42,000 developers, governments, and businesses. For financial services specifically:

• Verifier — accept the EUDI Wallet for onboarding, login, and SCA, with trust, revocation, and wallet-authenticity checks handled automatically. Transaction details for SCA — amount, currency, payee — are verified as specified in TS12, and results can be passed to existing AML, fraud, or risk systems during verification.
• Issuer — issue SCA attestations, account confirmations, and KYC attestations in all mandated formats (SD-JWT VC, ISO/IEC 18013-5, W3C VC), with credential data validated against the official schemas and revocation built into the issuance workflow.
• Wallet — launch a wallet app or embed compliant wallet capabilities into an existing banking app, with flexible key management from on-device to HSM-backed, plus everything needed for the certified wallet-provider path.

A role-by-role compliance breakdown is available in the eIDAS 2 Implementers Guide or reach out to our team to learn more.

Frequently asked questions

What does eIDAS 2 mean for banks?

eIDAS 2 (Regulation (EU) 2024/1183) requires banks and other financial institutions that use strong user authentication to accept the EUDI Wallet for customer authentication by the end of 2027. It also enables wallet-based Strong Customer Authentication (SCA) under PSD2, identity verification at Level of Assurance High for onboarding and KYC, and gives banks the option to issue their own credentials — such as account or SCA attestations — into customer wallets.

When do banks have to accept the EUDI Wallet?

By the end of 2027. eIDAS 2 (Regulation (EU) 2024/1183) requires banking and financial services to accept the EUDI Wallet. Micro and small enterprises are exempt. Member States must provide wallets to citizens by the end of 2026.

Can the EUDI Wallet be used for Strong Customer Authentication under PSD2?

Yes. Technical Specification 12 (TS12), published by the European Commission in December 2025, defines how EUDI Wallets implement SCA under PSD2 Article 97. The wallet covers all three authentication factor categories — knowledge, possession, and inherence — and satisfies dynamic linking by displaying the amount and payee to the payer and cryptographically binding the authentication code to those transaction details.

What is an SCA attestation?

An SCA attestation is a credential a payment service provider issues into a customer's EUDI Wallet that proves the wallet is associated with a specific payer and, where applicable, a specific account or card. It is cryptographically bound to the wallet's secure hardware, so it cannot be copied to another device, and the customer presents it whenever they approve a login, payment, account access, or direct debit mandate.

Does the EUDI Wallet replace KYC checks for banks?

It replaces the document-collection and verification steps for identity data, not the bank's wider due-diligence obligations. The PID in a certified wallet is verified at Level of Assurance High, and the EU Anti-Money Laundering Regulation (EU) 2024/1624 recognises the EUDI Wallet for verifying customer identity. Screening, risk assessment, and ongoing monitoring remain the bank's responsibility.

Do banks have to build their own EUDI Wallet?

No. The verifier requirement — accepting wallets for authentication by the end of 2027 — applies regardless of whether a bank offers a wallet. Becoming a certified wallet provider is optional and requires certification at Level of Assurance High, Wallet Unit Attestation management, and a conformity assessment. Some banks will pursue it to keep the authentication experience inside their own app.

Can customers sign bank contracts with the EUDI Wallet?

Yes. Every certified EUDI Wallet enables its holder to create a Qualified Electronic Signature (QES), which has the same legal effect as a handwritten signature across the EU. Banks can have customers sign loan agreements, mortgage contracts, and account-opening documents directly from the wallet and receive a signed document they can validate. Because the signer's identity is already verified at Level of Assurance High, no separate identity check is needed per signature, and for natural persons signing for non-professional purposes the signature is free of charge.