AMLR, eIDAS 2.0 and the EUDI Wallet: What the New CDD Rules Mean for Digital Onboarding

Introduction

Europe is building a new identity infrastructure. The EU Digital Identity (EUDI) Wallet, mandated under eIDAS 2.0, is no longer a future concept. Member States are required to make wallets available to their citizens by the end of 2026, and private-sector relying parties in regulated areas, including financial services, will need to accept wallet-based identification flows by the end of 2027. [1]

At the same time, the Anti-Money Laundering Regulation (AMLR), which applies from July 2027, is rewriting the rules for how organisations verify who their customers are. For the first time in EU AML law, digital identity tools such as eIDs, qualified trust services, and the EUDI Wallet are explicitly recognised as valid, compliant pathways for remote customer verification. [2]

The document tying these two regulatory tracks together is AMLA’s draft Regulatory Technical Standards (RTS) on Customer Due Diligence under Article 28(1) of the AMLR. The draft RTS was published for consultation on 9 February 2026, with the consultation period closing on 8 May 2026. [3]

This blog explains what the draft RTS requires, why the EUDI Wallet sits at the centre of the EU’s new compliance infrastructure, and what organisations need to do to be ready.

Two regulations, one compliance moment

The convergence of eIDAS 2.0 and the AMLR is not coincidental. Both are part of the EU’s broader ambition to create a digital single market where identity can be interoperable: verified once, trusted everywhere, and reused across borders and sectors without friction.

Under the previous AML framework, a series of directives transposed differently across all 27 Member States, digital identity verification was often treated as a risk factor to be managed rather than a solution to be embraced. Remote onboarding meant higher scrutiny. Digital documents meant more checks, not fewer.

The AMLR changes that logic. [2]

Article 22(6) explicitly recognises electronic identification means and qualified trust services as legitimate verification pathways on equal legal footing with traditional document-based processes. [2] And the EUDI Wallet, as the EU’s flagship digital identity instrument under eIDAS 2.0, is the natural beneficiary of that recognition.

Key dates at a glance

The regulatory timeline is now clear: AMLR was adopted on 31 May 2024, AMLA published its draft CDD RTS on 9 February 2026, and the consultation period closed on 8 May 2026. [2] [3]

The next milestones are implementation-driven: EUDI Wallets and AMLD6 transposition are due in 2026, the AMLR applies from 10 July 2027, and financial institutions must accept EUDI Wallet credentials by December 2027. [1] [2] [4]

The draft RTS, built on earlier work by the European Banking Authority (EBA) and extended by AMLA to cover the non-financial sector, sets the technical rules for how this works in practice. [3] [5] It is, in effect, the implementation bridge between the legal text of the AMLR and the operational reality of onboarding a customer in 2027.

What Article 22(6) of the AMLR actually says

Before getting into the RTS, it is worth being precise about what the AMLR itself establishes, because Article 22(6) is the legal foundation on which everything else rests.

When verifying customer identity in a non-face-to-face context, obliged entities may use:

• Document-based remote verification: submission of an identity document combined with information acquired from reliable independent sources, which is the standard remote ID verification flow.
• Electronic identification means: eIDs at “substantial” or “high” assurance levels under eIDAS, or qualified trust services as defined under eIDAS. This explicitly includes EUDI Wallet-based identification flows and Qualified Electronic Signatures (QES). [1] [2]

This represents a fundamental shift compared to previous AML frameworks. Digital identity is no longer a workaround or a risk mitigation measure. It is a fully recognised compliance pathway with explicit legal status in EU AML law.

The draft RTS builds on this by specifying exactly what technical attributes each method must carry, and at which CDD tier each can be applied.

The EUDI Wallet: from policy ambition to compliance infrastructure

The EUDI Wallet is the centrepiece of eIDAS 2.0. Every EU Member State is required to make a wallet available to its citizens and residents by 2026. Financial institutions, along with a broad range of other relying parties, are required to accept wallet-presented credentials by December 2027. [1]

What the wallet provides is a user-controlled, cryptographically secured container for digital identity credentials. [6] A citizen can store their national identity data, driving licence, professional qualifications, and other verified attributes, and present only the specific data requested by a relying party without exposing anything else.

