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?
** 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.
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.
If an ASPSP has obstacles within their consent flow, then it is not likely they could be available for wide usage.
Yes. ASPSPs should remediate any errors, obstacles, bugs identified in questions 1 through 5 by 14 March 2019?