EUDI Wallet Registration: The Relying Party Filing Every Fintech Must Get Right

A fintech's engineering team can be fully ready to accept a digital identity wallet, credential parsing built, selective disclosure supported, trust-chain validation working, and still have no technical path to request a single attribute from an EU citizen's wallet. The gap isn't code. It's a legal filing, registration as a wallet-relying party with a national eIDAS authority, the step that has to happen before any of that engineering work becomes usable in the EU.

Commission Implementing Regulation (EU) 2025/848 sets out exactly what that filing requires, and the part most teams underestimate isn't the company paperwork, it's the registered intended use statement: a declaration of which attributes a business will request and why, checked against its live credential requests after the fact. Overclaim there and a national registrar can suspend access within 24 hours. This post maps what the filing actually requires, where the WRPAC and WRPRC certificates fit, and where Hypersign's own eIDAS 2.0 readiness stops and the legal filing starts.

What a European Digital Identity Wallet Actually Requires From a Relying Party

The European Digital Identity Wallet is the credential store every EU Member State must offer citizens and residents at least one certified version of, under Regulation (EU) 2024/1183, dated 11 April 2024 and in force since 20 May 2024, the amendment that added the wallet framework to the base eIDAS Regulation. A citizen holds verified person identification data and electronic attestations of attributes in it, a national ID, a driving licence, a proof of age, and shares specific claims with a business on request, logged on a transparency dashboard the wallet itself provides.

That sharing only happens through a registered relying party. The regulation requires a relying party to disclose in advance what data it will request and to apply data minimization to that request, enforced through a formal registration step rather than a terms-of-service checkbox. Register, and a wallet hands over a cryptographic attestation. Don't, and there's no technical path to request anything from a wallet holder at all, no matter how complete a business's own digital identity wallet integration is on the backend.

The direction matches what other jurisdictions are converging on. Australia's Digital ID framework, the UK's trust framework, and India's Aadhaar-linked systems point at the same outcome, a single high-assurance verification that travels, instead of a fresh document upload at every new service. The EU has codified the relying-party side of that model into a formal registry with legal consequences attached.

What eIDAS 2.0's Relying-Party Register Requires You to Disclose

The rules for that registry exist in detail now. Regulation 2025/848 of 6 May 2025 lays down exactly how wallet-relying party registration works, and it applies from 24 December 2026. Under it, every Member State must designate at least one registrar to run at least one national register of wallet-relying parties, publishing the register's contents online in both human-readable and machine-readable form, reachable through a single national API and website.

The Annex I Baseline: Legal Identity, Contact, and Service Details

Annex I of the regulation sets the floor. At minimum, a business files its legal or trading name, an official identifier (a business registration number, VAT number, EORI, or LEI), its registered address, a service URL, a description of what the service does, and contact channels for the registrar and for wallet users. Article 5 adds the ongoing obligation, the information has to be accurate at the time of registration, and it has to be updated without undue delay whenever it changes. There's no annual renewal cycle baked into the disclosure itself, only a continuous duty to keep it current.

The Registered Intended Use Statement

None of that baseline data is where the real work is. The part that actually constrains a product is the intended use statement, a declaration of which attributes or attestations a business intends to request from the wallet, and the specific purpose for which each one will be used. This is the field a registrar reads against live requests later, worth treating as an architecture document, not a compliance formality.

Consider how this plays out for a crypto exchange building its onboarding flow under this regime. A first-draft intended use statement might declare "person identification data, for KYC" as the request, with the purpose written broadly as "account opening." Filed that way, it authorizes pulling the full PID set eIDAS 2.0 defines, family name, given name, date of birth, place of birth, and nationality, every time a user onboards. Most exchanges' actual obligation at account opening is narrower, confirm the user is over 18 and not on a sanctions list. A registrar comparing that filing against the exchange's live credential requests has grounds to call it overbroad under Article 9. The fix is splitting the filing into two declared uses, "age-over-18 attestation, for age verification at account opening," and a separate "full person identification data, for enhanced due diligence," invoked only once a customer crosses an EDD trigger. Two narrow, traceable entries survive an audit against the logs; one broad one doesn't.

WRPAC and WRPRC: The Two Certificates Issued After Registration

Registration produces one certificate for certain and a second, optional one. The Wallet-Relying Party Access Certificate (WRPAC) is issued by a Qualified Trust Service Provider and is what a business's systems present to authenticate to a wallet at the technical layer. Alongside it, Member States may authorise a certificate authority to issue a Wallet-Relying Party Registration Certificate (WRPRC), and Article 8 of Regulation 2025/848 specifies what that certificate has to carry: it must include a general access policy, and registrars must ensure that wallet providers established in that Member State inform users when a wallet-relying party requests data that isn't specified in the registration certificates. Article 8(2)(g) adds one more disclosure at this layer, not at the Annex I baseline, a URL to the privacy policy covering the intended use, and Article 8(3) requires that policy to be expressed in the registration certificate itself, not just published on a website.

In plain terms, the WRPRC makes a registered scope, and the privacy policy behind it, visible to the wallet at the moment of a data request, and the wallet is required to flag it to the user if a business asks for anything outside that scope.

