Talk to usTry the demo

The European Digital Identity Wallet as a Verification Source for Regulated Firms

Regulation and standards

For: Compliance lead, product owner or architect at a bank, payment firm or other regulated firm that onboards customers in the European Union

The EU digital identity wallet for regulated firms, with the July 2026 amendments: registration certificates, person identification data, the portrait, selective disclosure and dates.

For information; not legal advice.

A bank, a payment firm or a crypto-asset service provider in the European Union may, in the coming years, be asked by some customers to identify themselves with an identity wallet on a phone instead of a passport photographed in a browser. The European Digital Identity Wallet is the instrument the Union created for that purpose, and the firm that receives it is called a relying party. This article explains what the wallet is in legal terms, what a firm has to do before it can receive one, what data a wallet hands over, how selective disclosure limits it, which dates are fixed by the texts, and how the wallet connects to the customer due diligence rules.

Two neighbouring articles already cover parts of the ground, and this one does not repeat them. The article on the EU AML Regulation and remote customer identification explains the two verification routes of the identification article and the technical standards that follow from it. The article on ETSI TS 119 461 explains identity proofing for trust services, including the identity verification duty of qualified trust service providers. What neither of them describes is the wallet itself: its rules, the registration of the firms that receive it, the data it holds and the timetable. That is the subject here.

This article reads the implementing regulations in the form they have after the two amending acts of 15 July 2026, which the sections below introduce where they apply. A reader who works from the original texts alone will miss changes to the data formats, the registration certificates and the portrait.

Where the wallet comes from

The wallet is created by Regulation (EU) 2024/1183 of the European Parliament and of the Council of 11 April 2024, which amends Regulation (EU) No 910/2014 "as regards establishing the European Digital Identity Framework". It was published in the Official Journal on 30 April 2024 and, under its last article, entered into force on the twentieth day following publication. Regulation (EU) No 910/2014 is the eIDAS Regulation of 2014, so the wallet is an amendment to an existing text and not a separate law.

The European Commission describes the change this way: the 2014 regulation let Member States notify national electronic identification schemes on a voluntary basis, and recognition of notified schemes became mandatory in 2018, but there was no requirement for any Member State to develop a national scheme. The new regulation, in the Commission's words, mandates Member States to offer citizens and businesses digital wallets that can link national digital identities with proof of other personal attributes. The Commission's page adds that the framework mandates Member States to provide wallets to citizens by the end of 2026.

The vocabulary a firm has to learn

The amended text defines its terms, and the definitions decide who owes what.

  • Person identification data is a set of data issued in accordance with Union or national law that enables the establishment of the identity of a natural or legal person, or of a natural person representing another person.
  • Relying party is a natural or legal person that relies upon electronic identification, European Digital Identity Wallets or other electronic identification means, or upon a trust service.
  • European Digital Identity Wallet is an electronic identification means that allows the user to securely store, manage and validate person identification data and electronic attestations of attributes for the purpose of providing them to relying parties, and to sign by means of qualified electronic signatures or seals.
  • Attribute is a characteristic, quality, right or permission of a natural or legal person or of an object, and an electronic attestation of attributes is an attestation in electronic form that allows attributes to be authenticated.
  • Strong user authentication is authentication based on at least two factors from different categories of knowledge, possession or inherence, which are independent in that the breach of one does not compromise the others.

Two consequences follow for a regulated firm. First, a firm is a relying party the moment it relies on a wallet, and an intermediary acting on behalf of a relying party is deemed to be one as well, with a duty not to store data about the content of the transaction. Second, the wallet is defined as an electronic identification means. That matters in the AML Regulation, which names electronic identification means as a verification route, as the section on customer due diligence below shows.

What the wallet must do

Article 5a of the amended regulation sets what a wallet has to offer its user. The user can securely request, obtain, select, combine, store, delete, share and present person identification data, under the sole control of the user, "while ensuring that selective disclosure of data is possible". The user can also generate pseudonyms and keep them encrypted and local to the wallet. A common dashboard lets the user view a list of relying parties with which a connection was made and the data exchanged. From that dashboard the user can request erasure of personal data by a relying party under Article 17 of the General Data Protection Regulation, and report a relying party to the national data protection authority if a request for data seems unlawful or suspicious.

