Dashboards

PIS VRP Access Dashboard

This version is:

Published 3 years ago 21 Oct 2021

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

Other pages in this section

Overview

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

Dashboards play an important role in clearly and transparently setting out what accounts the PSU has given permission to make payment on their behalf and what are the associated payment rules provided to a PISP. They, therefore, play a role in multiple user journeys, including:

The ASPSP Access 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 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 an example of a PIS-VRP Access Dashboard that is one-click from the home screen but please refer to the AIS section for examples of zero and two clicks; 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 a PISP and therefore the two-click option is most likely. In the zero-click example, an overview of the connected services 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 a PISP, 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, “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.

Note

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

  • The PSU authenticated with their ASPSP and granted PISP 1 access to initiate VRP payments from the PSU’s current account on 17/04/2022. This permission has a 12-month duration and will expire on 16/04/2023.

  • Consent was given by the PSU to The PSU authenticated with their ASPSP and granted PISP 2 access to initiate VRP payments from the PSU’s current account on 17/04/2022. This is ongoing permission without a set expiry date i.e. the ASPSP will need to initiate VRP payments until the PSU withdraws their consent at the PISP or revokes access at their ASPSP.

Figure 1: ASPSP Access Dashboard for PIS-VRP – one-click from home page (desktop)

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 PISP. The preferred name when acting solely as a PISP is “open banking connections” and/or “open banking connected services.” If the provider is operating as both ASPSP and PISP, 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.

CEG Checklist Requirements & CX Considerations

1

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

2

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

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 2: ASPSP Access Dashboard for PIS-VRP home page

Figure 3: ASPSP Access Dashboard for PIS-VRP detailed page expanded

CEG Checklist Requirements & CX Considerations

1

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

2

ASPSPs must display the PISP’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 PISP even if it is different.

*- For more details refer to section – Access Dashboards when the customer-facing service provider and the PISP are different entities

3

ASPSPs must make available on all digital channels a PIS-VRP Access Dashboard which allows PSUs to view VRP access that has been previously granted and it must be easy and intuitive for PSUs to find and use.

The ASPSP must provide PSUs with sufficient information to enable them to make an informed decision on the VRP Access Dashboard Home Page.

As a minimum, ASPSPs must show on the VRP Access Dashboard Home Page:

  • PISP Trading Name*
  • Account type (if provided)
  • ASPSP Sort Code and Account Number
  • Start date i.e., date VRP access was first granted
  • End date or where relevant the ongoing nature of the VRP access

The ASPSP must also provide a manage button that allows the PSU to revoke access for each specific PISP.

*- For more details refer to section – Access Dashboards when the customer-facing service provider and the PISP are different entities

10b 10d

4

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

5

ASPSPs must use just three status flags “Active” or “Cancelled” or “Expired”. Consent is defined as active if it has a valid access token that has not expired, and the consent expiry date has not elapsed.

ASPSPs should make the status of PISP VRP access clear by either emboldened words or other design options like colouring as shown in the wireframe.  

10d

6

ASPSPs should provide additional explanatory text to help PSUs understand how to revoke VRP access; using information bubbles helps to keep information manageable.

7

ASPSPs must provide a history of old connections. This should include VRP access that has been cancelled (revoked) at the ASPSP, consent that has been cancelled (revoked) at the PISP and consent that has expired. This gives the PSU a record of old VRP accesses.

10e

8

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

  • PISP Trading Name
  • PSU’s payment account details
    • Account type (e.g., current account)
    • Sort Code and Account Number
  • Start date i.e., date VRP access was first granted
  • End date or where relevant the ongoing nature of the VRP access
  • List of all Consent parameters (payment rules) associated with each VRP consent

Note: Each VRP access may have a different set of consent parameters associated depending on the PISP proposition.

10d 19a


Revocation Journey

Figure 4: ASPSP Access Dashboard revocation user journey for PIS-VRP

The ability to revoke PISP permissions to make payments via connected accounts is one of the primary roles of the Access Dashboard.

Figure 5: ASPSP Access Dashboard revocation journey for PIS-VRP

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 VRP access.

2

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

3

CEG Checklist Requirements 3
ASPSP must make sure the PSU can see the cancelled (revoked) VRP access under historic consents (refer to section Access History example) where the status of the VRP access is “Cancelled”.rnrn ASPSPs must advise PSUs that they should contact the associated PISP to inform them of the cancellation of variable recurring payment access and/or understand the consequences of doing so.

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 VRP access.

10c

2

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

10c

3

ASPSP must make sure the PSU can see the cancelled (revoked) VRP access under historic consents (refer to section Access History example) where the status of the VRP access is “Cancelled”.

 ASPSPs must advise PSUs that they should contact the associated PISP to inform them of the cancellation of variable recurring payment access and/or understand the consequences of doing so.

10f

Principle 3: Be as transparent as possible

ASPSPs should provide PSUs with as much relevant information as possible, including both a history of previous connections and a history of payments made.

Access History 

Where the PSU has cancelled (revoked) access or the consent has expired or been cancelled at the PISP, the ASPSP should make this information available to the PSU as historic connections under a separate tab.  The ASPSP should make clear whether the reason is cancelling of connection or expired.  For reference see the AIS history example or PIS-VRP Consent Dashboard example.

Figure 6: PIS-VRP Access Dashboard history example

CEG Checklist Requirements & CX Considerations

1

ASPSPs must make all the historic VRP 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)

10d

Payment History

One important aspect of the detailed VRP Access Dashboard is the payment history for both active and expired consents, so the PSU has a record of all transactions made related to a specific consent.

Figure 7: PIS-VRP Access Dashboard payment history

CEG Checklist Requirements & CX Considerations

1

ASPSPs should make available a list of payments associated with each VRP consent on the payment history page for all the active VRP consents

2

ASPSPs should show a list of payments associated with each cancelled/expired VRP consent on the payment history page or at least the total amount of payment made against each VRP consent.

Access Dashboards when the customer-facing service provider and the PISP are different entities

If there is a customer-facing service provider (e.g., Merchant or Sweeping service provider) who is not a PISP but has a commercial relationship with a PISP, the PISP must ensure the software statement reflects this information correctly so that it can be displayed accurately to the PSU on the ASPSP Dashboard.

For more details please refer to the PIS-VRP Consent Dashboard section Dashboards when the customer-facing service provider and the PISP are different entities

Refer to the Examples section below to see how the names should be displayed.

Figure 8: ASPSP Access Dashboard for PIS-VRP when PIS is using a customer-facing service provider

CEG Checklist Requirements & CX Considerations

1

ASPSPs must display the customer-facing service provider name (the ‘on behalf of’ field in the software statement) along with the PISP trading name (‘client name’ field in the software statement) on the access dashboard.

We note that ASPSPs can only show the customer-facing service provider/On Behalf field in cases where this information has been provided by PISP.

Examples

 

PISP Trading Name
(Client Name in Software Statement)		Registered Legal Entity Name (Company Name/ Organisation Name)Customer-facing entity 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 LtdABC Company Ltd via OBO Ltd
[PISP Trading Name][PISP Company name][Merchant Trading name][PISP Trading Name] via [Merchant 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