Skip to main content
The Signicat Blog
Blog image- Strong Customer Authentication (SCA) with EUDI Wallets
Portrait of Esther Makaay
Esther Makaay

VP of Digital Identity, Signicat

Strong Customer Authentication (SCA) with EUDI wallets: What financial services need to know

With the introduction of the EU Digital Identity Wallets (EUDI Wallets) under eIDAS 2.0, banks and financial institutions that need to apply Strong Customer Authentication (SCA) under PSD2 will be required to accept EUDI Wallets as a means of strong authentication by end 2027. 

Strong Customer Authentication (SCA) is already a core requirement in European financial services under the EU Regulation Payment Services Directive 2 (PSD2) . It protects users when they log in, make payments, access sensitive data or perform any action that carries a risk of fraud. 

Now, with the introduction of the EU Digital Identity Wallets (EUDI Wallets) under eIDAS 2.0, the European Digital Identity regulation, a major shift is coming: services like banks and financial institutions that are required to apply SCA under PSD2 will also be required to accept EUDI Wallets as a means of strong authentication (referred to as Strong User Authentication, or SUA, under eIDAS) by the end of 2027. 

Understanding Strong Customer Authentication (SCA)

One of the most important security requirements introduced by the EU’s Payment Services Directive 2 (PSD2) is Strong Customer Authentication (SCA). It is also expected to remain central under the upcoming Payment Services Directive 3 (PSD3).

SCA ensures that a user really is who they claim to be before accessing an account or approving a payment. Here are a few things to know about SCA.

  • PSD2 requires SCA whenever there is a risk of fraud, including logging into an online bank account and initiating an electronic payment.

  • Although there’s no formal definition of what SCA entails, in practice it’s considered to be MFA and must use at least two independent authentication factors:

    • Something the user knows (e.g. PIN or password)
    • Something the user has (e.g. phone, device, or wallet)
    • Something the user is (e.g. fingerprint or facial recognition)

    These factors must be independent. This means that if one factor is compromised, it does not weaken the others. They should also be combined with what is regarded a 4th type of factor: context (such as the geographical location, time, or channel).

  • For electronic payments, SCA includes an additional safeguard called dynamic linking.

    This means the authentication is tied to the specific payment transaction, including the amount and the recipient (for example, €500 to Amazon). If any detail changes, the authentication becomes invalid.

    This prevents fraudsters from reusing an approval for a different payment.

EU Digital Identity Wallets are designed to meet all of these SCA requirements, making them a strong foundation for secure authentication and payment approval in Europe.

Mandatory acceptance of EUDI Wallets for SCA

Under eIDAS 2.0, financial institutions will be required to accept EU Digital Identity Wallets as a method for Strong Customer Authentication (referred to as “Strong User Authentication” in eIDAS) when users choose to use them.

This requirement is legally binding.

In practice, this means:

  • Wallets must be supported alongside existing methods
    Financial institutions must support EUDI wallets as a new authentication method next to existing options such as eIDs or biometric logins.
  • Cross-border acceptance becomes mandatory
    Institutions will need to accept all EUDI wallets issued across EU member states (27+ wallets), even if they do not operate in those countries.

Where this applies in financial services

This requirement impacts several everyday user journeys

  • Users should be able to authenticate using their EUDI Wallet next to existing methods currently offered. 

    For example, a customer wants to access their online banking service and selects “Log in with the EUDI Wallet” to securely access their account.

  • Wallets will need to be supported to approve payments.

    Some examples include-

    • Approving an online purchase directly in the wallet instead of using an SMS OTP
    • Confirming a bank transfer before it is executed
    • Authorising a recurring subscription with secure, wallet-based approval
  • Wallets will also need to be accepted for verifying identities during account opening and onboarding.

    For example, a user opens a bank account by sharing verified identity data directly from their wallet, reducing manual checks and friction.

What this means for financial institutions

Financial institutions need to prepare for new authentication flows powered by EUDI Wallets.

This is not just about adding another login option. It means adapting systems to support wallet-based authentication across login, payments, and onboarding, while continuing to support existing methods during the transition.

Where the requirement comes from: Article 5f of eIDAS

The obligation to accept EUDI Wallets is defined in Article 5f of eIDAS 2.0. Section 2 applies to financial services and other regulated industries.

 "Where private relying parties that provide services, with the exception of microenterprises and small enterprises as defined in Article 2 of the Annex to Commission Recommendation 2003/361/EC, are required by Union or national law to use strong user authentication for online identification or where strong user authentication for online identification is required by contractual obligation, including in the areas of transport, energy, banking, financial services, social security, health, drinking water, postal services, digital infrastructure, education or telecommunications, those private relying parties shall, no later than 36 months from the date of entry into force of the implementing acts referred to in Article 5a(23) and Article 5c(6) and only upon the voluntary request of the user, also accept European Digital Identity Wallets that are provided in accordance with this Regulation."

