27 Member States, 27 Wallets: What Cross-Border Actually Means for KYC

Every EU member state must make at least one wallet available by the end of 2026. Each one issues and governs its own scheme. That sounds like twenty-seven integrations. It is not. The formats are harmonised and the protocols are fixed. What varies sits somewhere less obvious, and it is the part that breaks a KYC flow in production. 

What is already harmonised

Start with the good news, because it is better than most coverage suggests.

Credential formats are fixed. Two are mandatory: SD-JWT VC and ISO/IEC 18013-5, the mdoc format. Person identification data is specified in both encodings under Commission Implementing Regulation (EU) 2024/2977, and the core requirements apply regardless of which encoding a scheme uses. W3C Verifiable Credentials is a third, optional format, restricted to certain attestation types.

Protocols are fixed. OpenID4VCI for issuance, OpenID4VP for presentation, and ISO/IEC 18013-7 for remote presentation of mdoc credentials.

The core attribute set is fixed. Given name, family name, date of birth and the rest of the mandatory person identification data are the same whether the credential arrives from EUDI Wallet Deutschland or France Identité.

So a verifier that speaks SD-JWT VC and mdoc over OpenID4VP can technically read a credential from any compliant scheme. One integration, not 27.

One caveat that matters if driving licences are part of your flow. Mobile driving licences are governed by separate EU legislation that specifies ISO/IEC 18013-5 and nothing else, so the mDL Rulebook defines only an mdoc encoding. Format choice varies by credential type, not by country.

What actually differs

Here is where cross-border gets real.

National PID attributes. Person Identification Data is the core credential every scheme issues, and its mandatory attributes are identical across all twenty-seven. Beyond that set, member states may define their own. Those national attributes have to be formally defined and published, so they are discoverable. But they exist in one country and not the next, and your flow only sees them if you build for them. 

Optional attributes may simply be absent. The mandatory set is guaranteed. Optional fields are not. A flow that quietly depends on one will work in one member state and fail in another, and it will fail for a user who did nothing wrong.

Registration policies. Each member state designates its own registrar and writes its own registration policy, covering supporting documentation, identity verification procedures, whether registration is automated, and how you seek redress if refused. Our relying party readiness guide covers that ground in detail.

Whether registration certificates exist at all. Issuing them is a member state decision, not a Union-wide requirement. Build a flow that assumes them and it will not behave the same everywhere. Our explainer on intermediaries covers what that means if a vendor holds them on your behalf.

Trust lists. Each member state publishes its own lists of certified wallet providers, authorised certificate authorities and registered relying parties. Validating a credential means resolving trust to the right national list, not to a single European one. Our interoperability page tracks which schemes we resolve today.

Timing. Schemes are not arriving together. France Identité is a live production app with over 4.5 million users and certification still in progress. Germany has set 2 January 2027 for its national launch, after the December 2026 deadline. Denmark put AltID into production in June 2026. Your addressable base grows country by country, not all at once.

What this means for KYC specifically

Three consequences worth designing for.

Your assurance level is consistent. Your attribute availability is not. Person identification data is issued at level of assurance high across the board, which is the hard part and it is solved. What you cannot assume is that every optional field you would like is present in every scheme.

Your fallback path is not optional. For any attribute outside the mandatory set, you need a defined behaviour when it is missing. Ask for it again, degrade gracefully, or route to an alternative check. Deciding this at design time is cheap. Discovering it in production is not.

Under the Anti-Money Laundering Regulation, a wallet is one of three accepted routes. From 10 July 2027, customer due diligence is tied to eIDAS methods: wallets, notified national eIDs at substantial or high assurance, and identity proofing through qualified trust services. Other methods remain possible with justification and equivalent assurance. Wallet coverage does not have to be complete for the approach to be viable.

What to do about it

Build against the mandatory set. Design your core user onboarding and ID verification flows using only guaranteed attributes, and apply selective disclosure so you request no more than you registered. Treat everything else as an enhancement with a defined fallback. 

Test against more than one scheme. A flow that works against a single national wallet has not been tested for cross-border. Differences in optional attributes and trust resolution only appear when you run against a second scheme. We can give you access to the government sandboxes and test wallets that are running now, so you can do this before your registration is filed. 

Resolve trust per country, not per region. Your validation logic needs to reach the correct national trust list. That is a design decision, not a configuration detail.

Sequence your markets by scheme readiness, not by market size. The countries furthest along are where your first real users will be, and they may not be your biggest markets.

Register once, integrate once, expand gradually. You register with the registrar in your own member state. The integration model you choose, direct or intermediated, then determines how much of the per-country variance you handle yourself.

How Hovi helps

Hovi works across the Nordics and Baltics, and already operates inside two of the ecosystems moving fastest. 

In the France Identité EUDI ecosystem and the German EUDI Wallet Deutschland sandbox, we can help you integrate and verify against these test wallets. You can build eIDAS 2.0 compliant user onboarding and KYC identity verification flows using Person Identification Data and age verification credentials, and issue Electronic Attestation of Attributes credentials into wallet units across the full credential lifecycle. 

We presented live in Paris at the France Identité event EUDIW Unfold #3, running verification demos with the France Identité digital wallet, built on the Hovi platform. Watch the full demo.

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.

Hovi gives you the orchestration layer to integrate with EUDI schemes and build your use cases at scale and connect with all 27 member state EUDI Wallets  Talk to us about your EUDI Wallet Integration Strategy.. 

‍