Several rules protect the user and constrain a firm's design.

  • Use of the wallet is voluntary, and access to public and private services shall not be restricted or made disadvantageous for persons who do not use it.
  • The text adds that it shall remain possible to access public and private services by other existing identification and authentication means.
  • Issuing, using and revoking the wallet is without charge for natural persons, which is a rule about the wallet's provider and not about the firm that receives it.
  • The technical framework must not allow providers of attestations of attributes, after issuance, to obtain data that allows transactions or user behaviour to be tracked, linked or correlated, unless the user explicitly authorises it.
  • The wallet must meet the requirements of Article 8 at assurance level high, in particular for identity proofing and verification, and it is provided under an electronic identification scheme with assurance level high.

The voluntary-use rule has a direct operational meaning for a firm that accepts the wallet. Access must not be made disadvantageous for a person who does not use a wallet, and it must remain possible by other existing identification and authentication means, so a firm should not make the wallet its only way in. Which other means a firm offers is its own design choice, and the document route in the AML Regulation is the obvious candidate.

What a wallet holds: person identification data

Commission Implementing Regulation (EU) 2024/2977 of 28 November 2024 sets the rules for person identification data and electronic attestations of attributes issued to wallets. It was published in the Official Journal on 4 December 2024. Commission Implementing Regulation (EU) 2026/1731 of 15 July 2026 amends Implementing Regulations 2024/2977, 2024/2979, 2024/2980 and 2024/2982 as regards applicable standards and specifications. It was published in the Official Journal on 22 July 2026 and, under its last article, enters into force on the twentieth day following publication. Counted from 22 July 2026, that day is 11 August 2026, and this date is a count made for this article from the text, not a date written in it. Article 1, point (4), of the amending regulation replaces the Annex to Implementing Regulation 2024/2977, so the attribute lists below are those of the replaced Annex.

Table 1 of the replaced Annex lists the mandatory person identification data for a natural person, each item named with a machine identifier: family_name, given_name, birth_date, birth_place, nationality and portrait. Birth place is the country as a two-letter code, or the state, province, district, local area, municipality, city, town or village where the person was born. Nationality is one or more two-letter country codes, and the Annex tells Member States to use the value QU where the nationality is unknown and the value QS where the person holds no nationality. Where the birth date is not known, Member States choose appropriate values that comply with the encoding specifications of the Annex.

The portrait is treated differently from the other five identifiers. Its entry in Table 1 describes a facial image provided as a JPEG that meets the full frontal image quality requirements of part 5 of standard 39794 or, for backward compatibility, part 5 of standard 19794, the two series being published jointly by the International Organization for Standardization and the International Electrotechnical Commission, and it states that this applies from 11 August 2028 except where the user explicitly opts out. The Annex adds that Member States may provide that the user has the option to decline the insertion of the portrait, that selective disclosure applies to each data identifier including the portrait, and that Member States set the value empty where the user opts out. Recital (3) of the amending regulation gives the reason: to give Member States sufficient time to adapt their national procedures, the portrait may be part of the mandatory person identification data for a natural person only as of 11 August 2028.

Table 2 lists the optional person identification data for a natural person: the full residence address and its parts (country, state, city, postal code, street and house number), a personal administrative number, the family name and given names at birth, sex, an email address and a mobile phone number. For a legal person, Table 3 fixes two mandatory data elements, the current legal name and a unique identifier constructed by the sending Member State for cross-border identification, and Table 4 lists as optional the current address, the value-added tax registration number, the tax reference number, the European unique identifier, the Legal Entity Identifier, the economic operator registration and identification number and the excise number. What this means for a regulated firm is a plain gap analysis. The AML Regulation lists, for a natural person, all names and surnames, place and full date of birth, nationalities and the national identification number where applicable, and the usual place of residence. The first three groups map onto the mandatory wallet attributes, and the usual place of residence maps onto attributes the Annex lists as optional. A firm that needs a residence address cannot assume that every wallet will carry it, and the onboarding design should plan for a second source for that field. The same caution applies to the portrait: because a Member State may let the user decline it and the value is then empty, a face comparison step cannot rely on a portrait being present in the wallet data. The final word on which data points are collected in which risk situation belongs to the technical standards, which are discussed below.