In simple terms, it states: if your service requires strong user authentication (the equivalent of SCA in PSD2), you must also accept EUDI Wallets as an option for users.

 This article has other sections applicable to other stakeholders:

  • Section 1 - public sector services (effective from launch of the wallets - December 2026)
  • Section 2 - regulated industries mandated to use strong authentication (effective from December 2027)
  • Section 3 - very large online platforms (VLOPs) (effective from launch of the wallets in December 2026)

Key timelines to know

  • December 2026: EUDI Wallet rollout begins
    EU Member states are expected to launch their national wallet solutions. This marks the beginning of real-world adoption and early use cases going live. 
  • July 2027: AMLR comes into force
    The new Anti Money Laundering Regulation (AMLR) requiring the use of eIDAS-compliant identity methods (eIDs, EUDI wallets and Qualified Trust Services) kicks in.
  • December 2027: Mandatory acceptance for regulated industries
    Regulated industries, including financial services, are required to accept EUDI Wallets for authentication.

Enforcement of mandatory acceptance: what to expect

Although there are concerns in the ability of the EUDI Wallets to fully support all SCA use cases from the start, and lots of unanswered questions on how this will affect enforcement of mandatory acceptance, this requirement is legally binding. 

The European Commission is going to enforce mandatory acceptance. They will likely give any non-compliant service a time-limit to set this up (roughly 6 months going by experience) and apply penalties (similar to those for trust services - €5 million or 1% of the annual turnover, whichever is biggest). There is no formal published enforcement model yet, but this approach has been verbally communicated.

While acceptance of the EUDI Wallets is mandatory, there are still open questions around how feasible this will be in practice, especially in the early years of rollout.

Several national wallet implementations have indicated that they will not to be able to support 3rd-party issuing into the wallets from the start. This capability is needed for enabling certain payment flows described in the technical specifications on this topic. Many functional flows for payments rely on emerging standards, such as W3C Digital Credential (DC) APIs, that are not yet finalized and not fully mature enough to be supported across platforms and ecosystems.

EUDI Wallets as part of AMLR compliance

The new Anti-Money Laundering Regulation (AMLR) triggers eIDAS from July 2027 onwards (before mandatory acceptance on SUA in December 2027):

It requires the use of 3 identification methods that are compliant and explains how to use them in KYC/AML processes:

  • EUDI Wallets
  • Notified national eIDs (substantial or high)
  • Identity proofing through Qualified Trust Services

AMLR (EU Regulation 2024/1624) explicitly links identity verification requirements to eIDAS. Using (existing) alternative methods (such as biometrics) is allowed only if you can justify the reason why the identity verification was not performed with one of the mentioned eIDAS methods. The alternative (biometric) method would also have to be proven to be on Level of Assurance High, compliant with eIDAS (including the implementing regulations and ETSI standards). This could have to be assessed by a Conformance Assessment Body.

Out of these offered identification methods, the EUDI Wallet by far is the least costly one. 

Learnings from the Large Scale Pilots (LSPs)

The European Commission co-funds LSPs to test-drive the specifications of the EUDI Wallets in functional use cases. Signicat is an active participant in these LSPs.

Payments were worked on in 2 LSPs (EWC and NOBID) that are now wrapped up. They collaborated on this topic, with NOBID focusing on account-to-account payments and EWC covering card payments as well. 

Some relevant deliverables on this topic from the 1st round of LSPs:

  1. Payment enabler services: Download the document
  2. Payments white paper: "What does it take to use the European Digital Identity wallet for payment? Download the white paper
  3. EWC demo video: "Fast checkout with discounts with an EUDI Wallet". Watch the video

One of the current LSPs, WE BUILD, is taking that work as a starting point and has 4 distinct use cases: supporting payments (for natural and for legal persons) and opening a bank account (also for natural and for legal persons). 

Read more about the LSPs and their deliverables on the website of the European Commission.

Specifications and guidelines from the Commission

The work in the LSPs is the basis for specifications that are now part of the Architecture Reference Framework (ARF), which provides the architecture of the EUDI Wallet ecosystem. It specifies the standards, protocols, and formats of information exchanges between issuers, wallets, and service providers. 

