Digital Identity Verification at Onboarding

Most eIDAS 2.0 content is written for compliance and legal teams, and it reads that way — obligations, deadlines, “member states shall.” None of it tells you what to actually put in a specification when the development team asks what the signup flow does on the Tuesday morning eIDAS 2.0 goes live in one country and stays exactly as it was in six others. This one’s for the BA holding that spec. 

The honest version of “engineer eIDAS 2.0 into the signup flow” isn’t a replacement project. It’s an addition to a system that already has to keep working, for years, across markets that are adopting the EU Digital Identity Wallet on completely different timelines. Acceptance criteria that only account for the wallet, without accounting for everywhere it isn’t live yet, are the ones that come back from engineering with the same question every time: “what happens for everyone else?” 

The rollout you’re specifying against is not uniform, and won’t be for years 

Under eIDAS 2.0 (Regulation (EU) 2024/1183), member states are required to offer at least one certified EUDI Wallet to citizens and businesses within 24 months of the relevant implementing acts being adopted — a timeline broadly expected to land in late 2026. As of Q2 2026, however, implementation across the EU-27 sits in three visibly different tiers. France, Italy, and Poland already have production or near-production wallets; Germany and Sweden are running beta programmes; a handful of smaller states haven’t published a national strategy at all. A homogeneous EU-wide launch on the current deadline is already considered unlikely by people tracking it closely — what arrives is a first wave of compliant-or-near-compliant launches with genuinely different functional scope market to market. And the deadline that actually matters for a bank’s obligations is later still: large platforms and regulated-sector organisations, banking included, are expected to be required to accept the wallet as a primary authentication method by late 2027. 

That gap — wallets appearing country by country from 2026, banks obligated to accept them EU-wide only from 2027 — is the entire shape of the specification problem. A signup flow spec written as “if wallet available, use wallet; else, fall back to eKYC” sounds complete, but it isn’t. “Available” isn’t a global boolean — it’s a per-country, per-issuer, slowly-shifting fact your system needs to be able to check and act on independently for each market it operates in, for a multi-year window, not a cutover weekend. That’s a feature-flagged capability matrix, not a runtime fallback — and it needs to be specified as one from the first version, because retrofitting per-country branching into a spec that assumed a single global switch is exactly the kind of rework a precise spec exists to avoid. 

The rail under the most pressure isn’t the one everyone’s planning around 

It’s tempting to treat the current eKYC rail as the stable baseline while the wallet integration is the hard new work. In this context, eKYC is the umbrella term for the set of remote identity-verification methods a bank already operates — and the specific rails within it deserve individual scrutiny. Germany’s own supervisory picture illustrates why. BaFin recognises four remote identification rails under the GwG: video identification, chip-based eID, qualified-electronic-signature-bundled flows, and automated document-plus-biometric verification. 

Video-ident — trained agents verifying a customer against ID document security features over a live video call — remains widely used, and it’s also the rail under the most active pressure right now. Deepfake and injection attacks target exactly that channel: a live video session is precisely the surface where synthetic media threats are most effective. 

That’s worth putting in front of engineering leadership as its own priority, independent of the eIDAS 2.0 timeline: if video-ident is the primary rail your onboarding flow depends on today, the acceptance criteria for liveness and injection-attack detection on that existing flow need attention now, not as a “we’ll harden it later, once the wallet takes over” deferral. The wallet migration is a multi-year project. The video-ident attack surface is a today problem wearing a future-looking regulation as an excuse to wait. 

What the wallet flow actually requires, in terms a developer can build against 

When a market’s wallet is live and a bank has completed relying-party registration, the technical shape of a presentation request is specific enough to write real acceptance criteria against, not just “integrate with the EUDI Wallet”: 

Ubiquitous

The signup flow SHALL request only the PID attributes required for the specific product being opened (name, date of birth, and residential address for a current account — not the full Person Identification Data set) via an OpenID4VP presentation request, honouring the wallet’s selective disclosure mechanism. 

