In my experience, the question of how to navigate EUDI Wallet integration is the one preoccupying most financial-services product and compliance teams. It’s an important question, but it often eclipses a harder question that most teams haven't fully worked through yet: what does the wallet actually hand off, and what does your stack need to do with it next? 

Those two questions have very different answers, and different implications for your business. Here, I’ll explore what the EUDI Wallet can do, and what it can’t — and why thinking holistically about compliance is the only way to build products that stand up to scrutiny.  

What the EUDI Wallet actually does 

The EUDI Wallet is a genuine step forward for identity verification, and it's worth understanding precisely why. 

The Wallet is one of the flagship product of eIDAS 2.0, the EU's updated digital identity regulation. Whereas the original eIDAS regulation established common standards for electronic identification across member states, eIDAS 2.0 requires every EU member state to provide citizens with a standardised digital identity wallet, and mandates regulated entities to accept it.  

The Wallet delivers Person Identification Data at eIDAS “high” assurance; though not all countries will launch at that level from day one. The data is government-sourced and cryptographically signed, which means you're not just checking a photograph of a document and hoping the OCR is accurate. Instead, you're receiving authentic data verified by a government source. 

Selective disclosure adds another positive dimension. Customers can prove they are over 18 without sharing their birth date, or confirm their EU residency without submitting their home address. This means that institutions receive only what the transaction requires; a meaningful GDPR advantage that simultaneously reduces customer friction. 

And, for the first time in any meaningful sense, cross-border interoperability is becoming a reality for the first time. This means there’s one solution that’s recognised across all 27 Member States. 

All this is to say that the EUDI Wallet is a verified identity credential. It gives you the customer’s name, date of birth, nationality, and a person identifier (a unique code assigned by the issuing authority). However, the EUDI Wallet is not a passport. It doesn’t give you a document number, biometric chip data, or other identifying information.  

Presenting the information contained in the EUDI Wallet is step one of any onboarding process. But it’s not the entire thing.  

What the EUDI Wallet doesn’t deliver 

If the EUDI Wallet tells organisations who a person is, AMLR requires you to determine more; namely: whether or not you can onboard them. Here’s what you won’t be able to source from the EUDI Wallet that you will likely still need to be AML-compliant:  

• Liveness. The Wallet confirms that a credential is valid. But what it doesn’t confirm is whether the person presenting it is who they claim to be. This is where liveness detection comes in: a biometric check (typically a guided selfie) that confirms a real person is present, in real time, and matches the identity in the Wallet’s credential. Regulators expect identity verification and liveness detection to happen as part of the same flow; a credential presented without a simultaneous liveness check leaves a window for fraud to occur.  

• Sanctions and PEP screening. A clean Wallet credential tells you nothing about whether the person is on an EU sanctions list, a PEP database, or flagged in adverse media. These screenings, however, are essential for AML compliance. 

• Ongoing monitoring. A real-time identity verification may be valid in the moment, but the customer’s profile can change. A new sanction designation or a shift in risk profile are all changes the Wallet has no visibility into and cannot flag. This is where perpetual KYC takes over: the continuous, event-driven monitoring of customer risk that operates independently of how the individual was originally identified.  

Why "Wallet-ready" and "fully compliant" are not the same thing 

The point worth driving home is that Wallet integration is really an addition to your compliance flow, rather than a replacement for it.  

Consider a common pattern: Wallet acceptance is added as a separate lane with its own audit trail, its own liveness step, but no shared screening record. On paper it probably works. However, during a regulatory examination, that fragmentation is exactly the kind of thing that would be flagged. AMLR articles 20, 22, and 23, as well as AMLA’s RTS draft article 28 state that CDD measures need to be completed as part of a single, coherent onboarding process 

AMLR and eIDAS 2.0 are separate instruments that converge at identity proofing. They have different legislative authors, different timelines, and even different supervisory structures. Treating them as one unified thing may lead to gaps in your architecture, while treating them as entirely separate will lead to problems as well. If you were to build a Wallet integration that achieves high LoA but has no AML screening attached, then you've verified who the person is but have no idea whether you can legally onboard them. Conversely, if you build an AML flow that assumes a document was always presented, you won’t be set up to handle a Wallet credential if and when one arrives. In both cases, the gap isn’t present while you’re building but becomes visible later. 

What good architecture actually looks like 

So, what should we be building, exactly? To answer this question, it’s worth thinking in layers: 

• Layer 1: Identity proofing. Here's where the Wallet gets to shine! 

• Layer 2: Liveness. Liveness detection is expected to happen in the same session as identity proofing. 

• Layer 3: AML screening. Occurs after the first two layers are completed. It’s compulsory during onboarding and throughout the customer relationship.  

• Layer 4: Audit trail and ongoing monitoring. This is what regulators examine, and what catches everything that changes after onboarding. 

The gap most institutions face isn't necessarily in the tools themselves. Instead, it's in how they connect. A liveness check that runs in a separate system from your screening record, or a Wallet integration that generates its own audit trail rather than feeding into a shared one creates exactly the kind of fragmentation that will become a problem from a regulatory standpoint. 

There’s perhaps an even more pressing thing that I should point out here: not every customer will have the EUDI Wallet, and your architecture needs to reflect this. Document verification and national eID need to be equally supported, equally screened, and equally audited. The compliance steps should be identical regardless of which identity method the customer used.  

Read more about the gaps in eID adoption in Europe here.  

Building intelligently for what comes next 

The EUDI Wallet is the best version of pan-European identity credentials the continent has ever had. It’s government-sourced, cryptographically signed, High assurance, and works across borders. For institutions that have been navigating what came before, from document capture friction to OCR errors, the shift is seismic. 

But the compliance obligations that follow it are another step in your verification process that need equal attention. Liveness checks, AML screening, perpetual KYC, and a regulator-ready audit trail are required every time, for every customer, regardless of how they identified themselves.  

If I were part of a compliance team at a financial organisation, I’d be asking vendors the following questions:  

• Does your platform treat identity verification, liveness, and AML screening as a single event, or as separate ones? 

• If a regulator asks to see the records for a specific onboarding, how quickly can you produce it, and what does it contain? 

• How does your platform handle customers who don't have an EUDI Wallet? Furthermore, is the compliance flow identical regardless of which identity method they used? 

• What does your perpetual KYC monitoring actually flag, and how is that escalated to your compliance team? 

At Fourthline, that's exactly the architecture we've built toward: identity proofing, liveness, screening, and audit trail as a single integrated flow, consistent across every identity method AMLR recognises. The Wallet becomes one input among several, feeding into a compliance infrastructure that covers liveness, AML screening, perpetual KYC, and audit trail as standard, regardless of which identity method the customer used. 

Get in touch with a specialist at Fourthline