In October 2025, the European Banking Authority (“EBA”) released three Question and Answers (“Q&A”) on the topic of strong customer authentication (“SCA”).
In particular, the Q&As focussed on the topics of (i) payment terminals that do not allow for an offline PIN, (ii) which encryption techniques should be used for exchanging data and (iii) the difference in SCA application for users interacting directly with the customer interface versus users redirected via a third-party service provider.
Understanding SCA
Strong customer authentication or SCA is a requirement introduced by Directive (EU) 2015/2366 (“PSD2”) for payment service providers (“PSP”) to implement a multi-factor authentication (MFA) when a user:
- accesses its payment account online;
- initiates an electronic payment transaction; or
- carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.
SCA is based on the use of two or more authentication elements categorised as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) that are independent, in that the breach of one does not compromise the reliability of the others, and is designed in such a way as to protect the confidentiality of the authentication data.
Contactless only payment terminals
The background of this first question concerned a PSP wanting to develop a contactless only terminal (a so-called SoftPOS), intended for use during exceptional circumstances such as cyber-attacks or other disruptions to internet connectivity and acquirer systems.
As SoftPOS terminals operate exclusively with contactless transactions, which do not support an offline PIN, the PSP argued it is technically impossible to perform SCA in offline mode.
The EBA clarified that SCA is required when the payer initiates an electronic payment transaction, unless a specific exemption foreseen in PSD2 applies. As an exemption for exceptional circumstances or emergency situations is not foreseen, SCA should still be applied in such cases.
Encryption techniques
Account servicing payment service providers (“ASPSP”), PSPs issuing card-based payment instruments, account information service providers (“AISP”) and payment initiation service providers (“PISP”) must ensure that, when exchanging data by means of the internet, secure encryption is applied between the communicating parties.
PSD2 does not clarify which encryption techniques exactly should be used (e.g. RSA or ECC or both). The EBA clarified in this second Q&A that any strong and widely recognised encryption technique can be used.
If an ASPSP specifies a particular encryption technique in the technical documentation of its application programming interface (“API”), it is not obliged to support all widely recognised encryption techniques. Consequently, it may rightfully reject API calls that use encryption techniques not supported by the API.
Authentication with the ASPSP in a combined AIS and PIS journey in a redirection approach
When users make use of the customer interface of a PSP, e.g. an online banking website, they can access their account data by performing full SCA, using at least two elements. However, once they are logged in, they are entitled to initiate a payment with an authentication using only one element, while the other static element that does not change over time or per transaction, is reused from the log-in.
In contrast, if users initiate a payment via a third-party service provider (“TPP”), like an AIS or PISP, using a redirection flow and without having to enter their account details, they have to perform full SCA twice: once for the retrieval of the list of accounts on the TPP’s domain and subsequently once more for the payment itself.
TPPs have complained that this discrepancy creates an inferior customer experience for TPPs users compared to the experience of user who are and remain in the customer interface of their PSP. It is important in this context to clarify that articles 66(4)(c) and 67(3)(b) PSD2 require ASPSPs to treat payment orders and data requests transmitted through TPPs respectively, “without any discrimination other than for objective reasons” compared to those transmitted directly by the payment service user.
The EBA clarified in a third Q&A that in the scenario where the user first authenticates with the ASPSP to give access to the TPP where the user selects an account on the TPP’s domain, and is subsequently redirected to the ASPSP to authenticate the payment, indeed two SCAs are required. One SCA is for granting access to the TPP to the list of accounts, and the other is for initiating the payment. Nevertheless, the ASPSP may in such cases allow the reuse of one SCA factor, provided that it is technically feasible to maintain the session established by the ASPSP with the user across the TPP steps.
Conversely, if maintaining session continuity is not technically feasible or secure encryption cannot be applied, full SCA twice will be required. It should be noted that this is to be assessed on a case-by-case basis.
In a different scenario where the TPP has already obtained the list of accounts from the ASPSP, the user selects the account on the TPP’s domain to initiate a payment. The TPP then sends the payment order to the ASPSP with all the required details, including the payer’s IBAN, and only one SCA should be required to initiate the payment.
If you have any questions or would like to discuss this topic, feel free to reach out to us at digitalfinance@simontbraun.eu.
***
This newsletter does not constitute legal advice or a legal opinion. Please consult with a legal counsel before taking any action based on the information provided.