Event-driven

WHEN a wallet returns a presented credential, the system SHALL verify the credential’s signature chain against the relevant Member State’s published trusted-issuer list before accepting any attribute value from it. 

Event-driven

WHEN a presented PID attestation does not carry “high” level of assurance as defined under eIDAS 2.0’s implementing regulation, the system SHALL reject wallet-based onboarding for that session and route the customer to the fallback eKYC rail — a “substantial” assurance attestation is not sufficient for account opening. 

Event-driven

WHEN a presented credential’s issuer certificate has been revoked, the system SHALL treat the presentation as failed and log the revocation check result, not merely the outcome. 

Two details matter enough to call out explicitly in a spec, because they’re the ones a developer building against a vaguer requirement will guess wrong. 

First, selective disclosure isn’t an implementation nicety — it’s the point of the credential format. A spec that asks the wallet integration to pull the full PID every time, “just in case a later screen needs it,” works against the framework’s actual design and creates a data-minimisation problem worth flagging to whoever owns privacy sign-off. 

Second, “high” assurance is not a formality to check once and forget. eIDAS 2.0’s implementing regulation ties this requirement to the ETSI TS 119 461 technical standard specifically, and a “substantial”-level attestation, which some issuance paths can produce, does not carry the same weight for AML customer due diligence. A spec that doesn’t distinguish assurance levels in its acceptance criteria is a spec that will let engineering treat any successful wallet presentation as equally trustworthy — which it isn’t. 

The dependency that isn’t a sprint — relying party registration 

A bank cannot start accepting wallet presentations by shipping code. Before any of the flow above is technically possible, the institution has to register its intent to rely on the EUDI Wallet with the relevant Member State authority — a formal, non-engineering process with its own lead time, run by legal and compliance, not by the delivery team. This belongs in a BA’s delivery plan as an explicit blocking dependency with its own timeline, tracked the same way an external vendor contract would be, not folded into “integration work” as if it were a configuration step the engineering team controls. A spec that’s otherwise perfect and ships against an assumption that registration is already complete is a spec that’s going to sit blocked on a legal process nobody scheduled for. 

Spec around the part that’s still genuinely unsettled, rather than waiting for it to resolve 

Here’s the honest gap: AMLR sets out what banks must achieve — reliable, risk-based customer due diligence — while eIDAS 2.0 and its technical standards describe how a high-assurance identity proofing process can look. What the industry has been waiting on is the granular Regulatory Technical Standards that say explicitly whether a high-assurance wallet presentation, on its own, fully satisfies a bank’s CDD obligation, or whether it’s one strong input among several a risk-based decision still has to weigh. 

That guidance has been described as still catching up even as wallets start going live — which means a spec written today can’t treat “the RTS said X” as a fixed input. It can only design for the range of reasonable answers. 

The move that survives whichever way that guidance lands is the same discipline we’ve written about before for specs that have to survive being read by something — or someone — other than the person who wrote them: treat wallet presentation as one signal into a risk-based decision engine that also runs sanctions screening, PEP checks, and whatever risk-scoring already gates a new account, rather than hard-coding “valid high-assurance presentation received” as an automatic full-CDD pass. If the eventual RTS says a high-assurance presentation is sufficient on its own, that’s a configuration change to how much weight the signal carries — not a rebuild of the decision engine. If it says otherwise, the architecture already assumed as much. Specifying flexibility into the exact point that’s still unresolved is cheaper, by a wide margin, than specifying certainty and being wrong about which certainty to specify. 

None of this is really a story about a new regulation. It’s the same discipline regulated banking delivery has always demanded of a requirements document — precise enough that an engineer building from it doesn’t have to guess, and honest enough about what’s still unresolved that the system built from it doesn’t have to be rebuilt when the answer arrives. eIDAS 2.0 just made sure that discipline has to hold across country borders and a rollout timeline nobody fully controls, instead of inside one team’s release calendar.