Until recently, the acronym SCA rarely caused confusion. In the world of electronic signatures, it refers to a Signature Creation Application, i.e., an application for creating a signature. In the payment world, it refers to Strong Customer Authentication of payment transactions.
These two meanings coexisted because they belonged to different domains: trust service providers versus banks and payment service providers. But today, both worlds are converging in one place: the European Digital Identity Wallet. The EU framework for the EUDI Wallet assumes that the wallet will serve both authentication and legally binding e-signature purposes. The European Commission explicitly states that the wallet should enable authentication, signing, and use in many everyday scenarios, including banking and payment services.
SCA as Signature Creation Application
Let’s start with the first meaning of SCA, Signature Creation Application. This is simply an application involved in the electronic signature creation process. The ETSI EN 319 102-1 standard describes it as part of the Signature Creation System, operating alongside the Signature Creation Device. In practice, this means the signature application is neither the key itself nor the cryptographic device. It is more like a “signing desk”: a place where the user views the document, selects signature parameters, initiates the process, and the system prepares the data for signing and builds the final signature object.
The standard also specifies that such an application can operate:
- on a computer,
- on a mobile device,
- as a web service,
- as part of a larger service.
In this sense, the SCA “for signing” ensures the security and correctness of the signing process. It collects the document or its representation, prepares the data for signing, attaches the necessary attributes, initiates signing on the device or cryptographic module, and returns the result.
In qualified trust services, such an application is often provided by a qualified trust service provider or operates under their controlled model. Therefore, the user typically sees a simple “sign document” screen, while a whole structured process, defined by ETSI standards, runs behind the scenes.
SCA as Strong Customer Authentication
The second meaning of SCA is entirely different. Strong Customer Authentication comes from payments and PSD2 regulation (Payment Services Directive 2). The directive defines it as authentication based on at least two elements from three categories:
- knowledge (something the user knows),
- possession (something the user has),
- inherence (something the user is).
These elements must be independent of each other so that compromising one does not weaken the others. PSD2 requires such authentication, for example, when a user accesses an online account, initiates an electronic payment transaction, or performs a remote action that could carry fraud risk.
For remote payments, simply “proving it’s me” is insufficient. PSD2 and the implementing technical standards also require dynamic linking. This means the authentication code must be tied to a specific amount and a specific payee. If either the amount or the recipient changes, the code should become invalid. This is a practical security mechanism: it’s not just about logging in, but ensuring the user confirms the exact transaction displayed on their screen.
In the payment world, responsibility for SCA lies with the payment service provider: the bank, card issuer (the financial institution issuing the card to the client), or another PSP. The European Banking Authority (EBA) has clarified that even for digital wallets, SCA is required, e.g., when adding a card to the wallet or initiating a transaction with a digitized card.
One acronym, two different meanings
Here lies the core: both SCAs sound identical, but they mean entirely different things. One relates to signature creation, the other to customer authentication in payment services. One originates from the e-signature and trust services world, the other from financial regulations and payment security. For years, this wasn’t an issue because the two domains rarely overlapped. Today, however, the digital identity wallet brings them together into a single ecosystem.
European wallet regulations go even further. The amended eIDAS Regulation stipulates that the European Digital Identity Wallet must enable the creation and use of qualified electronic signatures recognized across the EU, and member states must offer individuals the ability to sign with a qualified signature by default and free of charge. At the same time, the wallet must provide secure authentication and identity verification for digital services, including banking and payment scenarios.
This is why both meanings of SCA are now starting to converge. Moreover, SCA-Sign can reinforce SCA-Pay. A well-designed signing application organizes the entire authorization process:
- shows the user exactly what they are approving,
- which data are involved,
- who the parties are,
- and the legal and technical context.
This aligns closely with the payments market’s expectations for strong authentication and dynamic linking. In other words, technologies developed over the years for secure electronic signatures can also help build clearer, safer authorization processes in finance. This doesn’t mean signatures replace PSD2 SCA, but they can become a key part of a broader trust architecture.
SCA vs SCA challenge
The biggest challenge will not be technology itself, but language and mutual understanding. Today, when a bank representative says “SCA,” they usually mean customer authentication under PSD2. Meanwhile, a signature specialist using “SCA” refers to a signature creation application. In the EUDI Wallet world, both sides will need to learn to speak more precisely. Terms like SCA-Sign and SCA-Pay may be used more frequently to clarify which domain is being discussed.
The good news is that the convergence of these two SCA meanings doesn’t have to be a problem – it can be an opportunity. The European Digital Identity Wallet can become a space where the payments and trust services markets begin using common security mechanisms, a shared approach to responsibility, and a unified trust language. This could become one of the most interesting developments in the European digital identity transformation.
Publication date: 15.04.2026