Why Your Credential Request Scope Has to Match What You Filed

Data Minimization Enforced by the Registrar, Not Just Policy

Under most existing KYC regimes, data minimization is a policy commitment, a privacy team writes it down, and enforcement depends on an internal audit or a regulator eventually asking questions. Regulation 2025/848 moves that enforcement into the registration infrastructure itself. A registered intended use statement becomes the technical ceiling on what a wallet will hand over, and the general access policy on the WRPRC is what a wallet checks, and discloses to the user, before it releases anything. This is the structural version of the same tension the GDPR-KYC literature already covers, KYC checks routinely pull more data than a given check strictly needs, and regulators are increasingly building the minimization requirement into the infrastructure layer rather than trusting it to policy.

Suspension and Cancellation Within 24 Hours

Article 9 of Regulation 2025/848 gives registrars the power to suspend or cancel a registration where they have reason to believe a relying party is requesting more attributes than it registered, or that the information it submitted is inaccurate, out of date, or misleading. When a registrar makes that call, it has to notify the relying party without undue delay, and in any case no later than 24 hours after the decision.

A day is not much runway to fix a scope mismatch once a wallet has already flagged a request to a user and a registrar has acted on it. That's the practical argument for building credential requests to match a filed intended use statement exactly, rather than filing conservatively and hoping a product team never widens the request later without a corresponding update. Registrars also have to hold onto registration records for 10 years under Article 10, so a scope mismatch doesn't age out quietly.

Passporting: One Member State, Recognized Across the EU-27

Registration is a one-time filing per business, not a country-by-country slog, but the mechanics for that come from a different regulation than the one governing everything above. Regulation 2025/848 itself only sets up national registers, Article 3 requires each Member State to run its own, and Article 6 has registrars check for duplicate filings elsewhere rather than granting cross-border recognition directly. The actual passporting principle sits in the base Regulation (EU) 2024/1183, which requires Member States' EUDI Wallets and the trust infrastructure behind wallet-relying party certificates to interoperate across borders. In practice, a fintech registered in, say, Ireland or Germany can request its declared attributes from a wallet holder in any other Member State without filing again there, the certificate issued under one Member State's authorization is recognized by wallets across the Union, not reissued per country. That's a meaningful simplification against KYC regimes that require local licensing or local data-residency arrangements market by market, and it's worth knowing which regulation actually earns that simplification if a registrar or auditor ever asks.

The December 2026 Deadline and Where eIDAS 2.0 Implementation Stands

Regulation 2025/848 applies from 24 December 2026, the date national registers must be operational and accepting relying-party filings. As of February 2026, the most recent point with verifiable public reporting, no Member State had a live relying-party registration portal running in production, according to eIDAS-Pro's registration guide, which expected portals to start opening around mid-2026. Confirm current status directly against a target Member State's registrar before treating that timeline as settled, six months have passed since that reporting and portals may have opened in the interim.

The wider wallet rollout runs on a related but distinct timeline. Member States must offer at least one certified EUDI Wallet by late 2026, and organisations in regulated sectors face mandatory wallet acceptance roughly 12 months after their Member State's wallet launches, putting that obligation around late 2027 on current estimates. Registration is the prerequisite that has to be in place before that acceptance deadline arrives, not something to leave until wallets are already live in a given market.

Industry estimates put annual national registration fees somewhere in the EUR 100 to 1,000 range, and separately, the WRPAC access certificate from a QTSP typically carries one-year validity with estimated annual costs of roughly EUR 500 to 5,000, though neither figure is fixed yet since most national fee schedules haven't been published. Budget for both as recurring compliance line items, not one-time setup costs.

Why Web3 Exchanges and MiCA-Era CASPs Face This Filing Too

This isn't a fintech-only filing. Crypto-asset service providers licensed under MiCA face their own compressed timeline, the MiCA transitional period for firms operating under national registration closed on 1 July 2026, after which every CASP serving EU customers needs a full MiCA authorisation. That deadline landed months before the EUDI Wallet relying-party register even opens, which means a CASP handling both pieces of compliance work in the same year has to sequence a MiCA licensing push against a wallet registration filing that still had no live portal as of early 2026.

The scope discipline is already familiar to anyone running AML on crypto transfers. Under the recast Transfer of Funds Regulation, a CASP has to assess whether a self-hosted wallet address is owned or controlled by its customer for any transfer over EUR 1,000, and it has to collect and transmit sender and recipient identifying data on every transfer regardless of amount. A CASP that's already built the habit of matching data collection to a specific regulatory threshold is closer to ready for a registered intended use filing than one still pulling a full KYC document set by default. Exchanges evaluating identity vendors for exactly this kind of EU readiness are worth comparing on whether they can express a credential request that's this narrow, not just whether they can verify a document, see how nine of them stack up in Best KYC Providers for Web3 Companies in 2026.

What Hypersign Does and Does Not Do for This Filing

