EUDI Wallet cross-border acceptance: one integration across the EU
How to accept every national EUDI Wallet with one integration: the real trust lists, PID attributes that differ by country, name normalisation, identity matching, formats, testing and what to do when a country is late.
In short
Accepting EUDI Wallets across borders means building one verifier against shared rules, not 27 integrations: every wallet carries the same person identification data (PID) schema in the same two formats, and its signer is checked against lists the European Commission publishes.[2][8] What stays national is the content: optional fields, how names are written, and when each wallet arrives.
- Five attributes are mandatory today. Address and national number are optional, and a portrait joins the mandatory set on 11 August 2028.[2]
- On 31 October 2026 the Commission's first compiled list of PID Providers was still being prepared.[12]
- The EU's identity matching rules bind public bodies. Private companies should borrow them as a design, not assume they apply.[5]
EUDI Wallet cross-border acceptance looks like a 27-country project, but Regulation (EU) 2024/1183 and its implementing acts fix the data model, formats and trust lists for every Member State. The hard part sits in your own systems: a French customer's PID does not look like a Polish one, a returning customer has no common EU identifier, and some countries will arrive late.
This guide assumes you know what a relying party must do and how an OpenID4VP verifier works. Choosing how to connect: read our guide to EUDI Wallet integration routes. Rules below come from the primary text, including the July 2026 amendments and the Architecture and Reference Framework (ARF) 3.0.0.
| At a glance | Short answer |
|---|---|
| How many wallets | At least one per Member State, so 27 or more[1] |
| Where you register | Once, in the Member State where you are established[1] |
| What you verify against | Lists of Trusted Entities (LoTEs) published by the Commission[8] |
| Credential formats | ISO/IEC mdoc and SD-JWT VC[2] |
| Common EU customer ID | None. Matching uses attributes[2][5] |
| Key dates | 24 December 2026, 24 December 2027, 11 August 2028[1][2] |
Need a route today
EUDI Wallet acceptance is coming soon at Didit. National eIDs and the document route work in the same workflow now. Start free or talk to us about your countries.
What EUDI Wallet cross-border acceptance means in law
Each Member State must provide "at least one European Digital Identity Wallet", directly, under a mandate, or independently but recognised by that state, so one country can have several.[1] A relying party "shall register in the Member State where it is established", once, and wallets must be able to authenticate it "irrespective of where they are established in the Union".[1][6] And the relying party is "responsible for carrying out the procedure for authenticating and validating" the data it requests.[1]
For private firms, Article 5f(2) excludes micro and small enterprises and applies "only upon the voluntary request of the user".[1] Our deadlines guide covers who is in scope.
- 11 August 2026PID rules updatedRegulation 2026/1731, published 22 July, enters into force and replaces the PID annex.
- 24 December 2026Wallets dueIdentity matching and registration rules also apply.
- First quarter of 2027Test baselineIndicative goal for the conformance release candidate.
- 24 December 2027Private acceptanceArticle 5f(2) deadline for firms in scope.
- 11 August 2028Portrait, certificatesPortrait in the mandatory set; wallets validate registration certificates.
The dates that shape a cross-border rollout. 24 December 2026 and 2027 are computed from the entry into force of the implementing acts on 24 December 2024.[1][2][5][15]
The trust model: LoTEs, not one big list
For a PID, "the EU trusted list" is the wrong mental model. ARF 3.0.0 states that "Trusted Lists exist only for QEAA Providers", the qualified attestation issuers, whose national lists are reached through the Commission's List of Trusted Lists (LOTL).[8] Everything else sits in Lists of Trusted Entities, "signed and published by the Commission" after Member States notify the entities.[8]
| List | Published by | Standard | Why you need it |
|---|---|---|---|
| PID Providers LoTE | Commission | ETSI TS 119 602 | Validate the PID signature |
| Wallet Providers LoTE | Commission | ETSI TS 119 602 | Mainly used by PID Providers at issuance |
| Public-sector attestation (PuB-EAA) Providers LoTE | Commission | ETSI TS 119 602 | Validate public-sector attestations |
| Access Certificate Authorities, registration certificate providers LoTEs | Commission | ETSI TS 119 602 | Wallets check you against these |
| National Trusted Lists, via LOTL | Member States | ETSI TS 119 612 | Validate qualified attestations |
Which list does what, based on ARF section 3.5 and Regulation 2024/2980 Article 5.[4][8] Relying parties themselves are on no list.[8]
The EUDI Wallet trust model, shown unchanged. Source: EUDI Wallet Architecture and Reference Framework, European Commission, CC BY 4.0.
When a wallet responds, your verifier walks one chain, the same for a PID from any Member State:
1Refresh the lists
Download the current lists, verify the signature with the certificates the Commission publishes, and store anchors by type.[4][9]
2Verify the PID signature
Build the path to the provider's trust anchor. It may use an intermediate signing certificate.[9]
3Check revocation
Read the status list when the PID is valid for more than 24 hours.[9]
4Verify device binding
Confirm the wallet signed your challenge with the key bound to the PID.[9]
All checks pass and the attributes meet your policy
Move to matching
Keep the evidence and continue.
Use another route
Offer a document or a national eID.
One verification chain for every issuing country, condensed from ARF sections 6.6.3.6 to 6.6.3.9.[9]
Watch out
On 31 October 2026 the eIDAS Dashboard said: "The first compiled list of PID Providers is being prepared by the European Commission from the information notified by the Member States."[12] It says the same for Wallet Providers and for Registrars and Registers. Build your list loader now, but do not hard-code a URL or assume today's test data matches production.
The ARF calls revocation checks and device binding checks "recommended but not mandatory" in general, yet trusting the wallet's user authentication "implies that Relying Parties must verify device binding".[9] For onboarding, we advise treating both as required. What device binding does not prove is a separate question.
You cannot check the wallet itself: you rely on the PID Provider, which revokes the PID if the wallet unit is revoked, so the PID status check covers the wallet.[9] Entities are never deleted from a list, only set to Invalid, so read status.[8]
Register once, and ask only what you registered
You register at home only, and any wallet can authenticate you; the wallet compares your request with your registration certificate.[1][6][9]
How a wallet checks a relying party's registration, shown unchanged. Source: EUDI Wallet Architecture and Reference Framework, European Commission, CC BY 4.0.
Checks against Commission lists
Compares request with registration
Register once at home, present anywhere. Simplified from ARF section 6.6.3 and Regulation 2025/848.[6][9]
The cross-border trap is the outcome. If you ask for more than you registered, the wallet "shall clearly warn the wallet user before any disclosure", but each wallet provider decides, on its own risk analysis, whether the user may continue, whether only the registered subset is shared, or whether the request is rejected.[2] One over-asking request can therefore give three different results in three countries.[2] Wallets only have to validate registration certificates from 11 August 2028, so test this behaviour per wallet rather than rely on one result.[2]
Register every attribute you may need in any country, then request per journey only what it needs. Member States "may require" registration certificates, so check your registrar's policy.[6] Our policies and controls guide turns this into an owned control.
PID attributes: same schema, different contents
The PID annex of Regulation 2024/2977 was replaced by Regulation 2026/1731 in July 2026, so older tables are out of date.[2] Attribute names also differ between the two formats.
| Data identifier | Status | mdoc name | SD-JWT VC name | What varies |
|---|---|---|---|---|
| family_name, given_name | Mandatory | same | same | Script, name order, particles |
| birth_date | Mandatory | birth_date | birthdate | Member State value if unknown |
| birth_place | Mandatory | place_of_birth | place_of_birth | Country, region or locality |
| nationality | Mandatory | nationality | nationalities | One or several; QU, QS |
| portrait | From 11 August 2028 | portrait | picture | User opt-out where allowed |
| resident_address and parts | Optional | resident_* | address.* | Full text, parts, or nothing |
| personal_administrative_number | Optional | same | same | Whether it exists, its policy |
| family_name_birth, given_name_birth | Optional | same | birth_family_name, birth_given_name | Whether issued |
| sex, email_address, mobile_phone_number | Optional | same | sex, email, phone_number | Whether issued |
The natural-person PID as replaced in July 2026.[2] Metadata: issuing_authority and issuing_country are mandatory; expiry_date, issuance_date, document_number and issuing_jurisdiction are optional.[2]
Test each of these:
- Unknown and stateless. Unknown nationality is the value QU, no nationality is QS.[2] A strict ISO country parser rejects both.
- Place of birth. It "shall contain at least one" of country, region or locality.[2] You may receive a town with no country.
- Several nationalities. The provider "may include" all of them. The Rulebook also allows a second one in a domestic attribute.[2][11]
- Street. resident_street now includes the house number; the separate house number attribute is gone.[2][3]
- Domestic extras. Countries may add attributes in a namespace such as eu.europa.ec.eudi.pid.[country] or a domestic type, published under Regulation 2025/1569.[2]
For firms under the Anti-Money Laundering Regulation (AMLR), this is where one wallet stops being enough. The EU Anti-Money Laundering Authority's (AMLA) final draft standard of 30 September 2026, still a draft, says that where a means does not hold every attribute, the firm "shall take steps to obtain and verify the missing attributes through other means".[14]
| AMLR Article 22(1) data | PID source | Cross-border gap |
|---|---|---|
| Names | family_name, given_name | None in the data set |
| Place and date of birth | birth_place, birth_date | Place may be partial |
| Nationalities | nationality | Ask if the customer holds another[14] |
| National number, where applicable | personal_administrative_number | Optional, by country |
| Address | resident_* fields | Optional, so collect by another route |
| Tax number, where available | Not in the PID | Other attributes or sources |
Based on Annex I of AMLA's draft standard.[13][14] That draft still lists resident_house_number, which the July 2026 PID annex removed, so expect the mapping to change.[2][14] Read our AMLR guide for the full position.
Normalising names, addresses and places
PID text is UTF-8 with the full Unicode range, and an mdoc text field has a 150-character limit.[2] No PID attribute carries a Latin transliteration: neither the annex nor Rulebook 1.7 defines one.[2][11] So a customer can arrive in Greek or Cyrillic script while your sanctions screening and your existing records use Latin characters. AMLA's draft asks firms to screen names "in their original alphabet and/or transliterated into the Latin alphabet".[14]
The closest legal standard, written for public bodies, says the outcome of matching "shall, to the extent possible, not be affected by differences in transliteration, blank spaces, hyphenation, concatenation, and similar orthographic variations".[5] Our recommended design, engineering advice rather than law:
- Keep the original. Store the signed value as evidence; derive a separate match key.
- Normalise in one place. Apply Unicode normalisation (NFC), fold case, collapse spaces, and treat hyphens and apostrophes as separators.
- Compare in layers. Try exact, then without diacritics, then token order, and record which layer matched.
- Treat script changes as evidence. Use the Latin form on the customer's own document, not one transliteration table.
Example
Invented customer: your record says "Garcia Nunez, Maria". The PID says family_name "García-Núñez", given_name "María José". The first layer fails. Without diacritics and hyphens the family name agrees. The extra given name still differs, so send it to review with the birth date as support.
Language is yours to handle. No PID attribute carries a language or locale, so take it from your own flow.[2][11] The wallet shows its own screens, while your request, intended-use text and error messages need translating; for the portrait the rules expect intended use "in clear and intelligible language".[2]
Addresses need the same care. resident_address is free text, while the parts are separate attributes, and any of them may be missing.[2] AMLA's draft asks for country, town and street elements, and its recitals want attributes in "structured data fields".[14] Accept both shapes.
Identity matching and returning customers
There is no EU-wide customer number. personal_administrative_number is optional and unique only "among all personal administrative numbers issued by the provider".[2] For several PIDs of the requested format, the wallet asks the user unless context decides, and technical PIDs typically last days or weeks.[10][11] So never key an account on a PID signature, public key or document_number.
Regulation (EU) 2025/846 sets cross-border identity-matching procedures applicable from 24 December 2026. It binds "public sector bodies or [...] bodies acting on behalf of a public sector body".[5] Member States decide whether private relying parties can use those systems, and where they do, the procedures apply "where applicable".[5]
Article 2(7)Regulation (EU) 2025/846
"Where the match is not exact or relates to more than one natural person, or the party performing the identity matching cannot guarantee that the match is unequivocal, the identity matching process shall be deemed unsuccessful."
1Collect the data set
The mandatory PID attributes, plus optional data needed to make the set unique.[5]
2Compare with your records
Ignore orthographic variation where you can.[5]
Exact match to exactly one person
Successful
Tell the user and offer to store the match for this account.[5]
New user
Register them as new where the rules allow it.[5]
Unsuccessful
Explain why, then offer another wallet, a data update or extra information.[5]
3Log the process
Values used, date and time, outcome and related identifiers.[5]
The Regulation 2025/846 process, simplified. Public bodies must follow it. For private firms it is a template unless national rules extend it.[5]
The logs are retained "for a minimum of 6 months and a maximum of 12 months for security purposes", and longer for other purposes only where Union or national law requires it.[5] Keep them apart from AML records. After a first match, store your own association between the person and the account, one of the listed reuse options, so a re-issued PID does not repeat the work.[5]
Plan your country routing with Didit
EUDI Wallet acceptance is coming soon at Didit. Today you choose the national eIDs accepted per country and what happens on failure, including a fallback to document capture.[21] Talk to us about the countries you serve.
Formats, protocols and wallet versions
A PID Provider "SHALL issue any PID in both" formats, so a PID-only verifier could ask for one, but cover both unless your testing proves otherwise.[10] Our SD-JWT VC vs mdoc comparison explains the differences. Presentation has two profiles, each with two ways to reach the wallet.[2]
| Profile | Format | API-mediated | Not API-mediated |
|---|---|---|---|
| ISO/IEC-mdoc | mdoc | ISO/IEC 18013-7 Annex C | ISO/IEC 18013-5 |
| OpenID4VC-HAIP | SD-JWT VC, mdoc | HAIP sections 5, 5.2, 5.3, 7, 8 | HAIP sections 5, 5.1, 5.3, 7, 8 |
Regulation 2024/2982 Annex II, added in July 2026.[2][7]
The rules name dated specifications, which amending acts can move, and ISO server retrieval is banned for everyone.[2][7] The operating system is a variable too: a wallet must support a mediating API, but the Regulation records that a device or browser may not support both protocols, a case it treats as a non-conformity outside the wallet's control.[2]
Check certification status separately from protocol conformance. Member States report certified wallets for a Commission list under Article 5d.[1] The Commission's functional conformance framework is still in its 0.x series: its roadmap, marked indicative, aims for "a release candidate in the first quarter of 2027", with version 1.0.0 as "the first full-scope baseline suitable for certification".[15]
Test before the national wallets arrive
The Commission's reference implementation includes a sample wallet, a test verifier and a test issuer, with open repositories for the verifier endpoint and trust validation.[19] A pass shows protocol fit, not national wallet behaviour.
The Launchpad 2026 testing track moved to "validating how solutions work together under real-world conditions, ahead of launch", with test access to LoTEs on the eIDAS Dashboard.[16] Relying parties join through Large Scale Pilots or a national invitation, and solution providers also take part.[16] Six pilots have run, POTENTIAL among them on cross-border authentication.[18] APTITUDE and WE BUILD remain active, the second on business and payment use cases.[17]
| Test case | Input | Expected result |
|---|---|---|
| Both formats | Same person, mdoc and SD-JWT VC | Same internal record |
| No address | PID with no resident_* fields | Address collected by another route |
| Partial birthplace | Locality only | Accepted and stored as received |
| Stateless or unknown | QS, QU | No parser failure; policy decision |
| Non-Latin name | Greek or Cyrillic script | Stored raw; Latin form for screening |
| Provider invalidated | Status set to Invalid | Rejected after list refresh |
| Revoked PID | Status list marks it revoked | Rejected, other route offered |
| Over-asking | Unregistered attribute | Caught in your own pre-release check |
| Returning customer | New technical PID, same person | Same account |
What to do when a country is late
Our EUDI Wallet tracker holds the status by country, and Germany and Italy have their own guides. Make each country a configuration with one of three states, driven by the lists, not the press.
State A
Listed and tested
- PID Provider on the LoTE
- Passed your test cases
- Offer the wallet alongside other routes
Article 5f(2) applies when your deadline arrives
State B
App live, not listed
- A national app exists
- No trust anchor you can verify
- Keep it off, or treat it as a separate scheme
Read the scheme's own rules
State C
No wallet yet
- Nothing to accept
- Use a national eID or a document
- Recheck when the list changes
Article 22(6) AMLR routes remain
A country state model for rollout. This is our suggestion; the law does not define these states.
You need the other routes anyway. Wallet use "shall be voluntary", access must not be "restricted or made disadvantageous" for people without one, and it "shall remain possible" to use other means.[1] Under the AMLR, identity documents and electronic identification at level substantial or high stand side by side as verification routes.[13] Your integration route should make a late country a setting.
Your cross-border checklist for this month
- Map which entities and countries fall under Article 5f(2).[1]
- Confirm your home Member State's registrar and registration policy.[6]
- List every attribute you may need in any country.
- Build one internal schema that maps mdoc and SD-JWT VC names.[2]
- Replace old PID tables with the July 2026 annex.[2]
- Add test cases for QU, QS and partial birthplace.[2]
- Build a list loader for ETSI TS 119 602 and ETSI TS 119 612.[8]
- Write match failure messages in each customer language.[5]
- Set log retention for matching and compare it with AML retention.[5]
- Ask your national coordinator about pilot, Launchpad or Commission programme access.[16][20]
How Didit helps with cross-border acceptance
EUDI Wallet acceptance is coming soon at Didit, and you can follow it on our EUDI Wallet page. Today you can build the routes that surround it. National eIDs (MitID, BankID Sweden, Finnish Trust Network, Smart-ID, Mobile-ID) work through wallet sign-in, with results normalised because "wallet attribute names vary".[21] You choose accepted wallets per country and whether a failure falls back to a document or declines.[21] The document route covers 14,000+ document types.[22] For the name and address gaps above, it reads the customer's document, and AML screening runs against 1,300+ sanctions, PEP and watchlist sources.[23]
Didit provides
- National eID sign-in where listed as available
- Document capture, liveness and face match
- Per-country national eID choice and fallback
- AML screening
- Retention settings from 1 month to 10 years[24]
Stays with you
- Your registration as a relying party
- Your risk assessment and policies
- The onboarding decision
- Matching rules for your own records
- Records and supervisor relations
Build your country routing before the wallets arrive
Start with national eIDs and documents in one workflow, and tell us which countries matter most.
Key takeaways
- One verifier can serve every wallet, but your data handling must expect national differences.
- PID providers sit in Lists of Trusted Entities, not in national Trusted Lists.
- Only five attributes are mandatory today. Address and national number are optional.
- No common EU customer identifier exists. Matching relies on attributes and your own link to the account.
- Regulation 2025/846 binds public bodies; for private firms it is a design to borrow unless national rules extend it.
- Treat late countries as a routing state, with documents and national eIDs ready.
Frequently asked questions
Do I need a separate integration for each national EUDI Wallet?
No. Wallets share one PID schema, two formats and common presentation profiles, so one verifier can serve them.[2] Test per wallet anyway.
Does a verifier check a PID against the EU List of Trusted Lists?
No. ARF 3.0.0 says Trusted Lists exist only for QEAA Providers. PID Providers sit in a List of Trusted Entities signed and published by the Commission.[8]
Which PID attributes will every wallet give me?
family_name, given_name, birth_date, birth_place and nationality, with the portrait added from 11 August 2028.[2] The user can still decline to share any single attribute.[2]
Will a wallet always include the customer's address?
No. All address attributes are optional, so plan for a PID with none.[2] AMLA's draft standard says missing attributes must be obtained and verified through other means.[14]
Is there a European identifier for matching returning customers?
No. personal_administrative_number is optional and unique only within its provider.[2] Match on attributes, then keep your own association between the person and the account.[5]
Does Regulation 2025/846 on identity matching apply to banks and other private companies?
Not directly. It covers public sector bodies, and applies to private relying parties only where a Member State enables them to perform identity matching.[5] Use it as a design template either way.
How should I handle names in Greek or Cyrillic script?
Store the signed value as received and derive a separate match key; the PID has no Latin transliteration attribute.[2][11] Our advice: obtain any Latin comparison form from the customer's document.
Must I accept a wallet from a country that launches late?
You can only accept a wallet that exists, and in scope firms face the 24 December 2027 deadline.[1] Keep other routes: wallet use is voluntary, and other means must remain possible.[1]
Can I test cross-border acceptance before national wallets launch?
Partly. The Commission's reference tools are public, and Launchpad testing uses test LoTEs.[16][19] Reference tools show protocol fit, not national wallet behaviour.
Does Didit accept EUDI Wallets today?
EUDI Wallet acceptance is coming soon at Didit. National eIDs and the document route work today, in the same workflow.[21][22]
Sources
- Regulation (EU) No 910/2014 as amended by Regulation (EU) 2024/1183, consolidated text, EUR-Lex.
- Commission Implementing Regulation (EU) 2026/1731, amending Regulations 2024/2977, 2024/2979, 2024/2980 and 2024/2982, EUR-Lex, 15 July 2026.
- Commission Implementing Regulation (EU) 2024/2977, person identification data, EUR-Lex, original text.
- Commission Implementing Regulation (EU) 2024/2980, notifications, EUR-Lex.
- Commission Implementing Regulation (EU) 2025/846, cross-border identity matching, EUR-Lex.
- Commission Implementing Regulation (EU) 2025/848, registration of wallet-relying parties, EUR-Lex.
- Commission Implementing Regulation (EU) 2024/2982, protocols and interfaces, EUR-Lex.
- Architecture and Reference Framework 3.0.0, chapter 3, Roles, European Commission.
- Architecture and Reference Framework 3.0.0, chapter 6, Trust model, European Commission.
- ARF Annex 2, High-level requirements by topic, European Commission.
- PID Rulebook, version 1.7, European Commission, 17 July 2026.
- Compiled list of PID Providers, eIDAS Dashboard, European Commission, read 31 October 2026.
- Regulation (EU) 2024/1624 (AMLR), EUR-Lex.
- Final Report, draft regulatory technical standards under Article 28(1) AMLR, AMLA, 30 September 2026.
- Functional conformance roadmap, EUDI Wallet functional conformance framework, read 31 October 2026.
- Launchpad Testing 2026, European Commission, updated 23 October 2026.
- What are the Large Scale Pilots, European Commission, updated 22 July 2026.
- PID Identification Manual, European Commission, updated 11 February 2026.
- EUDI Wallet Reference Implementation documentation, European Commission.
- Relying Party Engagement Programme, European Commission, updated 18 September 2026.
- Digital ID Wallet Verification API and Coverage, Didit documentation.
- ID Verification overview, Didit documentation.
- AML Screening overview, Didit documentation.
- Data retention, Didit documentation.
Follow the rollout on our EUDI Wallet page, see the routes that work now on our eID verification page, and compare options on the pricing page.
Serve every European customer with one workflow
Combine national eIDs, documents and AML screening, and keep your routing in one place.
Artigos relacionados
- Requisitos KYC da FINTRAC para MSB de cripto e pagamentos (2026)
- Quebec Law 25 and biometrics: identity verification guide (2026)
- EUDI Wallet integration: how to choose your route (2026 guide)
- EUDI Wallet readiness: policies and controls for regulated firms
- EUDI Wallet holder binding: what a presentation really proves
- Verificação da idade no Canadá: S-209, C-34 e o que fazer agora