TRUSTTECH / BLOG

How can banks use EUDI Wallet verification to streamline customer re-identification?

Bank customer presenting a digital credential on a smartphone at a minimalist navy-toned bank counter, officer reviewing a tablet in soft background blur.

Banks can use EUDI Wallet verification to streamline customer re-identification by requesting verified identity attributes directly from a customer’s wallet, replacing manual document checks and outdated credential processes with a single, cryptographically verifiable exchange. Because the wallet operates at assurance level high, the verified data meets the bar that most existing re-identification methods do not reach on their own. The sections below walk through the regulatory context, the verification mechanics, the data involved, and what banks need to get started.

What regulatory requirements make customer re-identification necessary for banks?

Banks are required to periodically re-verify the identity of existing customers under anti-money laundering rules. The EU’s Anti-Money Laundering Regulation (AMLR), which applies from July 2027, requires financial institutions to keep customer due diligence records current and to re-identify customers when circumstances change or at defined intervals. This is separate from the initial Know Your Customer check performed at onboarding.

Re-identification is triggered in several situations:

  • A customer’s identity document has expired and the bank holds outdated data
  • A risk review flags the account for enhanced due diligence
  • A customer requests a new product or service that requires a fresh identity check
  • Regulatory audits reveal gaps in the existing customer file

The AMLR determines whether a bank may rely on an identity check performed elsewhere. The EUDI Wallet provides the mechanism for delivering verified identity data, but whether that data satisfies a specific AML obligation depends on the AMLR and applicable sector rules, not on eIDAS 2.0 itself. Banks should assess both frameworks together when designing their re-identification process.

Under article 5f of eIDAS 2.0, banks and other financial service providers fall within the regulated private sector that must accept certified EUDI Wallets where strong user authentication is legally or contractually required. The deadline for that acceptance obligation is 24 December 2027. Before a bank can request wallet data, it must register as a relying party under CIR (EU) 2025/848 with the national authority in its member state of establishment.

How does EUDI Wallet verification actually work in a banking context?

EUDI Wallet verification works through a structured presentation flow: the bank sends a request for specific identity attributes, the customer reviews and approves the request in their wallet app, and the wallet returns a cryptographically signed response containing only the requested data. The bank then runs three verification checks before accepting the result.

Those three checks are:

  1. Issuer signature: the bank verifies the attestation’s digital signature against the national trusted list of the member state that issued it, using the EU List of Trusted Lists (LOTL) as the overarching reference. ARF v3.0.0 also introduces Lists of Trusted Entities (LoTE, ETSI TS 119 602) alongside the trusted lists.
  2. Revocation status: the bank checks whether the attestation has been revoked. The issuer publishes separate status information for this purpose. Skipping this step means the bank may accept an attestation that is no longer valid.
  3. Wallet unit attestation: the bank confirms that the presenting wallet is running on a certified wallet solution. This check is what distinguishes a genuine EUDI Wallet from a spoofed presentation.

Only the first check works fully offline. The other two require the bank’s verification system to reach out to the issuer’s status endpoint and the wallet’s attestation service at the time of the request. Banks building re-identification flows need to account for this in their technical architecture.

The customer’s approval in the wallet is a per-request action, not a standing consent. It is also distinct from consent as a legal basis under article 6(1)(a) GDPR. For KYC re-identification, the bank’s legal basis is typically a statutory obligation, and the wallet approval is the mechanism through which the customer releases the data, not the GDPR ground for processing it.

What customer data can banks verify through the EUDI Wallet?

Through the EUDI Wallet, banks can verify the attributes contained in a customer’s Person Identification Data (PID) and any Electronic Attestations of Attributes (EAA) the customer holds. The PID typically includes name, date of birth, place of birth, current address, and a national identifier, depending on what the issuing member state includes.

Beyond the PID, customers may carry additional attestations relevant to banking:

  • Address attestations issued by a public authority
  • Tax identification numbers
  • Professional qualifications or licences, where relevant to the product
  • Document references such as a passport or national identity card number

Selective disclosure is a core feature of the wallet. A bank requesting re-identification can ask for only the attributes it needs for a specific purpose, and the wallet presents only those. The bank’s registered attribute scope, declared at registration under CIR (EU) 2025/848, defines the ceiling. Requesting more attributes than registered is an explicit ground for revocation of the registration. This makes the registration scope a practical compliance boundary, not just an administrative formality.

One important point for customer file management: never link a customer record to a wallet unit identifier. If a customer switches devices, their attestations are re-issued by the original issuer rather than copied. The same person will return with a different wallet unit and freshly issued attestations. Stable identity attributes from the PID are the right anchor for a customer file.

How does EUDI Wallet re-identification compare to traditional re-identification methods?

EUDI Wallet re-identification delivers verified identity data at assurance level high, which most traditional re-identification methods do not reach without additional steps. A customer presenting a scanned document by email, or confirming details over the phone, provides data that the bank cannot independently verify as current or untampered. The wallet replaces that uncertainty with a cryptographically signed attestation from a state-authorised issuer.

