Why We're Bringing in eID: The Bridge to Privacy-First Age Verification You Can Use Today

We started with the wallet. Here's why we're adding the bank.

If you have read this blog before, you know our thesis: the EU Digital Identity Wallet changes age and identity verification from a data-collection exercise into a single cryptographic question — is this person over 18? — answered yes or no, with no birth date, no document, and no name changing hands.

We still believe that. It is the destination.

But there is a gap between the destination and today, and that gap has a date on it. The rules that force merchants to verify age are arriving now. Production EU Digital Identity Wallets, in enough hands to verify against, are not — the realistic window is late 2026 into 2027. A verifier that only speaks "wallet" has nothing to talk to this year.

So we are bringing in eID — the bank and national electronic identities that hundreds of millions of Europeans already carry and trust. Not as a detour from the wallet. As the bridge to it. This post explains the gap, why eID fits it so precisely, the layered model we are building around it, and why none of it is a fork in the road.

The gap: mandates now, wallets later

Look at what has already happened in the last few months:

• The Netherlands is moving toward mandatory online age verification for alcohol, with compliance today estimated at only a quarter of webshops — a regulatory lane that is open and largely unserved.
• Google Play, since 28 January 2026, requires dating apps to restrict declared minors, part of a broader child-safety wave across the app stores.
• The Digital Services Act and a June 2026 CJEU ruling are pushing adult platforms toward real age assurance, not a checkbox.
• The Commission is promoting a white-label EU age-verification app for the end of 2026 — while member states openly disagree on how many wallets and apps there will even be.

Every one of these obligations is live or imminent. And every one of them lands on merchants who cannot wait for a wallet rollout that is still, in practical terms, a 2027 event. If your only answer to "how do I verify age?" is "wait for the EUDI Wallet," you are asking a webshop selling alcohol this quarter to break the law until the infrastructure catches up.

That is not a real answer. eID is.

eID is the live bridge — and it already works the wallet's way

Bank-eID and national eID are not a stopgap technology. They are the identity rails that a huge share of Europe already runs on:

• iDIN in the Netherlands — age confirmation through your own bank login, the same gesture as an iDEAL payment.
• itsme in Belgium — used by the overwhelming majority of Belgian adults (and, notably, itsme owns iDIN, so one partnership reaches both markets).
• BankID, MitID, Smart-ID, Freja across the Nordics and Baltics, with eID adoption near universal.

The crucial point is not just that these exist. It is that a well-designed eID age check already behaves the way the wallet will. When a merchant asks iDIN or itsme "is this person 18 or older?", the scheme can return a single answer. The user authenticates with an identity they already have, from an issuer a regulator already trusts, and your platform never touches an ID scan or a biometric database.

In other words, eID lets you deliver the wallet's core promise — selective disclosure, government-grade trust, zero document handling — using infrastructure that is in production today. The wallet will make this the default across all 27 member states. eID makes it available to your checkout this month.

The real product: layered verification, in the right order

Adding eID is not just "one more integration." It is the first and most important layer of the model we are building the whole platform around. We call it layered verification, and the order is the entire point:

Layer 1 — eID first, always. The privacy-optimal path, and the only layer that is on by default. A bank or national eID returns a verified result with no document, no selfie, and minimal data. Most of your users in Benelux and the Nordics can complete this in seconds with an identity they use weekly.

Layer 2 — age estimation, optional. For the user who has no eID — a new resident, a foreign visitor — you may enable privacy-preserving facial age estimation (the kind that estimates age from a selfie without identifying the person and deletes the image immediately). This is age assurance, not identification, and it processes no special-category identity data when done right. It is a graceful fallback — but one you switch on deliberately, not a default.

Layer 3 — document scan, optional and last. The most data-heavy, highest-friction, highest-GDPR-exposure option. If you enable it at all, it sits behind the first two, as a last resort.

The layers you switch on are a merchant policy, and the default is strict. Each fallback is opt-in (allowAgeEstimation, allowDocumentFallback — both off unless you turn them on). And the flow is fail-closed: if a user cannot pass any layer you have permitted, verification is refused — the system does not quietly downgrade to a more invasive method to force a result through. A merchant who leaves both fallbacks off runs a provably eID-only flow that cannot collect a document or a biometric even in principle. That is the cleanest data-minimisation story you can put in front of a regulator: not "we delete the data quickly," but "we never had the ability to collect it."

The trade-off is honest and it is yours to make: a stricter policy blocks the small share of users who have no eID, in exchange for a smaller data surface. That is a decision you set per market and per vertical — and because it is explicit and logged, it is defensible.

Almost every incumbent runs this stack upside down: document upload first, because that is what they built. That single inversion — plus making the invasive layers something you opt into rather than out of — is the difference between a verification flow that leaks identity data by default and one that protects it by default. Putting eID first, and everything else behind a switch, is not a feature. It is the privacy architecture.

The privacy contract: ask only for the answer

Here is where we have to be precise, because this is where most "privacy-first" claims quietly fall apart.

