Why Most Organizations Can’t Actually Verify Digital Wallets
Clive Bourke
President, EMEA & APAC
Clive Bourke is President of EMEA and APAC for Daon and is a member of Daon’s Board of Directors. His team are responsible for all Daon’s business activities across Europe, the Middle East, Africa and Asia Pacific. They deliver and support biometric and identity solutions in banking, payment, public sector, aviation, telecommunication, gaming, online markets and fintech sectors.
Clive has been intimately involved in the development of Daon from start-up to an established global business with market leadership in biometrics and identity. With over 25 years of international technology experience, Clive brings a track record in taking multiple first-of-a-kind initiatives from concept to realization. He earned his Electronic Engineering degree from University College Dublin in Ireland.
In his free time, Clive enjoys going to the gym, running, hanging with family and socializing, reading and playing golf.
February 12, 2026
Digital wallets are scaling faster than the infrastructure needed to verify them. Governments are mandating wallet rollouts through regulations like eIDAS 2.0, tech giants are integrating wallets into operating systems, and user adoption is accelerating across multiple parallel tracks. Meanwhile, most organizations cannot actually verify wallet credentials when users present them.
Traditional identity systems place organizations in control of credentials while users request access. The wallet model inverts this relationship entirely. Users now control credentials, and organizations must request specific claims. This isn’t just a user experience change. It requires fundamentally different technical architecture, and most organizations haven’t built it yet because they optimized for a different model.
The problem isn’t whether wallets will reach users. Regulatory mandates and market forces guarantee they will. The problem is whether organizations built the right kind of verification infrastructure to use those wallets when they arrive. Understanding why most haven’t requires examining what wallet verification means from a technical perspective.
What Changed: From Centralized Storage to Selective Disclosure
The old identity model was straightforward. Organizations stored your credentials, you authenticated to access them, and organizations controlled what data existed about you. You requested permission to use services, and those services determined what information they needed to grant access.
The wallet model inverts every element of this relationship. You store your credentials, organizations request specific claims, you control what data gets shared, and organizations must verify without centralizing that data. This inversion creates profound technical implications.
Consider selective disclosure, the core innovation that makes privacy-preserving wallet verification possible. In traditional systems, proving you’re old enough to access age-restricted content meant showing your entire ID with your full birthdate visible. The wallet model changes this fundamentally. An organization requests proof that you’re over 18, and you provide a cryptographic proof without revealing your actual birthdate. Zero-knowledge proofs allow mathematical verification without data exposure. You share the claim (“I’m over 18”), the verifier validates the proof, but the underlying data (your birthdate) never gets transmitted.
This creates verification challenges that most organizational identity systems cannot handle. Those systems were designed for centralized credential storage where verification logic assumes full document access. Compliance frameworks were built around data retention not data minimization. The infrastructure lacks capability to request specific attributes and validate cryptographic proofs.
Wallet compatibility does not equal wallet verification capability. An organization might be able to accept the credential and read its data, but that doesn’t mean they can validate it properly, preserve privacy through selective disclosure, or meet the new compliance expectations this technology enables. Most current identity infrastructure cannot bridge this gap.
The Multi-Jurisdiction Problem
The complexity multiplies when credentials cross borders. Let’s say, a German citizen presents a wallet credential to a financial institution operating in Spain. The credential was issued under the German trust framework, but the institution operates under Spanish regulatory requirements. The transaction must meet EU-wide eIDAS 2.0 standards. Each layer carries different assurance levels, liability models, and audit requirements.
Verification infrastructure must coordinate several technical dimensions simultaneously. Trust framework translation becomes essential. The German issuer operates under the BundID framework while the Spanish verifier is subject to Banco de España requirements. The eIDAS 2.0 regulation creates an interoperability layer, but the verification system must actively map between frameworks while maintaining appropriate assurance levels.
Assurance level mapping presents another challenge. The credential might be issued at “High” assurance under eIDAS, but the specific transaction requires “Substantial” assurance under PSD2. The system must understand the relationship between these standards and generate an audit trail proving the appropriate assurance level was applied.
Liability attribution adds further complexity. If verification fails, who bears responsibility? The German issuer, the Spanish verifier, or the EU framework itself? Verification infrastructure must document the entire decision chain and create compliance evidence that correctly attributes liability across jurisdictional boundaries.
This goes far beyond just reading credentials from different countries. The system must actively translate between different trust frameworks in real time, maintaining cryptographic integrity while crossing jurisdictional boundaries, and creating audit trails that satisfy multiple regulatory regimes simultaneously. Multi-jurisdiction capability isn’t an optional enhancement. For any organization operating in the EU under eIDAS 2.0, it’s a fundamental requirement. Technical architecture must preserve privacy across jurisdictional handoffs while coordinating between trust frameworks that were designed independently.
The eIDAS 2.0 Timeline: Why This Matters Now
EU member states must offer digital identity wallets by the end of 2026. Cross-border recognition is required, meaning credentials issued anywhere in the EU must be accepted everywhere. Large-scale pilot programs including POTENTIAL, NOBID, and DC4EU are testing interoperability right now.
This creates specific technical requirements for organizations. They must verify wallet credentials for high-value use cases including payment authentication and account access in financial services, benefit claims and tax filing for government services, and age verification for gambling, alcohol, and restricted content. Organizations cannot opt out of this requirement. Regulatory expectation becomes operational necessity.
Architecture decisions being made now will determine organizational capabilities when wallets reach scale. These decisions include how selective disclosure gets implemented, which cryptographic protocols enable privacy preservation, what trust frameworks get recognized, where verification processing occurs (cloud versus on-premises), and who controls encryption keys. Timing matters because infrastructure decisions made in 2025 and 2026 establish the foundation for years to come. Retrofitting verification architecture after initial deployment proves expensive, early implementations establish organizational patterns, and technical debt accumulates quickly in identity infrastructure.
The broader pattern extends beyond Europe. US state mDL programs are following a similar trajectory, the UK digital identity framework is establishing parallel requirements, and a global convergence toward selective disclosure and privacy-preserving verification is underway. Technical architecture decisions made to satisfy eIDAS 2.0 requirements will likely apply to these other contexts as well.
The Deployment Architecture Question
A SaaS-first approach encounters immediate constraints when applied to wallet verification. Data sovereignty requirements prevent many organizations from sending identity data to external cloud services. Financial services face customer data residency requirements, government agencies navigate national security implications, and healthcare organizations must comply with HIPAA and equivalent regulations. These aren’t examples of irrational conservatism. They reflect actual regulatory compliance requirements.
This matters for wallet verification because the process requires processing sensitive identity data. Selective disclosure reduces data exposure but doesn’t eliminate processing requirements entirely. Organizations need cryptographic validation happening in environments they control. SaaS-only architecture cannot satisfy these requirements.
Customer-controlled encryption through BYOK (Bring Your Own Key) addresses this challenge. Organizations generate and manage their own encryption keys, vendors never access unencrypted data, cryptographic control remains with the customer, and zero-trust architecture becomes possible. This capability is rare because most SaaS vendors control encryption infrastructure themselves. Customer-controlled keys complicate vendor operations and require fundamentally different technical architecture from the ground up. According to Gartner’s 2025 Magic Quadrant for Identity Verification, Daon offers this as a standard capability.
The hybrid deployment pattern provides maximum flexibility. Organizations get the same verification capabilities whether they choose SaaS, managed hosting, or on-premises deployment. They select the deployment model based on their specific requirements. Financial services organizations often choose on-premises deployment for regulated data, retail companies often prefer SaaS for operational simplicity, and government agencies frequently use hybrid approaches for different assurance levels.
This reveals something important about architectural maturity. True hybrid capability requires fundamentally different design decisions from the beginning. It cannot be “SaaS-first with an on-premises option bolted on later.” Most vendors operate exclusively in SaaS environments, while others offer limited on-premises capability. Daon’s approach reflects proven large-scale on-premises deployments across financial services, government, and healthcare sectors.
How Sophisticated Verification Actually Works: A Technical View
Examining how this works in practice reveals the complexity involved. Using Daon’s TrustX platform as an example, the process unfolds across several distinct steps.
First, the organization defines verification requirements by specifying required attributes, acceptable issuers, necessary assurance levels, and compliance standards that must be satisfied. For instance, the requirement might be “Prove user is over 18, issued by an EU member state, High assurance level, generate GDPR-compliant audit trail.”
Second, the system generates a presentation request. This cryptographically signed request specifies exactly what claims are needed and indicates why the data is being requested, establishing lawful basis under GDPR Article 6. The user receives this request in their wallet.
Third, selective disclosure occurs. The user sees a clear request like “Organization X wants to verify you’re over 18.” The user chooses whether to share a cryptographic proof. Their wallet generates this proof without revealing their birthdate, and only the proof gets transmitted to the verification system.
Fourth, cryptographic validation takes place. The system verifies the issuer signature to confirm the credential is authentic, checks revocation status to ensure the credential remains valid, validates the assurance level to confirm requirements are met, and confirms the trust framework to verify the issuer is recognized under eIDAS 2.0.
Fifth, the system generates compliance evidence. It creates an audit trail showing verification occurred, documents what claims were requested and why, records the assurance level and issuer trust framework, and produces evidence without storing underlying personal data.
Two contrasting use cases illustrate how this differs from traditional approaches. For age verification of restricted content, traditional systems collect the birthdate, store it in a database, and create ongoing data retention liability. Wallet verification instead requests an “over 18” proof, validates the cryptographic claim, generates a compliance record, and never stores the actual birthdate. Privacy gets preserved, compliance is satisfied, and users maintain control.
For payment authentication during high-value transfers, traditional systems rely on device-based authentication like Face ID or Touch ID. These verify device access, not identity. Wallet verification requests identity confirmation from a user-controlled credential, validates at the server rather than the device, and enables risk-proportional step-up authentication. The organization controls the assurance level rather than delegating this decision to device manufacturers. The approach works consistently across all channels including mobile, web, and contact centers.
What This Means for Digital Identity Infrastructure
A technical transformation is underway in how identity verification operates. Identity verification is shifting from centralized to distributed models, privacy preservation is becoming an architectural requirement rather than an optional feature, multi-jurisdiction coordination is becoming operationally necessary, and customer-controlled cryptography is becoming a compliance expectation.
This shift is fascinating from an infrastructure perspective. Solving selective disclosure requires different cryptographic primitives than traditional systems used. Multi-jurisdiction coordination requires trust framework translation capabilities that most organizations haven’t built. Privacy-by-design requires verification without data centralization, contradicting how most identity systems were architected. All of this must work at scale, with low latency, and across multiple channels.
Organizations evaluating verification infrastructure should consider whether it can verify credentials across EU member states under eIDAS 2.0, whether it supports selective disclosure for privacy-preserving verification, whether it can deploy where regulatory requirements dictate, whether it offers customer-controlled encryption, how it handles trust framework coordination, and what compliance evidence it generates.
What the wallet transition reveals is that user adoption isn’t the bottleneck. Regulatory mandates and technology integration are driving adoption regardless of organizational readiness. Verification infrastructure is the actual constraint. Organizations that understand this technical shift can build appropriate capability before wallets reach scale. Those who treat wallets as just another authentication method will discover infrastructure gaps when adoption arrives.
