EUDI Wallet readiness for regulated businesses

On 4 December 2024, the European Commission published the first implementing acts under Regulation (EU) 2024/1183, starting a 24-month clock that obliges every EU member state to offer its residents a European Digital Identity Wallet (EUDI Wallet) by late December 2026. Germany, the largest market in the bloc, has already said its state wallet will launch on 2 January 2027, days after that clock runs out, according to the Federal Ministry of the Interior’s wallet documentation. That small gap tells you most of what you need to know about the next 18 months. The wallets are coming, the timetable is law, and the rollout will be uneven. This guide covers what the EUDI Wallet changes for regulated onboarding, which deadlines bind you, what a wallet credential does and does not prove, and how to get ready without rebuilding your stack.

What is the EUDI Wallet and why does it change onboarding?

The EUDI Wallet is a government-backed digital wallet that lets EU residents store person identification data (PID) and other verified credentials on a phone, then share them selectively with services that need to check identity. The legal basis is Regulation (EU) 2024/1183, the framework update better known as eIDAS 2.0, which we unpacked separately in how eIDAS 2 regulations reshape identity verification. Each member state must offer at least one wallet, free of charge, and must recognise wallets issued by other member states.

What the wallet actually holds

The core credential is the PID, a government-issued attestation of the attributes that identify a person, including name, date of birth, and a national identifier where the member state uses one. Around the PID, the framework supports electronic attestations of attributes, which is where driving licences, diplomas, professional qualifications, IBANs, and age attestations will live. Selective disclosure is built into the design, so a user can prove they are over 18 without revealing a birth date, or share a name and nationality without exposing an address. For your data-minimisation posture under GDPR, that granularity is an improvement over holding a full document image on file.

How the wallet relates to national eID schemes

The wallet does not arrive into empty space. Much of the EU already runs national eID schemes, from Nordic bank-issued identities to state eID apps, and those schemes keep working under the amended framework. The wallet adds a common, cross-border container on top of that landscape rather than replacing it. In several member states the wallet will be built by the same institutions that run the national scheme, and early adoption will likely be strongest where residents already use an eID daily. For your architecture, the practical consequence is that wallet support and eID support are siblings, not successors. A user in an eID-mature market may present either credential for years, and your flow should accept both without caring which arrived.

Why onboarding changes shape

For onboarding teams, the shift is in where identity assurance comes from. Today your flow establishes identity at session time, from a document capture, a biometric check, or a database lookup. A wallet presentation reverses that. The user arrives holding a credential a government authority has already verified, and your job becomes validating the presentation rather than constructing the proof. Session time drops, capture friction disappears for wallet holders, and the evidence in your CDD file changes from an image you judged to a cryptographic presentation you validated.

Two design choices in the regulation shape everything downstream. Wallet use is voluntary for citizens, so adoption will build gradually and unevenly across 27 markets. And acceptance is mandatory for regulated businesses on a fixed date, whether or not your customers have adopted it by then. You will carry wallet acceptance and every existing verification path in parallel for years. Plan for that from the start.

Which deadlines actually apply to your business?

Three dates matter between now and the end of 2027, and only one of them binds your business directly.

The sequencing is the point most planning misses. Your AMLR remediation lands in July 2027 and your wallet acceptance obligation lands five months later. Teams that treat these as two separate programs will specify their new CDD processes in the summer and then reopen them before Christmas to add a credential type. Treat them as one program with two milestones, and specify wallet credentials as a CDD input from the first workshop.

Scope on the acceptance obligation deserves a careful read rather than a headline read. The duty attaches to services where the law already requires strong user authentication or formal identification of the user, which is why banks, payment institutions, telecoms, and large online platforms sit squarely inside it. A business outside those categories can still choose to accept the wallet voluntarily, and many will, because a pre-verified credential converts better than a document upload. The strategic question for a voluntary adopter is timing, not obligation. Moving early captures the conversion upside while competitors are still reading the implementing acts.

Does a wallet PID satisfy KYC under the AMLR?

A wallet PID satisfies the identity verification component of customer due diligence, and nothing else. That single sentence should anchor your policy work, because both halves of it get misread.

What the PID covers at high assurance

The PID is issued against a national identity anchor and presented from a certified wallet, which makes it strong evidence of who the customer is. The AMLR recognises electronic identification means under the eIDAS framework, including the wallet, as a basis for verifying customer identity. In practice that means a compliant wallet presentation can replace document collection and biometric matching for the identification step, with less friction than any capture flow you currently run. Your CDD policy still has to specify which assurance level each customer category requires, so the mapping between wallet assurance and your risk tiers is policy work you own, not something the wallet decides for you.