The best eID schemes never hand us a birth date at all. For age verification we request the age attribute itself, not the identity behind it. iDIN, with the customer's consent, shares one-time only whether this customer is older than 18 or not — without the webshop needing to receive the exact birthdate. itsme's Qualify service confirms thresholds like 16+, 18+, 21+ or 30+ without exposing the birthdate or any ID document. In both cases the answer is computed at the source — the bank, or itsme — and what crosses the wire to us is a signed yes or no. There is nothing for us to discard, because we never receive it.

That is the default we build toward, scheme by scheme. But not every eID exposes a ready-made age flag; some can only return a verified birth date. Only in that fallback case does a birth date pass through our service at all — and there the contract is derive-and-discard: compute the single boolean the merchant needs (age_over_18, or whatever threshold applies) in memory, return that, and never persist the birth date. Either way the merchant stores a yes/no and a timestamp — never the underlying identity.

Be clear about our own role in the middle. eIDAS Pro does not save your customers' personal or sensitive data. Where a scheme returns only a boolean, we hold nothing else to begin with. Where a birth date must transit, it lives only in memory for the instant it takes to compute the answer — never written to a database, a log, or a backup (our logging strips identity fields by design). We keep no names, no birth dates, no document images, no biometrics. What remains is a minimal, non-identifying verification record — the result and a timestamp — so you can demonstrate the check took place. The strongest data you can never leak is the data you chose never to hold.

And your optional fallbacks don't change that. When you enable age estimation or a document check, the selfie or ID is captured by that specialist provider's own SDK and sent directly to them — it does not pass through, or rest on, our servers. We receive only the outcome (an age estimate, or a pass/fail), never the image. So even the more data-heavy layers deposit no biometric or document data with us.

We are honest about the frontier, too. For the EU Digital Identity Wallet — the destination — a fully standardised, date-of-birth-free proof still depends on the age_over_18 attribute, which remains optional in the current wallet rulebooks, or on a zero-knowledge proof generated on the user's own device. Those are maturing. But the privacy property they promise — prove the threshold, reveal nothing else — is one the best eID schemes already deliver today. That is exactly why eID is the right bridge: not a privacy compromise you tolerate until the wallet arrives, but the wallet's own privacy model, available now.

Why this is the same road, not a detour

The fair question: if the wallet is the destination, is eID a distraction that we will throw away in 2027?

No — for three concrete reasons.

Same privacy contract, same API. The layered model, the boolean-out interface, the derive-and-discard rule — these do not change when the wallet arrives. The wallet simply becomes a new source behind the same verification call. A merchant who integrates eID with us today keeps their integration when we light up the wallet path.

eID is a certification-independent lane. The EU Digital Identity Wallet relying-party path is gated on registration certificates (WRPAC) that no member state has fully operationalised yet. Bank-eID needs none of that machinery to serve a merchant today. It lets us — and you — build revenue and real compliance now, without waiting on a certification pipeline that is still standing up.

eID is also the on-ramp to the privacy endgame. The identity a user proves once through their bank can, in the architecture we are researching, seed a holdable credential on their own device — after which zero-knowledge age proofs mean the birth date never leaves the phone again. That own-wallet, ZKP path is genuine R&D, not a shipping promise. But it starts exactly where eID does. The bridge and the destination are the same road.

Why Benelux first

We are aiming this at the Netherlands and Belgium before anywhere else, and the logic is deliberate:

• The Netherlands has a law-driven, largely unserved need (online alcohol) and iDIN as a clean, self-serve eID rail.
• Belgium has itsme with near-universal adult adoption — and because itsme owns iDIN, one partnership reaches both markets.
• The Nordic Shopify niche is already well covered by existing players; Benelux is the open lane where the privacy-first, layered model is genuinely differentiated.

Germany and the KJM-regulated verticals (adult, gambling) are a deliberate second wave. Start where the need is sharp, the rails are clean, and the regulation rewards doing it right.

What this means for you

If you are a European merchant or platform facing an age-verification obligation this year, the message is simple: you do not have to wait for the wallet, and you should not compromise on privacy while you don't.

• You can verify age today through the eID your customers already trust.
• You can do it privacy-first, on your terms — eID by default (a yes/no straight from the bank or itsme, no birth date in sight), estimation and document fallback opt-in per market, fail-closed when a user cannot pass a permitted layer, and no identity data stored with us either way.
• And you can do it without stranding your integration, because the wallet, when it arrives, plugs into the same flow.

That is why we are bringing in eID. Not because we changed our minds about the wallet — because we found the bridge that gets you there without leaving your compliance, or your customers' privacy, waiting on a rollout.

eIDAS Pro provides privacy-first, eID-based age and identity verification for European platforms — layered across national eID schemes like itsme and iDIN, with optional facial age estimation and document fallback, and built to add EU Digital Identity Wallet verification as it goes live. Book a consultation →

This article is general information, not legal advice. Verify current obligations for your market and vertical with qualified counsel.