How Will the EUDI Wallet Change KYC? | Authologic Legal Briefing

Key takeaways

• The EUDI Wallet legal framework is already in force. Regulation (EU) 2024/1183 amending eIDAS entered into force on 20 May 2024.
• Three dates, not one: 24 December 2026 (wallet availability), 10 July 2027 (AMLR applies), 24 December 2027 (acceptance obligation).
• The acceptance obligation arises from eIDAS, not from the AMLR, and does not cover every obliged entity or every KYC process.
• Verifying identity through the Wallet does not determine whether the customer is a PEP, is subject to sanctions, or what the source of their funds is.
• Relying-party registration adds a Wallet-specific constraint: the data a relying party may request is declared in advance and checked against the registered purpose.

The European Digital Identity Wallet ("EUDI Wallet" or the "Wallet") will not turn KYC into a one-click process. It will, however, undoubtedly change the way institutions, including financial institutions, verify customer identity and demonstrate to supervisors that they have done so correctly.

2027 will undoubtedly be an important year for the use of the Wallet in AML/CFT processes - procedures used, among others, by banks to prevent money laundering and terrorist financing. One element of these processes is KYC, which includes, among other things, customer identification and identity verification. The legal and operational reality is, however, somewhat more complex.

The Wallet may make it easier to verify customer data, but it will not relieve institutions of responsibility for the AML/CFT process as a whole. While it may become possible to complete customer identification and identity verification entirely within a Wallet-based flow, this will not be mandatory.

The market can nevertheless be expected to move in this direction if the Wallet genuinely simplifies the process.

Is there one EUDI Wallet deadline, or three?

There are three, and they do different things.

The legal framework for the EUDI Wallet is already in force: Regulation (EU) 2024/1183 amending eIDAS entered into force on 20 May 2024.

The rollout of the Wallet and its broader market adoption are, however, spread over time.

The 24 December 2027 obligation arises from eIDAS rather than the AMLR and does not automatically apply to every obliged entity or every KYC process. As a rule, it does not apply to microenterprises and small enterprises, and use of the Wallet takes place only at the voluntary request of the user. Entities subject to this obligation therefore need to prepare sufficiently early to support the Wallet.

The scope of that obligation, and how it interacts with strong customer authentication, is covered in How eIDAS 2.0 affects private relying parties and SCA.

Accepting an EUDI Wallet will therefore not automatically mean that every attestation contained in it is sufficient for AML/CFT purposes.

How will the Wallet change the way KYC is conducted and documented?

It moves the object of verification from the document to the data.

In a typical remote KYC process, an obliged entity checks whether the identity document presented is authentic, has not been altered and is being presented by its genuine holder. In a Wallet-based model, instead of assessing an image of an identity document, the institution will primarily verify who issued the data, whether it has been altered and whether it remains valid.

When using the Wallet, an institution can verify the issuer of an attestation, as well as its integrity and validity. This does not automatically mean, however, that the data received will be complete from an AMLR perspective. The AMLR establishes a common EU set of basic identification data, but the availability of additional attestations in national Wallets may initially differ.

The relevant question should therefore not be "did the customer use an EUDI Wallet?", but rather whether the data provided corresponds to the scope required under the AMLR - in the case of a natural person, in particular under Article 22(1)(a) AMLR. This approach makes it possible to determine whether the information received actually satisfies the applicable identification requirements.

Instead of an ID scan, a financial services provider may receive data whose origin, integrity and validity can be checked automatically. This will reduce manual data entry, document copying and some error-prone manual checks, thereby reducing the risk associated with the use of a forged copy or image of an identity document. At the same time, the EUDI Wallet is designed to enable specific attributes to be shared instead of entire documents.

The key conclusion is therefore that compliance with eIDAS requirements by an electronic identification means or a trust service will provide a regulatory basis for assessing the reliability of the mechanism and the origin of the data, but will not determine whether the AML/CFT process as a whole is complete. What matters, among other things, is which data has actually been provided.

Does the EUDI Wallet replace KYC checks?

It does not replace the risk-based part of the process.

The AMLR will require the identification and verification of customers and beneficial owners, an understanding of the purpose of the business relationship, a risk assessment and ongoing monitoring of business relationships.

Verifying a customer's identity using the Wallet alone will not determine whether the customer is a PEP, is subject to sanctions, displays unusual activity or - where required by the level of risk - what the source of their funds is.

What a wallet actually presents depends on the user. Identity attributes will be there; others, such as an attestation covering source of funds, may not be - and, as set out above, the Wallet does not carry sanctions or PEP information.

Authologic therefore treats it as one channel inside a broader process, routing the remaining checks to other trusted sources within the same flow.

What can obliged entities do now?

First, they should map their existing processes.

Business and operational analyses should be carried out to create a map of Wallet use cases rather than merely an IT integration plan. For account opening, changes to customer data or customer re-verification, institutions should determine the minimum set of information required for AML/CFT purposes, compare it with the data available through the Wallet and identify any additional sources that may be required.

Institutions do not necessarily have to build the entire integration layer themselves.

Authologic is one of the identity verification platforms that allow different identification methods and data sources to be combined within a single process, covering 91 methods from 84 providers across 236 countries and territories as of August 2026. In such a model, the EUDI Wallet can be incorporated into the existing KYC architecture as another fully fledged path for obtaining and verifying data, rather than operating as a separate solution alongside existing methods.

Second, institutions should develop a Wallet acceptance policy or incorporate the Wallet as an electronic identification means into their existing procedures, policies or customer terms and conditions. They should define the types of attestations required, the rules for assessing their issuers, the validation process and how the verification process is to be documented. The future "KYC file" does not need to be based on an archive of document scans. In line with the accountability principle, however, it should make it possible to demonstrate what data was received, from whom, when, and with what verification outcome.

