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

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

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.

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.

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

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.

If the ASPSP has marked the consent status as ‘Cancelled’ when the PSU cancelled their access on the Access Dashboard or the ASPSP has marked it as ‘Cancelled’ for any reason where a reinstate is possible, then the ASPSP must mark the status back to ‘Authorised’ after successful authentication by the PSU.

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

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