EUDI Wallet for banks and payment service providers: mandatory acceptance, strong customer authentication and practice

Banks and financial service providers – except micro and small enterprises – must accept the EUDI Wallet as an additional method by 24 December 2027 (calculated) when a customer asks for it. The obligation applies wherever the bank is required by law, or requires by contract, strong user authentication for online identification. For onboarding and login this is clear. Whether it also covers payment approval (strong customer authentication, SCA) has not been settled in a binding way – technically, the EU’s Technical Specification 12 already prepares for it.

The general rules are explained in Which businesses must accept the EUDI Wallet?. This page covers what is specific to banks and payment service providers.

What eIDAS says about banks

Article 5f(2) eIDAS names “banking” and “financial services” explicitly. Article 3(51) defines strong user authentication almost exactly as PSD2 defines strong customer authentication: at least two independent factors from knowledge, possession and inherence.

Recital 62 of Regulation (EU) 2024/1183 is more specific. Electronic identification and attestations of attributes should help the financial sector to identify customers, meet customer due diligence requirements and “support the fulfilment of strong customer authentication requirements for online identification for the purposes of account login and of initiation of transactions in the field of payment services”. Recitals guide interpretation; they do not create obligations of their own.

Strong customer authentication with the wallet

The SCA obligation itself comes from payments law: Article 97 PSD2 and the RTS in Delegated Regulation (EU) 2018/389. A payment service provider must apply SCA when the payer accesses the account online, initiates an electronic payment, or carries out a remote action that implies a risk of fraud. For remote payments, authentication must be dynamically linked to amount and payee.

What the Architecture and Reference Framework (ARF) foresees: Section 2.6.4 of ARF v3.0.0 describes the wallet as an authenticator for payments. It “assumes” that strong user authentication under Article 5f(2) means wallets must meet the PSD2 SCA requirements. There are three phases:

1. Registration: The customer identifies (for example with the PID) and the bank issues its own device-bound attestation into the wallet (SCA attestation).
2. Authentication: The bank requests this attestation and sends transaction data, at least amount and payee. The wallet shows them and signs them once the customer approves. According to the ARF, this signature is the proof of transaction required by PSD2 (dynamic linking).
3. De-registration: The attestation is deleted or revoked.

The details are in Technical Specification 12 (version 1.0 of 5 December 2025, editorially updated as 1.0.1). Under requirement SUA_01 in Annex 2 of the ARF, every wallet must be able to process this transaction data. The ARF is a technical framework, not a legal act.

What is open: Neither the Commission nor the EBA has stated in a binding way whether the acceptance obligation covers payment approval or only identification and login (unverified, as of 13 October 2026). In May 2025 the Dutch Payments Association considered it hardly possible to use the wallet as a second factor in full compliance with PSD2; TS12 was published afterwards. Either way, the bank remains responsible for correct SCA.

Germany as an example: The explanatory memorandum to Germany’s Digital Identities Act (DIdG; government bill, printed paper 21/7408) goes further. It says private relying parties must adapt their systems so that “both identification and (strong) authentication” are possible with the wallet, naming SCA under the German payment services supervision act (section 55 ZAG). The Bundestag adopted the act on 15 October 2026 as amended by its digital affairs committee (printed paper 21/8617); section 15(1) was not changed. The Bundesrat still has to consent, and the act has not yet been promulgated (as of 26 October 2026).

Payment functions inside the wallet

Paying with the wallet is a separate matter. Article 5a(7) eIDAS lets member states add functionalities to their wallets. Germany’s act (section 17, unchanged by the committee) would allow existing payment instruments of a licensed payment service provider, such as cards, to be added; according to the memorandum there is neither an obligation nor a right to this. For banks, this is an option, not part of the acceptance obligation.

What about the Payment Services Regulation (PSR)?

The EU Payment Services Regulation (procedure 2023/0210(COD)) is set to replace the SCA rules of PSD2. According to the European Parliament’s Legislative Observatory, the ECON committee approved the negotiated text on 5 May 2026; the procedure is awaiting the Council’s position, with an indicative plenary date of 14 December 2026 (as of 13 October 2026). The PSR is therefore not yet in force. We have not checked whether it addresses the EUDI Wallet for SCA unverified.

Typical use cases

Our own classification, not an official list:

Onboarding: Identification under AML rules, required data, record keeping and the portrait are covered in EUDI Wallet for AML and KYC. One point matters for process design: the address is only an optional field in the PID (Annex I, Implementing Regulation (EU) 2026/1731). Onboarding for customers from other member states needs a second route for the address.

Change of address: If the PID contains an address, the customer can send it in signed form. In our view this does not automatically replace the bank’s own verification duties unverified.

What to do, and by when

1. Check scope and size: Micro and small enterprises are exempt, medium-sized ones are not (small business exemption).
2. Plan two roles: For identification and login the bank is a relying party. For SCA under TS12 it also issues an attestation; according to the ARF, issuers also need an access certificate (requirement ISSU_32).
3. Register in the member state of establishment, stating the purpose and exactly the data requested (Article 5b eIDAS, Implementing Regulation (EU) 2025/848). The rules for national registers apply from 24 December 2026 (Article 11). Process: relying party registration. Requesting more than registered is not allowed: What data can relying parties request?
4. Technology: TS12 builds on SD-JWT VC and OpenID4VP. Agree with core banking and authentication providers who implements what.
5. Note the dates: registers from 24 Dec 2026, AMLR from 10 July 2027, acceptance obligation from 24 Dec 2027 (calculated) – overview: deadlines.

Whether the wallet replaces existing methods such as the banking app or video identification is the bank’s decision. The obligation is only to offer it in addition when the customer requests it (Article 5a(15), Article 5f(2) eIDAS). Eudigo does not provide legal advice; whether a specific process is covered depends on the individual case.