This selective disclosure capability is not just a privacy feature. [6] It is also a compliance feature. It means the wallet can support the AMLR’s data minimisation requirements under GDPR while simultaneously providing the verified attributes an obliged entity needs for CDD. [7]

Under eIDAS 2.0, EUDI Wallet credentials are designed to meet assurance level “high”, the highest level defined under the eIDAS framework. [1] This places them in the top tier of the AMLR’s verification hierarchy.

The draft RTS operationalises this by specifying the information and documents that obliged entities must collect and verify for CDD, including when they rely on electronic identification means and qualified trust services. [3]

In practice, this creates roughly the following assurance picture:

The implication is direct: for higher-risk customer relationships requiring enhanced due diligence, an EUDI Wallet or QES is not just an option. It is among the few verification methods that can satisfy the assurance threshold the RTS is expected to require.

What the draft RTS requires for CDD

Standard CDD: the information baseline

For natural persons, the draft RTS specifies that obliged entities must collect and verify a baseline set of identity attributes, including: [3]

• full legal name,
• date and place of birth,
• nationality,
• national identification number,
• usual place of residence,
• and tax identification number, where available.

This is exactly the kind of data the EUDI Wallet is designed to provide as government-issued, cryptographically signed attributes, verified once at the point of credential issuance and reusable across every subsequent interaction.

A customer presenting a wallet credential does not need to re-submit documents, fill in forms, or wait for a manual check. The obliged entity receives verified attributes directly, with cryptographic proof of authenticity.

For legal entities, the requirements extend to legal form, registered address, names of legal representatives, and beneficial ownership. [3] Wallet-based solutions are increasingly relevant here too, with the EUDI framework extending to legal person identification data (LPID) as a recognised credential type. [6]

The reliability and independence standard

The draft RTS requires identity information to come from sources that are both reliable and independent. [3] This is the standard against which all verification methods, including digital ones, are assessed.

Government-issued EUDI Wallet credentials, signed by a national identity authority, sit at the top of this hierarchy. They are issued by a state or public authority, meet eIDAS 2.0 technical standards, and carry a cryptographic proof of origin that can be machine-verified in real time.

Once an obliged entity has assessed EUDI Wallet credentials as meeting the reliability and independence standard, that assessment can be reused across all customers who present wallet credentials. No repeated evaluation is needed per customer.

That is a significant operational efficiency gain compared to document-based flows, where each submission requires individual authenticity checks and manual or automated verification against external databases.

Simplified CDD: still real verification

The draft RTS is clear that simplified due diligence is not an absence of verification. [3] It is a reduced set of scrutiny measures that must still address all components of the standard process.

Minimum identification requirements in low-risk situations should still include, at a minimum, the information typically found in a passport or identity document.

The EUDI Wallet satisfies this requirement comfortably. Even in a simplified CDD flow, a wallet presentation delivers verified identity attributes instantly, with no reduction in data quality. The difference is only in the volume of additional information the obliged entity needs to collect about the purpose and nature of the relationship.

Enhanced CDD: where high assurance becomes non-negotiable

In high-risk situations, the draft RTS requires additional information on source of funds and source of wealth. [3] It also specifies that this information must meet the reliability and independence criteria and be of sufficient quality to assess its authenticity. Self-declaration is not enough.

For the identity verification component of enhanced CDD, “high” assurance is the relevant threshold.

The EUDI Wallet, operating at high assurance under eIDAS 2.0, and QES, which carries a legal presumption of validity under EU law, are the tools designed for exactly this context. A QES backed by certified remote identity verification provides one of the strongest available legal bases for an onboarding decision in a high-risk scenario.

Beneficial ownership, PEPs, and ongoing monitoring

The draft RTS also addresses areas where digital identity infrastructure is increasingly well placed to support compliance after initial onboarding. [3]

Beneficial ownership

Consulting a central register is necessary, but not sufficient, under the draft RTS. [3] Firms must independently verify beneficial ownership and assess the reliability of the information obtained.

Wallet-based credentials for legal persons, including LPID credentials under the EUDI framework, offer a pathway to more reliable beneficial ownership verification as the ecosystem matures.

PEP screening

