If you run an identity verification (IDV) or KYC service, your clients might be starting to ask you the question: "Can our users onboard with the EUDI Wallet?" The pressure is real. Member States have to offer an EUDI Wallet by the end of 2026, and regulated private services have to accept it about a year later. Your clients will expect their identity provider to handle that.
If not your clients, the question might be showing up internally in strategy meetings. Whether you see it as a threat or an opportunity, IDV or KYC providers should be discussing how to handle upcoming EUDI Wallets.
This article is for product and technology teams at IDV and KYC providers. It covers what the rules require, what a wallet adds to document and selfie checks, what changes in your onboarding flow, and what it takes to offer wallet verification to your own clients. At Paradym we build the verification infrastructure behind wallet flows, so along the way we point out which parts Paradym can take off your hands and which stay with you.
What the rules say, and when they apply
Three pieces of EU law shape the demand for wallet verification in onboarding.
Regulation (EU) 2024/1183 (eIDAS 2.0) obliges each Member State to provide at least one EUDI Wallet within 24 months of the entry into force of its implementing acts (Article 5a). The first implementing acts entered into force on 24 December 2024, so wallets are due by December 2026. Article 5f(2) of the same regulation then requires private relying parties that must use strong user authentication for online identification (including in banking, financial services, telecommunications, transport, energy, health and digital infrastructure) to accept the EUDI Wallet when the user asks for it. That deadline is 36 months after the implementing acts entered into force, which puts it at December 2027. Micro and small enterprises are exempt.
The third is Regulation (EU) 2024/1624, the Anti-Money Laundering Regulation (AMLR), which applies from 10 July 2027. Its Article 22(6) lets obliged entities verify a customer's identity with an identity document, or with electronic identification means at assurance level substantial or high under eIDAS, together with relevant qualified trust services. The EUDI Wallet is designed to reach assurance level high.
The data in the wallet is defined too. Implementing Regulation (EU) 2024/2977 sets the Person Identification Data (PID): family name, given names, date and place of birth and nationality are mandatory, while attributes such as the resident address are optional and depend on the issuing Member State.
Outside of the industries required to accept the wallet, opportunities also arise for industries that don't have the requirement. Once the EUDI Wallet is introduced, a reliable, reusable means of electronic identification suddenly becomes available for all EU citizens.
What a wallet presentation gives you
Both a document check and a wallet presentation build on verified evidence. To issue the PID, the Member State has already verified the person's identity, and with a document check you can read the chip of most identity documents. The difference is in the experience and the protection. The wallet is already on the user's phone, so there is nothing to photograph or scan, and the credential is protected by a PIN and bound to the device's hardware.
Wallets share credentials over OpenID4VP, the protocol that carries the request from you to the wallet and the credential back to you securely. In practice, a successful presentation gives you:
- Issuer-signed attributes. The PID arrives as an SD-JWT VC or an mDoc, signed by the PID provider. You verify the signature against the provider's certificate on the EU list of PID providers, instead of judging a scanned document.
- Proof of possession. The wallet signs the presentation with a key bound to the credential, so a copied credential is worthless without the device.
- User authentication by the wallet. The holder confirms with a PIN or biometric before sharing.
- Only the data you ask for. Selective disclosure means you request the attributes your client actually needs, which helps with data minimization under GDPR.
What it doesn't give you is coverage. Not every user will have a wallet in 2027, optional PID attributes differ per Member State, and non-EU customers will still show up with a passport. Wallet verification is a new, faster path in your product, not a replacement for it.
How wallet verification complements document and selfie checks
For most IDV providers the result will be a combined flow with the wallet as the first option. Offer the wallet when the user has one, and fall back to your existing document and selfie flow when they don't, or when the PID lacks an attribute your client needs. Your own checks stay in place: run sanctions and PEP screening, fraud signals and address checks on the verified PID, just as you would on data extracted from a document. Once their issuers exist, attestations such as a proof of address can be requested together with the PID.
For audits, your clients need to show how each customer was verified: the verification result, the issuer, the trust anchor used and the time of the check. When you act as an intermediary, hand this evidence to your client to keep, rather than storing it yourself (see below).
If you sell to Qualified Trust Service Providers (QTSPs), note that Implementing Regulation (EU) 2025/1566 makes ETSI TS 119 461 V2.1.1, the identity proofing standard many IDV providers certify against, the reference for verifying people who receive qualified certificates or qualified attestations. That standard also covers electronic identification means as evidence.
What changes in the onboarding flow
For the user, the flow is short: tap "Continue with your EUDI Wallet" (or scan a QR code on desktop), review who is asking for what, confirm with a PIN, and land back in the onboarding flow. Behind that, your service takes on four new jobs, and Paradym can handle most of the technical work in each of them.
The first is building the request. For each client and use case, you decide which credential types and attributes to request, in which formats (SD-JWT VC, mDoc or both), and which issuers to trust. In Paradym you set this up once as a presentation template and create verification requests from it.
The second is securing the flow. Same-device flows should send the user back to the session that started the request, so that a presentation can't be replayed in someone else's session, and response encryption keeps the data private between wallet and verifier. Paradym's OpenID4VP redirect flow (experimental) binds the result to the device that started the flow, and our assurance and security guide recommends a high-assurance configuration.
The third is managing trust. Member States notify their PID providers to the Commission, which publishes them in a signed list, and that list changes. Your verifier needs to fetch, validate and refresh it, and handle revoked credentials. With Paradym trusted entities you point to EUDI trust lists (experimental) such as the EU PID Providers List, which Paradym fetches, validates and refreshes daily. For wallets such as France Identité and the German EUDI Wallet Sandbox, we keep common trusted entities up to date for you.
The fourth is identifying yourself to the wallet. Wallets authenticate the relying party with an access certificate, and show a registration certificate that states what the relying party may ask for. ETSI TS 119 475 defines both. Paradym signs your requests with your access certificate and can include the EU registration certificate (experimental). Our article on how to register as a Relying Party goes into the process.
Offering wallet verification to your own clients
This is where IDV providers differ from a bank integrating a wallet for itself: you serve many clients, each with its own legal entity, use cases and data needs.
eIDAS 2.0 addresses this directly. Article 5b(10) states that intermediaries acting on behalf of relying parties are deemed to be relying parties themselves, and must not store data about the content of the transaction. Implementing Regulation (EU) 2025/848 on the registration of wallet-relying parties applies from 24 December 2026. It has no separate registration for intermediaries: a relying party states in its own registration that it uses an intermediary, and identifies it (Annex I). For an IDV provider, that raises practical design questions:
- Whose name does the user see? The wallet shows who is asking for data. Decide with each client whether that is their brand, yours, or both, and how that matches the registration.
- Who registers what? Each client registers its own intended use and requested attributes, and names you as its intermediary.
- What do you keep? As an intermediary you must not store the content of the transaction. Design your logs and retention so that the verified data and the audit evidence go to your client, who keeps them.
- Separation per client. Trust configuration, certificates, keys and request templates should be separated per client, so that one client's setup can't affect another's. In Paradym, each client can get its own wallet (tenant) with its own templates, trust setup and webhooks.
What is still open
Plenty is still moving, and it is better to plan around it than to wait for it. Wallet rollout differs per country: a few Member States already have wallets in use, while others launch close to or after the December 2026 deadline, so volumes will grow gradually. National registration routes are still being set up, and portals and certificate providers differ per Member State.
The AMLR details are not final either. How the technical standards of the Anti-Money Laundering Authority (AMLA) treat wallet-based verification, and what "relevant qualified trust services" means in practice, will shape how banks use your wallet flow.
What Paradym handles for you
Paradym lets you add EUDI Wallet verification to your existing service without building the standards and trust layer yourself. You keep the client relationship, your onboarding flow and your existing checks.
You can integrate through a REST API with webhooks, or use verification with OpenID Connect (experimental) if your platform already speaks OpenID Connect. Signing keys can live in your choice of key backend, and Paradym runs in our cloud, or on-premise when your clients or auditors require full control over hosting.
Registration doesn't have to be a burden either. Your clients register in their own name, and we help you and them through it, from the certificate signing request for the access certificate to adding the registration certificate to your requests. Paradym helps you comply with the technical elements and keeps the verification infrastructure up to date with the standards, while the legal basis and AML obligations stay with your clients.
In short: the EUDI Wallet becomes a new way for your users to prove who they are, backed by eIDAS 2.0 and recognized in the AMLR. It doesn't replace your document and selfie checks, but it becomes the fastest path for users who have one. IDV providers that add it now will be ready when their clients' deadlines arrive.
To discuss how to add EUDI Wallet verification to your service, reach out to our team.
