.svg)
.svg)
.svg)
.jpg)
Under eIDAS 2.0 there are two ways to reach a wallet. You register yourself, hold your own access certificate, and connect directly. Or you work through an intermediary, a party that requests attributes on your behalf and is treated as a relying party in its own right. Buying software does not automatically put you in the second category, and plenty of teams assume it does. This explainer covers what an intermediary actually is, what it takes off your plate, what stays yours regardless, and the part of the model that has real consequences for how you handle customer data.
An intermediary is a company that connects to a digital wallet on behalf of another business, requests the attributes that business needs, and passes them on. The business that ultimately receives the data is called the end relying party.
The legal position is unambiguous. Article 5b(10) of the European Digital Identity Regulation states that intermediaries acting on behalf of relying parties are deemed to be relying parties and shall not store data about the content of the transaction. The Architecture and Reference Framework describes them as a special class of relying party, performing all the tasks assigned to a relying party on the intermediated party's behalf.
Not a processor. Not a passthrough. Not a technical vendor sitting outside the framework. Any verification provider that touches a wallet on your behalf is operating inside the regulation, whether or not it uses the word intermediary. If you are working through what a businessneeds before it can verify wallet credentials for the first time, this is the distinction to get straight before you shortlist vendors.
An intermediary takes over the paperwork and the plumbing. It does not take over your place in the transaction.
They do the registering. The intermediary registers itself, and it registers you. You are still on a register, with your own registrar in your own country. Someone else filed it.
You never touch a certificate. Only the intermediary holds an access certificate. Yours does not exist, and your registration certificates sit with them. Worth remembering when you think about switching providers.
The wallet still sees you, not them. Every request carries your identity, your declared purpose, and a pointer to your registrar. The intermediary's own registration details are not used.
The intermediary is the pipe. You are still the party asking, and the user is told so.
Germany's published guidance on the intermediary role puts it in one sentence: whether you interact with the wallet directly or through an intermediary, the legal and technical accountability stays the same.
Four things stay yours regardless of who you contract with.
Your declared intended use. Registration certificates are optional at member state discretion. The declaration of intended use is not. It is registered with your registrar and retrievable by the wallet at the moment of the request. No intermediary arrangement removes it.
Your identity in the request. Every data request, direct or intermediated, must identify the end relying party. The wallet user is told who is ultimately receiving the data.
Your privacy policy. Where the requesting party is an intermediary, the privacy policy URL in the request points to the end relying party's policy, not the intermediary's. Your document, your obligation.
Your data minimisation. You cannot request more than you registered. Routing a request through someone else does not widen your declared scope, and the same data minimisation discipline applies to what you ask for.
An intermediary can carry the paperwork and the plumbing. It cannot carry the responsibility.
This is the part worth reading twice.
The ARF states that end-to-end encryption between the wallet unit and the intermediated relying party is not required. An intermediary is not architecturally blind to your users' attributes. It can see them.
What constrains it is a deletion duty rather than an encryption barrier. The intermediary must delete any person identification data or attestations it obtained from the wallet unit, including user attributes, immediately after sending those attributes to the relying party. Article 5b(10) separately prohibits it from storing data about the content of the transaction.
For a fintech, that turns a technical question into a due diligence question. You are not asking whether your provider could see customer identity data. You are asking what it does in the moment it can, and how it proves deletion. That belongs in your contract and your vendor assessment, not in an architecture diagram.
Where will you register me? Registration belongs with the registrar in the member state where your business is established. Confirm they register you there and reference your registrar in requests.
Whose privacy policy URL do you send? It should be yours. If the answer is theirs, the request is not being constructed correctly.
How do you evidence deletion? Given that attributes pass through in the clear, ask for the mechanism, the logging, and the audit position. Not the policy statement.
What happens to my registration if I leave? Your registration exists because someone filed it, and your registration certificates are hosted by them. Ask what transfers, what has to be redone, and how long you are without a working flow.
Which schemes do you actually cover today? Not roadmap. Which national wallet schemes have you issued into and verified against, and can you show it.
What is not settled yet
The intermediary model is defined in principle and unfinished in detail. Three gaps are worth knowing before you build a procurement plan on it.
The technical binding is still being specified. The relationship between an intermediary's access certificate and the registration certificates of its end relying parties has been listed as work in progress across ARF revision rounds. Implementers asked publicly how a wallet should authenticate two related relying parties in a single request, and parts of that answer are still landing in technical specifications.
The framework is still moving. ARF v3.0.0 arrived in July 2026, following v2.0 in May, and aligns the framework with the implementing regulations amended on 15 July 2026, including CIR (EU) 2025/848 on relying party registration. It also introduces a conformance assessment framework and a new treatment of relying party service roles. Anyone who scoped intermediary work against an ARF version from 2025 should re-check it.
Scale is an open question. Consortium feedback to the Commission has flagged that requiring intermediaries to hold registration certificates for every end relying party may not scale, particularly across categories of similar businesses. How registration is organised nationally is not mandated by the ARF, and member states may take different approaches. That national variance is covered in more depth in our guide to relying party readiness.
There is no single right answer, and the decision is less about company size than about how many markets and schemes you plan to touch.
Direct registration suits you if you operate in one member state, have a small number of intended uses, and hold compliance capacity in house. You keep full control and add no third party to your trust chain.
An intermediary suits you if you serve users across several member states, need to work with multiple national wallet schemes, or want one integration rather than one per scheme. You trade some control for a much smaller surface area. This is the usual answer for reusable KYC and KYB and for cross-border verification in financial services.
Either way, the preparation is identical. Decide your intended use. Draft your attribute list against a legal basis. Write the privacy policy that will be referenced in every request. An intermediary can file these for you. It cannot decide them for you.
Hovi already operates inside two of the ecosystems moving fastest.
In the France Identité EUDI ecosystem and the German EUDI Wallet Deutschland sandbox, we can help you integrate and verify against these test wallets and other member state EUDI wallets. You can build realistic flows using Person Identification Data (PID), age verification credentials, and issue Electronic Attestation of Attributes credentials into wallet units across the full credential lifecycle.
We presented live in Paris at the France Identité event EUDIW Unfold #3, running verification demos with the France Identité digital wallet, built on the Hovi platform. Watch the full demo.
We also tested against ETSI TS 119 472-1 at the ETSI EAA Plugtests, covering SD-JWT VC and ISO/IEC 18013-5 across several government and private wallet providers.
Our Business Wallet API, Cloud Wallet API, SDKs, and the Studio business console give you the orchestration layer to integrate with EUDI schemes and build your use cases at scale. Start with our documentation, or book a demo with us.
.svg)
