PIS VRP Consent Dashboard

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.

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.

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

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.

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.

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.

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.

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 may include the following at their discretion:

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

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.

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

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.

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.

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

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.

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.

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)

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

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