For a decade, banks have owned the login. The institution issued the credential, ran the authentication, held the audit trail and decided what "verified" meant. The European Digital Identity Regulation ends that arrangement without ever saying so directly. It requires every Member State to make a wallet available to citizens by December 2026, and it requires banks — named by sector, not by inference — to accept that wallet for strong user authentication by December 2027. Between those two dates sits a year in which the credential exists, customers hold it, and the obligation has not yet bitten. Most institutions are treating that year as slack. It is the build window.
Executive Summary
- This is settled law, unlike most of the 2026 file. Regulation (EU) 2024/1183 is in force. The dates are fixed in the text rather than pending in trilogue, which makes this one of the few programmes that can be planned against with confidence.
- The bank becomes a relying party. That is a defined legal role with a registration obligation attached. It is the first identity regime in which a bank must formally declare, to a public registrar, what it intends to ask customers for.
- Acceptance is not authentication strategy. The obligation is to accept a wallet presentation when a user offers one. What the bank does with the resulting assurance — and how it reconciles that with its own risk model — is left to the bank.
- The hard part is what happens after the credential verifies. A cryptographically valid presentation tells you the holder is who the state says they are. It does not tell you whether they are the person who opened the account in 2014.
Two Dates, One Gap #
Start with the timeline, because almost every misreading of this file comes from collapsing the two dates into one.
Regulation (EU) 2024/1183 amended the original eIDAS Regulation, Regulation (EU) No 910/2014, and entered into force in May 2024. It gave the Commission a mandate to adopt implementing acts specifying how wallets are built, certified, registered and used, and it set two obligations running on different clocks.
The first falls on Member States. By 24 December 2026, each must make at least one European Digital Identity Wallet available to its citizens and residents. That is a supply obligation: the state, or a party it designates, provides the wallet, and natural persons are not charged for it.
The second falls on relying parties. By 24 December 2027, under Article 5f, large and medium relying parties that are legally or contractually required to use strong user authentication for identification — and that operate in one of the listed sectors, which include banking and financial services — must accept the wallet where a user voluntarily asks to use it.
Those are twelve months apart, and the order matters. The credential arrives first. The obligation to accept it arrives a year later.
Most programme plans I have seen anchor on the 2027 date, which is a reasonable reading of a compliance deadline and a poor reading of the actual risk. From December 2026 onward, a bank's customers can hold a state-issued digital identity credential that the bank cannot yet consume. Competitors who can will use it — for onboarding times measured in seconds rather than days, and for re-authentication journeys that skip the document upload entirely. The deadline is 2027. The competitive exposure starts in 2026.
Relying Party Is a Legal Role, Not an Integration Pattern #
This is the provision most often skipped in technical readings, and it is the one with the longest lead time.
Under Article 5b, a party that intends to rely on European Digital Identity Wallets must register in the Member State where it is established. Registration is not a developer-portal signup. It identifies the institution, records the Member State of establishment and registration number, and — critically — covers the intended use, including the attributes the relying party will request.
Three consequences follow, and none of them are engineering problems.
The attribute request becomes a declared position. A bank must decide, in advance and on the record, what it will ask customers to disclose. "Everything the wallet will give us" is not an available answer. Data minimisation stops being a principle the privacy office advocates for and becomes a constraint the registration encodes.
Product changes acquire a registration dependency. A new journey that needs an attribute outside the registered scope is not a sprint item. Whatever the administrative turnaround proves to be in each Member State, it is not the same day.
Multi-jurisdiction banks register in more than one place. An institution established in several Member States deals with several registrars. The wallet is designed to be cross-border — a German wallet works with a French relying party — but the registration obligation attaches to establishment, and group structure determines how many conversations that means.
Table 1: Where the bank sits before and after #
| Dimension | Bank-owned identity (today) | EUDI Wallet (Article 5f) |
|---|---|---|
| Who issues the credential | The bank, after its own onboarding | The Member State or a designated provider |
| Who decides it is valid | The bank, against its own records | The bank, against the issuer's signature and status |
| What the customer controls | Little; the bank holds the relationship | Which attributes are released, per presentation |
| What the bank must do | Whatever its risk appetite supports | Accept a presentation when a user asks |
| Precondition to participate | None beyond its own systems | Registration as a relying party under Article 5b |
| Cost of asking for more data | An internal product decision | A change to a registered, declared scope |
The Wallet Does Not Repeal Strong Customer Authentication #
A recurring error in early planning decks is the assumption that wallet acceptance supersedes PSD2's authentication regime. It does not.
Strong customer authentication under Directive (EU) 2015/2366 and the regulatory technical standards in Commission Delegated Regulation (EU) 2018/389 continues to govern how payment service providers authenticate payers and authorise transactions. The Article 5f obligation is layered onto that, not substituted for it. A bank must still satisfy its SCA obligations; it must additionally accept a wallet when a customer offers one for strong user authentication.
The practical question is therefore not "does the wallet replace our SCA factors" but "what does a wallet presentation contribute to an SCA-compliant authentication, and what must we still do ourselves". That is an architecture question with a real answer, and it is worth working out before the deadline rather than during it, because the two regimes were drafted by different instruments for different purposes and they meet inside your authentication service.
There is a related trap in the liability model. Under the current arrangement, the bank issues the credential and therefore owns most of the failure modes. Under the new one, the credential is issued elsewhere and verified by the bank. Verification failing open, an issuer's revocation status being stale, or a presentation being replayed are all failure modes the institution has limited history with, and the allocation of loss between wallet provider, issuer and relying party is precisely the sort of question that gets settled slowly and expensively after the first incident.
What Verification Does Not Tell You #
Here is the part that consistently surprises identity teams, and it is worth stating plainly.
A wallet presentation gives cryptographic assurance that a set of attributes was issued by a trusted authority to the holder of the wallet, and that the holder is present. It tells you, with high confidence, that this person is who the state says they are.
It does not tell you that this person is the customer who opened the account.
For onboarding, that distinction does not matter much — the wallet is close to ideal, and identity proofing that currently takes a document scan, a liveness check and a manual review collapses into a single presentation. For an existing book, it matters enormously. Binding a state-issued digital identity to an account opened in 2014 against a passport that has since expired, under a name that may have changed, is a record-linkage problem. It is the same entity-resolution work that open finance and customer-data programmes keep rediscovering, and it does not get easier because the incoming credential is cryptographically excellent.
Institutions that treat wallet integration as a channel project will build a working presentation flow and then discover that the interesting failure is a match rate against their own customer master. That work has a long lead time and no dependency on any implementing act. It can start now.
Table 2: What the build actually decomposes into #
| Workstream | Depends on the wallet existing? | Can start now |
|---|---|---|
| Relying-party registration in each Member State of establishment | Registrar operational | Decide the attribute scope you will declare |
| Presentation verification, trust-list and revocation handling | Yes, for end-to-end testing | Protocol selection and service design |
| Binding a verified identity to an existing customer record | No | Yes — this is the long pole |
| Reconciling wallet acceptance with SCA obligations | No | Yes |
| Liability, incident and dispute handling for a credential you did not issue | No | Yes |
| Attribute-minimisation review of existing journeys | No | Yes |
Four of six do not wait on anything.
The Operating Playbook #
Six moves, in the order I would sequence them.
- Name the accountable owner. This sits across identity, onboarding, payments and legal, which in most banks means it sits nowhere. Wallet acceptance fails as a federated initiative.
- Decide the attribute scope before the registrar asks. The registration declares what you will request. Work out the minimum that supports your journeys, because the declared scope is easier to widen deliberately than to narrow after a privacy review.
- Start the binding problem now. Matching a state identity to an existing customer record is the workstream with the longest tail and the fewest dependencies. It is also the one that determines whether acceptance is a good experience or a support queue.
- Write the SCA reconciliation down. Document how a wallet presentation interacts with your existing authentication factors and where the regimes meet. Do it as an architecture decision record, not a slide.
- Model the failure modes you have never owned. Stale revocation, issuer outage, verification failing open. You did not issue this credential; assume the failure modes are not yours to control and design accordingly.
- Use the twelve-month gap deliberately. Wallets are live from December 2026. Treat 2027 as the year you operate the capability, not the year you build it.
Banks spent the open banking era learning that a mandated interface is rarely just an interface. This is the same lesson arriving through a different instrument. The institutions that read Article 5f as an integration ticket will deliver a compliant presentation flow on time and still be unable to answer the only question that matters at the counter: is the person holding this wallet the person whose account you are about to open?
Frequently Asked Questions #
When exactly does a bank have to accept the wallet?
By 24 December 2027 for large and medium relying parties that are legally or contractually obliged to use strong user authentication and operate in a listed sector, which includes banking and financial services. The separate obligation on Member States to make at least one wallet available runs a year earlier, to 24 December 2026.
Is this settled, or could the dates move?
Regulation (EU) 2024/1183 is in force and the dates sit in the adopted text rather than in a proposal under negotiation. That makes it materially firmer than most of what banks are currently planning against, and it is one of the reasons this file rewards early work.
Does accepting a wallet mean we can retire our own authentication?
No. The obligation is to accept a wallet presentation when a user voluntarily asks to use one. Customers who do not hold a wallet, or who do not wish to use it, still need to be served, and PSD2's strong customer authentication requirements continue to apply to payment journeys regardless.
What does the Article 5b registration actually commit us to?
Registering in the Member State where you are established, identifying the institution, and declaring the intended use including the attributes you intend to request. The practical effect is that your data-minimisation position becomes a matter of public record and a constraint on future product changes.
We are not established in the EU. Does this reach us?
The acceptance obligation in Article 5f attaches to relying parties operating in the listed sectors within the Union's framework, and the registration obligation attaches to the Member State of establishment. Group structure and where each regulated entity is established determine the answer, which is a legal question worth resolving early rather than a technical one.
What is the single most useful thing to start this quarter?
Entity resolution between a state-issued identity and your existing customer master. It has no dependency on wallets, implementing acts or registrars, it is the workstream most likely to determine whether acceptance works in practice, and it is the one nobody owns by default.
References #
- European Parliament and Council of the European Union, 2024. Regulation (EU) 2024/1183 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework. Brussels: Official Journal of the European Union. Available at: European Parliament and Council of the European Union, 2024..
- European Commission, 2026. European Digital Identity Wallet. Brussels: Directorate-General for Communications Networks, Content and Technology. Available at: European Commission, 2026..
- European Commission, 2026. EUDI Wallet Architecture and Reference Framework. Brussels: European Commission. Available at: European Commission, 2026..
- European Parliament and Council of the European Union, 2015. Directive (EU) 2015/2366 on payment services in the internal market (PSD2). Brussels: Official Journal of the European Union. Available at: European Parliament and Council of the European Union, 2015..
- European Commission, 2018. Commission Delegated Regulation (EU) 2018/389 supplementing Directive (EU) 2015/2366 with regard to regulatory technical standards for strong customer authentication. Brussels: Official Journal of the European Union. Available at: European Commission, 2018..
- OpenID Foundation, 2026. OpenID for Verifiable Presentations. San Ramon: OpenID Foundation. Available at: OpenID Foundation, 2026..
Last reviewed .