How assurance levels map to your risk tiers

The eIDAS framework grades electronic identification at three levels of assurance, low, substantial, and high, and the wallet PID is anchored at the top of that scale. Your CDD policy work is deciding which customer categories can onboard at which level. A sensible starting posture treats substantial as the floor for standard retail onboarding and reserves high for enhanced due diligence triggers, higher-risk products, and business relationships where the AMLR demands more. Writing that mapping down before the deadline matters, because an auditor’s first question about a wallet-verified file will be why that assurance level was sufficient for that customer.

What the wallet does not do

Screening is absent from the wallet by design. A PID presentation tells you the customer is who they claim to be. It does not tell you whether that person appears on a sanctions list, holds a political position, carries adverse media, or has changed risk profile since onboarding. Every obligation in your AML screening stack survives the wallet untouched, including ongoing monitoring. The audit gap to avoid is the tempting shortcut of logging “wallet verified” as if it closed the whole CDD file. Regulators will read that file the same way they read one built on documents, and the screening evidence still has to be in it.

Fraud controls follow the same logic. A genuine credential can be presented by the wrong person under coercion, a synthetic identity can predate its wallet enrolment in rare failure cases, and account takeover after onboarding remains untouched by anything the wallet proved on day one. Device signals, behavioural analytics, and step-up verification keep their jobs in a wallet-era stack.

What does accepting the wallet require technically?

Registration comes first, protocol support second. Both have lead times worth respecting.

Wallet-relying party registration

Any business that wants to request and receive wallet credentials must register as a wallet-relying party in the member state where it is established. Registration means proving your legal identity and declaring what data you intend to request and why. Each member state runs its own register under the implementing rules, so a group with entities in five countries should not assume one registration covers all five. Map your entity structure against your registration obligations early, because national registers will open on different dates with different procedures.

The protocols your stack must speak

Wallet presentations reach you through a defined set of standards, and your onboarding flow has to consume them.

• OpenID for Verifiable Presentations (OpenID4VP) carries the presentation request and response between your service and the wallet.
• ISO/IEC 18013-5 defines the mdoc credential format the wallet uses for identity documents.
• W3C Verifiable Credentials covers the attestation format for other credential types.

Validation is the half of the protocol work that determines whether your CDD file holds up. A presentation is only as good as the trust chain behind it, so your flow has to verify that the credential was issued by a wallet provider on the EU trust framework, that it has not been revoked, and that the presentation is bound to the user in the session rather than replayed from another one. Logging those checks is what turns a wallet presentation into audit evidence.

None of this is exotic engineering, but it is new plumbing in a flow that regulators audit. Germany opened a sandbox for testing wallet integrations in early 2026, run through its Federal Agency for Disruptive Innovation, as reported by Biometric Update in January 2026. Rehearsing there before your build hardens is cheaper than refactoring after.

The data-handling questions registration forces

Registration also forces a privacy conversation that onboarding teams sometimes defer. The register entry declares what data you request and for what purpose, which makes over-collection visible to regulators and to users in a way a document upload never was. Wallet users see and approve each attribute you ask for at presentation time. Requesting a full attribute set when your CDD file needs four fields will show up as friction in your funnel and as a question in your next supervisory review. Design the request around the minimum attribute set your policy justifies, and document the justification alongside the registration.

What happens if your customers’ wallets arrive late?

Wallet-only onboarding strands real customers, and the rollout calendar makes that certain rather than hypothetical. Germany’s wallet arrives in January 2027. Other member states will hit the December 2026 deadline with wallets that vary in scope, credential coverage, and early adoption. A French customer may hold a full wallet in January 2027 while a German customer holds none for weeks and a Portuguese customer holds one with a thinner credential set. Every one of them is still your customer, and every one still has to pass CDD.

Germany deserves its own line in your planning, because it is the largest onboarding market in the EU and the one whose calendar is publicly specific. The state wallet launches on 2 January 2027 through the Federal Ministry of the Interior, with the market opening to private wallet providers afterwards. A business with a large German customer base should plan for a wallet lane that carries near-zero German volume through 2026, then ramps through 2027 while the December acceptance deadline approaches. The sandbox is the useful part of the German timeline today, since integration testing can start well before residents hold wallets.

