The EU Digital Identity Wallet — why a payment firm will have to accept it, and when
Because PSD2 requires strong customer authentication, a payment firm is squarely inside the group of private relying parties that will have to accept the EU Digital Identity Wallet — and the clock runs from implementing acts, not from a date in the Regulation. Regulation (EU) 2024/1183 rewrote the eIDAS framework to create the European Digital Identity Wallet, oblige member states to provide one, and require certain private services to accept it on the user’s request. This walks through the acceptance obligation, who is exempt, the two pegged deadlines, and what the wallet changes for onboarding and authentication.
1. What the Regulation does
Regulation (EU) 2024/1183 amends Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework. It inserts a new section on the European Digital Identity Wallet and, with it, obligations on member states to provide wallets and on defined categories of relying party to accept them.
Article 5a(1) sets the supply side: for the purpose of ensuring that all natural and legal persons in the Union have secure, trusted and seamless cross-border access to public and private services while having full control over their data, each member state shall provide at least one European Digital Identity Wallet within 24 months of the date of entry into force of the implementing acts referred to in Article 5a(23) and Article 5c(6).
Article 5a(2) allows a wallet to be provided directly by a member state, under a mandate from a member state, or independently of a member state but recognised by it — so the wallet a customer presents will not necessarily be a state-operated application. Article 5a(3) requires the source code of the application software components to be open-source licensed, with member states able to withhold disclosure of specific components other than those installed on user devices for duly justified reasons.
2. What the wallet actually does
Article 5a(4) sets the functional requirements, and they matter for anyone designing an onboarding or authentication flow. In a user-friendly, transparent and user-traceable manner, the wallet must enable the user to:
- securely request, obtain, select, combine, store, delete, share and present — under the sole control of the user — person identification data and, where applicable, in combination with electronic attestations of attributes, in order to authenticate to relying parties online and, where appropriate, offline, while ensuring that selective disclosure of data is possible;
- generate pseudonyms and store them encrypted and locally within the wallet;
- securely authenticate another person’s wallet, and receive and share person identification data and electronic attestations of attributes securely between the two wallets.
Two of these change design assumptions. Selective disclosure means the relying party receives what it asks for rather than a document image from which it extracts everything — so the request itself becomes the compliance artefact. And locally generated pseudonyms mean a user may authenticate repeatedly without disclosing an identifier the firm can use as a customer key.
3. The acceptance obligation, and who it binds
Article 5f is the operative provision. Paragraph 1 covers the public sector: where member states require electronic identification and authentication to access an online service provided by a public sector body, they must also accept wallets provided in accordance with the Regulation.
Paragraph 2 is the one that reaches financial services. Where private relying parties that provide services — with the exception of microenterprises and small enterprises as defined in Article 2 of the Annex to Commission Recommendation 2003/361/EC — are required by Union or national law to use strong user authentication for online identification, or where strong user authentication for online identification is required by contractual obligation, including in the areas of transport, energy, banking, financial services, social security, health, drinking water, postal services, digital infrastructure, education or telecommunications, those relying parties must — no later than 36 months from the date of entry into force of the implementing acts referred to in Article 5a(23) and Article 5c(6), and only upon the voluntary request of the user — also accept wallets provided in accordance with the Regulation.
Read that against PSD2. Strong customer authentication for electronic payment transactions and for online access to payment accounts is a requirement of Union law, so a payment institution or e-money institution operating online is within the description in Article 5f(2). The sectoral list in the paragraph names banking and financial services expressly, but the trigger is the strong-authentication requirement rather than the sector label.
Paragraph 3 adds very large online platforms within the meaning of Article 33 of Regulation (EU) 2022/2065: where they require user authentication for access to online services, they must also accept and facilitate wallet use, again only on the user’s voluntary request and in respect of the minimum data necessary for the specific service.
| Who | Obligation | Timing |
|---|---|---|
| Member states | Provide at least one wallet | Within 24 months of entry into force of the Article 5a(23) and 5c(6) implementing acts |
| Public sector bodies | Accept wallets where they require electronic identification and authentication | Per Article 5f(1) |
| Private relying parties subject to a strong-authentication requirement (excluding micro and small enterprises) | Accept wallets on the user’s voluntary request | No later than 36 months from entry into force of the same implementing acts |
| Very large online platforms | Accept and facilitate wallet use on voluntary request, minimum data necessary | Per Article 5f(3) |
The two deadlines are pegged to the same implementing acts, which is why they should be tracked as a dependency rather than diarised as dates. The gap between them — 24 months to supply, 36 months to accept — is the twelve-month window in which wallets exist and acceptance is not yet compulsory.
4. What it changes for onboarding
The wallet arrives into an onboarding regime that already anticipates it. The EBA remote customer onboarding guidelines treat several criteria of the pre-implementation assessment as satisfied where the solution uses an electronic identification scheme notified under Article 9 of Regulation (EU) No 910/2014 meeting assurance level substantial or high, or relevant qualified trust services. A wallet-based flow is therefore not only an acceptance obligation; it is a route to a lighter assessment burden on the AML side.
Facts: an e-money institution plans a wallet integration purely as a compliance item, keeping its existing document-and-selfie flow as the primary path and treating the wallet as a rarely used alternative.
What the rule says: Article 5f(2) requires acceptance on the user’s voluntary request, so a secondary path is compliant as far as the Regulation goes. But the EBA guidelines’ treatment of notified schemes means the wallet path can also discharge parts of the pre-implementation assessment that the document-and-selfie path cannot.
What the practitioner does: scopes the integration once, for both purposes — acceptance and assessment relief — rather than building a minimal compliance path and separately maintaining the heavier evidential burden on the primary flow.
Facts: a firm designs its wallet request to pull the full person identification dataset on every authentication, mirroring what it collects today.
What the rule says: the wallet must ensure selective disclosure is possible, and the Regulation’s reasoning requires any request by a relying party to be necessary for and proportionate to the intended use, in line with data minimisation, with transparency about which data is shared and for what purposes. Article 5f(3) states the minimum-data principle expressly for platforms.
What the practitioner does: defines a separate attribute request per use case — age or residence confirmation for eligibility, full identification only for onboarding — because a maximal request is both a data protection exposure and visible to the user at the moment of consent.
5. Attestations of attributes, and pseudonyms
The wallet is not only an identity document. It carries electronic attestations of attributes that can be presented in combination with person identification data, and the Regulation’s approach is that general requirements should ensure a qualified electronic attestation of attributes has equivalent legal effect to lawfully issued attestations in paper form — without prejudice to Union or national law defining additional sector-specific requirements as to form, and to cross-border recognition where appropriate.
For a financial institution that reframes several checks. Attributes such as residence, age or a professional qualification become presentable claims rather than documents to be collected, read and stored — which shifts the control from extraction and retention towards verification of the attestation.
The pseudonym function cuts the other way for customer-linking. A user authenticating under a locally generated pseudonym is deliberately not handing over a durable identifier. Where a firm’s architecture assumes a stable external identity key, wallet-based authentication will not supply one, and the Regulation protects the user’s right to use freely chosen pseudonyms in the platform context.
Article 5f(4) has the Commission facilitating the development of codes of conduct in collaboration with stakeholders including civil society, to contribute to wide availability and usability. Article 5f(5) requires the Commission, within 24 months after deployment, to assess demand for, and the availability and usability of, wallets — taking account of user take-up, cross-border presence of service providers, technological developments, evolving usage patterns and consumer demand. That review is where the acceptance regime may be tightened or extended, so it is worth watching rather than treating the current text as settled.
6. FAQ
Will payment firms have to accept the EU Digital Identity Wallet?
Private relying parties subject to a Union or national law requirement — or a contractual requirement — to use strong user authentication for online identification must accept wallets on the user’s voluntary request, and Article 5f(2) names banking and financial services among the areas covered. Microenterprises and small enterprises are excepted.
By when?
No later than 36 months from the entry into force of the implementing acts referred to in Article 5a(23) and Article 5c(6). Member states must provide at least one wallet within 24 months of the same acts, so both dates are pegged to those acts rather than fixed in the Regulation.
Can we require customers to use a wallet?
No. The Regulation’s approach is that users are under no obligation to use a wallet for private services and must not be restricted or hindered in access because they do not. Acceptance is triggered only by the user’s voluntary request.
Can we request the full identity dataset every time?
The wallet must support selective disclosure, and requests must be necessary for and proportionate to the intended use, consistent with data minimisation and transparent as to what is shared and why. Article 5f(3) states a minimum-data rule expressly for very large online platforms.
Does a wallet help with AML onboarding?
Indirectly but materially. The EBA remote onboarding guidelines treat parts of the pre-implementation assessment as met where the solution uses an eID scheme notified under Article 9 of Regulation (EU) No 910/2014 at assurance level substantial or high, or relevant qualified trust services.
Are wallets always state-run applications?
No. Article 5a(2) allows provision directly by a member state, under a mandate from a member state, or independently of a member state but recognised by it.
7. What to do, today
- Track the implementing acts, not a calendar date. Both the 24-month supply deadline and the 36-month acceptance deadline run from their entry into force.
- Confirm you are in scope: if Union or national law — or a contract — requires strong user authentication for online identification and you are not a micro or small enterprise, plan for acceptance.
- Design attribute requests per use case rather than one maximal request. Selective disclosure makes over-collection both visible to the user and harder to justify.
- Check whether your identity architecture assumes a durable external identifier, because pseudonymous authentication will not provide one.
- Scope the integration jointly with AML, so the notified-scheme relief in the EBA onboarding guidelines is captured rather than left on the table.
- Put the Commission’s post-deployment review on the horizon list — it is the point at which the acceptance perimeter could move.
Related: EBA remote customer onboarding guidelines · SCA exemptions under the PSD2 RTS · EU AI Act deadlines for financial institutions