Other rules in Implementing Regulation 2024/2977 shape how much a firm can trust what arrives.

  • Under Article 3(4), a Member State shall ensure that the person identification data issued to a given wallet user is unique for that Member State.
  • Under Article 3(5), the provider of person identification data shall ensure that the data is cryptographically bound to the wallet unit to which it is issued.
  • Under Article 3(7), wallet users are enrolled in accordance with the requirements for enrolment at assurance level high set out in Commission Implementing Regulation (EU) 2015/1502, and identity verification is performed before the data is issued.
  • Under Article 5(1) and (3), a provider of person identification data must have written and publicly accessible policies on validity status, and where it revokes data it informs the wallet user through dedicated and secure channels within 24 hours of the revocation and of the reasons.
  • Under Article 5(5) and (6), a revocation cannot be reverted, and revoked data must remain accessible for as long as Union or national law requires.
  • Under Article 5(7), the validity status of issued data is made publicly available in a privacy preserving manner, with its location indicated in the data.
  • Article 5(4), point (b), as replaced by the amending regulation, makes revocation of person identification data mandatory where the wallet unit attestation of the wallet unit to which the data was issued has been revoked.

Person identification data is issued in the formats of two clauses of Annex II to Implementing Regulation 2024/2979, as replaced: clause 5, the SD-JWT VC format, and clause 6, the mdoc format of the joint standard series 18013. In the mdoc format the attestation type is eu.europa.ec.eudi.pid.1, and the same string identifies the namespace of the attributes. Annex II to Implementing Regulation 2024/2979, as replaced, applies clauses 2 to 6 of ETSI TS 119 472-1 V1.2.1 (2026-02), read with adaptations. One adaptation says that a status element used for person identification data may only indicate whether the attestation is revoked or not revoked, with no other status value such as suspension, and that a revoked attestation is permanently revoked. Another says that revocation is not required for short-lived attestations of attributes with a validity period of 24 hours or less. Recital (1) of the amending regulation adds that the wallets should also support the W3C VCDM format when the new profiles on that format are available. A firm that builds a verifier therefore has two data formats to support now, SD-JWT VC and the mdoc format, and should watch for a third, and the next section covers the presentation standards.

How selective disclosure works in practice

Commission Implementing Regulation (EU) 2024/2982 of 28 November 2024 lays down rules on protocols and interfaces for issuing, presenting and managing the data in a wallet. It was published in the Official Journal on 4 December 2024. Article 4 of the amending regulation 2026/1731 amends it, deletes its single Annex and adds two, Annex I for the issuance protocols and Annex II for the presentation protocols. Article 5(1), as replaced, obliges wallet providers to make sure that wallet solutions support protocols and interfaces for presenting attributes to wallet-relying parties remotely and, where appropriate, in proximity, in accordance with the technical specifications in Annex II. Annex II applies the technical specification in Annex C to part 7 of standard 18013, edition 2025, published jointly by the International Organization for Standardization and the International Electrotechnical Commission, and clauses 4.1, 4.2, 5 and 6 of ETSI TS 119 472-2 V1.2.1 (2026-03), with adaptations. The ETSI specification describes two profiles for a relying party to request attestations or person identification data and for the wallet to send them. One is the mdoc profile, built on part 5 of standard 18013 for non-API mediated transmission and on Annex C of part 7 of that standard for API-mediated transmission, and the other is the OpenID4VC-HAIP profile, which covers both transmission mechanisms. Article 5(4), which the amendment leaves in place, requires that wallet solutions support the selective disclosure of attributes of person identification data and of electronic attestations of attributes.

Selective disclosure means that the user shares only the attributes a request asks for, not the whole record. The regulation builds the protection on several checks that happen in the wallet before any data leaves it. Under Article 3, as amended, wallet providers must make sure that wallet units authenticate and validate the access certificates of wallet-relying parties without delegating those processes to an operating system browser or other intermediary application. They must authenticate and validate requests made using access certificates, and display to the user the information contained in those certificates. They must not present any requested attribute until two checks are complete: that embedded disclosure policies have been processed within the wallet unit, and that the user has approved the presentation in part or in full. Where an attestation does not require the identification of the user, Article 3, point (10), still requires wallets to enable privacy preserving techniques that ensure unlinkability across different relying parties. Article 3, point (4), as replaced, adds that wallet units authenticate and validate the wallet-relying party registration certificate, and under Article 8 of that regulation, as replaced, this point applies from 11 August 2028. Recital (6) of the amending regulation says that this date gives Member States, providers of registration certificates and wallet providers sufficient time to enable wallet units to authenticate and validate the certificates.