PEP checks must cover the customer, their beneficial owner, and any person acting on their behalf. [3]

The draft RTS, in one of the areas where AMLA refined the EBA’s original text, requires that once a PEP is identified, specific and additional CDD measures apply to the entire relationship.

Ongoing monitoring

The AMLR’s CDD obligations do not end at onboarding.

The reusability of EUDI Wallet credentials — their ability to be re-presented, re-verified, and selectively disclosed at any point in the customer lifecycle — makes them a natural fit for ongoing monitoring obligations as well as initial verification.

The technical reality of remote onboarding

Understanding why the EUDI Wallet represents such a significant step forward requires looking at the alternative: what traditional remote onboarding without digital credentials demands from organisations and customers under current EU technical standards.

ETSI TS 119 461 v2.1.1, the EU’s primary technical standard for identity proofing in trust services, defines three modes of remote identity verification. [8] The requirements for each reveal why the traditional path is becoming increasingly burdensome, and why the digital credential path is operationally attractive.

The traditional path: remote onboarding without digital credentials

Without a digital eID or EUDI Wallet credential, remote onboarding under EU technical standards requires one of two approaches.

Attended remote onboarding with a live agent

Under clause 9.2.2 of ETSI TS 119 461, the customer connects via video to a registration officer who guides them through the process in real time. [8]

The officer must follow a defined procedure specifying how to handle deviations and when to abort the session. For Baseline Level of Identity Proofing (LoIP), manual document validation by the agent is permitted.

For Extended LoIP, the level required for qualified trust services under eIDAS 2.0, manual operation alone is explicitly not permitted. [8] Only hybrid or automated approaches qualify.

This creates a structural constraint: live agent video sessions can satisfy standard CDD requirements, but they cannot on their own satisfy the higher assurance requirements for qualified services under the amended eIDAS regulation.

Unattended automated remote onboarding

Under clause 9.2.3.4, the customer completes the process without a live agent, using an automated system. [8]

Here, the requirements are technically demanding. The standard requires at least one digital identity document, meaning an eMRTD with a readable chip rather than a photograph, to be used as authoritative evidence. It also requires binding to the applicant to be established through automated face biometrics.

The deepfake problem: why technical requirements are tightening

The v2.1.1 update to ETSI TS 119 461, published in February 2025, introduced significantly stronger requirements for attack detection. [8] This was a direct response to the rapid advancement of AI-generated identity fraud.

These requirements apply to any remote process using video capture, regardless of whether a live agent is present. [8]

The standard now requires:

• Video capture quality: a live video stream of the applicant’s face must be captured at sufficient quality, for example 25 fps at 1280×720 resolution, and must happen in real time during the identity proofing session. Pre-recorded videos are explicitly prohibited. [8]
• Presentation attack detection: the system must apply presentation attack detection to ensure the video stream is of a live person present in front of the camera. This protects against photo attacks, video replay attacks, and physical mask attacks. [8]
• Deepfake detection: the standard explicitly names AI-generated faces as a threat. Video capture must apply means to detect artificially generated or manipulated face appearance, including “deep fake” attacks. [8]
• Injection attack prevention: the process must prevent both the applicant and external attackers from injecting a previously recorded or artificially generated video stream into the process undetectably. [8]
• Laboratory testing: for Baseline LoIP, injection attack detection systems must be tested by an accredited laboratory to CEN/TS 18099 level Substantial, or level 2, by the end of 2026. [8]

The standard itself acknowledges the challenge: protection measures, including those based on artificial intelligence, are rapidly evolving to detect deepfakes. But it does not mandate specific technical approaches, which places the burden on service providers to implement and validate effective countermeasures.

Notably, EN 319 401 v3.1.1, the general policy standard for trust service providers, does not specify deepfake or AI attack controls directly. [9] Those requirements sit within TS 119 461. EN 319 401’s role in remote onboarding is organisational: it governs personnel screening, information security management, and the operational framework within which identity proofing takes place.

The digital credential path: what changes

When a customer presents a digital eID or EUDI Wallet credential instead of a physical document, the technical requirements shift fundamentally.

Rather than capturing and validating a video stream against a document photograph, the verification process becomes cryptographic.

