EBA Q&A clarifies strong customer authentication requirements in open banking solutions

The evolving landscape of online payments under the Payment Services Directive (2015/2366) (“PSD2”) has consistently aimed to provide consumers with efficient, convenient and secure payment methods. Central to this effort is the application of strong customer authentication (“SCA”), a security measure requiring two or more independent factors to verify a user’s identity for online payments or account access. However, its practical implementation often faces friction.

Pertinent to the issue is the Commission Delegated Regulation (EU) 2018/389 (“Regulation”), supplementing PSD2 with regulatory technical standards on SCA. Article 32(3) of the Regulation explicitly prohibits account servicing payment service providers (“ASPSPs”), such as banks, from creating obstacles to the provision of open bank services, namely payment initiation (“PIS”) and account information services (“AIS”) by third parties in the interface provided to their clients (the payment service users). In essence, banks are not allowed to create barriers which make third-party services more cumbersome than their own. By way of example, banks shouldn’t force the user to leave the bank’s app to navigate multiple browser windows for a task which the bank’s app handles with a single click (also known as redirection).

A recent European Banking Authority (“EBA”) Q&A (Q&A 2025_7358) further illustrates this point. The question arose from a competent authority within the Union who requested EBA guidance on the authentication process within the context of payments initiated through open bank service providers. The context is namely that banks permit the reuse of the static SCA element in their online banking website. In practice, this essentially means that if a user accesses the online banking website, it can access its account data by performing full SCA, using both elements. However, once the user is logged in, a payment can be initiated with only one additional authentication element, while the other (static) element, is reused from the log-in.

In contrast, when the same user initiated a payment via an open banking service provider, such as a PISP using a redirection flow, they were required to perform full SCA twice. The authority claims that PISPs have complained that this discrepancy creates a worse customer experience for PIS users compared to the experience in the customer interface.

In Q&A 2025_7358, the EBA examined whether requiring two separate SCAs in redirection-based flows, constitutes a prohibited obstacle under Article 32(3) of the Regulation or otherwise. In a typical journey involving AIS and PIS services, the user interacts with AIS/PIS providers (“TPPs”) to initiate a payment. To avoid the manual entry of account details (such as the IBAN), the TPP retrieves the user’s list of accounts, requesting the user to be redirected to their bank’s website and perform SCA. This would in turn grant the TPP access to their account list. Once authenticated, the user is first redirected back to the TPP to select the specific payment account, and then finally redirected back to the bank’s app, to perform a second SCA so as to authorise the actual payment initiation.

This multistep process may feel like being forced to navigate a hall of mirrors just to reach the exit of a small room. However, while this ‘double-SCA’ process is more burdensome than a direct bank interface (where login and SCA elements are reused), the EBA has ruled that such an obstacle is not inherently prohibited under the Regulation. The EBA’s interpretation aligns with EBA Opinion (EBA/OP/2020/10), which views AIS and PIS as distinct services, wherein one service involves granting access to sensitive financial data, the other involves the authorisation of a financial transaction. Since these are two separate actions, requiring distinct SCAs does not violate the Regulation.

This interpretation is also consistent with previous EBA Q&As stating that SCA must be applied to every payment initiation. Even if a user has already authenticated to access their data, the act of initiating an electronic payment transaction remains one of the three triggers for mandatory SCA under Article 97(1) of PSD2.

Despite the EBA’s acceptance of double-SCA in flows involving TPPs, banks (and other APSPS) remain bound by the non-discrimination principle under PSD2. Banks must ensure that TPP requests are not treated less favourably than transactions initiated directly through their own online banking portals. Accordingly, if a bank allows a customer to reuse an SCA factor (for instance, using the same password from the login and only requiring a new SMS one-time password for the payment), it should offer equivalent functionality to TPPs.

This obligation, however, applies only where it is technically feasible to maintain the continuity of user’s session as they navigate between the bank and TPP domains. Hence, a bank may require two full SCAs, even where it allows factor reuse internally, if it can demonstrate “objective reasons” such as security conflicts or technical inability to retrace the session.

Another iteration which was considered is the PIS-only journey. If the TPP already has the user’s account list and transmits the payment order to the bank, the latter must support a single SCA. Requiring one SCA to access the account and a second SCA to initiate the payment would be considered a prohibited obstacle under the Regulation. As clarified in previous EBA Q&As, one authentication element used during initial account access may be reused for a payment initiation within the same session, provided the ‘dynamic linking’ requirement remains satisfied. PSD2 is clear – the authentication code for any remote electronic payment must be specific to the amount and the payee. While a bank might allow the reuse of a knowledge factor (such as PIN) it must always require a second and unique possession or inherence factor at the time of payment to link the authentication to that specific transaction.

As digital finance and open banking continue to evolve, the balance between robust security measures and a seamless user experience remains the central challenge for regulators and providers alike.