The EUDI Wallet is becoming mandatory infrastructure. By the end of 2026, every EU member state must provide a state-issued wallet. From 24 December 2027 onwards, banks, payment institutions and e-money providers will have to accept the wallet as a means of identification and authentication (Article 5f of eIDAS 2.0). A recent Bitkom survey shows that 70 percent of the population do not know the project or know little about it. In many delivery teams, the wallet has yet to appear on the roadmap either. This whitepaper compiles the current state of play, frames the acceptance obligation, and outlines a pragmatic programme approach for the time that remains.
Introduction
In the roadmaps of many banks and payment service providers in the DACH region, the EUDI Wallet rarely surfaces as a topic of its own. Where it does surface, it is almost always reduced to the single onboarding scenario. However, the acceptance obligation under Article 5f reaches across the entire institution, not only the digital direct channel. It cuts into every identification and authentication flow from the counter to the back office, and it arrives together with AMLR and PSD3/PSR within a narrow window.
On 24 December 2027, banks, payment institutions and e-money providers in the EU must accept a digital wallet as a means of identification and authentication that is currently unknown or barely known to seven out of ten people in Germany. The regulatory foundation is unambiguous. Regulation (EU) 2024/1183 entered into force on 20 May 2024 and obliges every member state to provide at least one state-issued or state-recognised EUDI Wallet by the end of 2026. From 24 December 2027 onwards, private relying parties in regulated sectors will be required to accept the wallet at the user’s request. Banks, payment institutions and e-money providers are listed by name in Article 5f of the regulation.
In parallel, the new EU Anti-Money Laundering Regulation (AMLR) becomes applicable in July 2027, and the ongoing PSD3 and PSR process introduces a further regulatory layer. Both directly affect identification and strong customer authentication. The three pieces of legislation cover the same processes, interlock technically, and reach financial service providers within a narrow time window.
This leaves, from today’s perspective, around 18 net months to integrate the EUDI Wallet into existing identification, authentication and onboarding flows. This whitepaper positions the wallet in the DACH context, describes the acceptance obligation and its interfaces with AMLR and PSD3, and sets out three recommendations for the time that remains. It deliberately sets emphases that are underweighted in the typical EUDI discussion: the less obvious use case flows, the federated structures specific to DACH, and the three business bets beyond the obligation that carry the actual upside.
The EUDI Wallet becomes mandatory infrastructure from 2027
Three functions in one app: identity, signature, credentials
The European Digital Identity Wallet (EUDI Wallet) is a mobile application provided or mandated by the respective member state. It brings together three functional areas that have so far been handled in separate systems: an officially issued Person Identification Data element (PID) at eIDAS assurance level “high”; qualified electronic signatures and seals with EU-wide legal effect; and verified credentials (Electronic Attestations of Attributes, EAA) such as driving licence, insurance certificate or proof of account holdership. From the user’s perspective, the wallet remains voluntary. Anyone who does not wish to use it retains access to all services via existing identification procedures.
Financial service providers act as relying party
For financial service providers, the role of Wallet Relying Party (RP) is central. They act as RP in virtually every user-driven scenario that requires identification or strong authentication. This requires registration in a national register as a Wallet Relying Party, including a transparent declaration of intended uses; once registered, the institution holds access and registration certificates that the wallet verifies cryptographically on each request. Personal data remains on the user’s smartphone; profiling by public bodies is technically excluded under the Architecture and Reference Framework. Banks can additionally become issuers themselves, for example for proof of account holdership or creditworthiness attestations. The recommendations at the end of this whitepaper come back to that role, because it reaches beyond the duty itself.
DACH moves on three parallel tracks
Germany has opted for a state-orchestrated solution. The Federal Agency for Disruptive Innovation (SPRIND) is building the state-issued wallet on behalf of the Federal Ministry for Digital and State Modernisation (BMDS), with availability planned from 2 January 2027. The national legal framework is being put in place through the Digital Identities Act (DIdG), whose draft was opened for consultation with federal states and associations on 26 March 2026. SPRIND has been operating a publicly accessible sandbox since early 2026, in which organisations can test identification and EAA processes. Bitkom, the BMDS and more than 100 companies signed a Memorandum of Understanding in early 2026 to support the successful introduction of the wallet. Signatories include Deutsche Bank, Mastercard, N26, SAP, IDnow and Bundesdruckerei.
Austria has, with ID Austria and the eAusweise app, an infrastructure that already largely meets EUDI requirements. The Austrian Federal Ministry of Finance stated publicly in 2024 that Austria is ready to launch the EUDI Wallet and that ID Austria already covers the majority of EUDIW functions. A full convergence on the EUDIW specifications is under way. A final date for the EUDI-compliant wallet had not been publicly announced as of spring 2026.
Switzerland, as a non-EU member, is not directly bound by eIDAS 2.0 but is pursuing a conceptually compatible path. The Federal Act on Electronic Identity (BGEID) was approved by a narrow majority of 50.39 percent in a referendum on 28 September 2025. The Swiss wallet, swiyu, has been in public testing since April 2025. The regular rollout starts in summer 2026, and the e-ID can be ordered free of charge via swiyu from December 2026. Full technical interoperability between swiyu and the EUDI Wallet did not exist as of spring 2026, but is conceptually anticipated. For DACH-based PSPs with Swiss business, this means swiyu has to be planned for as a separate track alongside the EUDI Wallet for the foreseeable future.
The regulatory roadmap is heading towards December 24, 2027
Regulation (EU) 2024/1183 entered into force on 20 May 2024 and sets the European framework for the provision and acceptance of the wallet. On 28 November 2024, the European Commission adopted five central implementing acts, which entered into force on 24 December 2024 following publication in the Official Journal. This has officially started the clock on three binding deadlines. Figure 1 shows the milestones at a glance.
The first deadline concerns provision. No later than 24 months after the implementing acts enter into force, i.e. by the end of 2026, each member state must make at least one certified EUDI Wallet available. Germany is meeting this deadline with the wallet launch on 2 January 2027, and other member states are following similar timelines.
The second deadline concerns the public sector. From 1 January 2027, the acceptance obligation under Article 5f(1) takes effect. As soon as the wallets are available in the member states, public authorities and bodies must accept the EUDI Wallet wherever they currently require an electronic identification with strong authentication. This is not directly binding for financial service providers, but it creates the market dynamic: with public sector acceptance becoming mandatory about eleven months ahead of the private sector obligation, the wallet becomes a visible reality and shapes user expectations towards financial service providers.
The third deadline concerns the private sector. No later than 36 months after the implementing acts enter into force, i.e. by 24 December 2027, private relying parties in the regulated sectors must accept the wallet at the user’s request (Art. 5f(2)). Which actors are covered in detail, what consequences follow, and where the obligation will have the strongest technical impact is the subject of the next chapter.
The acceptance obligation reaches from onboarding into the back office
Article 5f allows few exemptions
The EUDI acceptance obligation reaches practically every financial service provider in the DACH region; only micro and small enterprises with fewer than 50 employees fall outside its scope.
Article 5f of the eIDAS 2.0 Regulation contains two acceptance obligations. Paragraph 1 obliges the public sector from 1 January 2027: public authorities and bodies must accept the EUDI Wallet wherever they currently require an electronic identification with strong authentication. The key provision for financial service providers is paragraph 2.
The key provision for the private sector acceptance obligation is Article 5f(2). It covers private Wallet Relying Parties that provide services where strong user authentication for online identification is required under EU or national law, or under contractual obligation. The regulation names the sectors in scope explicitly. They include banking and financial services, transport, energy, telecommunications, healthcare, digital infrastructure and other critical sectors.
For financial service providers, this means in concrete terms that practically every universal bank, direct bank, savings bank, cooperative bank, payment institution licensed under national payment services supervision law and e-money provider operating in the DACH region is covered. The only exemption applies to micro and small enterprises with fewer than 50 employees and annual turnover or balance sheet total of no more than EUR 10 million. For most actors in the DACH market, this exemption does not apply.
The obligation only takes effect when the user actively uses the wallet. Financial service providers do not need to promote the wallet in their own front end or present it as a default identification option. Once a customer presents the wallet, however, they have a right to acceptance by the regulated institution in question. The freedom of choice of users is explicitly protected under the regulation. Sanctions will be defined at national level. The German draft Digital Identities Act provides for corresponding powers of the national supervisor; in Austria the responsibility lies with the FMA; in Switzerland the autonomous BGEID regime applies. Structurally, the EU approach aligns with other digital regulations such as GDPR, with effective, proportionate and dissuasive penalties.
AMLR, PSD3 and eIDAS interlock
Three regulations act on identification and authentication in the same window; a cleanly built wallet stack addresses all three in a single flow.
The EUDI Wallet does not stand alone in regulatory terms. It coincides with two further major pieces of legislation that take effect in the same period. The new EU Anti-Money Laundering Regulation (AMLR) becomes applicable in July 2027 and requires EU-compliant identification methods as part of customer due diligence. eIDs, EUDI Wallets and qualified trust services are explicitly named as suitable instruments. For banks, this means the wallet becomes the Europe-wide harmonised KYC instrument and that existing national identification procedures such as PostIdent or VideoIdent in Germany can continue to exist but will lose importance over time.
In parallel, the Payment Services Regulation (PSR) and the third Payment Services Directive (PSD3) extend the requirements for strong customer authentication. The two-factor principle remains in place, but the scope of application and the technical requirements are being expanded. In this context, the wallet becomes the Europe-wide standardised third pillar of strong customer authentication, alongside SMS-OTP and app-based methods. Market players such as Signicat, Lissi and walt.id already describe it as a plausible default approach for SCA in the coming years.
An isolated calculation of the implementation effort for AMLR, PSR and eIDAS 2.0 therefore underestimates the picture. A qualified wallet credential satisfies KYC obligations under AMLR, can trigger SCA under PSR, and at the same time qualifies as a means of identification under eIDAS 2.0. A cleanly designed wallet stack thus addresses three regulations in a single flow.
Alongside the regulatory convergence, a second convergence is at work that is often underestimated organisationally. Identification, authentication, credentialing and payment processing have been organised in banks as separate disciplines for years, with dedicated product owners, compliance teams and tech stacks. With the EUDI Wallet, these four domains merge into a single interaction loop. An identification provided by the wallet also delivers strong authentication, can immediately add a verified credential and can authorise a payment in the same step. This applies independently of regulation and challenges the historical separation between identity, authentication, credential and payment functions in many institutions.
Four use case clusters cover the full scope
Customer interaction falls into the digital direct channel, payment and transaction authorisation, branch and back office, and a fourth group of less obvious flows.
The acceptance obligation under Article 5f does not differentiate between individual use cases. It applies wherever strong customer authentication or AML-relevant identification is required. In a universal bank or a PSP, this in practice affects four use case clusters: the digital direct channel, authorisation of payments and transactions, branch, telephone service and back office, and a set of less obvious flows that rarely appear in today’s roadmaps. Figure 2 summarises the four clusters with concrete examples from day-to-day banking operations.
The sections below walk through the four clusters in the order shown in the figure and deliberately treat the fourth cluster at the end, because the largest commercial upside sits there and emerges sharpest after reading the first three.
- Direct channel: onboarding, login, re-identification
Cluster 1 covers the bank’s classic digital direct channel. At its centre sits customer onboarding. Today, PostIdent and VideoIdent dominate in Germany, ID Austria-based procedures dominate in Austria, and video-based procedures dominate in Switzerland. Going forward, onboarding becomes a matter of seconds, with the identity data required by anti-money laundering law (Section 12 GwG in Germany) flowing cryptographically signed from the wallet into the bank’s systems. Retention obligations under anti-money laundering law (usually five to ten years under MaRisk) remain in place but must be mapped to the new data types.Beyond pure new-customer onboarding, the obligation also covers every point at which existing customers are re-identified. This includes triggered KYC checks at higher risk profiles, repeated identifications under enhanced due diligence requirements, address changes and changes in the beneficial owner. Everyday login to online and mobile banking is also within scope, where it requires strong customer authentication. SMS-OTP, app TAN and push procedures remain admissible factors. The EUDI Wallet joins them as an equivalent method and is expected to become the preferred default option. The commercial impact for institutions is substantial, since identification and authentication events are the most frequent customer contact in a bank.
- Payment and transaction authorisation: card, transfer, brokerage
Cluster 2 covers the authorisation of specific transactions. This includes transfer approvals in online banking, direct debit mandates, securities orders in brokerage and, above all, online card payment. The EMV 3-D Secure protocol is currently the central mechanism for SCA in online commerce and therefore the point at which the wallet obligation under Article 5f hits the widest. EMVCo published a dedicated whitepaper on the integration of the EUDI Wallet with EMV 3DS in June 2025. Among other things, it introduces the new variant of “merchant-captured authentication”, in which the merchant integrates wallet-based authentication directly into the checkout and passes the outcome via the 3DS protocol to the issuer.
The technical complexity of this integration is underestimated in many institutions. The initiation of SCA in card payments typically does not happen directly through the bank, but via an Access Control Server, which is often operated outside the bank’s IT environment. The 3DS protocol itself is standardised by EMVCo, an international consortium without direct influence by individual banks. A wallet integration in the card payment flow therefore requires changes to the protocol, to the Access Control Server and to the customer journey on the merchant side. Combined with the volume of card payments, this becomes the most significant technical and organisational task of the entire wallet introduction.
Authorisation flows within online banking are affected as well. Today, transaction approvals run mostly via app-based push procedures or, for smaller banks, via SMS-TAN. In both cases, Article 5f requires an additional wallet flow that has to be compatible with the existing SCA infrastructure. For institutions with their own brokerage business, the same applies to the authorisation of securities orders.
- Branch, phone and back office: the quiet third of the duty
Cluster 3 is still invisible in the internal discussion in many banks. It concerns identification and authorisation flows outside the digital direct channels. Identity checks in the telephone customer service, at the counter or in a personal advisory appointment usually run today via a secret number, security questions or document presentation. With the EUDI Wallet, a uniform, regulatorily robust means of identification becomes available for these flows for the first time, the acceptance of which can be required under Article 5f.
In addition, there are back-office processes such as identification in credit processing, in securities settlement or in collections. These flows have grown historically, are often implemented in technically decoupled ways, and differ by multi-tenant capability, account holder structure and logging requirements. A wallet integration that only addresses onboarding and online banking login overlooks this part of the obligation.
- Four less obvious flows that carry the largest upside
Cluster 4 is the cluster that is least addressed in current roadmaps. In the programme plans of many banks and payment service providers, none of its four use cases currently appears, even though all four are fully covered by Article 5f and at the same time carry the largest upside. The effort that is overlooked here is not small: PISP integration via the XS2A API and QES integration into the contract flow are regulatorily mandatory and, at the same time, the points where the identity architecture of the institution shifts on a lasting basis.
The first flow concerns the EUDI Wallet as a Payment Initiation Service Provider. Wallet providers will be authorised as PISPs under PSD2 (and the future PSR) and can therefore initiate payments directly from the user’s bank account, without a classic banking app and without a card. In practice, the customer scans the merchant’s QR code in the online checkout with their EUDI Wallet, confirms identity and payment amount with biometrics, and triggers an account-to-account payment through the bank’s XS2A API. Wero is building a comparable flow in the DACH region; the EUDI Wallet variant is harmonised across Europe and uses the wallet as the identity anchor. The consequence for banks is that their access interface to the payment account, i.e. the existing XS2A API, will in future have to serve wallet providers as PISPs alongside classic third parties. Tink and the EUDI Wallet consortium already describe this variant as a regular payment flow. The wallet thus becomes, for the bank, both an accepted SCA factor and an initiator of transactions against the bank’s own account, which shifts the requirements for the open banking interface and for liquidity buffering.
The second flow is age verification in the online checkout. Its legal basis lies in Article 28 of the Digital Services Act, which mandates age-appropriate access controls for online platforms in parallel with the acceptance obligation under eIDAS 2.0. Very Large Online Platforms are required to accept the EUDI Wallet as a means of identification for age checks, and seven member states are already piloting a dedicated age verification app that will be integrated into the national wallets. For PSPs, this means that merchants with age-restricted product ranges (alcohol, tobacco, gambling, age-rated content) will expect wallet-based age proofs as a standard component in the checkout. The previously external flow via third-party providers will be replaced by wallet-based selective disclosure (“over 18 years of age”).
The third flow is the fully digital contract conclusion with a qualified electronic signature. Consumer credit agreements, guarantees, insurance applications and other contracts with statutory written-form requirements run in many institutions today via a separate identification and QES flow, typically VideoIdent plus a separate signing service. The EUDI Wallet bundles identification, KYC data and qualified signature in a single transaction, which forces banks, insurers and building societies to restructure their application and contract flows. In consumer credit business, this creates the opportunity for the first time to map the entire process from KYC to the legally binding signature without media breaks within the banking app.
The fourth flow is KYB onboarding through the European Business Wallet. Bitkom and the European Commission are discussing a dedicated wallet variant for corporate customers from 2026, in which commercial register extracts, representation rights and beneficial owners are held as verified credentials. Banks that today handle corporate onboarding through manual document checks or external KYB providers will receive a structured digital format that can flow into standard KYB processes and dramatically shortens processing times.
A complete use case inventory covering all four clusters is the first step of robust planning. Beyond the obligation, the EUDI Wallet also opens three strategic business opportunities: the bank’s issuer role for EAA credentials such as account holdership and creditworthiness, IBAN tokenisation at the checkout, and the digital employee credential against impersonation fraud. The following chapter develops these three opportunities as prioritised recommendations.
Recommendations for the next 18 months
From the previous sections, three concrete recommendations follow for financial service providers covering the remaining time until the acceptance obligation on 24 December 2027. For self-positioning, the following rough maturity staging provides a starting point:
| Stage | Criteria for an institution at this stage |
|---|---|
| Awareness | The EUDI Wallet is named as a regulatory topic, an accountable owner is assigned, an initial use case list exists. |
| PoC | At least one use case runs in the sandbox, an OID4VP verifier is connected to the existing IAM or CIAM, latency and error rates have been measured. |
| Pilot | At least one use case is running with real users, the Wallet Relying Party registration has been filed, end-to-end testing across at least two clusters is complete. |
| Production | At least three of the four clusters are in production, contingency, logging and retention flows have been signed off by compliance, and the wallet is anchored in the IAM target picture. |
As of spring 2026, most institutions in DACH sit between Awareness and an early PoC. For an orderly production rollout in 2027, the next stage needs to be addressed in the coming weeks.
1. Set up a cross-functional task force
In most institutions, the EUDI Wallet sits with IAM or information security in spring 2026. Compliance, anti-money laundering, payments and sales have no mandate of their own on the wallet, even though the four use case clusters cut across all four disciplines. This is precisely where the structural gap arises that the following step addresses.
The EUDI Wallet affects compliance, anti-money laundering prevention, payments, sales and customer service equally and therefore requires cross-functional governance. Setting up a central task force with representatives from IT, the relevant business units, compliance, anti-money laundering prevention, payments and sales is recommended. A fragmented implementation creates inconsistencies, rework and gaps in use case coverage.
The first task of the task force is a complete functional inventory of all authentication and identification use cases in the institution, as illustrated by the four use case clusters in the previous chapter. On this basis, dependencies, synergies and priorities can be identified. The actual implementation can then proceed in a decentralised way in the respective tribes or domain structures, as long as the central steering function ensures end-to-end testing, regulatory alignment and consistent user experiences.
A second task of the task force is to make the institution visible in the ongoing working groups. At European level, this concerns EMVCo (for 3DS integration), the EU wallet consortia (EWC, NOBID, POTENTIAL) and the German sandbox community around SPRIND in particular. Financial service providers that engage here influence the technical standards that are not yet fully finalised and gain an information advantage.
For institutions in the Sparkassen-Finanzgruppe and in the cooperative banking group, a third layer comes into play. Federated structures distribute decisions across central institutions, central IT providers (Finanz Informatik, atruvia) and primary banks. A wallet strategy that is conceived only at the level of an individual house ignores the fact that central functions such as the EBL login, the OSPlus or agree21 banking platform and card issuing processes are centralised. It is therefore advisable to interlock the in-house task force early on with the respective central group programme and to carve up the institution’s own use cases deliberately along the primary bank / central IT interface. The same applies in the Austrian Raiffeisen sector and, in Switzerland, to the Raiffeisen and PostFinance groups.
2. The sandbox produces reliable numbers before 2027
The SPRIND sandbox has been publicly accessible since early 2026 and has, since spring 2026, also been extended to support issuance and verification of Electronic Attestations of Attributes. It enables financial service providers to set up a first working proof of concept without waiting for the national wallet launch in January 2027. Comparable test environments exist in Austria around ID Austria and in Switzerland around swiyu, as well as a pure reference implementation in the EU-wide repositories of the Commission.
A sandbox proof of concept delivers at least four useful insights. First, it shows the actual effort required to integrate an OID4VP verifier with the existing IAM or CIAM. Second, it surfaces weaknesses and incorrect assumptions in the use case definition. Third, it produces robust internal numbers on latency, error rates and user journey, which improve planning for 2027. Fourth, it provides a credible basis vis-à-vis the board, supervisors and external auditors that the institution is actively addressing the wallet.
For later production rollout, registration as a Wallet Relying Party in the national register is required. Only after successful registration does the institution receive the Wallet Relying Party Access Certificates (RPAC) and Registration Certificates (RPRC), which the wallet verifies for each request. Since the national registration processes in Germany are not yet finalised as of May 2026, early functional and legal preparation is advisable so that the application coincides with the productive wallet start.
Three patterns put the implementation particularly at risk. First, the wallet stays in the IT or security silo; compliance, AML, payments and sales are not engaged, and the use case inventory remains limited to the digital direct channel. Second, the roadmap addresses only onboarding; cluster 4 with PISP, DSA age verification, QES-based contract closure, KYB onboarding and the employee credential is missing from the backlog, even though it is fully covered by the regulation and carries the largest commercial upside. Third, the sandbox runs as a playground without use case binding; the PoC produces no robust latency, error rate or customer journey data that flows into production planning, and remains without consequence. Institutions that avoid these three patterns have already stabilised the programme at the second maturity stage.
3. Three business opportunities turn the obligation into a position
The acceptance obligation under Article 5f is the duty. But it only covers a part of what the wallet changes in the business model of a financial service provider. Anyone who wants to articulate their own commercial story should focus on the three business opportunities that are commercially viable for 2027. They are cut so they can be realised out of the pillar implementation that is needed anyway. Figure 3 shows the three opportunities with their respective actors and data flows.
Opportunity 1: bank as EAA issuer for account proof and creditworthiness
Banks can themselves become issuers of verified credentials, for example for proof of account holdership and creditworthiness attestations. An energy provider or mobile operator currently requires the customer’s full bank account details to set up a SEPA direct debit mandate. With the EUDI Wallet, the customer’s home bank provides a signed proof that the account exists and that the account holder matches the applicant. In the creditworthiness market the shift is more fundamental still. Today’s three-party model, in which the bank reports to Schufa and Schufa answers the creditor’s enquiry, becomes a two-party model. The home bank issues the creditworthiness attestation directly into its customer’s wallet, and the creditor in consumer credit, in rental deposits or in a mobile contract verifies it there. The bank replaces the credit bureau as the trust intermediary in an established market. The opportunity is attractive because it sits on the infrastructure that is being built for the obligation anyway (Wallet Relying Party registration, OID4VCI/OID4VP stack), and because it does more than enter a market: it changes that market’s structure.
Opportunity 2: IBAN tokenisation as a data-minimisation argument
Instead of passing the full account number in the checkout to merchants or acquirers, the wallet shares a short-lived account token, which the issuing bank resolves to the actual IBAN in the background. This reduces data disclosure to third parties, creates a measurable differentiator in the competition between payment flows and positions the bank as a trust anchor in the emerging wallet economy. This opportunity is attractive because it ties the bank closer to the customer in the card payment and account-to-account flow and pre-empts acquirer-side data-minimisation demands from AML and GDPR debates.
Opportunity 3: employee credential against impersonation fraud
The vishing wave of the past years has caused significant direct losses in the DACH region and led to a clearly tightened liability framework in the PSR draft. A digital employee credential in telephone service and advisory contact verifies in real time that the caller is in fact a bank employee, and the customer sees this in the institution’s mobile banking app. This opportunity is attractive because it directly addresses an existing, quantifiable loss exposure, brings liability clarity into the institution’s terms and conditions, and at the same time delivers a trust argument in the competition for existing customers.
Further levers such as KYB onboarding via the European Business Wallet, early integration into a later digital euro app, or issuer roles for other customer attributes are regulatorily and technically open as well, but from today’s perspective realistically achievable only after 2027 and belong to a second wave.
Across all use cases, the wallet modernises the operational identity architecture of a financial service provider. It forces institutions to take stock of their own authentication and identification flows, requires a consolidated view of identity data, and creates the basis for a single, regulatorily robust customer identity foundation. The minimum bar is compliance. Positioning the wallet as a platform for the institution’s identity architecture additionally brings efficiency in onboarding, a more consistent user experience and a stronger risk position.
Conclusion
The EUDI Wallet is part of Europe’s digital infrastructure and, for financial service providers, mandatory programme work from 24 December 2027. At the same time, AMLR and PSD3/PSR introduce two further major pieces of legislation that act on identification and strong customer authentication. The deadline lies, from today’s perspective, about 18 months in the future. Anyone treating EUDI only as an onboarding topic overlooks the four flows in cluster 4 (PISP, DSA age verification, QES-based contract closure and KYB onboarding) and with them the part of the duty that carries the largest commercial upside. A centrally coordinated inventory of all identification and authentication use cases now provides the basis for an orderly implementation and reduces the risk of reactive compliance under time pressure.
With a task force established by autumn 2026, a completed use case inventory and an ongoing sandbox proof of concept, an orderly production rollout in 2027 is achievable. An institution that additionally pursues the three strategic business opportunities (EAA issuer role, IBAN tokenisation and digital employee credential) turns the compliance investment into a strategic position of its own. The decision to do so falls in the coming weeks.
Sources
- Amaranth Advisory. EUDI Wallet – Regulatorischer Zwang und strategische Chance für Banken. 2026. https://www.amaranth-advisory.com/de/publications/eudi-wallet
- Austrian Federal Ministry of Finance. Tursky: Austria ready for the EU Wallet thanks to ID-Austria. March 2024. https://www.bmf.gv.at/presse/pressemeldungen/2024/maerz/eu-wallet.html
- Baker McKenzie. European Union: EUDI Wallet Harmonizes Identification and Age-Gating. 2026. https://www.bakermckenzie.com/en/insight/publications/2026/03/european-union-eudi-wallet-harmonizes-identification-and-age-gating
- Bitkom. Bitkom on the European Business Wallet. Position paper, 2026. https://www.bitkom.org/Bitkom/Publikationen/Bitkom-zur-European-Business-Wallet
- Bitkom. Memorandum of Understanding for the successful introduction of the EUDI Wallet. 2025. https://www.bitkom.org/MoU-EUDI-Wallet
- Bitkom. The EUDI Wallet is still largely unknown among the population. Press release, 13 April 2026. https://www.bitkom.org/Presse/Presseinformation/EUDI-Wallet-weitgehend-unbekannt
- Bundesnetzagentur. On 20 May 2024, the revised version of the eIDAS Regulation entered into force. 20 May 2024. https://www.elektronische-vertrauensdienste.de/EVD/DE/Aktuelles/Meldungen/eIDAS2_in_Kraft.html
- Bundesnotarkammer (German Federal Chamber of Notaries). The EUDI Wallet — A further step towards the continent’s digital transformation. 2025. https://www.bnotk.de/aufgaben-und-taetigkeiten/zeitschriften/bnotk-international/details/das-eudi-wallet-ein-weiterer-schritt-in-richtung-digitale-transformation-des-kontinents
- EMVCo. Use of the EUDI Wallet in EMV® 3-D Secure Payment Authentication. White paper, 17 June 2025. https://www.emvco.com/knowledge-hub/use-of-the-eudi-wallet-in-emv-3-d-secure-payment-authentication/
- EU Digital Identity Wallet. Age Verification Technical Specification. GitHub, 2026. https://github.com/eu-digital-identity-wallet/av-doc-technical-specification
- EU Digital Identity Wallet. Architecture and Reference Framework (ARF). 2026. https://eudi.dev/latest/architecture-and-reference-framework-main/
- EU Digital Identity Wallet. Reference implementations and technical specifications. GitHub, 2026. https://github.com/eu-digital-identity-wallet
- EU Digital Identity Wallet Consortium (EWC). 2026. https://eudiwalletconsortium.org/
- EU Digital Identity Wallet Consortium. Technical Specification TS12 on SCA implementation with the wallet. GitHub, 2026. https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/blob/main/docs/technical-specifications/ts12-electronic-payments-SCA-implementation-with-wallet.md
- European Commission. Implementing Regulation for European Digital Identity Wallets. 4 December 2024. https://digital-strategy.ec.europa.eu/en/library/implementing-regulation-european-digital-identity-wallets
- European Commission. Large Scale Pilot Projects. 2026. https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/694487808/What+are+the+Large+Scale+Pilot+Projects
- European Commission. The Age Verification Manual — EUDI Wallet. 2026. https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/930450954/The+Age+Verification+Manual
- European Parliament and Council. Regulation (EU) 2024/1183 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework (eIDAS 2.0). 11 April 2024. https://www.european-digital-identity-regulation.com/Article_5a_(Regulation_EU_2024_1183).html
- German Federal Ministry for Digital and State Modernisation (BMDS). Draft Act on the European Digital Identity Wallet (DIdG ministerial draft). 26 March 2026. https://bmds.bund.de/service/gesetzgebungsverfahren/digitale-identitaetengesetz-didg
- German Federal Ministry for Digital and State Modernisation (BMDS). EUDI Wallet (topic page). 2026. https://bmds.bund.de/themen/digitaler-staat/digitale-identitaeten/eudi-wallet
- NOBID Consortium. 2026. https://www.nobidconsortium.com/
- PayTechLaw (Annerton law firm). EUDI Wallet in the Draft Digital Identity Act (DIdG): Overview and Assessment from a Financial Sector Perspective. 14 April 2026. https://paytechlaw.com/en/eudi-wallet-in-the-draft-digital-identity-act/
- SPRIND (Federal Agency for Disruptive Innovation). EUDI Wallet Prototypes. 2025. https://www.sprind.org/de/artikel/eudi-wallet-prototypes/
- SRF. Vote of 28 September: e-ID legislation passes after a close vote. September 2025. https://www.srf.ch/news/schweiz/abstimmung-28-september-nach-abstimmungskrimi-e-id-vorlage-in-trockenen-tuechern
- Swiss Confederation. Federal popular vote of 28 September 2025. 2025. https://www.admin.ch/gov/de/start/dokumentation/abstimmungen/20250928.html
- Swiss Federal Office of Justice. The electronic identity (e-ID). 2026. https://www.eid.admin.ch/de/e-id
- Tink. From authentication to authorisation: Navigating the changes with eIDAS 2.0. 2025. https://tink.com/blog/open-banking/eidas-eu-digital-identity-wallet/
- VÖB (Association of Public Banks of Germany). Digital identities and trust services. Positions, 2025. https://www.voeb.de/unsere-positionen/digitale-identitaeten
Author
