.svg)
.svg)
.png)
Banks and payment institutions across the EU will soon be required to accept EUDI Wallets when a customer asks to use one. Most coverage of that obligation stops there.
The harder question is what happens next. Accepting a wallet and performing Strong Customer Authentication with one are not the same thing, and the gap between them is wider than the industry usually admits.
Here is the honest summary. The presentation half of wallet-based SCA is specified in detail. The issuance half is not. The issuance half is where a bank's build work actually sits.
This guide sets out what each law requires, where the two frameworks fail to meet, and what a payments team can usefully do in 2026. It is current as of August 2026.
SCA is a payments term. It comes from PSD2 and its Regulatory Technical Standards, and it carries a precise definition.
Authentication must use at least two factors drawn from different categories: knowledge, possession, and inherence. The factors must be independent, so that breaching one does not compromise the others. This is set out in Article 97 of PSD2 and Articles 4 and following of Commission Delegated Regulation (EU) 2018/389.
For payment initiation, SCA also requires dynamic linking under Article 5 of the same Delegated Regulation. The authentication must bind to a specific amount and a specific payee. Authenticating the person is not enough. You must authenticate the transaction.
One point worth stating plainly, because it shapes everything else. PSD2 and Delegated Regulation 2018/389 remain the law in force today.
The Council published the final compromise texts for PSD3 and the Payment Services Regulation on 23 April 2026, as documents 8221/26 and 8222/26, and the ECON Committee has recommended approval without amendments. What remains is procedural: the final Parliament vote, Council adoption, and publication in the Official Journal. ECON has urged adoption by September 2026 at the latest.
The PSR enters into force 20 days after publication. Most of its conduct rules, including SCA, then apply 21 months after entry into force, with the payee verification provisions following at 27 months. That points to 2028 for general application. Until publication happens, PSR is a planning input rather than a compliance obligation.
The acceptance obligation sits in Article 5f(2) of Regulation (EU) No 910/2014, as amended by Regulation (EU) 2024/1183.
The wording is narrower than most summaries suggest. It applies to private relying parties, excluding microenterprises and small enterprises, that are required by Union law, national law, or contractual obligation to use strong user authentication for online identification. The regulation then lists sectors, including transport, energy, banking, financial services, social security, health, drinking water, postal services, digital infrastructure, education, and telecommunications. The list is introduced by the word "including", so it illustrates rather than limits.
Two qualifiers get dropped in most coverage, and both matter operationally.
The obligation applies only upon the voluntary request of the user. Nobody is obliged to push customers onto wallets. You are obliged to accept one when a customer brings it.
And the deadline runs from implementing acts, not from the regulation. The Commission adopted those acts on 28 November 2024 and published them on 4 December 2024. Article 5f(2) sets a limit of 36 months from their entry into force, which puts the date at 24 December 2027.
Treat that as a legal date rather than a safe planning assumption. It is fixed by calculation, but the ecosystem around it has slipped repeatedly. No wallet has been certified in any member state, the certification scheme itself is still in draft, and the rulebooks that wallet-based SCA depends on have not appeared. A deadline can hold in law while the conditions for meeting it move.
Read the two texts side by side and the problem becomes obvious.
eIDAS 2.0 says strong user authentication. PSD2 says Strong Customer Authentication. These are different terms, in different laws, drafted to different levels of detail, for different purposes.
Article 5f(2) tells a bank that it must accept a wallet. It does not tell that bank how a wallet presentation satisfies two-factor requirements, or how it achieves dynamic linking, or what evidence to retain for a supervisor. Those questions belong to payments law, and payments law does not currently answer them for wallets.
This is where the common industry claim breaks down. Wallets do support all three PSD2 factor categories by design. That statement is true and largely beside the point.
The credential that proves who you are does not prove that you hold the account. Person Identification Data establishes identity. It does not establish an account relationship, and it cannot bind a consent to a specific amount and a specific payee. The EWC Payment Taskforce reached the same conclusion, finding that approaches relying solely on pre-existing wallet credentials such as PID do not meet PSD2 requirements, citing the EBA Opinion on the elements of SCA of 21 June 2019 regarding device binding.
The Commission has published a technical specification for this. It is worth reading closely, because what it leaves out is as instructive as what it contains.
TS12, "Specification of Strong Customer Authentication (SCA) Implementation with the Wallet", reached final version on 5 December 2025 with an editorial update on 30 January 2026.
TS12 builds on Section 2.6.4 of the Architecture and Reference Framework, which introduces dedicated attestations issued into a user's wallet unit by their account servicing payment service provider. The bank issues a purpose-built SCA Attestation into the wallet. That attestation, not the identity credential, is what authenticates the payment.
The specification then describes a three-part flow: Registration, Authentication, and Dynamic Linking. Registration is defined as the secure association of the wallet unit and holder with the account holder, achieved by the payer's PSP issuing that cryptographically bound attestation.
And on Registration, TS12 says directly that this step is not described in the document.
The detail is deferred to SCA Attestation Rulebooks, which the specification says the financial sector will deliver. We could not find a published rulebook as of August 2026. TS12 itself is a technical specification rather than binding law, and it is not referenced in any Commission Implementing Regulation.
So the position in August 2026 is this. How a wallet presents an SCA Attestation is specified in real detail, down to the required authentication method references in the key binding token and the transaction data schemas for payments, logins, account access, and e-mandates. How a bank gets that attestation into a customer's wallet in the first place is not.
Separate the two obligations in your programme plan. Article 5f(2) acceptance and PSR SCA compliance run on different clocks under different regulators. Planning against one will leave you exposed on the other.
Treat issuance as the long pole, not verification. Verification is well specified and comparatively cheap to build. Issuing attestations into wallet units, binding them to accounts and cards, managing their lifecycle against wallet unit attestation validity, and revoking them is the work. Start there.
Build against the schemes you can actually test. France Identité, EUDI Wallet Deutschland, IT-Wallet and AltID have environments you can work against today. Work built against them carries over, because the formats and protocols do not change. We set out what varies and what does not in 27 member states, 27 wallets, and the registration trade-offs in EUDI intermediaries.
Do not reshape the programme around PSR before it is published. A gap analysis against the agreed text is sensible. Rebuilding your authentication stack around a text that is still in legal-linguistic review is not.
Hovi works across the Nordics and Baltics, and operates inside two of the ecosystems moving fastest.
In the France Identité EUDI ecosystem and the German EUDI Wallet Deutschland sandbox, we can help you integrate and verify against these test wallets. You can build onboarding and KYC identity verification flows using Person Identification Data and age verification credentials, and issue Electronic Attestation of Attributes credentials into wallet units across the full credential lifecycle.
We presented live in Paris at the France Identité event EUDIW Unfold #3, running verification demos with the France Identité digital wallet, built on the Hovi platform.
We also tested against ETSI TS 119 472-1 at the ETSI EAA Plugtests, covering SD-JWT VC and ISO/IEC 18013-5 across several government and private wallet providers.
Hovi gives you the orchestration layer to issue and verify credentials across EUDI schemes and connect with all 27 member state wallet ecosystems. Talk to us about your EUDI Wallet Integration Strategy..
.svg)