For the firm, the practical point is that a request is a registered, signed and visible act. A request for more than the firm registered is something the wallet is built to detect and show, as the next section explains, with the registration certificate check applying from the later date. Under Articles 6 and 7, the user can also, through the wallet, ask a relying party to erase the data provided and report the relying party to the data protection authority, and the protocols regulation requires the wallet to support both. A verification flow that stores wallet data therefore has to be able to act on an erasure request from the wallet, subject to the retention duties that law imposes on the firm.

Safeguards for the portrait

The amending regulation inserts a new Article 3a into Implementing Regulation 2024/2977, headed protection of the portrait. Under Article 3a(1), wallet providers shall ensure that wallet solutions issue warnings to users where relying parties request the disclosure of the portrait, indicating that the request involves the sharing of biometric data and requires confirmation for the selective disclosure of the portrait. Under Article 3a(2), wallet providers shall ensure that wallet solutions require the user to explicitly and specifically confirm the presentation of the portrait. Under Article 3a(3), relying parties shall not retain the portrait unless its processing is necessary for the purposes of identification and authentication in compliance with Union data protection law, or where Union or national law provides for it. The same paragraph says that the portrait shall not be transferred to third countries or international organisations unless Union data protection law permits it. Recital (2) adds that silence or pre-ticked boxes should not be considered confirmation, and that the confirmation is a technical safeguard that does not in itself provide a legal ground for processing. Recital (2) also says that where a relying party processes the portrait for the purpose of uniquely identifying a natural person or confirming a claimed identity, Articles 6 and 9 of the General Data Protection Regulation apply.

For a firm, this means that a face comparison against the wallet portrait is a distinct request with its own warning and its own confirmation, and the firm needs a legal basis and a retention rule for it that does not depend on the user's click.

Becoming a relying party: registration

Article 5b of the amended regulation says that where a relying party intends to rely upon wallets for the provision of public or private services by means of digital interaction, it shall register in the Member State where it is established. The registration must be cost-effective and proportionate to risk. The relying party gives at least the Member State of establishment, its name and, where applicable, its registration number, its contact details, and the intended use of wallets, including an indication of the data it will request from users. Relying parties shall not request users to provide any data other than the data indicated in that registration. They must inform the Member State without delay of any change. They are responsible for the procedure of authenticating and validating the data they request from wallets, and they may not refuse pseudonyms where identification of the user is not required by Union or national law.

Commission Implementing Regulation (EU) 2025/848 of 6 May 2025 lays down the rules for the registration of wallet-relying parties. It was published in the Official Journal on 7 May 2025, and its last article says that it applies from 24 December 2026. Commission Implementing Regulation (EU) 2026/1730 of 15 July 2026 amends it as regards applicable standards and specifications. It was published in the Official Journal on 22 July 2026 and, under its last article, enters into force on the twentieth day following publication, which is 11 August 2026 by the count used above. Its Article 1 makes seven amendments, to Article 6(3), a new paragraph 3a in Article 6, Article 8 and Annexes I, IV and V of Implementing Regulation 2025/848. None of them touches the last article of the registration regulation, so this article reads its application date as unchanged, and a firm should confirm that with the registrar of its Member State. Its main duties, in the amended form, are these.

  • Each Member State maintains at least one national register of wallet-relying parties, designates at least one registrar, and makes the register available online both in human-readable form and in a form suitable for automated processing.
  • The information is served through a single common application programming interface and a national website, and it is electronically signed or sealed by or on behalf of the registrar.
  • Member States publish registration policies that describe the identification and authentication procedures for relying parties, the supporting documentation, the authentic sources used, the redress mechanism and the rules for verifying the information.
  • A relying party must provide the information in Annex I, ensure that it is accurate at the time of registration and update it without undue delay.
  • Under Article 6(3), point (a), as replaced, registrars verify, where possible in an automated manner, the accuracy, validity, authenticity and integrity of the information required under Annex I, points 1 to 6 and 11 to 16.
  • Article 6(3) still lists the verification of the power of attorney of representatives and of the absence of an existing registration in another national register, and under Article 6(6) a registrar that cannot verify the information rejects the registration.
  • Point (c) of Article 6(3), which covered the type of entitlement, is deleted.
  • Under new Article 6(3a), registrars collect the information referred to in Annex I, points 7 to 10 in an automated manner only for the purpose of transparency and, without prejudice to Article 5b(4) of Regulation (EU) No 910/2014, shall not apply any preauthorisation process on this information.
  • A relying party that no longer intends to rely on wallets under a registration notifies the registrar without undue delay and requests cancellation.

