Banks, payment institutions and e-money issuers that use strong customer authentication have a fixed date for EUDI Wallet acceptance. Under Article 5f(2) of the European Digital Identity Regulation, they must accept the EUDI Wallet for user authentication by 24 December 2027 when a customer chooses to use it.
The rule is narrower than "support EUDI Wallet-based SCA for every payment". This guide covers what it requires, what it leaves open, and how it lines up with the new EU payment rules that are still being finalised.
Timetable
- 20 May 2024: The European Digital Identity Regulation (eIDAS 2) enters into force.
- 24 December 2024: The first wallet implementing acts enter into force. The 24- and 36-month deadlines below count from this date.
- 7 May 2025: The implementing regulation on relying-party registration, (EU) 2025/848, is published.
- 27 November 2025: The Parliament and Council reach political agreement on the PSR and PSD3.
- 23 April 2026: The final PSR and PSD3 compromise texts are published.
- 24 December 2026: Each Member State must offer at least one EUDI Wallet to its citizens.
- 24 December 2027: Banks and other private relying parties that use strong user authentication must accept the wallet when a customer chooses it.
- Expected 2028: Most PSR rules apply, about 21 months after the regulation enters into force. The exact date depends on its publication in the Official Journal, which was still pending at the time of writing.
Where the December 2027 date comes from
Article 5f(2) applies to private relying parties that must use strong user authentication for online identification, whether a law or a contract requires it. The article names banking and financial services among the affected sectors, alongside transport, energy, health, telecommunications, education and others.
Those relying parties must accept the wallet no later than 36 months after the wallet implementing acts entered into force. The first implementing acts were published on 4 December 2024 and entered into force on 24 December 2024, which puts the deadline at 24 December 2027. Member States must offer at least one wallet to their citizens a year earlier, by 24 December 2026.
What the obligation covers
- Authentication, at the customer's choice. The wallet becomes an option the customer can pick. The regulation does not require you to replace your existing authentication methods.
- Only the data you need. Article 5f(2) limits acceptance to the minimum data necessary for the online service in question. Plan requests around a specific purpose, not a full identity record.
- Registration first. Relying parties register their intended use and the data they plan to request (Article 5b). That registration shapes what a wallet will agree to share.
What it leaves open
Article 5f is about accepting the wallet for user authentication. It does not settle how a wallet presentation counts as strong customer authentication for a payment under PSD2. In particular:
- Two independent factors. The wallet must show that it used two factors from different categories (knowledge, possession, inherence), and your SCA policy decides which combinations you accept.
- Dynamic linking. For a remote payment, the authentication must be bound to the amount and payee (Article 5 of Commission Delegated Regulation (EU) 2018/389). Proving who the customer is does not do that on its own.
- A single-use authentication code. Article 4(1) of the same regulation requires each authentication code to be accepted only once.
The EUDI Wallet technical specification for payments, TS 12, describes how a wallet can carry these: the payment provider issues an SCA attestation to the wallet, the request carries the transaction details, and the wallet signs a hash of them together with the factors it used and a one-time code.
How the new payment rules fit
The EU's new payment framework, the Payment Services Regulation (PSR) and the third Payment Services Directive (PSD3), reached political agreement in November 2025. The final compromise texts were published in April 2026. At the time of writing, formal adoption and publication in the Official Journal were still pending, and most PSR rules are expected to apply about 21 months after entry into force, so likely in 2028.
That means the eIDAS deadline arrives first. Until the PSR applies, payment authentication still runs under PSD2 and the current EBA technical standards. Some legal summaries of the agreed text report that payment providers will have to accept EUDI Wallets for SCA and that the EBA will review its SCA standards for them; check the final text once it is published.
Other points in the agreed text matter for wallet-based SCA:
- Dynamic linking still applies to remote payments.
- SCA must not depend only on owning a smartphone, so a wallet cannot be a customer's only option.
- Where a third party verifies SCA elements on a provider's behalf, the provider needs an outsourcing agreement and keeps liability, with audit rights over the third party.
A practical plan for 2027
- Start with identification and login. This is what the eIDAS deadline clearly covers. Map the journeys where you use strong authentication today: onboarding, login, account recovery, adding a payee.
- Decide your factor policy. Write down which factor combinations you accept from a wallet, and whether you accept unspecified methods.
- Design payments for dynamic linking. Treat payment confirmation as a separate step that binds amount and payee, using the TS 12 transaction types.
- Keep an alternative. Customers without a wallet, or without a smartphone, need another route.
- Plan for audit. Keep evidence of what was authorised and how, without storing more personal data than you need.
- Test with real wallets. Wallet support for TS 12 transaction types is still emerging. Confirm behaviour with the wallets your customers will use before you rely on it.
How DLBR EID supports SCA
DLBR EID is a verification gateway for EUDI Wallet presentations. For TS 12 SCA it:
- validates the four TS 12 transaction types: payment, login and risk, account access, and e-mandate;
- checks that the wallet signed a hash of the exact transaction it was shown, which binds amount and payee;
- requires two factors from distinct categories, and lets each request narrow the accepted factors with a policy;
- accepts each authentication code once and fails a presentation that reuses one;
- records the transaction hashes, authentication codes and factors in a hash-chained audit log, without amounts, payees or claim values.
DLBR EID does not issue SCA attestations, run payments or decide whether a payment is authorised. Those remain with the payment provider. Read the SCA guide for banks for how the flow works end to end.
FAQ
Do banks have to accept the EUDI Wallet by December 2027?
Banks and other financial services providers that must use strong user authentication for online identification have to accept the wallet for user authentication by 24 December 2027, when a customer chooses to use it.
Does the wallet replace our current SCA methods?
No. The obligation is to accept the wallet as an option. You can keep existing methods, and you need an alternative for customers who do not use a wallet.
Can a wallet presentation confirm a payment?
TS 12 defines how, using transaction data signed by the wallet. Whether and how that counts as SCA for a payment depends on PSD2, the PSR once it applies, and the EBA standards that follow. Treat payment confirmation as a separate design step from login.
How can my organisation evaluate DLBR EID?
DLBR EID is accepting private-pilot requests from banks, payment institutions and e-money issuers. Request pilot access with a short description of your journeys and target markets.