Customer Experience Guidelines

Account Information Services

This version is:

Published 3 years ago 31 Mar 2021

One of the primary ambitions of these guidelines is to provide simplification and consistency throughout each stage of the Open Banking implementation. As such, we have defined a core set of AIS journeys to illustrate the roles played by each of the Participants in the Open Banking ecosystem.

Other pages in this section

AIS Core Journeys

The Open Banking Read/Write API specifications support Account Information Services (AIS). They enable an Account Information Service Provider (AISP) to access account information from online payment accounts held at Account Service Payment Service Providers (ASPSPs), in order to provide account information services to a Payment Service User (PSU), provided they have obtained the PSU’s explicit consent.

This section describes the core journeys that support the set-up and management of AIS. The key components are:

  • Account Information Consent – PSU giving consent to an AISP to request account information from their ASPSP
  • Refreshing AISP Access – PSU authenticating at their ASPSP to refresh on-going access they previously given consented to
  • Consent Dashboard and Revocation – AISP facility to enable a PSU to view and revoke consents given to that AISP
  • Access Dashboard and Revocation – ASPSP facility to enable a PSU to view all AISPs that have access to their account(s) and the ability to revoke that access. This must be available on all channels that a PSU could access via the ASPSP directly and be easy and intuitive for PSUs to find and use. This facility should not include unnecessary steps, superfluous information or language which could discourage the use of TPP services or divert the PSU from the access management process.
  • Generic guidance around the effective use of re-direction screens (when the PSU is transferred to and from the ASPSP domain) is included in section Effective use of redirection screens.
  • Access Status Notifications by ASPSPs – Notifications by ASPSPs to inform AISPs about access revocation and other access status changes related to the PSUs account(s).
  • AIS Access for PSUs from Corporate Entities – PSU acting with delegated user authority on behalf of a corporate entity, may only be able to use AISP services, if this is permitted within the parameters of that delegated user authority.

Note: This section does not include guidance around scenarios when more than one TPP is involved in the delivery of a service – sometimes referred to as “Onward Provisioning”. This subject will be addressed as part of the on-going OBIE evaluations of eIDAS and Consent/Access Dashboards.

Featured journeys

Account Information Consent

User Journey     In this journey the AISP presents to the PSU a description of the data that it requires in order to support its service proposition.PSU selects the ASPSP(s) where their payment account(s) is held. The PSU is then directed to the domain of its ASPSP for authentication and to select the account(s)…

This version was published 3 Years & 7 Months ago 31 Mar 2021

Refreshing AISP access

User Journey     The PSRs require strong customer authentication to be performed each time the PSU accesses its online payment account, either directly or using the services of an AISP. The frequency of authentication can be reduced if an ASPSP applies the exemption relevant to account information access (RTS, Article 10).  However, this will…

This version was published 3 Years & 7 Months ago 31 Mar 2021

Consent Dashboard & Revocation

User Journey   AISPs must provide PSUs with a facility to view and revoke on-going consents that they have given to that AISP. They may have consented to share data from several ASPSPs with a single AISP. This section describes how these consents should be displayed and how the customer journey to revoke them should…

This version was published 3 Years & 7 Months ago 31 Mar 2021

AIS Access Dashboard & Revocation

User Journey   ASPSPs must provide PSUs with a facility to view and revoke on-going access that they have given to any AISP for each account held at that ASPSP. This section describes how AISP’s access should be displayed and how the customer journey to revoke them should be constructed. Wireframes   Examples What the…

This version was published 3 Years & 7 Months ago 31 Mar 2021

Access Status Notifications by ASPSPs

In addition to the mandatory notifications between AISPs and ASPSPs (refer to section Mandatory notification mechanisms between AISPs and ASPSPs), OB Standards have been extended to provide additional notification mechanisms.

This version was published 3 Years & 7 Months ago 31 Mar 2021

AIS Access for PSUs from Corporate Entities

User Journey   PSUs, with delegated user authority on behalf of corporates who are authorised to receive corporate account information via AISPs, will be able to provide consent to the AISPs using the standard AIS journey shown in section Account Information Consent. In this journey the AISP presents to the PSU a description of the…

This version was published 3 Years & 7 Months ago 31 Mar 2021

90-Days Re-authentication

User Journey     The PSRs require Strong Customer Authentication (SCA) to be performed each time the PSU accesses its online payment account, either directly or using the services of an AISP. The frequency of authentication can be reduced if an ASPSP applies the exemption relevant to account information access (RTS, Article 10), however, this…

This version was published 3 Years & 7 Months ago 31 Mar 2021

Permissions & Data Clusters for AIS journeys

Permissions In the Open Banking API design, data elements are logically grouped together into “permissions”. It is at this level that AISPs request data access. If they request access to a specific permission they will have access to all the data elements in the permission. This provides a pragmatic approach, allowing AISPs to be selective…

This version was published 3 Years & 7 Months ago 31 Mar 2021