Annex I lists the data a register holds. It includes the name as stated in an official record, a user-friendly name, one or more identifiers such as a registration number, a value-added tax number, a legal entity identifier or a tax reference number, the physical address, a web address, and contact information. Point 8 asks for a description of the type of services the relying party provides. Point 9 asks, for each intended use, for a list of the data, including attestations and attributes, that the relying party intends to request, with a user-friendly name and a technical name, the attestation type and any other syntaxes the data is grouped under, in a machine-readable format for automated processing. Point 10 asks, for each intended use, for a description of the intended use of the data that the relying party intends to request from wallet units. The amending regulation adds a point 16 to Annex I: where applicable, an association to the wallet-relying party that is relying upon the intermediary to whom the access certificate has been issued and that is acting on behalf of the relying party who intends to rely upon the wallet. Points 7 to 10 are therefore the contact information, the description of the services and, for each intended use, the data list and the purpose description, and these are the items for which a registrar collects the information but applies no preauthorisation. The entitlement of the relying party is expressed in a fixed vocabulary, and the first value, Service_Provider, is the entitlement of a relying party that provides services. On a plain reading, a bank or payment firm that only receives data from the wallet to onboard customers would register under that first value, and a firm should confirm the reading with the registrar in its Member State. The other values describe providers of person identification data and of attestations, and certain trust service providers.

Registration certificates are now part of the design and not an option. Article 8(1) of 2025/848 used to say that Member States may authorise at least one certificate authority to issue wallet-relying party registration certificates. As replaced by the amending regulation, it says that Member States shall authorise at least one certificate authority to issue wallet relying party registration certificates, and that they shall ensure that the providers issue those certificates in an automated manner and without undue delay after the registration. Recital (3) of the amending regulation gives the purpose: to enable the wallet unit to validate that the data requested by a wallet-relying party are within the scope of the registered intended use. Under Article 8(2), as replaced, Member States shall do the following.

  • Require providers of registration certificates to issue them exclusively to registered wallet-relying parties.
  • Ensure that each intended use is expressed in the registration certificates.
  • Ensure that the certificates include a general access policy, harmonised across the Union, informing users that the relying party is only allowed to request the data specified in the certificates for the intended use registered in them.
  • Ensure that providers of wallet solutions established in the Member State comply with the general access policy by informing users when a relying party requests data that is not specified in the registration certificates.
  • Ensure that wallet-relying parties provide a URL to the privacy policy regarding the intended use.

The wallet side of that check has its own date: wallet units must authenticate and validate the registration certificate from 11 August 2028, as the previous section explained. Until that date the wallet-side validation duty does not yet apply, while the duties of the Member State follow the application date of the registration regulation.

Two further mechanisms show how a request is checked. Providers of access certificates issue them exclusively to registered relying parties, and wallets use these certificates to authenticate the relying party. A registrar can suspend or cancel a registration, among other grounds where the relying party is requesting more attributes than it registered, and it must inform the relying party and the certificate providers no later than 24 hours after the suspension or cancellation. Registrars keep records of the registration information for 10 years.

The consequence for design is that the intended use and the data requested under it are fixed when the firm registers, and they are visible to the customer. The registration separates the two: an intended use has a description of its purpose, and beneath it sits the list of the data that the use requires. A firm that onboards customers with the wallet would describe onboarding as one intended use, state its purpose, and list under it the attributes it needs, for example the address, the portrait and the nationality, before it asks. A different service that needs different data is a separate intended use with its own list and its own description.

The dates

