eIDAS 2 and the EU Digital Identity Wallet for KYC

eIDAS 2 turns a phone into a legal ID — and your KYC has to accept it

By the end of 2026, every EU Member State must offer its citizens and residents at least one certified EU Digital Identity Wallet (the EUDI Wallet). EEA countries — Iceland, Liechtenstein, Norway — get one extra year. That deadline comes from Regulation (EU) 2024/1183, known as eIDAS 2, which entered into force on 20 May 2024 and rewrote the original 2014 eIDAS framework.

For anyone running customer onboarding in Europe, this is not a distant standards exercise. A wallet-presented identity issued at assurance level "high" is, by law, as good as meeting your customer face to face. If you verify identities for a living, you will be expected to accept it.

Here is the part vendors gloss over: accepting the wallet is necessary, not sufficient. Most of the people you onboard in 2027 still won't have a usable one. This guide covers both halves — what the wallet obliges you to do, and what it can't do for you yet.

Why eIDAS 2 lands directly on KYC

eIDAS 1 (2014) gave the EU qualified signatures and trust services. It barely touched customer onboarding. eIDAS 2 does, because of one bridge written into a different law.

The EU's Anti-Money Laundering Regulation — AMLR, Regulation (EU) 2024/1624 — explicitly recognises the EUDI Wallet as a valid means of identifying and verifying a customer during customer due diligence. So the wallet isn't a "nice alternative" to your KYC flow. It is a regulator-blessed method of doing the identification step itself. When the new EU anti-money laundering authority, AMLA, begins direct supervision later this decade from Frankfurt, wallet-based identification will be a baseline expectation, not an edge case.

If you onboard customers in regulated EU verticals — payments, crypto under MiCA, lending, gambling — eIDAS 2 and AMLR are now one connected obligation. Treating them separately is how teams end up rebuilding onboarding twice.

What the EUDI Wallet actually lets you verify

The wallet carries two things you can request as a business:

• Person Identification Data (PID) — the core identity set (name, date of birth, nationality, a unique identifier) issued and guaranteed by the Member State itself. This is the high-assurance backbone.
• Electronic Attestations of Attributes (EAA / QEAA) — verifiable claims issued by trusted parties: a diploma, a bank account, a professional licence, proof of address, an "over 18" flag.

Three properties matter for verification design:

• Assurance level "high". The wallet meets the strictest eIDAS assurance tier. For most KYC purposes, a valid PID presentation removes the need for separate document capture and liveness on that user.
• Selective disclosure. A customer can prove a single attribute — "over 18", "resident in Spain" — without handing over the full document. This is exactly what age-gating regimes now demand, and it cuts the personal data you store.
• Cross-border by default. A wallet issued in Portugal must be accepted by a relying party in Germany. One integration covers all 27 Member States, which is the same passporting logic that makes MiCA attractive.

New to the underlying concepts? Our primer on what KYC is covers the identification and verification steps the wallet is designed to satisfy.

You have to register as a relying party — and you can't over-ask

Accepting wallet credentials is not open season. To request data from a wallet, a business must register as a relying party with the supervisory body in its Member State and declare, up front, exactly which attributes it intends to request and why.

Two consequences follow:

• Data minimisation is enforced at the protocol, not left to your conscience. If you register to check "age over 18", you cannot quietly pull the full date of birth. Over-collection is a registration breach, not a grey area.
• Users can refuse and still transact. The framework gives the holder control over each disclosure. Your flow has to handle a partial or declined presentation gracefully — which means a fallback path is mandatory, not optional.

The reality check: the wallet will not replace your KYC stack in 2027

This is the contrarian part, and the part that protects your roadmap.

Vendors selling "wallet-ready KYC" imply you can retire document and biometric verification. You can't — not for years. Look at how the rollout is actually arriving:

• Member States are launching with limited functionality. Several wallets will ship at the deadline carrying only PID, or PID plus a mobile driving licence, with private-sector attestations coming later. The full attribute ecosystem is not switched on at once.
• Citizen adoption starts near zero. A legal right to a wallet is not the same as a population that holds and uses one. Card-based eID schemes took a decade to reach majority use in the countries that led on them.
• Non-EU customers have no wallet at all. Every traveller, expat applicant, and customer outside the EU still needs document-and-selfie verification. For most cross-border businesses that is a large share of new users.

So the correct 2027 architecture is hybrid: accept the EUDI Wallet when a customer presents one, and fall back to AI-driven document and biometric verification for everyone else — without forcing the user to notice which path they're on. Teams that bet everything on the wallet will be unable to onboard the majority who don't yet have one.

How Joinble fits

Joinble's AI-powered identity platform is built for exactly this split. It acts as the verification and orchestration layer in front of your onboarding:

• Accept and validate EUDI Wallet presentations as a registered relying party, requesting only the attributes you declared.
• Fall back automatically to document recognition, certified liveness, and biometric matching when no wallet is present or a presentation is declined.
• Run sanctions and PEP screening on the resulting verified identity, regardless of which path produced it.

The routing decision — wallet versus document, what to request, when to escalate — is handled by Joinble's identity agents rather than hard-coded into your application. As wallet adoption climbs across fintech and other regulated verticals, the same integration shifts more traffic to the wallet path without a rebuild on your side.

How to prepare before the deadline

• Map which of your onboarding steps a high-assurance PID presentation would replace, and which (screening, ongoing monitoring) it never will.
• Decide the minimum attribute set you genuinely need, then register as a relying party for that set — nothing more.
• Build the fallback path first. It carries most of your volume in 2027 and is the part eIDAS 2 does not solve.
• Align the wallet work with your AMLR customer due diligence obligations so you implement identification once, not twice.

FAQ

Does eIDAS 2 force my business to accept the EU Digital Identity Wallet?

eIDAS 2 obliges Member States to provide wallets and requires very large platforms and several regulated sectors to accept them. Even where acceptance is not strictly mandatory for your sector, the AML Regulation recognises the wallet as a valid customer due diligence method, so refusing it puts you at a competitive and supervisory disadvantage.

When do EU Digital Identity Wallets become available?

Every EU Member State must make at least one certified EUDI Wallet available to citizens and residents by the end of 2026. EEA countries — Iceland, Liechtenstein, and Norway — have until the end of 2027. Functionality will expand after launch rather than arriving complete.

Can the EUDI Wallet replace document and biometric verification?

For EU users who hold a wallet and present a high-assurance PID, it can replace document capture and liveness for that identification step. It cannot cover non-EU customers, users without a wallet, or declined presentations — which is why a document and biometric fallback remains necessary well beyond 2027.

What is a relying party under eIDAS 2?

A relying party is any business that requests and relies on data from a user's wallet. You must register with your Member State's supervisory body and declare in advance which attributes you will request. The framework enforces data minimisation, so you cannot collect attributes beyond your registered purpose.

How does eIDAS 2 relate to the EU AML Regulation?

The AML Regulation (Regulation (EU) 2024/1624) names the EUDI Wallet as a valid means of identifying and verifying customers during due diligence. eIDAS 2 creates the wallet; AMLR makes wallet-based identification a recognised way to meet your KYC obligation. Plan the two together.