Dashboards

Dashboards Overview

This version is:

Published 1 year ago 16 Mar 2023

One of the primary objectives of the Customer Experience Guidelines is to provide simplification and consistency across all Open Banking implementations. As such, we have defined a core set of principles for dashboards that can and should be used, subject to the brand considerations of TPPs and ASPSPs.

Other pages in this section

Dashboards are a common tool used in many industries to enable customers to manage their connections with service providers. From Facebook and Google to health providers and utility companies, various industries are leveraging dashboard functionality to provide customers with more control of their data and experience. 

As the data economy continues to expand, dashboards are set to become a prominent feature within the digital landscape, offering customers a range of capabilities from managing their personal data and cookies to cancelling subscriptions for services they no longer need.  

Consent and Access Dashboards were introduced to the Open Banking Standards to ensure customers were able to view and manage (i.e. cancel/revoke if desired) TPP consents and ASPSP access arrangements. 

Consent Dashboard – TPP facility to enable a PSU to view and revoke consents given to that TPP to access account information from their ASPSPs’ payment account(s), make payments from their ASPSPs’ payment account(s) and/or request confirmation of funds checks. 

Access Dashboard– ASPSP facility to enable a PSU to view TPPs that have access to their payment account(s) and revoke access if desired. 

Extensive consumer research has repeatedly and definitively shown their importance in reassuring customers that they have complete control of their Open Banking-enabled services. Research from Ipsos MORI concluded that “[w]ell designed and readily accessible dashboards are essential for building confidence around Open Banking.” 

An effective dashboard provides a PSU with an overview of these arrangements, clearly shows them what has been agreed to, and provides them with the means to cancel or revoke such arrangements. 

Principles behind an effective dashboard

While the exact look and feel of Consent and Access dashboards is left to the discretion of TPPs and ASPSPs, there are design considerations that we strongly encourage all participants to consider:  

Principle 1: Easy to find and locate
  • Designed and tested with the direct involvement of real customers 
  • Available on all relevant channels 
  • Named appropriately, ideally using the agreed open banking terminology of “open banking connections” for the dashboard space, “open banking connected services” for an access (ASPSP) dashboard and “open banking connected accounts” for a consent (TPP) dashboard 
Principle 2: Intuitive to use and understand
  • Include clear and simple status messages and dates 
  • Ability to easily cancel or revoke live connections 
  • Provide relevant additional detail as optional view beneath the summary 
Principle 3: Transparent as possible
  • Include a history of expired or revoked connections 
  • Include all relevant parties on the dashboard, extending to agents, TPNPAs and other fourth parties, where relevant 

To support the above, we have also provided guidelines for intelligent PSU Notifications that we strongly encourage participants to consider. 

The rest of this section provides details on various aspects relating to dashboards: 

Naming of the Consent and Access Dashboards 

Following extensive research and discussions with the ecosystem, the following names for Dashboards have been agreed upon:

Open banking connections or Connections

Where the entity is acting solely as a TPP or an ASPSP, but not as both, the preferred term to describe the Dashboard is ‘Open Banking Connections’. This is a term that avoids jargon and should improve familiarity with the concept of open banking and associated services. It was understood that the term “connections” is considered a useful catch-all term that is not off-putting to real customers and provides an accurate description of the link between TPPs and ASPSPs that can be managed through Consent and Access Dashboards.

Note: If your dashboard includes non-open banking connections, it is acceptable to refer to the dashboard as “Connections” or “Connected Services”. If you have opted to split your payments and data access dashboards, you can change the naming to differentiate between the data and payments access dashboard, for example, Open Banking connected accounts and Open Banking Payments.

Open banking connected accounts

Where the entity wants to clearly distinguish that it is presenting a TPP Consent Dashboard (for example because they also act as an ASPSP), the preferred term is ‘Open Banking Connected Accounts’. This is the term for TPPs to label their Consent Dashboards because they are providing a tool for customers to manage the payment accounts they have given the TPP their consent to access for the purpose of AIS, PIS (for Variable Recurring Payments) and/or CBPII Confirmation of Funds checks.

Open banking connected services

Where the entity wants to clearly distinguish that it is presenting an ASPSP Access Dashboard (for example because they also act as a TPP), the preferred term is ‘Open Banking Connected Services’. This is the term for ASPSPs to label their Access Dashboards because they are providing a tool for customers to manage the TPP services they have given their consent to for the purpose of AIS, PIS (for Variable Recurring Payments) and/or CBPII Confirmation of Funds checks.

We show below how we recommend an organisation should name the respective Dashboards where they operate as both a TPP and as an ASPSP. Having navigated to “open banking connections” in the top menu, the PSU would click “open banking connected accounts” to see their Consent Dashboard, and “open banking connected services” to see their Access Dashboard:

Figure 1: Naming of Consent and Access Dashboards

We recognise that many providers in the market will fulfil multiple functions and this will have implications for their Dashboards. For example, there are a number of providers who operate as both ASPSPs and TPPs who will need to provide both an Access and a Consent Dashboard.

There will also be examples of TPPs who obtain both long-lived PISP and AISP consent and ASPSPs will need to be able to support AIS, PIS and CBPII through their Access Dashboard.

Figure 1 shows guidelines for entities that are both an ASPSP and TPP, but for the remainder of this section, we have shown single-use Dashboards only (i.e. AIS on its own, PIS on its own and CBPII on its own).

Providers who are acting in multiple capacities must ensure that their Dashboards remain clear and transparent for PSUs, both at an individual level and when combined with other Dashboards. Providers must consider how PSUs will navigate between different Dashboards and ensure that this is not confusing. We provide some guidelines on multiple product offerings in the section Showing AIS, PIS-VRP and CBPII through one Dashboard.

Showing AIS, PIS-VRP and CBPII through one Dashboard

It will often be necessary for an ASPSP to provide Dashboards that show AIS, PIS-VRP and CBPII; similarly, TPPs may offer two or three of AIS, PIS-VRP and CBPII to their customers and will need to be able to handle this. We show below a potential way for this to be managed through tabs and descriptions but leave it to participants to work out the exact UX they wish to implement.

Figure 2: Consent Dashboards that handle AIS (Data), PIS-VRP (Payments) and CBPII (Funds check)

Figure 3: Access Dashboards that handle AIS (Data), VRP (Payments) and CBPII (Funds check)


We note that for many VRP use cases the payment permissions may also have an associated AIS access and that if a PSU revokes their access for the VRP payment permissions the TPP/ASPSP will need to consider how to best communicate that the AIS consent/access may still be active.