The dates in the texts depend on the entry into force of the implementing regulations, so the sequence is easier to follow in order.

  1. Regulation (EU) 2024/1183 was published on 30 April 2024 and entered into force on the twentieth day after publication.
  2. Five Commission implementing regulations were adopted on 28 November 2024 and published on 4 December 2024. They cover person identification data and attestations (2024/2977), the integrity and core functions of wallets (2024/2979), notifications to the Commission about the wallet ecosystem (2024/2980), the assessment of wallets against the requirements of the regulation (2024/2981) and protocols and interfaces (2024/2982). The Publications Office records for all five show 24 December 2024 as the date of entry into force.
  3. Four more implementing regulations were adopted on 6 May 2025 and published on 7 May 2025. They cover cross-border identity matching of natural persons (2025/846), reactions to security breaches of wallets (2025/847), the registration of wallet-relying parties (2025/848) and the submission of information to the Commission and the Cooperation Group for the list of wallets that passed assessment (2025/849).
  4. Two more implementing regulations were adopted on 15 July 2026 and published on 22 July 2026. Implementing Regulation 2026/1730 amends the registration regulation 2025/848. Implementing Regulation 2026/1731 amends 2024/2977, 2024/2979, 2024/2980 and 2024/2982. Each enters into force on the twentieth day following publication, which is 11 August 2026 by the count above. Two provisions apply later, both from 11 August 2028: the portrait as mandatory person identification data under Table 1 of the replaced Annex, except where the user explicitly opts out, and the validation of registration certificates by wallet units under Article 3, point (4), of Implementing Regulation 2024/2982.
  5. Each Member State shall provide at least one wallet within 24 months of the date of entry into force of the implementing acts referred to in Article 5a(23) and Article 5c(6). Counted from 24 December 2024, that gives 24 December 2026, and this date is a count made for this article from the texts, not a date written in them. This article uses the first set of acts for that count and does not decide whether the later amendments move it. The Commission's page describes the same timetable as wallets provided to citizens by the end of 2026.
  6. Under Article 5f(2), private relying parties that are required by Union or national law to use strong user authentication for online identification, or that must do so by contractual obligation, shall accept wallets no later than 36 months from the same entry into force, and only upon the voluntary request of the user. The areas named include banking and financial services, and microenterprises and small enterprises are excepted. Counted from 24 December 2024, that is 24 December 2027, again a count made for this article.

Three limits on that last duty are worth stating plainly. It applies to the firms and situations the text describes, namely a legal or contractual requirement of strong user authentication for online identification. It applies only when the user asks to use the wallet. Whether a particular onboarding flow falls within it depends on the law that applies to the firm, and this article does not decide that question. For public sector bodies the text is separate: where Member States require electronic identification and authentication for an online service of a public sector body, they shall also accept wallets. Providers of very large online platforms must also accept and facilitate wallets for user authentication, on the voluntary request of the user and limited to the minimum data necessary.

The wallet specifications are kept in a technical document called the Architecture and Reference Framework, which the implementing regulations rely on. The framework is published online, and its home page showed release 3.0.0 of 21 July 2026 at the time of fetching. The source repository of the framework, which is hosted on a public code platform, describes the framework as the common technical specification for the wallet and its ecosystem. It says that the repository holds the main narrative text, annexes with the normative high-level requirements, and discussion topics open for public consultation. It also says that the latest authoritative version is the most recent tagged release, so a firm that cites the framework should cite a release and not the current state of the repository. Recital (1) of each amending regulation says that the architecture and reference framework has evolved significantly since the original regulations were adopted, and that the original regulations should therefore be amended to align them with the new standards, specifications and procedures. Because the implementing regulations rely on the framework and have already been amended once to follow it, the dates and details here should be checked again at the time of a design decision.

The wallet and customer due diligence

The AML Regulation, Regulation (EU) 2024/1624, applies from 10 July 2027, with a later date of 10 July 2029 for two categories of obliged entities. The wallet and the AML Regulation were written separately, and the connection between them is made by the words "electronic identification means".

Article 22(6) of the AML Regulation says obliged entities obtain the information needed to verify identity either through an identity document, passport or equivalent, or through "the use of electronic identification means which meet the requirements of Regulation (EU) No 910/2014 with regard to the assurance levels ‘substantial’ or ‘high’ and relevant qualified trust services as set out in that Regulation". Recital (66) says that the electronic identification as set out in that regulation should be taken into account and accepted by obliged entities for the customer identification process. It also says that the use of such means can reduce the risk level, where appropriate risk mitigation measures are in place, to standard or even low.

Reading the two texts together gives this chain. The wallet is an electronic identification means under the amended eIDAS definitions. It must be provided under a scheme with assurance level high. Assurance level high is one of the two levels that Article 22(6), point (b), names. A wallet presentation can therefore be a verification route under that point, within the limits the technical standards set. That is a reading of the two texts for this article and not a ruling by a supervisor, and a firm should confirm it with its own supervisor.

