Every organisation that wants to request attributes from an EUDI Wallet has two paths: register directly as a Relying Party in each Member State where it operates, or route requests through an organisation that has already done so on its behalf. The second option is what the ecosystem calls an intermediary Relying Party, and it exists precisely because the first option scales badly the moment you operate in more than one country.
What an intermediary Relying Party actually is
An intermediary Relying Party is registered in the trust ecosystem on its own legal account, holds its own access certificates, and performs presentation requests to wallets on behalf of other organisations under a contractual and technical mandate. From the wallet's perspective, the presentation request is signed and authenticated exactly like any other Relying Party request — the wallet does not need special support for intermediation, because the legal relationship sits between the intermediary and its client, not inside the wallet protocol itself.
- The intermediary carries the registration burden across every Member State it operates in.
- It manages certificate issuance, rotation and renewal centrally.
- It absorbs conformance changes as the ARF and implementing acts evolve.
- Its client integrates against a single API, regardless of which wallet ecosystem or Member State the end user's wallet belongs to.
The legal basis for intermediation
eIDAS 2.0 does not require the entity that ultimately relies on a verified attribute to be the same entity that technically requests it from the wallet, provided the responsibilities are clearly allocated by contract and the data flow is transparent to the user. In practice this mirrors patterns already familiar from payments (payment initiation service providers) and identity verification (outsourced KYC providers): a regulated intermediary performs a specific function under a service agreement, while the client organisation remains responsible for how it uses the resulting data. The presentation request itself still names the actual requesting purpose, so the user sees who is asking and why — intermediation changes who operates the infrastructure, not what the user is told.
Intermediation does not hide the requester from the user. It moves the registration, certificate and conformance burden off the requester's engineering roadmap.
Why single integration matters
A direct integration means maintaining a separate connection, certificate lifecycle and conformance track for every national wallet ecosystem you touch — a materially different engineering and legal commitment for a company operating in four or five Member States than for one operating in a single country. A single integration against an intermediary collapses that into one API contract, one SDK, one certificate to monitor on your side, regardless of how many national ecosystems sit behind it. As more Member States launch wallets and as cross-border usage increases, this gap only widens in favour of the intermediary model.
Build vs. buy: the real comparison
- Direct registration: full control over the trust relationship, no per-transaction intermediary fee, but multi-month registration per Member State, ongoing legal and technical maintenance, and internal ownership of every conformance update.
- Intermediary Relying Party: registration and certificate lifecycle handled externally, a single integration surface, faster time to market across multiple countries, but a dependency on the intermediary's own conformance and a recurring service cost.
- Hybrid: direct registration in your home market where volume justifies the fixed cost, intermediary coverage for expansion markets where volumes do not yet justify a dedicated compliance function.
The break-even point is rarely about raw cost — it is about whether wallet-based verification is core to your regulated business model or a supporting capability. A bank whose entire onboarding is built around strong customer authentication may reasonably justify direct registration as a strategic asset. A marketplace that needs to confirm 'is a licensed contractor' for a subset of listings almost never will.
Where Arkadiz fits
Arkadiz operates as an intermediary Relying Party and, on the issuance side, as a non-qualified EAA issuer: your organisation integrates once against a single API to both verify wallet-held attestations and issue your own non-qualified attributes (membership status, employment confirmation, customer tier) into users' wallets, without separately registering in every Member State or managing a portfolio of access certificates. The registration, certificate lifecycle and conformance tracking sit with us; your team ships the product-facing flow.
When the intermediary model is not appropriate
There are legitimate reasons to register directly instead:
- Verification volume and regulatory exposure are large enough that owning the trust relationship is a competitive asset, not overhead — typically true for large banks and telecoms.
- Your organisation already operates trust infrastructure for other purposes (e.g. an existing Qualified Trust Service Provider) and the marginal cost of adding Relying Party registration is low.
- Internal policy or a regulator explicitly requires the requesting entity and the relying entity to be the same legal person, with no intermediation permitted for your specific use case.
- You operate in a single Member State only and do not anticipate cross-border expansion, in which case the duplication problem the intermediary model solves does not apply to you.
For most product, marketplace, and platform businesses outside these categories, the intermediary model turns a multi-jurisdiction compliance programme into a single API decision — which is the trade most teams should make before committing engineering time to direct registration.