.svg)
.svg)
.svg)
.jpg)
If your service asks a user to prove something about themselves using an EU Digital Identity Wallet, eIDAS 2.0 classes you as a wallet-relying party. Before you can request a single attribute, you must register with a national registrar and hold a valid access certificate. Commission Implementing Regulation (EU) 2025/848 sets the rules and applies from 24 December 2026, the same date national wallet schemes must be available to citizens. Acceptance becomes mandatory for financial services roughly a year later. As of mid-2026 no member state had opened an eIDAS 2.0 relying party register. This guide covers what registration requires, what it does not, and what fintechs should do with the time in between.
Most coverage of eIDAS 2.0 follows the wallets. That is one side of the transaction. The other side is the organisation receiving the data, and it carries its own binding obligations.
By December 2026, every member state must make a wallet available to its citizens. Far fewer businesses will be able to accept a credential from one. Wallet availability is not the constraint. Relying party readiness is.
Article 5b of Regulation (EU) No 910/2014, as amended by Regulation (EU) 2024/1183, applies to any relying party intending to rely on EU Digital Identity Wallets for the provision of public or private services by means of digital interaction.
For a fintech, that covers three journeys:
Onboarding and account opening. You request identity attributes instead of collecting a document scan. Our KYC guide covers this in detail.
Authentication and payment approval. You accept wallet-based authentication alongside existing methods.
Ongoing compliance checks. You re-verify a customer without making them repeat the original process, the reusable KYC and KYB model.
None of these work until you are registered. Registration is the gate in front of deployment.
Registration is not a light-touch listing. What you declare binds you afterwards.
Annex I of CIR (EU) 2025/848 sets out the information required. In summary:
Identification. Your name as stated in an official record, plus a user-friendly trade or service name users will recognise. One or more official identifiers: EORI, national business register number, LEI, VAT number, or EUID. Your address of establishment, and where applicable a URL.
Contact information. At least one of a support website, a phone number, or an email address.
Services and entitlement. A description of the services you provide, whether you are a public sector body, and your entitlement. Annex I lists ten; most fintechs will register as Service_Provider.
Data requests, per intended use. For each intended use, the data, attestations, and attributes you intend to request, with a user-friendly name, a technical name, and the attestation type, machine-readable. Plus a description of that use.
Intermediary disclosure. Where applicable, that you rely on an intermediary.
That list has a consequence most teams miss. Article 5b(3) prohibits requesting any data beyond what you registered. Where a member state has authorised registration certificates, Article 8(2)(d) requires wallet providers to inform users when a relying party requests data not specified in them, and Article 9(2)(c) lets registrars suspend or cancel a registration on that ground.
Your attribute list is not a compliance form. It behaves like runtime configuration. Get it wrong and users see a warning at the moment you are asking for their trust.
Two things worth preparing early: where registration certificates are issued, Article 8(2)(g) requires a URL to your privacy policy for the intended use. And registrars keep your submitted information, and any later changes, for ten years.
Two certificates appear here, and teams routinely conflate them.
The wallet-relying party access certificate. A certificate for electronic seals or signatures that authenticates and validates you. Article 7 requires every member state to authorise at least one certificate authority, issuing only to registered relying parties. Under Annex IV the issuer verifies your registration first, then monitors the register and revokes if your status changes.
The wallet-relying party registration certificate. A data object describing your intended use and the attributes you registered an intention to request. Article 8(1) leaves this to national discretion: member states may authorise a certificate authority to issue them. Where a member state does, Article 8(2) requires each intended use to be expressed in the certificates, carrying a general access policy harmonised across the Union.
The access certificate proves who you are. The registration certificate proves what you are entitled to ask. Assume you need both, and check your member state's registration policy. Note that Annexes IV and V place their obligations on the certificate providers, not on you.
Article 5b requires registration in the member state where you are established, and requires the process to be cost-effective and proportionate to risk. Article 5b(11) gave the Commission its mandate to set technical specifications. That act is Commission Implementing Regulation (EU) 2025/848 of 6 May 2025, and its structure maps the work:
The regulation applies from 24 December 2026.
One update to track. On 15 July 2026 the Commission adopted Implementing Regulation (EU) 2026/1730, amending 2025/848 as regards applicable standards and specifications and pinning ETSI TS 119 475 v1.2.1. If you are working from a copy downloaded before July, check the consolidated version.
The Architecture and Reference Framework covers registration in Topic X, still in its 2026 refinement round. The regulation is settled. The technical layer underneath it is not.
24 December 2026. CIR (EU) 2025/848 applies and national wallet schemes must be available to citizens. Under Article 5f, public sector bodies and very large online platforms must accept wallets from launch.
10 July 2027. The Anti-Money Laundering Regulation, Regulation (EU) 2024/1624, applies. It ties customer due diligence to eIDAS methods: wallets, notified national eIDs at substantial or high assurance, and identity proofing through qualified trust services. Other methods require justification and equivalent assurance.
December 2027. Article 5f(2) requires private relying parties in listed sectors, including banking and financial services, to accept wallets where they already use strong user authentication. Microenterprises and small enterprises are excluded. The article expresses this as 36 months from entry into force of the relevant implementing acts rather than a fixed date, which is why some analyses place it in early 2028.
Read those in order and the sequencing problem is clear. The AMLR deadline lands months before the acceptance mandate. A fintech planning against December 2027 has already missed the obligation that reaches it first.
Most vendor guidance overstates this. Worth separating what the law says from what the industry assumes.
Settled. You register in the member state where you are established. Article 5b(1) is explicit, and each member state maintains a register for organisations established in its territory. You do not choose your registrar.
Settled. Registers are published in machine-readable form through a common API, so any wallet unit can query your registration in your home member state. That is what lets a German wallet check a Finnish relying party at all.
Not settled. Whether that registration confers operating rights across all 27 member states with no further national involvement. See the next section.
Plan for one registration in your country of establishment. Do not assume it removes every national touchpoint in every market you serve. Registration policies, fees, and processing times are set nationally under Article 4.
Our interoperability pages track which formats and schemes are covered.
This is the most important question a fintech can ask before signing with any verification provider, including us.
Germany's published blueprint states the rule plainly: when a relying party uses a hosted verifier service, the access certificate and registration certificate must belong to the relying party, not the service provider.
The regulation backs this up. Article 5b(8) requires you to identify yourself to the user. Article 5b(10) deems an intermediary acting for relying parties to be a relying party itself, and prohibits it from storing data about the content of the transaction. Annex I points 14 and 15 require you to declare that you rely on an intermediary.
Reliance on a vendor is a registered fact, not a private arrangement.
The practical test is short. Ask any prospective vendor:
The ARF does describe a legitimate intermediary model, where the intermediary registers, holds its own access certificate, and holds registration certificates issued in the name of each relying party it serves. That is different from a vendor putting its own name in the certificate and calling you covered. Ask which you are being sold.
Being straight about the gaps matters more than projecting certainty. Here is what nobody can tell you today.
No eIDAS 2.0 register is operational. As of late May 2026, EU trusted-entity lists remained unpublished, with the eIDAS Dashboard showing the access certificate provider list as unpublished. Denmark launched AltID in production on 3 June 2026 and runs a relying party registry, but it is national, not an eIDAS 2.0 register.
Cross-border recognition is still being written. The ARF Topic X refinement round lists cross-border registration and multi-registration, per intended use and per member state, as policy still to be specified. Practitioners in the Commission's own discussion threads have asked whether a national regulator could suspend a relying party registered elsewhere under local law. That question has no published answer.
Certification lags availability. France Identité is live as a national identity app but is not yet certified as an EUDI wallet. Germany has set 2 January 2027 for its national launch, after the December 2026 deadline, and its implementing statute was still in draft as of mid-2026.
Fees and processing times are unknown. Article 5b requires cost-effective, proportionate registration, but no national fee schedule is published and no registrar has handled volume. Figures circulating in the market are estimates.
Enforcement detail is thin. No formal enforcement model has been published for failure to accept wallets under Article 5f.
None of this is a reason to wait. It is a reason to do the work that does not depend on a portal.
The preparation takes months. Almost none of it needs a registrar, and none of it needs a portal to be open.
Decide your intended use and write it down. Onboarding, authentication, age assurance, or several. This wording goes into your registration, and Article 5b(3) then constrains every later request to it.
Draft your attribute list against a legal basis. For each attribute, state why you need it. Requesting the minimum is what selective disclosure is for. Anything you cannot justify should not be on the list, because adding it later means amending your registration.
Gather your identifiers. Legal name, an official identifier, and the user-friendly name shown on the wallet consent screen.
Build and test your EUDI wallet verification flow now. Create wallet presentation requests, receive verified data from EUDI wallets and process the business operations. Hovi gives you a single integration point into the government sandboxes that are already running, so you can build PID verification and age verification against real wallet schemes rather than a mock.
Test against the German EUDI Wallet Deutschland sandbox and France Identité EUDI Wallet through one API, then keep the same flows when the registers open. According to the German government's own parliamentary response, SPRIND's sandbox ran 115 organisations across 150 use cases in six months and identified relying party onboarding as the bottleneck. Start with setting a meeting with us.
Plan for parallel running. Wallet-based authentication sits alongside your existing methods for years, not instead of them.
Assign an owner for changes. Article 5b(6) requires you to inform your member state without delay of any change to your registered information. Registration is a standing obligation, not a one-time submission.
Do these and registration becomes an administrative step. Skip them and it becomes a project you start in December, in a queue.
Hovi already operates inside two of the ecosystems moving fastest.
In the France Identité EUDI Ecosystem and German EUDI Wallet (Deutschland) sandbox, we can help you integrate and verify with these test EUDI wallets. You can build realistic flow and use PIDs (Personal Identification Data) credentials, Age Verification Credentials and also issue Electronic Attestation of Attributes credentials into wallet units across the full credential lifecycle.
We presented live in France, Paris at France Identité event EUDIW Unfold #3, we ran live vérification demos with France Identité digital wallet built by hovi platform.
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 Business Console Studio gives you the orchestration layer you need to integrate effortlessly with EUDI and build any use case seamlessly at scale. Book a demo meeting with us.
.svg)
