How the eIDAS 2.0 Identity Wallet Changes KYC Onboarding Across the European Union

The European Union's eIDAS 2.0 framework, Regulation (EU) 2024/1183, entered into force on May 20, 2024 and obliges every member state to offer citizens a free European Digital Identity Wallet within 24 months — landing in 2026 — which lets a customer prove identity attributes to a bank from a government-issued app instead of uploading passport scans and selfies. For KYC architecture the change is structural: the authoritative record moves from a photographed document to a cryptographic presentation.

3G Times publishes information, not legal advice. Onboarding designs that touch AML obligations should be reviewed with counsel and the institution's AML officer.

What does the wallet actually hold?

The framework amends the 2014 eIDAS Regulation (EU) No 910/2014 and defines a container of verifiable credentials anchored to state-issued identity. The core items are the Person Identification Data set (PID) — name, birth date, and identifiers derived from national civil registries — and electronic attestations of attributes issued by qualified providers: proof of age, address, qualification, or account relationships. Each attestation carries a qualified-level assurance signature, meaning a relying party that validates it obtains the same legal presumption of reliability that qualified certificates have held since 2014. Selective disclosure is built in: a citizen can reveal that they are over 18, or that their address is in a given country, without exposing the underlying document.

Privacy constraints are statutory, not aspirational. Issuers must be technically unable to see when or where a presented attribute is used, wallets are free for natural persons, and no relying party may require users to expose more attributes than a stated purpose justifies.

How does onboarding change in practice?

Today's mobile onboarding stack — document photo, liveness selfie, OCR, and a fraud check against the result — gets a parallel path. The customer opens the bank's flow, a proximity or cross-device request reaches the wallet, the user consents to release the PID and selected attestations, and the institution receives signed attributes with a validation trail. The document-forgery problem narrows to a protocol problem: spoofing a signed presentation from a national issuer is a different, generally harder, attack class than replaying a photographed passport.

Cross-border reach is the framework's quiet achievement. A Portuguese national presenting a Portuguese-issued PID to a German neobank uses the same interoperability layer that has carried public-sector eIDs since the first eIDAS node went live, so a single onboarding design serves the Union rather than twenty-seven national variants.

What must regulated firms do?

Obligation arrives in stages. Member-state provision of wallets is the 2026 milestone; mandatory acceptance for relying parties phases in later, with the heaviest duties on very large online platforms rather than banks. Nothing in the framework forces a fintech to wait: accepting wallet presentations early is a compliance option, not a violation, provided the AML program still satisfies its own rules.

Readiness will be uneven, and product plans should assume it. Some member states have run national eID schemes at scale for a decade; others are commissioning their first qualified infrastructure against the 2026 deadline. A union-wide onboarding metric will therefore arrive gradually, institution by institution, as wallet holders accumulate — which is another argument for the dual-path design that keeps document capture warm behind the wallet button.

Anti-money-laundering duties are the boundary condition. The EU's 2024 AML package applies its core requirements mainly from mid-2027, and remote-onboarding rules already permit digital verification where the assurance is demonstrable. A wallet PID answers "who is this person per the registry" but not, by itself, every element of customer due diligence — beneficial ownership of a legal entity, screening against sanctions lists, and ongoing monitoring remain the institution's own work, now fed by better inputs and logged by the presentation protocol itself.

Where does liability sit when an attestation is wrong?

The framework distributes roles: the member state or qualified trust service provider vouches for attributes, the wallet vendor for the container, and the relying party for the acceptance decision. When a fraudulent onboarding traces back to a mis-issued attestation, the supervision chain of the issuer — national trust-service supervision, which eIDAS has run since 2014 — is the accountability path, while the bank's file shows a validated presentation. Institutions should still capture the full validation evidence per session, because the practical answer in any dispute is what the onboarding record can prove. That record is also the audit artifact examiners will ask to see.

How does wallet identity interact with payment-consent rules?

The wallet also slots into the authentication stack that payment rules already govern. Under PSD2's strong-customer-authentication regime, a payment requires two independent factors from possession, knowledge, and inherence, and the wallet naturally supplies the possession element — the credential on the device — while local biometrics or a PIN supply the second. A qualified signature or seal generated in the wallet carries, by regulation, recognition equivalent to the qualified certificates payment institutions have accepted for years, so banks can knit wallet presentations into existing strong-authentication flows rather than maintaining a parallel login path.

The longer-run convergence runs through consent management. Open-finance frameworks on both sides of the Atlantic are converging on revocable, purpose-bound access grants; a wallet that holds attribute attestations can hold payment-account consents in the same container, with the same selective-discipline applied — grant the reading of account data for twelve months to one named intermediary, and nothing else. No provision forces that integration, but nothing forbids it either, and it is the direction the implementing acts point.

What does this mean in practice?

• Design for dual-path onboarding now. Wallet presentation alongside document capture avoids a retrofit when national wallets reach critical mass in 2026–2027.
• Treat presentation logs as AML evidence. Session transcripts, attribute sets released, and validation results belong in the CDD file with retention matching the relationship, not the app session.
• Watch the implementing acts. Certificate formats and protocols for the wallet ecosystem arrive through Commission implementing acts; integration choices should track the final technical specifications rather than early reference implementations.
• Map attributes to duties. Decide in advance which CDD elements a PID plus which attestations can satisfy, and which — entity ownership, screening, source-of-funds — remain server-side work.

The wallet does not eliminate KYC; it moves the trust anchor. Institutions that treat the presentation protocol as a new evidence class — with its own logging, retention, and validation story — will convert 2026's rollout into an onboarding advantage rather than an integration scramble.

Frequently asked questions

Can a wallet presentation fully replace document verification?

For natural-person identity at qualified assurance, a validated PID presentation carries a legal presumption comparable to the underlying registry data. Institutions still owe their own CDD judgment, and entity customers, ownership structures, and screening require separate evidence the wallet does not supply.

Are banks required to accept the wallet in 2026?

The 2026 milestone binds member states to offer wallets, not every private service to accept them. Mandatory acceptance duties phase in later and fall first on the largest online platforms; banks adopting early do so as a design choice within their AML program.

How does selective disclosure affect AML files?

Selective disclosure limits what the customer reveals, not what the institution must record. The onboarding file should log the attribute set requested, what was released, and the validation result — the audit story survives even when the underlying document never appears.