Response to consultation on the Guidelines on the conditions to be met to benefit from an exemption from contingency measures under Article 33(6) of Regulation (EU) 2018/389 (RTS on SCA & CSC)
Go back
While we agree that redirection is not an obstacle per-se, the current implementation of redirection by many UK banks today contain what we consider as obstacles.
Non-definitive list of obstacles:
* Significantly divergent from the OBIE consent guidelines.
** Difficult for the PSU:
** Too many steps.
** Too many pages (the guidelines have 3 pages).
** Too many mouse clicks (the guidelines have 7 clicks).
** Too many fields to be entered (the guidelines have 3 fields).
** Require new tabs to be opened or take the PSU out of the window. (e.g. as not required by current online banking).
** Asking for the same information twice.
** Asking for superfluous information (e.g. asking for a PIN, when a PIN is not needed).
** Requiring a device that they not have to hand (e.g. Pinsentry, though if this is currently required for online banking, it would be an exception).
** Long pages with many unrelated steps.
** Opening a new window.
** Requiring the user to login many times, where previously the user only had to login once, e.g. to make multiple payments.
** Do all consents return the user reliably to the application redirect endpoint?
* Performance:
** Takes too long
** Slow to load pages.
** Buggy pages, or random crashing.
** Low service availability.
* Style and content:
** Branded differently to the bank’s website (i.e. confuse the customer).
** No clear signage to how to sign-up for online banking.
** Use of language creating a level of fear, uncertainty, and doubt when consenting to share their data with TPPs
** Use of too long and too legalize consent language that frustrates customer consenting to share data; frustrates customers, especially those using mobile devices.
** Incorrect instructions.
** Unnecessary interstitial pages or distractions around login controls (e.g. for advertising for other products or messaging around features).
** Subject to passing the above criteria, an ASPSP who has implemented a consent flow consistent with the OBIE consent guidelines can expect to be considered obstacle-free.
One straightforward KPI for the effectiveness of the consent flow is the percentage of PSUs that successfully complete it. For screen-scraping the figure is around 65%. An ASPSP could demonstrate they meet this requirement by publishing this KPI and its difference to screen scraping being statistically insignificant.
(a) To be able to test a set of use cases, the ASPSP must provide the TPPs with test accounts within their test facility that are representative on those like to be found in production.
(b) To point 52. On top of “connection and functional” testing, there is a use case for testing to discover and understand the APIs and any consent flow required.
Question 1: Do you agree with the EBA’s assessments on KPIs and the calculation of uptime and downtime and the ASPSP submission of a plan to publishing statistics, the options that EBA considered and progressed or discarded, and the requirements proposed in Guideline 2 and 3? If not, please provide detail on other KPIs or calculation methods that you consider more suitable and your reasoning for doing so.
YesQuestion 2: Do you agree with the EBA’s assessments on stress testing and the options it considered and progressed or discarded, and the requirements proposed in Guideline 4? If not, please provide your reasoning.
YesQuestion 3: Do you agree with the EBA’s assessments on monitoring? If not, please provide your reasoning.
YesQuestion 4: Do you agree with the EBA’s assessments on obstacles, the options it considered and progressed or discarded, and the requirements proposed in Guideline 5? If not, please provide your reasoning.
No.While we agree that redirection is not an obstacle per-se, the current implementation of redirection by many UK banks today contain what we consider as obstacles.
Non-definitive list of obstacles:
* Significantly divergent from the OBIE consent guidelines.
** Difficult for the PSU:
** Too many steps.
** Too many pages (the guidelines have 3 pages).
** Too many mouse clicks (the guidelines have 7 clicks).
** Too many fields to be entered (the guidelines have 3 fields).
** Require new tabs to be opened or take the PSU out of the window. (e.g. as not required by current online banking).
** Asking for the same information twice.
** Asking for superfluous information (e.g. asking for a PIN, when a PIN is not needed).
** Requiring a device that they not have to hand (e.g. Pinsentry, though if this is currently required for online banking, it would be an exception).
** Long pages with many unrelated steps.
** Opening a new window.
** Requiring the user to login many times, where previously the user only had to login once, e.g. to make multiple payments.
** Do all consents return the user reliably to the application redirect endpoint?
* Performance:
** Takes too long
** Slow to load pages.
** Buggy pages, or random crashing.
** Low service availability.
* Style and content:
** Branded differently to the bank’s website (i.e. confuse the customer).
** No clear signage to how to sign-up for online banking.
** Use of language creating a level of fear, uncertainty, and doubt when consenting to share their data with TPPs
** Use of too long and too legalize consent language that frustrates customer consenting to share data; frustrates customers, especially those using mobile devices.
** Incorrect instructions.
** Unnecessary interstitial pages or distractions around login controls (e.g. for advertising for other products or messaging around features).
** Subject to passing the above criteria, an ASPSP who has implemented a consent flow consistent with the OBIE consent guidelines can expect to be considered obstacle-free.
One straightforward KPI for the effectiveness of the consent flow is the percentage of PSUs that successfully complete it. For screen-scraping the figure is around 65%. An ASPSP could demonstrate they meet this requirement by publishing this KPI and its difference to screen scraping being statistically insignificant.
Question 5: Do you agree with the EBA’s assessments for design and testing, the options it considered and progressed or discarded, and the requirements proposed Guideline 6? If not, please provide your reasoning.
No. The definition omits critical elements:(a) To be able to test a set of use cases, the ASPSP must provide the TPPs with test accounts within their test facility that are representative on those like to be found in production.
(b) To point 52. On top of “connection and functional” testing, there is a use case for testing to discover and understand the APIs and any consent flow required.