What is a relying party in the EUDI Wallet ecosystem?

The role is not new. Your organisation is already a relying party every time it checks a passport, a company extract or a diploma. What changes is that the check stops being a human reading a document and becomes an automatic answer you can trust in seconds.

Relying party is a role, not a type of company. The same organisation can be a relying party in one process and an issuer in another: a university asks a student for an identity document at enrolment and hands out a diploma at the end. What makes you a relying party in a given moment is simply that you are the one asking, checking and deciding.

The important shift is where the proof comes from. Today the person in front of you carries the burden of proving that a document is genuine, and you carry the cost of judging it. With a wallet, the proof is signed by the organisation that already holds the fact, so the check becomes a calculation rather than a judgement call.

That is why the role is worth understanding even if nothing obliges you to take it on yet. Once a customer can prove who they are in a few seconds, every process that still asks for an upload and a manual review starts to look slow by comparison.

When your service asks for data, the request does not arrive silently. The wallet opens a screen that names the organisation asking, lists exactly which pieces of data are being requested, and states the purpose that organisation registered for them. Nothing is shared until the person taps to approve it.

The name on that screen is not typed in by you. It comes from the certificate you received when you registered, which is why the wallet can present it as a checked fact rather than a claim. A request from an unregistered party cannot produce that screen at all.

The person can refuse, and can refuse each time rather than once for good. Wallets also keep a history of what was shared and with whom, so the decision is reviewable afterwards instead of disappearing into an inbox. Consent stops being a checkbox and becomes something the user can actually inspect.

For your organisation that is the whole point. The familiar fraud, a convincing page asking for a copy of a passport, stops working when people are used to seeing a verified name before they share anything. Asking through the wallet puts you on the trusted side of that habit, and requests that look legitimate get completed more often.

In practice the list is less abstract than it sounds. It reaches retail banks, payment institutions and insurers, mobile operators signing up subscribers, energy and water suppliers, airlines and rail operators, hospitals, pharmacies and health insurers, universities and examination bodies, and the public administrations that already run a national login. If your onboarding today involves an identity document because a rule says it must, you are almost certainly in scope.

Accepting the wallet does not mean replacing what you have. It means offering the wallet as one of the ways a person can identify themselves where you already ask for strong identification, next to the methods you support now. Existing customers keep their route in, and new ones get a faster one.

The dates are worth writing down. Member states issue their wallets from the end of 2026, the rules on registering as a relying party apply from December 2026, and the obligation to accept the wallet arrives at the end of 2027. Registration depends on a national authority and on internal decisions about which data you need, so the calendar is tighter than a single date in 2027 suggests.

Everyone else may accept the wallet voluntarily, and a great many will. Once a customer already carries verified identity and company data, asking them to upload a scan instead is a step backwards that they will notice.

There is no single European wallet application. Every member state provides at least one, some will have several, and your customers will arrive carrying whichever their country issued. An organisation with customers in a handful of countries is therefore not integrating with one counterpart but with a moving set of them.

The standards underneath are shared, which is what makes this possible at all. What differs is everything around them: each wallet has its own trust anchors, its own national profile, its own test environment and its own release calendar. Passing a test with one wallet tells you very little about the next.

The first integration is rarely the expensive one. The cost sits in the years after it: following specification updates, re-testing when a national wallet ships a new version, tracking trust list changes, and keeping certificates current in every country where you are established. It is a maintenance line in the budget, not a project line.

A simple way to size it is to count two things: the number of member states your customers come from, and the number of releases each of those wallets is likely to ship in a year. Multiply them, and you have the number of times someone on your team has to stop what they are doing. That figure, rather than the initial build, is what the build-or-buy decision really turns on.