Traditional identity data businesses are paid by verifiers. A data broker collects information about a person, and a company that needs to trust that person pays to check it. The European Digital Identity framework makes that model harder to run. People will carry verified credentials in their own wallets, share them with consent, and, in the government wallet, present them without the issuer learning where they went.
That leaves an open question for every organization planning to participate: if the data no longer flows through the middle, who pays, and for what?
Agne Caunt, Product Owner at Dock Labs, mapped out the answer by role, walking through the business models available to issuers, verifiers, wallets, and ecosystem operators, and flagging which ones the notified EUDI wallet rules out and which remain open for EAAs, QEAAs, and business wallets. Richard Esplin, Head of Product at Dock Labs, added context on how the framework's privacy design breaks some familiar models, how they might be rebuilt without tracking the holder, and why liability has to be settled before any model is chosen.
The insights below cover the three credential paths businesses can choose between, why the classic "verifier pays the issuer" model breaks under unlinkability, why wallets are the hardest place to make money, and why the scheme owners running ecosystems are an overlooked source of revenue. They also cover the question that came up repeatedly from the audience: how liability shapes all of it.
EUDI shifts the job from collecting data to deciding what to ask
- Agne Caunt framed the core change as a shift in what a business actually does: customers arrive with verified data already in hand, so onboarding moves from document scans and data collection to sending a presentation request, and the real work becomes deciding what to ask for and which attestations to trust.
- Agne argued that almost every business already holds at least one verified fact about its customers (a phone number, account ownership, employment, membership), which turns "trusted issuer" into a new role in the ecosystem and potentially a new revenue line.
- Because selective disclosure lets people share an attribute (over 18, EU resident) instead of a full document, verifiers receive less data by design, and Agne noted that business models built on collecting and reusing customer data will become harder to sustain.
The credential format you choose sets the limits of your business model
- Agne laid out three paths: custom credentials in a custom format (full control over pricing and who verifies, but every verifier needs its own integration and trust agreement), EAAs in EUDI format (any registered relying party can request them with the same flow, but trust still depends on verifiers recognizing the issuer), and QEAAs issued by a QTSP (same legal effect as a paper attestation and checkable in any member state, but with conformity audits every 24 months, supervision, and stricter liability).
- Her rule of thumb for the qualified path: it makes sense for something like a nurse's license that needs to be recognized across borders, and it would be massive overkill for a gym membership.
- Richard Esplin argued that even organizations staying on their own stack will likely be pulled toward EUDI technical standards, because one of the biggest problems he has seen globally is issuers and verifiers wanting different formats; he also noted that registration rules for EAA issuers and verifiers are still changing, and that declaring a use case and proving data is only used for it is an administrative burden that can itself limit a business's options.
Issuers have the widest menu, but EUDI closes some doors
- Agne identified six issuer models: holder pays per issuance, the credential bundled into an existing service fee (a verified phone number credential included in a telecom bill), the issuer as its own verifier for operational savings (a bank reusing KYC across loans, cards, and insurance), customer acquisition through partner networks (airline loyalty schemes), regulated or mandated issuance funded by public budgets or regulated fees, and the verifier paying the issuer per event.
- Holder-pays models cannot apply to PIDs, which Agne noted must be free for natural persons under eIDAS 2 Article 5a, but she stressed that no such restriction applies to issuers of EAAs or QEAAs.
- The verifier-pays-issuer-per-event model, which underpins credit bureaus like Experian and Equifax, does not work with notified EUDI wallets, because the framework is designed so the issuer does not learn when a holder presents a credential to a verifier.
- Richard described two routes around this: a broker in the Truvera platform that checks a verifier has access to an ecosystem without tracking the holder, and a proposal from Italy for certified wallets to enforce payment between verifier and issuer, which he believed did not progress because EUDI is already a heavy lift for the initial launch, but which could return once wallets are certified; the constraint in both cases is paying issuers without going back to a data broker model.
Verifiers mostly keep their existing business model
- Agne's view was that pure verifiers rarely make money from verification itself, since they are the party that needs the data, while Richard added cases where they do charge: redeeming a coupon back to its issuer, selling event access, or billing a loyalty ecosystem for serving its members.
Wallets are where monetization is hardest
- For non-government wallets, Agne described three models: holders paying for access or premium features (e.g. CLEAR, password managers), wallets charging issuers to hold their credentials (e.g. Apple Pay charging card-issuing banks), and per-verification billing (e.g. a campus student ID where verifiers pay a small fee per check).
- Agne flagged per-verification wallet billing as needing caution because the wallet sees where and when a credential is used; Richard distinguished this from issuer tracking, describing it as a GDPR purpose question because the wallet already acts on the holder's behalf, and said whether a notified wallet could charge for non-qualified EAAs remains an open question with no clear legal barrier but many political ones.
- Business wallets are not bound by the free-for-natural-persons rule, so the models ruled out for government wallets all become available, which Agne suggested may explain why there is so much interest in building them; Richard added that there is currently no plan for a notified business wallet, at least not in 2027.
Ecosystems and scheme owners are the overlooked revenue layer
- Agne defined an ecosystem as a group of issuers, verifiers, and wallets that agree to use the same credentials under the same rules on top of EUDI infrastructure, with open ecosystems (like the internet CA model, where anyone can verify a TLS certificate for free) earning mainly from certification and issuer-side fees, and closed ecosystems (like airline alliances) suited to access and membership fees.
- She outlined five ecosystem models: governance or scheme fees (as banks pay Visa and Mastercard for the rulebook, brand, and dispute handling), certification and compliance membership, entry fees justified by avoided duplication (the SWIFT KYC registry), revenue sharing modeled on card interchange, and marketplace facilitation where the ecosystem connects verifiers to the issuers they need and takes a cut; Richard said these ecosystem models are often the ones people overlook.
Liability and the business model have to be designed together
- Answering an attendee's question about who pays when an underage user gets through on an inaccurate attribute, Agne passed on guidance she heard from the team building the German government wallet: do not issue what you do not want to be liable for.
- Richard argued that liability has to be resolved before a business model can be chosen, because an issuer needs to be compensated for the liability it accepts; an ecosystem might earn money by acting as the liable backstop, while a verifier might insist a credential be free precisely because it will not hold the issuer liable.
