Dashboards

AIS Access Dashboard

This version is:

Published 3 years ago 21 Oct 2021

ASPSPs must provide PSUs with a facility to view and revoke ongoing access that they have given to any AISP for each account held at that ASPSP. The PSU may have consented to share data from several accounts with a single AISP.

Other pages in this section

Overview

ASPSPs must provide PSUs with a facility to view and revoke ongoing access that they have given to any AISP for each account held at that ASPSP. The PSU may have consented to share data from several accounts with a single AISP. This section describes:

Dashboards play an important role in clearly and transparently set out the data, to which a PSU has provided their consent to an AISP to access at their ASPSP. They, therefore, play a role in multiple user journeys, including:

Our research demonstrates that being able to find the ASPSP access Dashboard easily and making it easy to understand plays a key role in building trust with Open Banking-enabled services.

Note

Please note that the wireframes have been created as if the time and date that the PSU is viewing their AIS access dashboard is 18/01/2022 shortly after 11:43 am. For clarity: 

  • The PSU authenticated with their ASPSP and granted AIS 1 access to their current account on 17/01/2022 and this connection is currently active i.e. within 90 days / not requiring a refresh. The PSU will need to refresh access by 17/04/2022.

  • The PSU authenticated with their ASPSP and granted AISP 2 access The AISP last requested data from the ASPSP at 11:43 am and hence the last connection is shown as 18/01/2022 at 11:43
  • The PSU authenticated with their ASPSP and granted AIS 2 access to their current account on 16/10/2021 and therefore access expired on 14/01/2022. The access needs to be refreshed by the PSU in order for the AISP to retrieve up to date information from ASPSP 2.

Principle 1: Easy to find and locate

The placement of the Access Dashboard within the ASPSP domain is important. Research shows a direct correlation between the number of clicks from the home page and the ease with which PSUs can find their Dashboard.

We have provided examples of zero, one and two clicks from the home screen; such an important tool should not be nested in menus further than that, though we do note that for an ASPSP there are many more services that need to be offered through their website or app than for an AISP and therefore the two-click option is most likely. In the zero-click example, an overview of the connected accounts is provided on the home page but there is also a separate “Open Banking connections” space for the customer that would provide more detail and the functionality to manage the access arrangements in place.

It is therefore not expected that an ASPSP will give it as much prominence as an AISP, but it should still be easy to find and locate. If it is nested, the name of where it is located is important. Several examples in the market today place it under “profile” which did not test well. Generally, the term “settings” was considered to be the logical place for it. Wherever it is positioned, and whatever it is called, ASPSPs should design and build while testing with real customers.

AIS Access Dashboard Examples

An important aspect of ensuring that the Dashboard is easy to find and locate is the naming of the Dashboard itself within navigation menus. The name of the Dashboard should use terms familiar to PSUs and avoid technical jargon such as consent, permission and AISP. The preferred name when acting solely as an AISP is “open banking connections” and/or “open banking connected services.” If the provider is operating as both ASPSP and AISP, they should clearly distinguish the Consent Dashboard from the Access Dashboard; the former should be named “Open Banking connected accounts” and the latter should be “open banking connected services.”

Finally, the placement of the Dashboard may be irrelevant if PSUs are not aware of its existence or the functionality it provides. An explanation of where and what the Dashboard is, and the role it plays, would be a useful tutorial for new customers after they have signed up. While this is left to the discretion of participants, we have provided guidelines on PSU Notifications for reference.

