EU Digital Identity Wallet

The wallet is an application under the control of the user that holds person identification data and electronic attestations of attributes, and presents selected parts of them to a party that asks. The user decides per request which attributes leave the wallet, so an age check can be answered without disclosing a date of birth and a residence check without a full address.

Each member state has to make at least one wallet available to its citizens and residents by the end of 2026. The obligation sits on the state, and a state can issue the wallet itself or have it issued by a party it certifies, which is why the German wallet comes out of the federal digital identity program and not from a bank. For an institution the practical consequence is that the wallet arrives as a given, with a specification to integrate against.

The Architecture and Reference Framework is the technical specification of the ecosystem: the roles of issuer, wallet and relying party, the credential formats, the protocols for issuance and presentation, the trust lists and the way a relying party registers itself. Integration teams use this document to implement the specified data formats and flows.

Alongside it, the Commission ran Large Scale Pilots in which member states, banks, payment providers and public bodies tested the wallet against real use cases, payments and account opening among them. The findings from the pilots shaped what the reference framework now requires of a relying party, so a bank starting now works with decisions developed in those consortia.

A relying party is anyone who asks the wallet for attributes, which is what a bank becomes the moment it reads one. For most private parties acceptance is voluntary, but the regulation names sectors where it is mandatory, and the sectors subject to strong customer authentication requirements under EU law are among them. That brings banks, financial service providers and payment institutions into the mandatory group, with acceptance required from the end of 2027, a year after the wallets themselves have to exist.

The party is legally required to register in its member state, declare which attributes it intends to request and for which purpose, and request only those attributes. A bank therefore writes its attribute list before it writes its integration, and that list has to match what its own KYC rules require, no more. The eIDAS 2 rules for finance govern the wallet and associated trust services.

Two kinds of content reach a bank from a wallet and they carry different weight. Person identification data is the core identity set issued under the member state's electronic identification scheme, and it is what a bank uses to establish who the customer is. An electronic attestation of attributes is a separate verifiable claim about a characteristic, such as a professional qualification, a company role, proof of address or being above an age.

A qualified electronic attestation of attributes is issued by a qualified trust service provider, and one issued in any member state has to be recognized as qualified in all the others, which is the change that makes cross-border onboarding workable. A plain attestation issued by an authorized body is usable too, but its acceptance is a matter for the receiving bank's own risk assessment and not for mutual recognition.

The EUDI Wallet replaces the identification step: establishing and verifying who the person is, which today runs through a video call, a bank transfer reference or a document scan with liveness detection. That step is the most expensive part of onboarding and the one where applicants drop out, so removing it is where the business case sits. This identification step must meet the requirements of KYC in Germany.

Beneficial ownership for a corporate customer, the purpose and intended nature of the business relationship, source of funds and source of wealth, politically exposed person screening, sanctions screening and ongoing monitoring are all separate duties that no identity attribute answers. Distinguishing KYC and AML helps define these duties, while checking the source of funds remains manual.

Strong customer authentication requires two independent elements from knowledge, possession and inherence, and a wallet on a phone with a device-bound key and a biometric unlock plausibly delivers possession and inherence in one gesture. That is why the wallet appears in payments discussions at all, and why the pilots tested it there.

Whether a wallet presentation counts as SCA for a given payment depends on how the authentication elements are assessed and on what the payment service provider remains answerable for when the wallet, and not the provider, holds the authentication means. The implementing acts and the supervisory practice settle that, and until they do a bank treats wallet-based payment authentication as a design option under review. PSD3 and payments regulation in Germany cover the framework it has to fit.

A wallet presentation is a signed document, and a bank has to decide whether the signature belongs to an issuer it should believe. That decision runs through trust lists: registers, published per member state and aggregated at EU level, naming the authorized issuers of person identification data and of qualified attestations, with their certificates. A bank's verification stack queries those lists, which means it has an operational dependency on them being reachable and current.

The relying party has to register itself in its own member state, connect to the trust infrastructure, and handle the case where a list is temporarily unavailable without either rejecting a valid customer or accepting an unverified credential. The bank therefore needs to maintain access to current trust lists during operation.

Not every wallet credential carries the same weight, and the bank decides which level it requires for which action. The electronic identification levels of assurance, low, substantial and high, describe how rigorously the identity was established in the first place, and a wallet issued under a notified scheme at high assurance is the one a bank can place against its own identification duty.

Opening an account, raising a transaction limit, changing a payout bank account and confirming a sensitive instruction each have a different risk, so each gets its own required assurance level and its own fallback. A bank's AML and customer due diligence policies have to state that mapping before an integration can be signed off, which is why this work starts in compliance and not in engineering. These duties form part of the requirements for AML in Germany.

The wallet lets the customer answer a question without handing over the underlying data: that the holder is over 18, without the date of birth; that the holder resides in a country, without the street address. For a bank that is a data minimization gain it gets for free, because the request determines what arrives.

Asking is now cheap, so the temptation is to request attributes the bank has no need for, which is exactly what the relying party registration is meant to constrain: the declared purpose binds the request. The second risk is consent fatigue, the cookie-banner outcome, where a customer who approves every request has stopped reading them. A bank designing the flow should ask for the minimum its policy requires and should expect a supervisor to compare its requests against its registration.

When a customer sets up a direct debit or enters a payout account, a wallet attestation can confirm that the person presenting the IBAN actually holds that account, which removes a class of misdirected payment and a class of fraud where an attacker substitutes their own account details.

This complements verification of payee requirements for credit transfers, including instant payments in Europe. An attestation of account ownership held in a wallet is one way to satisfy a check of that kind at the point the mandate is created, instead of at the point the money moves.

The bank is required to retain its existing identification route for customers without wallets. Wallet uptake will be uneven across member states and across age groups for years, and a bank that routes onboarding exclusively through a wallet excludes customers who are entitled to open an account by other means.

The design consequence is that a bank runs two paths and has to keep both working, with the same customer due diligence outcome at the end of each. The wallet path is the cheaper one and will carry the growing share, and the fallback path has to be maintained and not left to decay, because it is what serves the customer the wallet does not reach.

Member states have to make a wallet available by the end of 2026, and private relying parties in the mandated sectors, banks and payment institutions among them, have to be able to accept it from the end of 2027. The gap between the two dates is the integration window, and the bank needs this time because it also has to register as a relying party, define its attribute set and adapt its onboarding process around a flow that no longer produces a document image.

Partly, and the useful part is the attestation and not the identity. A natural person acting for a company identifies through the wallet as themselves, and an attestation of attributes can carry their authority to represent that company, which removes a document step from a corporate onboarding. The company's own ownership structure is a separate question that the wallet does not answer, so beneficial ownership work continues through registers and documents as before.