Dashboards

CBPII Consent Dashboard

This version is:

Published 3 years ago 21 Oct 2021

CBPIIs must provide PSUs with a Dashboard to view and revoke consents that they have given to that CBPII to perform a Confirmation of Funds check. PSUs may have consented to Confirmation of Funds (CoF) access to several accounts from one or more ASPSPs.

Other pages in this section

Overview

CBPIIs must provide PSUs with a Dashboard to view and revoke consents that they have given to that CBPII to perform a Confirmation of Funds check. PSUs may have consented to Confirmation of Funds (CoF) access to several accounts from one or more ASPSPs. This section describes:

Dashboards play an important role in clearly and transparently setting out what a PSU has provided consent for a CBPII to do on their behalf. They, therefore, play a role in multiple user journeys, including:

The CBPII Consent Dashboard should therefore be easy to find, and our research demonstrates that being able to find the Dashboard easily and making it easy to understand plays a key role in building trust with open banking-enabled services.

Principle 1: Easy to find and locate

The placement of the Dashboard within the CBPII 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 an example of a CBPII consent dashboard that is one-click from the home screen. Refer to AIS Consent Dashboard for zero-click (Figure 2) and two-click (Figure 4) options. Such an important tool should not be nested in menus further than that, though we do note that the channel being used and the offering of the CBPII may determine its positioning to some extent.

If it is nested, the name of where it is located is also important; generally, “settings” was considered to be the logical place as opposed to “account” when used on its own (see examples below). Wherever it is positioned, and whatever it is called, CBPIIs should design and build while testing with real customers.

Note

Please note that the wireframes have been created as if the time and date that the PSU is viewing their PIS-VRP accPlease note that the wireframes have been created as if the date that the PSU is viewing their CBPII consent dashboard is 30/07/2022. For clarity:

  • Consent was given by the PSU to the CBPII to make CoF requests from the PSU’s current account at ASPSP 1 on 17/04/2022. This consent has a 12-month duration and will expire on 16/04/2023, after which the CBPII would have to take the PSU through a new consent journey in order to continue to be able to make CoF requests from ASPSP 1.  The PSU can withdraw their consent at the CBPII or revokes access as ASPSP 1 prior to this date.will expire on 16/04/2023.

  • Consent was given by the PSU to Consent was given by the PSU to the CBPII to make CoF requests from the PSU’s current account at ASPSP 2 on 05/04/2022. This is ongoing permission without a set expiry date i.e. the CBPII will be able to continue to make CoF requests until the PSU withdraws their consent at the CBPII or revokes access as ASPSP 2.

Figure 1: CBPII Consent Dashboard – one-click from home page (desktop and app)

Main content image




An important aspect of ensuring it 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 ASPSP. The preferred name when acting solely as a CBPII is “open banking connections” and/or “open banking connected accounts.” If the provider is operating as both CBPII and ASPSP, 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 or tutorial of where and what the Dashboard is, and the role it plays, would be useful for new customers after they have signed up. While this is left to the discretion of participants, we have provided guidelines on PSU Notifications.

CEG Checklist Requirements u0026amp; CX Considerations

1

CBPIIs must provide PSUs with a facility to view and revoke consents that they have given to that CBPII. PSUs may have consented to CoF access to several accounts from one or more ASPSPs.

9b

2

Consent Dashboards must be easy and intuitive for PSUs to find and use. Careful consideration should be given to ensure that Dashboards are positioned logically and placed no more than two clicks from the CBPII’s Home Screen.

9b

3

CBPIIs 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.

CBPIIs must use the preferred term “open banking connections” and/or “open banking connected accounts” for a Consent Dashboard specifically.

9a

Principle 2: Intuitive to use and understand

Whilst the specific design of a Consent Dashboard sits in the competitive space, the Dashboard must provide PSUs with control by ensuring they are well informed and can easily manage the connections they have consent to.

Figure: 2 CBPII Consent Dashboard home page and information bubble

Figure: 3 CBPII Consent Dashboard detailed page 

CEG Checklist Requirements u0026amp; CX Considerations

To aid clarity whilst providing detailed information if the PSU needs it, a Consent Dashboard should provide an overview screen (Consent Dashboard Home Page) which lists high level information for all consents, and a detailed page for each consent (Consent Dashboard Detailed Page).

2

The customer-facing entity must provide PSUs with sufficient information to enable them to make an informed decision on the Consent Dashboard Home Page.

The CBPII Consent Dashboard must display all Confirmation of Funds access consents provided to the CBPII. Thus, for each PSU account, there must be a consent entry granting CoF access to the account for CoF purposes by the PSU.

As a minimum, CBPIIs must show on the Consent Dashboard Home Page:

  • ASPSP Name (or nickname if used)
  • Account type (if provided)
  • ASPSP Sort Code and Account Number
  • Start date i.e., date consent was first granted
  • End date or where relevant the ongoing nature of the consent

The CBPII must also provide a manage button that allows the PSU to revoke consents for each specific ASPSP account.

9d

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

For each ASPSP account granted CoF access, CBPIIs should display the PSU payment account identification (such as account name, sort code and account number) and expiration date and time.

Note: PSU account number should be masked.

The CBPII should also provide a history of all confirmation of funds checks.

Note: Refer to CoF History section below for details

6

CBPIIs must differentiate between current and historical consents. Consent is defined as active if it has a valid access token that has not expired, and the consent expiry date has not elapsed. This could just be displayed by showing active consents under “Current” and any expired or revoked ones under “History.”

CBPIIs must be mindful that a PSU could have revoked access at the ASPSP.

