- Question ID
-
2025_7604
- 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 multiple manual checkboxes for a single AIS consent
- Question
-
Does the practice of an ASPSP requiring a PSU to manually tick multiple, separate checkboxes for different categories of account data in order to grant a single consent for an Account Information Service (AIS) constitute an obstacle under Article 32(3) of the RTS, by adding unnecessary steps and friction to the user journey?
- Background on the question
-
Article 32(3) of the RTS prohibits the creation of obstacles. Paragraph 15 of the EBA Opinion on obstacles (EBA/OP/2020/10) specifies that the authentication journey should not create "unnecessary friction or add unnecessary steps".
When a PSU provides consent to an Account Information Service Provider (AISP) for access to their payment account information, this is typically a single, holistic act of consent for the scope of the AISP's service. However, some ASPSPs, during the redirection journey, present the PSU with a consent screen that breaks this single consent down into multiple, separate checkboxes. The PSU is then required to manually tick each box (e.g., one for 'account details', another for 'account balance', and a third for 'transaction history') to proceed.
This practice creates confusion, as the PSU has already provided their consent to the AISP. It also adds several manual steps to the process. It is unclear if this design pattern, which dissects a single user intent into multiple required actions, is compliant with the RTS. - 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 paragraph 43 of the EBA Opinion on obstacles (EBA/OP/2020/10).
- Status
-
Rejected question