Be precise about the boundary, it matters for how the work gets planned. What Hypersign actually does is sit inside the KYC workflow itself, a national ID or passport check, a driving licence or proof-of-age verification, a biometric or liveness check, and issue the result as a signed W3C Verifiable Credential rather than a stored document. From that credential, a relying party can selectively disclose only the specific attribute a given interaction needs, an age-over-18 flag, a KYC-passed status, a sanctions-screening result, instead of handing over the full underlying record every time. That's the same principle Regulation 2025/848 enforces at the wallet layer, issue a claim, not a document, and let a verifier check a signature and a scope rather than collect and store the underlying data, and it's what keeps a live credential request matched to a narrow, defensible registered intended use statement instead of a broad one that pulls more than a given check requires.

Vendors building wallet-side and issuer-side infrastructure cover a different layer of this problem well. Paradym's own technical writing walks through the ETSI standards stack, trust list validation, and certificate policy a relying party's systems need to satisfy at the protocol level, a real and separate body of work from the legal filing this post covers. Hypersign doesn't compete on that ETSI-conformance layer either, what it's built for is issuing and selectively disclosing the KYC credentials that keep a relying party's live requests narrow enough to defend against whatever it eventually files.

What Hypersign does not do is file a relying-party registration with a national eIDAS authority. That registration, and the legal work of confirming a specific data-request scope against what a product actually needs, stays with the business. We said the same thing when we first mapped Hypersign's eIDAS 2.0 stack readiness against the wider AMLR compliance picture, and it's still true here, issuing and selectively disclosing KYC credentials can keep those requests narrow enough to defend, but it can't sign an Annex I disclosure or write an intended use statement for a business. For the technical side of building a KYC credential and selective-disclosure workflow that matches what a business will eventually file, Hypersign's documentation is the starting point for how the credential network and issuance tooling fit together.

FAQ

Does registering as a wallet-relying party replace my existing KYC/AML obligations?

No. Registration under Regulation 2025/848 gives a business the technical and legal right to request wallet attributes, it doesn't substitute for AMLR, MiCA, or DPDP-equivalent screening obligations, which apply to what happens with the data once it's collected. Treat registration as unlocking access to the wallet, not as satisfying a separate compliance regime.

Can I register in one country and serve wallet holders EU-wide?

Yes, through the cross-border interoperability the base Regulation (EU) 2024/1183 requires, not through the 2025/848 registration mechanics themselves. A registration completed in one Member State is recognized across all 27, so there's no separate national filing needed for every market a business serves wallet holders in.

Is the WRPRC mandatory?

No. Article 8 of Regulation 2025/848 makes it something Member States may authorize a certificate authority to issue, not a requirement. The WRPAC is what's actually required to authenticate to a wallet at all, since it's the certificate a Qualified Trust Service Provider issues to prove a relying party is registered.

What happens if my product team widens a data request without updating the registration?

The wallet is required to flag the mismatch to the user at the point of the request. The registrar can also suspend or cancel the registration if it has reason to believe more attributes are being requested than were registered, with notification due within 24 hours of that decision under Article 9.

Is a registration portal available yet?

Not as of the most recent verifiable reporting, in February 2026. No Member State had a live relying-party registration portal in production at that point, even with the December 2026 applicability date on track, so confirm current status with your target Member State's registrar before planning a filing timeline around it.

References

Primary sources for the citations above:

• Commission Implementing Regulation (EU) 2025/848 of 6 May 2025 (EUR-Lex)
  Annex I baseline, and Articles 5, 6, 7, 8, 9, and 10 on registration, certificates, and suspension.
• Regulation (EU) 2024/1183 of 11 April 2024 (EUR-Lex)
  The base eIDAS 2.0 amendment establishing the EUDI Wallet framework and cross-border interoperability requirements.
• Regulation (EU) 2023/1113, recast Transfer of Funds Regulation (EUR-Lex)
  Self-hosted wallet ownership-verification threshold for CASPs.
• Regulation (EU) 2023/1114 (MiCA) (EUR-Lex)
  CASP authorization framework referenced for the transitional-period deadline.
• Elliptic, "What the end of MiCA's transitional period means for crypto businesses"
  Confirms the 1 July 2026 close of the MiCA national-registration transitional period.
• eIDAS-Pro, "eIDAS 2 Relying Party Registration: Complete Guide"
  Portal-status and fee-estimate reporting as of February 2026.
• Paradym, "What It Really Takes to Be an EUDI Wallet Relying Party"
  The ETSI standards and certificate-conformance layer of relying-party infrastructure.

Regulations change, and third-party reporting described here reflects public materials as of this post's publication date, not legal advice. Confirm current portal status, fee schedules, and filing requirements directly with your target Member State's registrar and against primary EUR-Lex sources before planning a filing timeline.

About Hypersign

Hypersign issues KYC credentials, national ID, passport, driving licence, and biometric checks turned into signed W3C Verifiable Credentials, and lets a relying party selectively disclose only the specific attribute a workflow needs, aligned with eIDAS 2.0 and the EU Digital Identity Wallet, so live requests can actually stay inside whatever scope a business files. See the full Verifiable Credentials platform or how this maps against the wider timeline in eIDAS 2.0 KYC Stack Readiness.