CBPIIs must not show different status messages at their Consent Dashboard to those that a PSU would see at their ASPSP Access Dashboard. There are a variety of methods that a CBPII can use to check that their access token is still valid. See this page for further details.

9d

CBPIIs should provide the ability for a PSU to edit the ASPSP Name so that it can be replaced with a ‘nickname’ (such as “Household Account” or “Holiday Savings Pot”) to help PSUs identify their accounts easily.

CBPIIs should provide additional explanatory text to help PSUs understand complex areas such as the expiry date or the ongoing nature of the consent and how to cancel it. Using information bubbles helps to keep information manageable. In the example provided we use the language “ongoing” but CBPIIs can decide how best to explain this point.

9

CBPIIs must make available a list of consents that have been cancelled or expired (NB: this refers to the expiry of the consent, not access) so that the PSU has a record of old consents.

9e

10

CBPIIs must provide a Consent Dashboard, Detailed Page, for each Consent, which includes:

  • ASPSP Name (or nickname if used)
  • Account type (e.g., current account)
  • Sort Code and Account Number (or other product identifier depending on the account type e.g., PAN for credit cards)
  • The date the consent was granted
  • The expiry date of the consent
  • The purpose for which the data will be used

CBPIIs may include the following at their discretion:

  • Details about the purpose for which the funds check is used (including whether any other parties will have access to the information)
  • Clear and reassuring messages about what information is made available from the ASPSP
  • The date and time of the last occasion when a CoF check was requested – this should also be available as a historical list of all past fund checks.

9d

 

Revocation Journey

 

Figure 4: CBPII Consent Dashboard revocation user journey

 

One of the most important user journeys is to use the Consent Dashboard to cancel a long-lived consent. This guidance sets out how CBPIIs should make this user journey clear and straightforward for users to build trust and confidence.

Wireframes

 

Figure 5: CBPII Consent Dashboard revocation journey

This content is best viewed on a desktop browser.

1

CEG Checklist Requirements 1
The Consent Dashboard must allow a PSU to cancel the access they have consented to easily and without obstruction or excessive barriers.

3

CEG Checklist Requirements 3
Cancellation Request

rnrnCBPIIs must allow PSUs to confirm that they want to cancel CoF consent of their account to the CBPII.rnrnCBPIIs should inform PSUs that once CoF consent is revoked, the CBPII will no longer be able to check the availability of funds in their account.rnrnCBPIIs should give equal prominence to the choices of continuing or cancelling the CBPII CoF consent.

CEG Checklist Requirements u0026amp; CX Considerations

1

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

9c

 The CBPII should make the exact consequences of cancelling the consent clear to the PSU – i.e., they will no longer be able to provide the specific service to the PSU.

The CBPII should make the implications of cancelling clear to the PSU and make sure they want to proceed.

A confirmation screen should be provided after this to confirm.

3

Cancellation Request

CBPIIs must allow PSUs to confirm that they want to cancel CoF consent of their account to the CBPII.

CBPIIs should inform PSUs that once CoF consent is revoked, the CBPII will no longer be able to check the availability of funds in their account.

CBPIIs should give equal prominence to the choices of continuing or cancelling the CBPII CoF consent.

9c

4

CBPIIs must inform the ASPSP that the PSU has withdrawn consent by making a call to the DELETE API endpoint as soon as practically possible (as described in Version 3 of the API specifications). This will ensure that no further CoF responses will be provided by the ASPSP.

ASPSPs must support the Delete process as described in the Version 3 API specifications. This activity is not visible to PSUs as it takes place in the background, however, it will ensure no further CoF responses are provided by ASPSPs to CBPIIs.

9c

CBPII Confirmation

CBPIIs should confirm to PSUs that CoF consent to their account has been cancelled.

ASPSPs should inform the PSU that no further CoF responses will be provided by the ASPSP to the CBPII.

After the Delete endpoint is called by the CBPII to remove the resource, ASPSPs should inform the PSU via their own channels (for example via SMS or via a notification on their mobile phone) that the CBPII will no longer be able to perform CoF calls and the ASPSP will not provide any further responses. This is an additional confirmation to the PSU that the CBPII has completed the delete endpoint process correctly.

u0026nbsp;

Principle 3: Be as transparent as possible

While it is important not to overwhelm PSUs with information, the Consent Dashboard plays a unique role in providing the PSU with the details about their arrangements and CBPIIs should try to be as transparent as possible about what has or is still occurring, and, where applicable, what other party or parties are involved.

Consent History

Where the PSU has cancelled the permission, or the consent has expired, the CBPII should provide a list of these previous connections as shown below. If the CBPII does not provide an archive on the Dashboard it must nevertheless be available on request.

Figure 6: CBPII Consent Dashboard history example

CEG Checklist Requirements u0026amp; CX Considerations

1

CBPIIs must make available a list of consents that have been cancelled or expired (NB: this refers to the expiry of the consent, not access) so that the PSU has a record of old consents.

9e

2

CBPIIs must make all the details of the consent available:

  • Consent granted
  • Consent expired/cancelled date
  • Consent from account
  • Consent status (Expired/Cancelled)

9d

CoF History

Additionally, the CBPII should provide a history of all funds checks that have been performed to date for current permissions (i.e.those that are still active with a valid consent) or a record of all requests that were performed for a historical consent. This is shown below:

Figure 7: CBPII Consent Dashboard funds check history example

CEG Checklist Requirements u0026amp; CX Considerations
CBPIIs should make available a list of the CoF checks associated with each consent on the fund check history page.

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

 

Click for customer research