Figure 1: ASPSP Access Dashboard for AIS – zero-clicks from home page (desktop

Figure 2: ASPSP Access Dashboard for AIS – one-click from home page (desktop)

Figure 3: ASPSP Access Dashboard for AIS – two clicks from home page (desktop)

 

CEG Checklist Requirements & CX Considerations

1

ASPSPs must make available on all digital channels an Access Dashboard, with the same name across channels, which allows PSUs to view access that has been previously granted and it must be easy and intuitive for PSUs to find and use. Careful consideration should be given to ensure that Dashboards are positioned logically and ideally placed no more than two clicks from the ASPSP’s Home Screen.

10b

2

ASPSPS must use the preferred term “open banking connections” and/or “open banking connected services” for an Access Dashboard specifically.

ASPSPs must carefully consider the naming of their Dashboard to aid PSU understanding and ability to find its location. Our research found that names such as “Permissions”, “Accounts”, “Logins” were not clear, and many consumers didn’t understand what they meant.

10a

 

Principle 2: Intuitive to use and understand

Whilst the specific design of an Access Dashboard sits in the competitive space, the Dashboard must give PSU control by ensuring they are well informed and can easily manage the connection.

 

Figure 4: ASPSP Access Dashboard for AIS home page

Figure 5: ASPSP Access Dashboard for AIS detailed page 

Figure 6: ASPSP Access Dashboard for AIS detailed page expanded
 

CEG Checklist Requirements & CX Considerations

1

To aid clarity whilst providing detailed information if the PSU needs it, and Access Dashboard should provide an overview screen (Access Dashboard Home Page) which lists high-level information for all AISP access arrangements, and a detailed page for a more detailed view of each access (Access Dashboard Detailed Page).

2

ASPSPs must display the AISP’s trading name/brand name (i.e., the Client Name in the software statement) to the PSU during authentication screens and on any Access Dashboards. They do not need to display the registered company name of the AISP even if it is different.

3

The ASPSP must provide PSUs with sufficient information to enable them to make an informed decision on the Access Dashboard Home Page. As a minimum, ASPSPs must show on the Access Dashboard Home Page:

  • AISPs’ trading name/brand name
  • Account type
  • The expiry date of each access. (Note: Some PSUs find an access countdown helpful, but most found an expiry date clearer. ASPSPs may choose to provide a countdown but it should be used in addition to an expiry date not instead of it.)
  • A status flag which is either “Active” or “Refresh” (see #5 below on status messages; where access needs refreshing, this should be highlighted through e.g. red text or a warning message)

The ASPSP should display the date and time when account data was last accessed by the AISP

The ASPSP must provide a button that allows the PSU to revoke ongoing access arrangements. The ASPSP should provide a button that allows the PSU to refresh any access arrangements that require a refresh.

10d

4

ASPSP should offer functionality (e.g. search, sort, filter) to enable a PSU to search for the relevant access. This will be of particular benefit as the number of consents for different ASPSPs/ accounts given by a PSU to AISPs increases.

5

ASPSPs must use just two status flags: “Active” or “Refresh”. A consent is defined as active if it has a valid access token that has not expired due to 90 days and the consent expiry date has not elapsed.

10d

6

ASPSPs should provide additional explanatory text to help PSUs understand 90-day refresh and how to revoke access; using information bubbles helps to keep information manageable.

7

ASPSPs must provide a history of old connections. This should include any access which has previously been revoked at the ASPSP, consent which has been revoked at the AISP, and consent which has expired. This gives the  PSU a record of old accesses and consents. Where the connection has not been refreshed for more than 90 days, and therefore access is blocked but can be refreshed as the consent remains valid, this should not be placed in the history, but listed on the Access Dashboard homepage with a “Refresh” status.

10e

8

ASPSPs must provide a Detailed Page for each access, which includes:

  • AISP Trading Name
  • Account type (e.g. current account) of accounts being shared with TPP
  • Sort Code and Account Number (or other product identifier depending on the account type e.g. PAN for credit cards)
  • Data clusters being accessed: using the structure and language recommended by OBIE following customer research (see Data Cluster Structure & Language)
  • The date the AISP was first granted access
  • The expiry date of the access (the same as shown on the Dashboard Homepage)
  • The expiry of the consent (in situations where the consent is not aligned to access duration and is not indefinite, for example where consent is for a fixed period such as 1 year)

ASPSPs may also provide detail about:

  • Where the request is for multiple product types, the detail should explain to the customer the product type to which it applies or state that it is shared across multiple product types
  • The date when the customer last refreshed their access as part of the 90 day re-authentication.
  • Which party provided the AISP access, in the case of joint/ multiple account holders

10d 13a

 

Revocation Journey

 

Figure 7: ASPSP Access Dashboard revocation user journey for AIS

 

 

The ability to revoke AISP access to connected accounts is one of the primary roles of the Access Dashboard.

 

Figure 8: ASPSP access revocation journey for AIS

This content is best viewed on a desktop browser.

1

CEG Checklist Requirements 1
The ASPSP must provide a manage button that takes the PSU to the detailed view where they are able to revoke access.

2

CEG Checklist Requirements 2
ASPSPs should make the status of TPP access clear using “Active” or “Refresh” and either emboldened words or other design options like colouring as shown in the wireframe.

3

CEG Checklist Requirements 3
The Access Dashboard must allow a PSU to revoke the access they have consented to easily and without obstruction or excessive barriers.

4

CEG Checklist Requirements 4
ASPSPs ASPSPs must advise PSUs that they should contact the associated AISP to inform them of the cancellation of access and/or understand the consequences of revoking access.

CEG Checklist Requirements & CX Considerations

1

The ASPSP must provide a manage button that takes the PSU to the detailed view where they are able to revoke access.

10c

2

ASPSPs should make the status of TPP access clear using “Active” or “Refresh” and either emboldened words or other design options like colouring as shown in the wireframe.

3

The Access Dashboard must allow a PSU to revoke the access they have consented to easily and without obstruction or excessive barriers.

10c

4

ASPSPs must advise PSUs that they should contact the associated AISP to inform them of the cancellation of access and/or understand the consequences of revoking access.

10f

Refreshing access 

While it is not a requirement, ASPSPs could offer functionality to refresh access directly through the Access Dashboard. Moreover, ASPSPs could allow multiple TPP access arrangements to be refreshed at once, thus synchronising them all on a 90-day cycle so the PSU is less likely to allow one or more to pass 90 days.

Figure 9: Refreshing access triggered by a customer alert

 

This functionality could be combined with intelligent notification about upcoming or already-past expiry of access at 90 days. Please refer to the PSU Notifications section for more information.

Note: There is a complication if one or more TPPs with active consent have less than 90 days of consent (not access) remaining. In instances where PSU have less than 90 days of consent left, it is advised that ASPSPs do not allow the PSU to refresh access, however, it is possible that an ASPSP would choose to allow refresh of access for the remaining period i.e. until the consent expires.

Principle 3: Be as transparent as possible

ASPSPs should provide PSUs with as much relevant information as possible.

History example

Where the PSU has revoked access, or the consent has expired or been cancelled at the TPP, the ASPSP should archive these connections as shown below. The ASPSP could choose to make clear whether the reason is revocation of consent or expiry of access; otherwise, the information provided should match what is provided for active connections.

Figure 10: ASPSP Access Dashboard for AIS history example

CEG Checklist Requirements & CX Considerations

1

ASPSPs must make all the historic AIS accesses (cancelled or expired) available to the PSU with details of consent parameters

Note: The duration of how long this is available on the Dashboard is in the competitive space of the ASPSP.

10e

2

ASPSPs must make available all the details of the consent

  • Consent granted
  • Consent expired/cancelled date
  • Ability to expand consent parameters
  • Ability to expand consent from an account and to account details
  • Consent status (Expired/Cancelled)

10e

Access Dashboards when the AISP is using an Agent

If there is an Agent acting on behalf of the AISP, ASPSPs must also display the Agent company name (as captured in the ‘On behalf of’ field of the software statement) to the PSU. We note that ASPSPs can only show the Agency/On Behalf field in cases where this information has been provided by AISP.

Figure 11: ASPSP Access Dashboard for AIS when AISP is using an agent

CEG Checklist Requirements & CX Considerations

1

ASPSPs must display the agent name (‘on behalf of’ in the software statement) along with the AISP trading name (‘client name’ in software statement) on the access dashboard.

We note that ASPSPs can only show the agent name/On Behalf of field when this information has been provided by AISP

Examples

TPP Trading Name (Client Name in Software Statement)Registered Legal Entity Name (Company Name/ Organisation Name)‘On Behalf of’ Name (‘On Behalf of’ field in Software Statement)
What to display
ABC TradesABC Company LtdABC Trades
ABC Company LtdABC Company LtdABC Company Ltd
ABC Company LtdABC Company LtdOBO LtdOBO Ltd on behalf of ABC Company Ltd
ABC TradesABC Company LtdOBO LtdOBO Ltd on behalf of ABC Trades
[TPP Trading Name][TPP Company registered Name][Agent Trading Name][Agent Trading Name] on behalf of [TPP Trading Name]
Note: 'On behalf of' field should be the customer facing entity name if it is different from the TPP Trading name

What the research says

“In addition, consumer research has shown that respondents prefer confirmation of a revocation in writing via email in addition to text on the website.”  

Click for customer research