Question ID
2025_7605
Legal act
Directive 2015/2366/EU (PSD2)
Topic
Strong customer authentication and common and secure communication (incl. access)
Article
Article: 98
Paragraph
Paragraph: 1
Subparagraph
Letter: d)
COM Delegated or Implementing Acts/RTS/ITS/GLs/Recommendations
Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication
Article/Paragraph
Article: 32; Paragraph: 3
Name of institution / submitter
ZNPay a.s.
Country of incorporation / residence
Czech Republic
Type of submitter
Other
Subject matter
Obstacle assessment of requiring an additional SCA for PIS within an existing authenticated AIS session
Question

If a Payment Service User (PSU) initiates a payment (PIS) immediately after establishing a session for an Account Information Service (AIS) (for which SCA has already been performed), does the ASPSP's requirement for an additional, separate SCA—such as the need to fully log in to the mobile banking app before the payment confirmation screen is displayed—solely to access the payment function (and preceding the dynamic linking SCA) constitute an obstacle under Article 32(3) of the RTS?

Background on the question

Article 32(3) of the RTS prohibits obstacles, and the EBA Opinion on obstacles (EBA/OP/2020/10), particularly paragraph 26, addresses the issue of requiring multiple Strong Customer Authentications (SCAs) for a single payment initiation.

A common user journey involves a PSU first establishing an authenticated session with their ASPSP via an AISP to view their account information, for which SCA is applied. Immediately thereafter, within the same continuous session, the PSU decides to initiate a payment (PIS) through the same TPP. In this scenario, some ASPSPs require the PSU to perform a second, separate SCA (e.g., a full login to their mobile banking app) merely to "access" the payment functionality, before being presented with the payment details for a third SCA (the dynamic linking one).

This practice imposes an additional, seemingly redundant SCA event into what should be a seamless user journey, creating friction and confusion for the user.

Submission date
Rejected publishing date
Rationale for rejection

This question has been rejected because EBA guidance or clarification is not needed. The question has already been addressed in paragraphs 22 - 28 of the EBA Opinion on obstacles (EBA/OP/2020/10).

Status
Rejected question