Technical specification ARF TS 12 explains how the EUDI Wallet should be used to perform Strong Customer Authentication (SCA) for payments. Read the Technical specification ARF TS 12.

The European Commission publishes use case manuals on various topics. You can find the use case manual on payment authentication already and there’s one on opening a bank account coming soon. Read the use case manuals.

FAQs on SCA and payments, straight from the European Commission

The European Commission publishes a FAQ covering many questions and topics. Relevant questions and answers in there on the topic of SCA currently are listed below. But please refer to the Frequently Asked Questions page by the Commission directly for the latest version.

  • In the context of Regulation (EU) No 910/2014, the term "strong user authentication" is used instead of "strong customer authentication" (SCA), which is a concept used in Directive (EU) 2015/2366 (PSD2). Since EU Digital Identity Wallets are provided free of charge and do not involve customers in the traditional sense, Regulation (EU) No 910/2014 consistently refers to their holders as "users" instead of “customers”. Although the terms differ, both refer to the same underlying concept, a multi-factor authentication process that ensures secure and reliable user authentication and should therefore be considered as synonyms in this context.

  • As per Article 5f(2) of Regulation (EU) No 910/2014, certain private relying parties are required to accept the wallets, upon request of the user, where Strong Customer Authentication (SCA) is required by Union or national law, or by contractual obligation. For example, under the PSD2 Directive, payment service providers are required to apply SCA in specific situations. This obligation to accept the wallets upon request of the user applies 36 months after the entry into force of the implementing acts referred to in Article 5a(23) and Article 5c(6) of Regulation (EU) No 910/2014.

  • Regulation (EU) No 910/2014 does not prescribe how service providers should fulfil their obligation to recognize the European Digital Identity Wallet to apply Strong Customer Authentication (SCA).

    However, large scale pilots have tested and developed the following way how payment service providers can fulfil their obligations under Art. 5f(2) of Regulation (EU) No 910/2014:

    Payment Service Providers issue a dedicated SCA attestation after carrying out a secure authentication of the user and linking users to their specific payment account and payment instrument.

    In this model, the payment service provider acts as both the issuer of the SCA attestation and the verifier. It should retain full control over the authentication decision, remaining able to authenticate the user independently. The payment service provider should remain fully responsible for validating the attestation and ensuring compliance with applicable regulations.

    The following detailed process has been developed by large-scale pilots in this context:

    1. Before the SCA attestation is issued to the user’s wallets, the user completes a registration process under the control of the payment service provider. This process begins when the user requests their wallets to be registered for a specific payment account and payment instrument.
    2. The payment service provider authenticates the user through an existing PSD2-compliant method.
    3. The wallets generate a cryptographic key pair: the private key is securely stored and used to sign messages, while the corresponding public key is shared with the payment service provider for verification purposes.
    4. The payment service provider issues an individual SCA attestation into the user’s wallets. This attestation is device-bound, ensuring usage is linked to the user’s keys on that device, and requires multi-factor authentication to activate the signing key. The resulting cryptographic signatures can then be verified by the payment service provider to securely authenticate transactions.
    5. Following this registration, the wallets can be used to present the SCA attestation when SCA is required, together with transaction-specific details for the user to confirm. The confirmation is cryptographically bound to the transaction and allows for dynamic linking, ensuring that authentication is directly tied to the transaction details, such as the specific amount and a specific payee, and that these details are protected from tampering.
    6. The SCA attestation and the transaction data can be shared with the payer’s payment service provider, supporting various use cases and allowing additional attributes, such as age verification, to be combined with the payment data.

    A description of this process can be retrieved at the following link: Directive - 2015/2366 - EN - Payment Services Directive - EUR-Lex.

  • Outsourcing agreements between payment service providers and wallets providers are not required under Regulation (EU) No 910/2014 for the implementation of the wallets for SCA. Where payment service providers act as both issuer of the SCA attestation and verifier, they should retain full control over the authentication decision and remain fully responsible for validating the attestation and ensuring compliance with applicable regulations.

    In this model, the wallets act as a secure carrier of the attested information. Given that payment service providers are responsible for issuing and relying upon attestations for SCA, a delegation of the authentication to a third party does not take place.

How Signicat helps you comply 

Signicat provides the largest selection of eIDAS approved methods, including 35 eIDs and all certified EUDI wallets, through a single API. This lets you support both eIDs and wallets for SCA, gives you full geographic coverage across Europe and ensures a smooth, future-proof transition as wallets roll out.

Read more about Signicat's eID and Wallet Hub API

Explore Signicat's full suite of EUDI Wallet services.