Dashboards

PIS VRP Consent Dashboard

This version is:

Published 1 year ago 16 Mar 2023

A PSU may setup VRPs from different ASPSPs with a single PISP. The PISP must provide the PSU a dashboard to view and revoke the consents they have given. Dashboards play an important role in managing the conditions of VRPs for which the PSU has provided consent.

Other pages in this section

 

Overview

PISPs must provide PSUs with a facility to view and revoke VRP consent(s) that they have given to that PISP. PSUs may have agreed to several VRP consents for different ASPSPs with a single PISP. This section describes:

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

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

In instances where the PSU is giving consent to a PISP via a third party because the PISP is not directly customer-facing, it should be easy to find the PISP Consent Dashboard.

The customer-facing service provider should make it clear that consent is given to the PISP.

Principle 1: Easy to find and locate

The placement of the Dashboard within the PISP 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 PISP consent dashboard that is zero-clicks from the home screen. Refer to AIS Consent Dashboard for one-click (Figure 2) and two-click (Figure 3) 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 PISP may determine its positioning to some extent. For PISPs offering a VRP service as their primary service, they may wish to show the parameters and an overview of their Consent Dashboard on the home page.

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, PISPs should design and build while testing with real customers.

In the following examples we have shown a PISP that is only providing the PSU with a VRP Dashboard; in the section Showing AIS, PIS-VRP and CBPII through one Dashboard we show how a PISP providing more than one service could build their Dashboard.

Note

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

  • The PSU authenticated with their ASPSP and granted AISP 1 access Consent was given by the PSU to the PISP to initiate VRP payments 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 PISP would have to take the PSU through a new consent journey in order to continue to be able to initiate payments from ASPSP 1.  The PSU can withdraw their consent at the PISP or revokes access as ASPSP 1 prior to this date.

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

Figure 1: PIS-VRP Consent Dashboard – zero-clicks 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 ASPSP. The preferred name when acting solely as a PISP for VRP is “open banking payments.” If the provider is operating as both PISP 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 PSUs after they have signed up. While this is left to the discretion of participants, we have provided guidelines under the PSU Notifications section.

CEG Checklist Requirements & CX Considerations

1

PISPs 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. PISPs must use the preferred term “Open Banking payments” and/or “Open Banking connected accounts” for a Consent Dashboard specifically.

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 PISP’s Home Screen.

In case of a customer-facing service provider that is different to the PISP, the customer-facing service provider must make the Dashboard available to the PSU or make a link available to the PSU that will redirect them to PISP Dashboard.

9a

2

PISPs or Customer facing service providers must provide PSUs with a facility to view and manage VRP consent(s) that they have given to that PISP. PSUs may have agreed to several VRP consents for different ASPSPs with a single PISP.

9b, 9c

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: PIS-VRP Consent Dashboard home page and information bubble

Figure 3: PIS-VRP Consent Dashboard detailed page and information bubble expanded

CEG Checklist Requirements & CX Considerations

