The Anchor Credential
How the EUBW can find its real purpose — as a feeder into architectures that actually work at machine speed
Europe has spent the better part of a decade building the most ambitious digital identity infrastructure in the world. The eIDAS 2.0 regulation, the European Digital Identity Wallet, and its business counterpart — the European Business Wallet (EUBW) — represent a genuine political achievement. Twenty-seven member states have agreed, in law, that verifiable digital identity is a public good. Hundreds of engineers across consortia like We Build are doing serious technical work to make it operational. The credential formats are defined. The issuance flows are specified. The trust registries are being stood up.
This is real. And it matters.
The question is: what is it real for?
The authentication achievement
The EUBW solves one problem extremely well: proving that a legal entity is who it claims to be, backed by a government-issued attestation, with cryptographic integrity and cross-border legal recognition.
This is a genuine advance. Before eIDAS 2.0, European cross-border business identity verification was a patchwork of national registries, manual document checks, and ad hoc notarization. The EUBW replaces that patchwork with a standardized, machine-verifiable credential that carries legal weight in every member state. For onboarding a supplier in another country, for regulatory filings that require verified entity status, for any process where a trusted authority must confirm “this organization exists and is registered under jurisdiction X” — the EUBW delivers.
Call these anchor credentials. They establish the foundational fact that an entity is real, registered, and recognized. Every digital economy needs anchor credentials for its participants, and Europe is building a robust system for issuing them.
Where the architecture reaches its ceiling
The difficulty begins when we move beyond authentication into transaction. The moment two or more organizations need to do something together — negotiate terms, settle a payment, enforce a contract, delegate authority to a software agent — the EUBW’s architectural assumptions start working against it.
The root issue is topological. The EUBW stack is built on OpenID4VC: OID4VCI for credential issuance, OID4VP for proof presentation, SIOPv2 for authentication. Every interaction follows a client-server pattern. The wallet holder presents a credential to a verifier’s endpoint. The verifier checks it and returns a result. The flow is unidirectional. The holder is always the supplicant. The verifier is always the gatekeeper.
This works for authentication. It breaks for negotiation.
In a real business transaction, neither party is purely a “holder” and neither is purely a “verifier.” Both parties need to present evidence. Both parties need to verify the other. Both parties need to agree on the terms of the interaction before committing. The relationship is inherently symmetric — two peers, each with something to prove and something to demand.
The EUBW has no protocol for this. It has no mechanism for mutual, multi-round proof exchange. It has no concept of a shared transactional context that parties of the transaction co-create. The architectural pattern — present a credential to an endpoint, receive a yes/no — is structurally incapable of supporting the bilateral negotiation that business transactions require.
The state accuracy gap
A second structural limitation compounds the first. The EUBW issues credentials that represent a snapshot: “As of the date of issuance, this entity has status X.” But business transactions happen in continuous time. The question a counterparty actually needs answered is: “Right now, at this millisecond, does this entity still have status X?”
Revocation in the EUBW framework operates through status registries that update on their own cycles. The regulation requires “timely” revocation, but defines timeliness in procedural terms, not in operational terms. A credential, such as a power of attorney, issued yesterday may be presented today. The issuing authority may have revoked it a minute ago. The status registry may not reflect that revocation until its next update cycle, or the status registry may be temporarily unavailable.
For human-speed interactions — showing an ID at a border, onboarding a vendor over the course of a week — this latency is tolerable. For machine-speed interactions — autonomous agents settling invoices, AI systems executing delegated mandates, supply chain nodes making real-time authorization decisions — it is a structural failure.
The issuer signs the credential and walks away. The holder carries a document. The verifier checks a registry that may or may not reflect the current state. Nobody in this chain is continuously accountable for the accuracy of the assertion right now. The liability for staleness sits in a gap between the issuer’s procedural compliance and the verifier’s operational need.
The governance scaling problem
A third limitation emerges at scale. The EUBW ecosystem depends on rulebooks — governance documents that define which credential schemas are valid, which trust anchors are recognized, and which attribute definitions are canonical within a given sector or use case.
How many rulebooks does a cross-border supply chain need? One per sector? One per jurisdiction? One per combination? The current model assumes convergence: all participants in a given domain must adopt the same schema, the same attribute names, the same data formats. This is the standardization committee model — the same approach that makes SWIFT message updates a multi-year project.
In practice, semantic diversity is permanent. A Finnish logistics company’s “proof of insurance” credential and a Spanish manufacturer’s “proof of insurance” credential will have different schemas, different attribute names, and different trust anchors. The EUBW framework requires them to converge on a single format before they can transact. The real economy cannot wait for that convergence. It needs transactions to proceed despite format differences, provided the semantic content is equivalent.
Anchor credentials feeding into operational architectures
None of these limitations diminish the value of what the EUBW achieves. They clarify its proper role.
The EUBW produces anchor credentials — foundational attestations of entity identity, legal status, and registration. These credentials are valuable. They are the “brute facts” that any trust architecture needs as input. The mistake is treating them as the complete trust solution, when they are one specific component of a larger system.
The architectural pattern that completes the picture looks fundamentally different from the EUBW’s client-server flows. It requires three capabilities that the EUBW was not designed to provide.
First, bilateral peer-to-peer negotiation. Both parties in a transaction must be able to present proofs, request proofs from each other, negotiate terms, and reach agreement — all without either party being subordinate to the other. This requires a communication protocol where organizations interact as peers, not as clients presenting to servers.
Second, live issuer accountability. The entity that issued a credential must remain reachable and queryable about the current state of that credential — not through a batch-updated registry, but through a direct, real-time channel. When a counterparty needs to know “is this mandate still valid?”, the legally binding answer must come from the issuer’s agent in milliseconds, not from a registry that was last updated four hours ago.
Third, disposable transactional contexts. The venue where a transaction executes should be purpose-specific and temporary. Two or more organizations, e.g. a buyer, a seller and a bank, spin up a shared context for a single deal. The context enforces the agreed business logic, verifies all required proofs, executes the settlement, issues cryptographic receipts to all parties, and then dissolves. No permanent platform accumulates transaction history. No honeypot of business data grows over time.
These three capabilities — peer negotiation, live issuer state, and disposable contexts — constitute what we might call the operational trust layer. It sits above the anchor credential issuance layer, consuming credentials as input and producing settled, receipted transactions as output.
The integration path
The practical question for the hundreds of engineers currently building EUBW infrastructure is: how does their work connect to an operational trust layer?
The answer is straightforward. The operational layer connects to the EUBW the same way it connects to any institutional data source — through an integration agent.
An integration agent is a component that bridges a legacy or external service into a peer-to-peer agentic trust network. On one side, it speaks the external system’s native protocol. On the other side, it participates as a peer in bilateral negotiations. It translates between the two worlds.
For the EUBW, this means an integration agent that connects to the EUBW infrastructure as a standard OpenID4VC client. It obtains credentials through the normal OID4VCI flow. It can present proofs through OID4VP when legacy verifiers require it. All the existing EUBW investment — the QTSPs, the trust registries, the wallet applications, the rulebooks — continues to function exactly as designed.
The integration agent harvests those credentials and brings them into the peer-to-peer network as anchor evidence. In the context of a bilateral transaction, a EUBW-issued legal entity credential serves as the foundational proof that this organization is real and registered. The transaction context then layers additional proofs on top: mandates, financial commitments, contractual terms, regulatory attestations — all exchanged peer-to-peer, verified in real time, and settled atomically.
The EUBW credential is the anchor. The operational layer is where the anchor credential becomes useful.
What this means for the EUBW community
This framing has three practical implications for organizations currently invested in EUBW development.
The credential work is preserved. Nothing about this integration path requires changes to credential formats, issuance protocols, or trust registries. The EUBW infrastructure is consumed as-is. SD-JWT credentials, mDL credentials, whatever format the ecosystem standardizes on — the integration agent accepts them all as input. The credential format debates that have consumed so much energy in the EUBW community become irrelevant at the operational layer. The format is an implementation detail of the issuance system. The operational layer cares about the semantic content and the cryptographic validity, not the serialization.
The gap in the architecture becomes explicit. The EUBW community has been asked to deliver a complete digital trust solution using a toolset designed for authentication. This has produced enormous complexity — increasingly elaborate governance frameworks, ever-more-detailed rulebooks, escalating interoperability requirements — because the architecture is being stretched beyond its design parameters. Recognizing that the EUBW’s proper role is credential issuance, and that a separate operational layer handles transactions, relieves this pressure. The EUBW can focus on what it does well: issuing high-quality, legally recognized anchor credentials. The impossible task of turning an authentication protocol into a transaction protocol can be set aside.
The path to machine-speed use cases opens. The use cases that European industry actually needs — autonomous agent-to-agent transactions, real-time supply chain settlement, AI systems operating under delegated authority, cross-border B2B commerce at machine speed — cannot be served by the EUBW’s client-server architecture. They require peer-to-peer agents. But those agents still need anchor credentials to establish their organizational identity. The EUBW provides exactly that. By positioning the EUBW as the anchor credential source and building the operational layer alongside it, Europe can move toward machine-speed trust without abandoning its investment in standardized digital identity.
The broader strategic picture
Europe’s AI Continent Action Plan calls for Gigafactories, massive compute infrastructure, and talent pipelines. Some thoughtful responses have correctly argued that compute without trust infrastructure is insufficient. They propose embedding the EUBW as the trust layer for AI operations.
The diagnosis is right. The prescription is incomplete. The EUBW can provide the identity anchors — verified organizational credentials for every participant in the AI ecosystem. What it cannot provide is the operational trust infrastructure that autonomous AI agents require: bilateral negotiation between agents, real-time mandate verification, delegated authority with live revocation, and atomic settlement of machine-speed transactions.
These capabilities require an operational layer that treats the EUBW as one input source among many — alongside core banking systems, trade registries, regulatory databases, and corporate authorization systems. Each of these data sources feeds verified facts into the operational network through its own integration agent. The network itself is peer-to-peer, context-based, and disposable by design.
This is where Europe’s real strategic advantage lies. Any jurisdiction can build data centers. Any jurisdiction can train AI models. The differentiator is the trust infrastructure that makes autonomous AI economically safe. Europe has the regulatory will (eIDAS 2.0, the AI Act) and the credential infrastructure (EUBW) to provide the anchor layer. What remains is building the operational layer that turns those anchors into a functioning machine-speed economy.
The EUBW is a foundation with a strong political backing. It is time to build the house.