Third, institutions should provide for an alternative route. Use of the Wallet is voluntary, and the range of attestations available through it may initially differ between Member States. The EUDI Wallet should therefore be one fully fledged channel for obtaining data and evidence for KYC purposes, but not the only one.

Authologic provides that alternative route as a platform default: when a user has no Wallet, or the attestation required for a given use case is not available in their Member State, the flow falls back to another eID, bank-based verification or a document check without a separate integration.

For a structured version of these three steps, see the EUDI Wallet Readiness Checklist (20 questions) and the SCA & AMLR Readiness Checklist (32 questions, covering both AMLR customer due diligence and eIDAS 2.0 wallet acceptance).

What does relying party registration mean for data minimisation?

It turns data minimisation into a declared and checkable scope.

Importantly, data minimisation in the context of the EUDI Wallet will not remain merely an organisational principle. An entity using the Wallet as a relying party is subject to registration, and its registered use of the Wallet also covers the scope of data it intends to request.

The implementing rules on relying-party registration provide that the registration certificate is to specify this scope, while the Wallet is to enable verification of whether the data requested falls within the registered purpose and to inform the user where a request goes beyond the registered scope.

In practice, this represents a significant change in how KYC processes are designed. Institutions will need to link each specific use case in advance to a specific set of required attributes.

Part of the compliance assessment will therefore move upstream: from asking, after the process has already been designed, "have we collected too much data?" to asking earlier, "what data do we actually need for this process?".

This may prove to be one of the more important, although less obvious, consequences of the EUDI Wallet for regulated organisations.

The roles behind registration - who issues an attestation, who provides the Wallet and who guarantees the result - are set out in the glossary Who Issues, Who Provides, Who Guarantees.

What does an ineffective EUDI Wallet implementation look like?

An ineffective implementation would consist of simply adding a "Use EUDI Wallet" button to a process that then still requires the customer to complete a full information form, upload an identity document and take a selfie.

Such a bare-minimum implementation of the new requirements would not only fail to realise the Wallet's potential but would, in practice, merely increase costs while preserving existing customer friction.

It would fail to capture the Wallet's core value: the ability to obtain precisely the trustworthy data required for a specific use case.

The design choices that avoid this outcome are covered in The simplest way to implement the EUDI Wallet is the one you don't rebuild later.

What should regulated organisations expect in 2027?

A migration period, not a single technical launch.

The EUDI Wallet will not automate AML/CFT processes overnight. The eIDAS 2.0 implementation timeline does, however, leave time for organisational and technical preparation. The Wallet can automate part of the collection and verification of the data on which KYC relies.

The biggest change will therefore not be another digital version of an identity document, but rather a shift away from collecting complete copies of documents towards obtaining specific, limited and verifiable data.

For banking and financial services - as well as, among others, the energy, healthcare and transport sectors - 2027 should therefore be seen not as the date of a single technical implementation, but as a period of migration: from manually reviewing document scans to operationally managing data whose source and integrity can be verified automatically.

The most important change may, however, begin even earlier: institutions will need to start designing KYC not by asking "what data can we collect?", but by asking "what data do we actually need?".

In the EUDI Wallet environment, the answer to that question will become part not only of compliance policy, but of the architecture of the process itself.

FAQ

When must banks accept the EUDI Wallet?

By 24 December 2027 at the latest, and only upon the voluntary request of the user. Certain private-sector service providers, including those in banking and financial services, must accept the Wallet where Union law, national law or a contractual obligation requires them to use strong user authentication for online electronic identification. The obligation arises from eIDAS rather than the AMLR.

Does the EUDI Wallet satisfy AMLR customer due diligence?

Not automatically. Accepting an EUDI Wallet does not mean that every attestation contained in it is sufficient for AML/CFT purposes. The question is whether the data provided corresponds to the scope required under the AMLR, in the case of a natural person in particular under Article 22(1)(a).

Does the EUDI Wallet replace sanctions and PEP screening?

No. Verifying a customer's identity using the Wallet alone will not determine whether the customer is a politically exposed person, is subject to sanctions, displays unusual activity or, where the level of risk requires it, what the source of their funds is.

Is using the EUDI Wallet mandatory for customers?

No. Use of the Wallet by users remains voluntary, and it takes place only at the voluntary request of the user. The obligation sits with the relying party, which must be able to accept the Wallet where strong user authentication is legally required.

Do small companies have to accept the EUDI Wallet?

As a rule, no. The acceptance obligation under Article 5f(2) eIDAS does not apply to microenterprises and small enterprises.

What happens if a customer does not have an EUDI Wallet?

The institution needs an alternative route. Use of the Wallet is voluntary and the range of attestations available through it may initially differ between Member States, so the Wallet should be one fully fledged channel for obtaining KYC data and evidence, but not the only one.

Can the EUDI Wallet be used to update existing customer data?

Yes, where the relevant attestation is available. A customer changing their address can provide only the attribute containing the new address instead of resubmitting the entire document, and the institution can verify the source, integrity and validity of that attestation and record the outcome.

When does the AMLR apply?

From 10 July 2027. Regulation (EU) 2024/1624 applies from that date across the EU. Obliged entities should already take the Wallet into account when designing their KYC and KYB architecture in order to prepare in time for the changes arising from both the AMLR and eIDAS 2.0.

Changelog

• 14 August 2026 - Initial publication.

This briefing sets out general information on the legal framework as it stood in August 2026 and reflects the authors' reading of that framework. It does not constitute legal advice.