The Commission's page adds the political expectation: service providers legally obliged to identify their customers unequivocally will be obliged to accept the wallet for authentication. Note how this differs from the text of Article 5f. The regulation speaks of strong user authentication and of the user's voluntary request. A firm should work from the article and not from the summary.

The technical standards that decide the details

Article 28 of the AML Regulation asked the Anti-Money Laundering Authority to develop draft technical standards by 10 July 2026, among them the list of attributes that electronic identification means and relevant qualified trust services must feature to meet the identification and verification duties. On 1 October 2026 the Authority announced that it had finalised three sets of standards, including one on customer due diligence that covers non-face-to-face verification and electronic identification. It said that the final drafts had been submitted to the Commission and that, once adopted and published in the Official Journal, they are proposed to apply six months after their entry into force. The Authority's factsheet on the customer due diligence standard says that its Annex I sets out the minimum attributes that electronic identification means and qualified trust services should be capable of providing. It adds that this does not mean obliged entities must identify or verify every attribute in each case, because some data points apply only to specific customer types or only where available. The factsheet also says the standards remain subject to review and potential amendment by the Commission and become definitive only on publication in the Official Journal.

This article does not report the content of Annex I, because the primary text of the final report could not be read by the tools used for this article. The factsheet is a summary, and the standards take precedence over it. A firm that plans around the wallet should read Annex I of the final report as soon as the Commission has adopted it and compare it with the attributes in the Annex to Implementing Regulation 2024/2977 as replaced by 2026/1731, because the gap between the two sets decides how much a firm must add from other sources.

Records

Article 77 of the AML Regulation requires obliged entities to retain a copy of the documents and information obtained in customer due diligence, "including information obtained through electronic identification means", and says the retention period is 5 years from the end of the business relationship or the occasional transaction. The wallet's rules on erasure and the firm's retention duty meet here. The regulation on the wallet lets the user ask for erasure under the General Data Protection Regulation, and the AML Regulation obliges the firm to keep the evidence it used. The firm needs a written position on which data is kept, for how long, and what it answers when the wallet sends an erasure request for data it must retain.

What a firm can decide now

Whatever the final shape of the standards, several design decisions do not depend on them.

  1. Decide the intended uses. Identify which services will receive wallet data, and register each as an intended use with a description of its purpose and, beneath it, the list of attributes it needs.
  2. Keep a non-wallet route. Article 5a(15) says it shall remain possible to access public and private services by other existing identification and authentication means, and it does not say which means. Keeping the document-based verification route is the design this article recommends for meeting that, and it is a recommendation and not a duty the text places on the firm in those words.
  3. Plan for the address field. Design a second source for fields the wallet may not carry, and make the flow say to the customer why the extra step exists.
  4. Decide on the portrait. If the flow requests the portrait, expect a warning and an explicit confirmation in the wallet, plan for a user who has opted out, and set a retention rule that matches the limits on keeping and transferring it.
  5. Support the formats the Annex fixes. A verifier must be able to read person identification data in the SD-JWT VC format and in the mdoc format, and should watch for the W3C profile.
  6. Treat wallet data as evidence. Store the validation result, the registration reference used for the request and the time, along with the data the firm must retain.
  7. Plan for erasure requests. Write down how the firm answers an erasure request from a wallet when a retention duty applies.
  8. Watch the standards and the dates. Track the adoption of the technical standards, the national registration policies in each Member State where the firm operates, and the two provisions that apply from 11 August 2028.

Questions to ask your own team

  • In which Member States will we register, and who in the firm owns the registration and its updates?
  • Which data points do we request in each flow, and can we justify each in the intended-use description?
  • What do we do when a customer arrives without a wallet, or with one from a Member State whose scheme is not yet live?
  • Which supervisor confirms that a wallet presentation counts as verification under our national law before the AML Regulation applies?
  • How will we test our verifier against both data formats, against a user who has declined the portrait, and against revoked data?

How this sits next to document verification

A flow built on NeuroVision KYC places the identity steps in one session: document, selfie, liveness and face match, with the scenario assembled in an editor. The individual steps are described on the document verification page. This article does not state that NeuroVision accepts the European Digital Identity Wallet. It states why a document-based route is a sensible companion to the wallet: use of the wallet is voluntary, and the text says it must remain possible to access services by other existing means.

To see how these steps look in your own scenario, contact the team.

Sources

All sources were fetched on 27 October 2026 or on 28 October 2026.

Ready to talk?

Tell us what you are building and we will help you plan the integration.

Talk to us