Under clause 9.2.4 of ETSI TS 119 461, when an existing eID is used as the primary means of identity proofing through authentication rather than as a document to be read, the cryptographic authentication of the eID substitutes for biometric binding to the applicant. [8]

The logic is straightforward: the person was biometrically verified when the eID was originally issued at LoA High, and the authentication mechanism cryptographically proves it is the same person presenting the credential now.

The practical implication for organisations building onboarding infrastructure is significant.

A traditional remote onboarding flow requires continuous investment in anti-fraud technology: PAD systems, deepfake detectors, injection attack prevention, and laboratory-certified testing. This investment has to keep pace with an adversarial landscape that is evolving rapidly.

A digital credential flow moves much of the security burden to the credential issuance process, which has already been certified and audited at the point of eID or wallet provisioning.

That does not mean digital credential flows are without security considerations. The WSCD and WSCA requirements for the EUDI Wallet, including certified hardware security at AVA_VAN.5 under Common Criteria, represent a substantial security investment. [6]

But that investment is made once at the infrastructure level by the wallet provider and the Member State. The obliged entity accepting the credential inherits that security, rather than having to build and maintain it independently.

Why organisations should not wait for the final text

The AMLR applies from 10 July 2027. The EUDI Wallet acceptance obligation applies from December 2027. [1] [2]

These deadlines are converging, and the time to prepare is not after the final RTS is published.

Several things are already clear from the draft.

EUDI Wallet acceptance is not optional

Financial institutions are legally required to accept EUDI Wallet credentials by December 2027. [1]

This is not a choice about preferred technology. It is a regulatory obligation that requires technical integration, staff training, and updated KYC procedures.

Assurance levels drive verification method selection

Organisations building risk-tiered onboarding workflows need to map their verification methods to eIDAS assurance levels, not just to broad CDD categories.

A single verification method applied uniformly across all customers will not satisfy the RTS.

The wallet is compliant by design

EUDI Wallet credentials are government-issued, cryptographically verified, and issued at high assurance level.

That means they are designed to meet the reliability and independence standard in the draft RTS without additional verification work on the obliged entity’s side.

Traditional remote onboarding is getting harder

The tightening of ETSI TS 119 461 v2.1.1 requirements for deepfake and injection attack detection means maintaining a compliant traditional remote onboarding flow requires ongoing technical investment and laboratory-certified testing.

The compliance cost of the traditional path is rising at the same time as the digital credential path becomes more accessible.

The non-financial sector is now in scope

One of AMLA’s explicit goals in revising the EBA’s draft was ensuring applicability across both financial and non-financial obliged entities. [3] [5]

Real estate agents, accountants, lawyers, and crypto-asset service providers face the same directly applicable standards as banks.

What organisations should assess now

Every organisation subject to the AMLR should be asking six questions:

1. Does your remote onboarding infrastructure support at least one of the two Article 22(6) pathways, and can you apply the right pathway based on customer risk level?
2. Are you technically ready to accept EUDI Wallet-presented credentials as a CDD verification method by December 2027?
3. Can you demonstrate that your verification sources meet the reliability and independence standard in the draft RTS?
4. If you rely on traditional remote onboarding, are your PAD and deepfake detection systems on track for laboratory certification by the end of 2026?
5. Is your beneficial ownership verification independent of central register data alone?
6. Does your PEP screening cover beneficial owners and persons acting on a customer’s behalf?

Conclusion

For organisations that have been watching the EUDI Wallet ecosystem develop from a distance, the convergence of eIDAS 2.0 and the AMLR changes the calculus.

Wallet acceptance is not just a feature to consider. It is becoming a compliance requirement with a hard deadline.

The organisations that integrate wallet-based verification into their onboarding flows now will be best positioned to meet both the July 2027 AMLR deadline and the December 2027 wallet acceptance mandate without a last-minute scramble.

The consultation on the draft RTS closed on 8 May 2026. [3] The next phase is about preparing for implementation, particularly around the technical attributes electronic identification means must carry, the assurance level thresholds for each CDD tier, and the practical requirements for wallet integration in non-financial sector contexts.

The infrastructure is being built. The regulatory framework is being finalised. The deadline is set. The time to act is now.