Traditional methods carry several structural weaknesses that wallet-based verification addresses:

  • Document expiry gaps: banks often hold copies of documents that have since expired. The wallet presents the current, issuer-signed version.
  • Manual data entry errors: re-keying data from a document scan introduces errors. Wallet data arrives in a structured, machine-readable format.
  • Friction for the customer: posting documents or visiting a branch creates drop-off. A wallet presentation takes seconds on a mobile device.
  • No issuer verification: a bank checking a document copy cannot confirm in real time that the document has not been revoked. Wallet verification includes a revocation check.

The wallet also supports cross-border re-identification in a way that traditional methods struggle with. A customer who moved from one member state to another and holds a wallet issued by their new country of residence can present that wallet to their bank in any member state. The bank verifies the signature against the relevant national trusted list via the LOTL, without needing a bilateral agreement with that country’s identity system.

The practical limit worth naming: the wallet delivers the identity data. Whether that data satisfies a specific AML re-identification obligation, and whether the bank may rely on a check performed by a third party, is determined by the AMLR and sector rules, not by the wallet itself.

What do banks need to implement EUDI Wallet verification?

To implement EUDI Wallet verification for customer re-identification, a bank needs three things: a completed relying party registration, a technical integration that supports the required credential formats and protocols, and an internal process that handles the verified data correctly once received.

Registration and access certificates

Before requesting any wallet data, the bank must register as a relying party under CIR (EU) 2025/848 with the national authority in its member state of establishment. At registration, the bank declares the exact attributes and attestations it intends to request, per intended use. The national authority issues access certificates that the wallet checks at every data request. Without a valid access certificate, the wallet will not release data.

Technical integration requirements

The wallet uses two credential formats: mdoc (ISO/IEC 18013-5 for proximity, ISO/IEC TS 18013-7 for online) and SD-JWT VC. The exchange protocols are OID4VP for presentation and OID4VCI for issuance. The bank’s verification system must support both formats and implement all three verification checks: issuer signature against the trusted lists, revocation status, and wallet unit attestation. The High Assurance Interoperability Profile (HAIP) profiles both protocols for high-assurance use and is the relevant reference for banks operating at assurance level high.

The bank must also ensure its logging practices respect selective disclosure. Recording only that the bank stayed within its registered attribute scope is sufficient. Logging the full set of presented attributes would undo the privacy protection that selective disclosure provides at the front end.

EUDI WALLET INTEGRATION

Every wallet. One connection.

Simplify verification across European markets without building a separate integration for each wallet.

Talk to TrustTech →

When will EUDI Wallet be ready for banks to use in production?

Banks can begin preparing their technical and compliance infrastructure now. The first production deadline is 24 December 2026, when every member state must issue at least one certified EUDI Wallet to citizens, residents, and businesses, and public service providers must accept notified wallets. This creates the initial live population of wallet holders that banks will interact with.

The private sector acceptance obligation for banks falls on 24 December 2027, twelve months later. From that date, banks and other regulated financial service providers must accept certified EUDI Wallets wherever strong user authentication is legally or contractually required. Micro and small enterprises (fewer than 50 employees and an annual turnover or balance sheet total of no more than 10 million euros) are exempt from this obligation.

The registration process under CIR (EU) 2025/848 is already open. Banks that register early can run internal pilots, test their verification flows against available wallet implementations, and refine their attribute scope declarations before the acceptance deadline arrives. The new AML Regulation applies from July 2027, five months before the private acceptance deadline, which means the compliance pressure from two directions converges in the second half of 2027.

Implementation readiness varies by member state. Some are running national wallets in production and marking them as EUDI-conformant. Others have limited beta programmes. A third group has not yet published a rollout plan. Banks with customers across multiple member states should monitor national wallet status per country, as the picture changes each quarter.

How the ID Connector helps banks with EUDI Wallet re-identification

The ID Connector is an integration that lets relying parties accept every certified European wallet, whatever member state issued it, for identification, login and qualified signing. EUDI Wallet acceptance comes first; the same interface also carries other IDs, such as national eIDs, bank IDs and identity documents, inside and outside the EU.

For bank customer re-identification specifically, the ID Connector handles the technical layer that sits between the bank’s systems and the wallet ecosystem:

  • Signature validation against the national trusted lists and the LOTL, including the Lists of Trusted Entities introduced in ARF v3.0.0
  • Revocation status checks at the time of each presentation
  • Wallet unit attestation verification, confirming the presenting wallet runs on a certified wallet solution
  • Enforcement of the bank’s registered attribute scope, so requests stay within the boundaries declared under CIR (EU) 2025/848
  • Reuse of verified identity data across interactions, so a customer who has already presented their wallet does not need to repeat the full flow for every re-identification event

The ID Connector is used by organisations in financial services, government, healthcare, and pharmaceuticals. Contact TrustTech to discuss how the ID Connector fits your bank’s re-identification process.