The EU Digital Identity Wallet and a bank's onboarding

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. An integration team reads this document and not the regulation, because it holds the data formats and the 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 pilots matter to a bank for one reason: their findings shaped what the reference framework now requires of a relying party, so a bank starting now inherits decisions that were argued out 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.

Being a relying party carries its own obligations. The party has to register in its member state, declare which attributes it intends to request and for which purpose, and ask only for those, which is enforceable and not a guideline. 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 and finance page covers the regulation and the trust services around it.

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.

The qualified version is the one that travels. 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.

It 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. The German identification requirements for this step are covered on the KYC in Germany page.

Everything else in the chain stays. 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. A bank that budgets for the wallet as an end to its KYC work has misread the scope; the KYC against AML hub answer separates the two, and source of funds covers the part that stays 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.

The open part is legal and not technical. 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.

That is an integration task with no business logic in it and it is where projects lose time. 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. A bank that treats the trust list as a configuration file, and not as a live dependency, will find that out in production.

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.

The work is in the mapping, and it is a compliance exercise and not a technical one. 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. The AML in Germany page covers the duties being mapped.

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.

The risk runs the other way. 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.

One payments use case is narrower than identity and solves a real loss. 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 matters next to the verification of payee requirements now in force for credit transfers in Europe, which the instant payments in Europe page covers. 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 keeps its existing identification route, and that is a requirement and not a transitional convenience. 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 it is shorter than it looks because the bank 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.