To aid clarity whilst providing detailed information if the PSU needs it, a VRP Consent Dashboard should provide an overview screen (VRP Consent Dashboard Home Page) which lists high level information for all consents, and a detailed page for each consent (VRP 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. As a minimum, PISPs must show on the Consent Dashboard Home Page:

  • ASPSP Name (or nickname if used)
  • Account type (if provided)
  • Start date i.e., date consent was first granted
  • End date or where relevant then ongoing nature of the consent
  • Date Last Payment was made
  • Total paid till to date
  • A status flag which is “Active” (see below on status messages)
  • Warnings or alerts if the consent is close to expiry. The PISP can define how close to the expiry date it should start to alert the PSU depending on their business model.

The PISP must also provide a manage button that allows the PSU to revoke consent or make changes to existing consent parameters. Refer to section Making changes to VRP Consent for details.

9d

PISP 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 PISPs increases.

4

PISPs must use just three status flags: “Active” or “Expired” or “Cancelled”. Consent is defined as active if it has a valid access token that has not expired, or the consent expiry date has not elapsed. Cancelled when the PSU has revoked consent on the Consent Dashboard or revoked VRP access at the ASPSP.

 PISPs must be mindful that a PSU could have revoked VRP access at the ASPSP. PISPs 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 PISP can use to check that their access token is still valid. See this page for further details.

9d

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

PISPs should provide additional explanatory text to help PSUs understand how to cancel long-lived consent and an overview of the payment details. Using information bubbles helps to keep information manageable. In the example provided we use the language “payment details” but PISPs can decide how best to explain this point.

7

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

  • ASPSP Name (or nickname if used)
  • Account type (e.g., current account)
  • PSU’s paying from Sort Code and Account Number
  • The date the consent was granted
  • The date consent will expire
  • Payee details
  • Only the consent parameters that are agreed with the PSU for their proposition. Refer to VRP and Sweeping journeys in the CEG for example parameters.

PISPs should include the following at their discretion:

  • Last payment made date.
  • The total amount paid as of today.

9d

8

PISPs must make available a list of consents that have been cancelled or expired so that the PSU has a record of old consents. Where the connection has been cancelled (revoked) or expired should be placed in the history, with cancelled or expired status.

9e

Figure 4: PIS-VRP 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 PISPs providing VRP should make this user journey clear and straightforward for users to build trust and confidence.

Figure 5: PIS-VRP 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
The confirmation screen must confirm what happens to any existing data that the PISP holds. PISPs must ensure that they are fair and transparent about how existing data is processed and that data that is no longer required is deleted, where appropriate.

CEG Checklist Requirements & 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 PISP 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 PISP should only provide two screens prior to cancelling/revoking access, one setting out the implications of cancelling and the second ensuring that the user is sure they want to proceed. A confirmation screen should be provided after this to confirm.

3

The confirmation screen must confirm what happens to any existing data that the PISP holds. PISPs must ensure that they are fair and transparent about how existing data is processed and that data that is no longer required is deleted, where appropriate.

8g

4

PISPs must inform the ASPSP that the PSU has withdrawn consent by making a call to DELETE the domestic-vrp-consents resource as soon as practically possible (as described in the API specifications). This will ensure that no further payments will be made using the cancelled VRP Instruction.

ASPSPs must support the Delete process as described in the API specifications. (This is not visible to the PSU but will ensure no further payments are initiated by the PISP).

9c

ASPSPs should inform the PSU that no further payments will be initiated by the PISP as VRP consent has been revoked at the PISP.

After the Delete endpoint is called by the PISP to remove the domestic-vrp-consents resource, the ASPSPs are advised to inform the PSU via their own channels (for example via SMS or via a notification on their mobile phone) that PISP will no longer be able to make VRP payment(s) from their account.

Re-authentication of access

There may be instances where an ASPSP may require SCA, even if the payment is made is to a trusted beneficiary, for example, suspicion of fraud. However, the ASPSP must only do so in permitted circumstances with an objective approach and in line with the proportionality requirements of the PSRs.

This section describes the customer journey when a PSU needs to re-authenticate with their ASPSP in order to enable further Variable recurring payments within a pre-existing VRP consent. All other elements of the VRP consent remain unchanged.

Figure 6: Re-authenticate PIS-VRP access from PISP customer alert or directly from the Dashboard

Figure 7: Re-authenticate PIS-VRP access from the Consent Dashboard

This content is best viewed on a desktop browser.

1

CEG Checklist Requirements 1
In circumstances where re–authentication needs to be performed by the ASPSP to refresh PISP access, PISPs should alert the PSU. There are many ways a PSU could receive this notification: as an alert, a message from the homepage or when checking their Consent Dashboard.

If the PSU reauthenticates at their ASPSP via their Consent Dashboard, the customer journey would be as set out in the wireframes: Consent Dashboard Homepage, a Detailed Consent Page, a Summary of reauthentication details followed by a confirmation page.

If the PSU is notified that they need to reauthenticate with their ASPSP, the PISP can take the PSU straight to the Summary of reauthentication page

2

CEG Checklist Requirements 2
PISPs must present a high-level summary of the consent parameters and make it clear that this data and the purpose for which it will be used are the same as when originally requested.

PISPs should not redirect the PSU to their ASPSP without first summarising the reauthentication.

4

CEG Checklist Requirements 4
ASPSPs must not replay the Variable recurring payment requested (as a default) or seek reconfirmation of consent.

CEG Checklist Requirements & Customer Experience Considerations

1

In circumstances where reauthentication needs to be performed by the ASPSP to refresh PISP access, PISPs should alert the PSU. There are many ways a PSU could receive this notification: as an alert, a message from the homepage or when checking their Consent Dashboard.

If the PSU reauthenticates at their ASPSP via their Consent Dashboard, the customer journey would be as set out in the wireframes: Consent Dashboard Homepage, a Detailed Consent Page, a Summary of reauthentication details followed by a confirmation page.

If the PSU is notified that they need to reauthenticate with their ASPSP, the PISP can take the PSU straight to the Summary of reauthentication page

16

2

PISPs must present a high-level summary of the consent parameters and make it clear that this data and the purpose for which it will be used are the same as when originally requested.

PISPs should not redirect the PSU to their ASPSP without first summarising the reauthentication.

19a

PISPs should make it clear that the PSU is being asked to authenticate to refresh the PISP access to continue to make payment and that no other element of the consent (e.g., the consent parameters, expiry date etc.) will change.

If the customer-facing entity is acting on behalf of a PISP, the PSU must be made aware that it is acting on behalf of the PISP. The customer-facing entity must also display the PISP’s full trading name.

4

ASPSPs must not replay the Variable recurring payment requested (as a default) or seek reconfirmation of consent

17

As part of the authentication journey, the ASPSP could have a call to action, for example, to an expandable section that the PSU can click on for information purposes only.

If the ASPSP provides this option for the PSU as supplementary information, it will enable the PSU to view the variable recurring payment details like consent parameters and payment account details they have chosen to share with the PISP.

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

If there is a customer-facing entity acting on behalf of the PISP, ASPSPs must also display that name (as captured in the ‘On behalf of’ field of the software statement) to the PSU.

PISPs should confirm the successful completion of the refreshing access to the PSU.

Making changes to VRP Consent

In situations where a PSU wants to amend the payment rules, they have given to a PISP (e.g., they want to change the max amount per transaction), the PISP will have to take the PSU through a new consent process as the API specifications do not support the ability to edit specific elements of consent. It is in the domain of the PISP to clearly explain this process to the PSU and develop customer journeys for each scenario where this might apply. As a good practice, the PISP must get the PSU to cancel the consent and use the DELETE resource to notify the ASPSP of the cancellation and set up a new consent.

 

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 PISPs 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. As with AIS, a PISP providing VRP should allow PSUs to view a record of expired or cancelled permissions.

Consent history

Where the PSU has revoked VRP access, or the consent has expired, the PISP should provide a list of these previous connections as shown below. The date this consent arrangement ended must be shown, and the other information provided should match what is provided for active connections. If the PISP does not provide an archive on the Dashboard it must nevertheless be available on request.

Figure 8: PIS-VRP Consent Dashboard history example

CEG Checklist Requirements & CX Considerations

1

PISPs must make available all the cancelled or expired consent including details of consent parameters and a list of all payments initiated under the history of consents.

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

9e

2

PISPs must make all the details of the consent available:

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

9d

PISPs should make available a list of payments associated with each VRP consent on the payment history page or, if this is not possible due to archiving of data, provide the total payments that were made for each VRP consent along with the details of the VRP consent

Payment history

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

Figure 9: PIS-VRP Consent Dashboard payment history

CEG Checklist Requirements & CX Considerations

PISPs should make available a list of payments associated with each VRP consent on the payment history page or, if this is not possible due to archiving of data, provide the total payments that were made for each VRP consent along with the details of the VRP consent

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.

We refer to these entities as customer-facing service providers, as these entities are providing the end service to the end-user, whereas the PISP is only undertaking the payment initiation element. This could occur in merchant journeys for example, where a merchant contracts with a PISP to provide Variable Recurring Payment as a payment option on their platform.

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

 

Click for customer research