Adoption inside each market adds a second layer of uncertainty on top of the launch calendar. Wallet use is voluntary, and no member state has published a credible adoption forecast for year one. Some markets will see fast uptake because the wallet ships inside an app residents already use, while others will build from zero. Sizing your wallet lane on the assumption of majority adoption in 2027 would be a planning error in either direction. The lane has to exist, and it has to carry whatever share of your applicants actually arrives holding a wallet, whether that is five percent or fifty.

Your non-EU customers make the fallback question permanent rather than transitional. A wallet mandate covers EU residents. If you onboard customers from the UK, the Gulf, Southeast Asia, or the Americas, wallet acceptance adds a lane without replacing any existing one.

The architecture that survives this is a credential waterfall inside one journey. Wallet presentation where the user holds one. National eID where the market has one, and national eID schemes already cover much of the EU. Docless verification against authoritative databases where neither applies. Document and biometric capture as the final fallback. Building four separate flows for those four paths is the failure mode. The teams in good shape run them as one electronic identity verification journey with routing logic deciding per user and per market, so a late wallet launch in any single country changes nothing about the program.

The four paths trade off differently, which is why the waterfall order should vary by market rather than being fixed globally.

How does the wallet interact with signatures and account access?

Onboarding is the first use case, but the wallet’s mandate reaches into two flows banks already run at scale. Both are worth planning alongside CDD rather than after it.

Qualified electronic signatures are the clearest adjacency. A qualified signature requires verified identity behind a qualified certificate, and the wallet is designed to carry that identity to the signing moment. Under the framework, wallet-held credentials can feed certificate issuance, which shortens the distance between verifying a customer and getting a legally binding signature from them. Loan agreements, account mandates, and high-value contracts all sit in that flow. For the mechanics of qualified signatures themselves, the assurance chain runs from identity proofing through a qualified trust service provider to a signature that carries legal equivalence to handwriting across all 27 member states.

Strong user authentication is the second adjacency, and the reason the acceptance obligation names it. Where a service already requires strong authentication for access, the wallet becomes an authentication means the user can choose. For a bank, that puts wallet support on the roadmap of the digital channels team, not only the onboarding team. Treating wallet acceptance purely as a KYC project misses half its surface area, and the half that touches every returning customer rather than only new ones.

How to sequence EUDI readiness between now and December 2027

Five steps, in order, starting now. Each one feeds the next.

1. Map your obligation. List every group entity that qualifies as an obliged relying party, the member states involved, and which services trigger the acceptance requirement. This determines where you register and what you must accept, and it usually surfaces at least one entity the first draft missed.
2. Set your assurance policy. Decide which customer categories require which eIDAS assurance level in your CDD policy, and write wallet presentations into the AMLR program as an identity verification input from the start. This is the step that merges the July and December 2027 deadlines into one body of work.
3. Plan the registration path. Calendar the wallet-relying party registration procedure in each member state of establishment, and assign ownership, because registers will open unevenly through 2026 and 2027. Registration is administrative work with legal review attached, so its lead time is measured in months.
4. Design the credential waterfall. Specify the routing order of wallet, national eID, database verification, and document capture per market and per risk tier, as one journey rather than four builds. The waterfall design is also where the conversion upside lives, because every user routed to a lower-friction path is a user who did not abandon a capture flow.
5. Rehearse and monitor. Test presentations in available sandboxes, starting with Germany’s, and put a monthly check on implementing-act publications and national wallet launches, because the technical specifications are still moving.

A team that finishes steps one and two in 2026 has converted the December 2027 deadline from a rebuild into a routing change. That is the whole game.

Where Shufti fits in EUDI Wallet readiness

If the acceptance obligation reads like one more integration program stacked on your AMLR work, that is the rebuild fear talking, and it is avoidable. Shufti’s eIDV hub already treats identity as credential-agnostic. The Passive layer verifies users against 230+ authoritative databases across 85+ countries with zero user involvement, and the Active layer connects 40+ national eID schemes, so the rails that will carry wallet presentations already carry government-anchored credentials today. The hub architecture is built to take the EUDI Wallet as one more input on those rails, with Journey Builder routing each user to the right path per market and per risk tier, and screening continuing into AML, PEP, and sanctions where the wallet stops. Shufti’s qualified electronic signature flow is live today, and its infrastructure is designed to accept EUDI Wallet credentials for certificate issuance.