CBPII Access Dashboard & Revocation
Regulation 68(6) PSRs states that if the PSU so requests, the ASPSP must inform the PSU of the CBPII which has made previous CoF and the answer given to that CBPII.
To enable this, ASPSPs must provide PSUs with a facility to view and revoke CoF access that they have given to any CBPII for each account held at that ASPSP. This section describes:
- How to make these Dashboards effective tools for PSUs
- How the revocation journey should be constructed
- How to inform the PSU about the implications of revoking consent
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:
- Checking that a connection is live
- Reminding a PSU which account(s) a CBPII has consent to request a CoF response from
- Informing a PSU how long the consent is for (or if it is ongoing until cancelled by the PSU)
- Clarifying what data (yes/ no confirmation of funds) the CBPII can request from their ASPSP
- Cancelling access
The CBPII 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.
This section describes how CBPII CoF access should be displayed, including CoF access history and how the customer journey to revoke them should be constructed.
Principle 1: Easy to find and locate
As with the Consent Dashboard, the CBPII Access Dashboard must be easy to find and locate. We show here an example where the CBPII Access Dashboard provided by an ASPSP is one click from the ASPSP home page.
Figure 1: ASPSP Access Dashboard for CBPII – one-click from home page (desktop)
We note that given the relative scarcity of CBPII providers, there may not be any CBPII consents for an ASPSP to display. In this situation, they may choose not to provide the relevant area of the Access Dashboard until such time that the PSU creates a CBPII connection to their account(s).
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 a 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.
ASPSPs must provide PSUs with a facility to view and revoke CBPII access that they have given. PSUs may have consented to CoF access to several accounts from the same ASPSP.
Access 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.
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.
CBPIIs must use the preferred term “Open Banking connections” and/or “Open Banking connected accounts” for a Consent Dashboard specifically.
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 CBPII home page and information bubble
Figure 3: ASPSP Access Dashboard for CBPII detailed page
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 (Consent Dashboard Detailed Page).
ASPSPs must make available on all digital channels a CBPII Access Dashboard which allows PSUs to view CBPII access that has been previously granted and it must be easy and intuitive for PSUs to find and use. The ASPSP Access Dashboard must display all Confirmation of Funds access provided to each CBPII. Thus, for each PSU account, there must be a corresponding explicit consent entry for each CBPII that has been granted CoF access to the account by the PSU.
The ASPSP must provide PSUs with sufficient information to enable them to make an informed decision on the Access Dashboard Home Page. As a minimum, ASPSPs must show on the Access Dashboard Home Page:
- CBPIIs’ trading name/brand name
- The date the CBPII was first granted access
- The expiry date of each access or where relevant the ongoing nature of the access. (Note: Some PSUs find an access countdown helpful, but most found an expiry date clearer. ASPSPs may choose to provide a countdown but it should be used in addition to an expiry date not instead of it.)
- A status flag which is “Active” (see #5 below for more information)
The CBPII Access Dashboard must display all Confirmation of Funds access(es) provided to CBPII(s). Thus, for each CoF access that is made, there must be an entry on the dashboard showing that the PSU has granted CoF access to the granting CoF access to the account for CoF purposes by the PSU.
The ASPSP must also provide a manage button that allows the PSU to revoke each specific access.
The ASPSP 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 CBPIIs/ accounts given by PSU increases.
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 each CBPII CoF access clear by either emboldened words or other design options like colouring as shown in the wireframe.
The ASPSP must provide a history of all confirmation of funds checks. This should be done via the dashboard but can be done differently and is left to ASPSPs to determine.
For each CBPII with CoF access, ASPSPs should display the PSU’s account details including account name, sort code, account number and expiration date.
ASPSPs must be able to provide PSUs with the CoF access history (CoF requests and responses) for a specific CBPII on request. This must include the identity of the CBPII who made the request, and the response (Y/N) given. ASPSPs should provide this functionality via the Access Dashboard.
Note: While OBIE recommends the use of the Access Dashboard for the provision of CoF Access History to the PSU, it is in the domain of each ASPSP to consider alternative options to meet their regulatory requirements for the provision of the COF access history.
The CoF history could also include the following:
- The date the Confirmation of Funds request was made
- The unique reference of the CoF request.
- The amount in relation to the CoF request.
Please note that where ASPSPs are unable to provide a response to a CoF request to the CBPII, a reason should be provided in the history entry for this CoF request.
ASPSPs 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.”
ASPSPs 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 ASPSPs can decide how best to explain this point.
ASPSPs must make available a list of consents which have been cancelled or expired (NB: this refers to expiry of the consent, not access), so that the PSU has a record of old consents.
ASPSPs must provide a Consent Dashboard, Detailed Page, for each Consent, which includes:
- CBPII Trading name
- 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
ASPSPs may include the following at their discretion:
- Clear and reassuring messages about what information is made available to the CBPII, making clear the balance will not be shared
The date and time of the last occasion when a CoF check was requested – this must also be available as a historical list of all past fund checks (see #5)
Figure 4: ASPSP Access Dashboard revocation user journey for CBPII
The ability to revoke CBPII access to request CoF responses from connected accounts is one of the primary roles of the Access Dashboard. This guidance sets out how CBPIIs should make this user journey clear and straightforward for users to build trust and confidence.
Figure 5: ASPSP access revocation journey for CBPII
The Access Dashboard must allow a PSU to cancel the access they have consented to easily and without obstruction or excessive barriers.
ASPSPS must allow PSUs to revoke the CoF access for each CBPII to a specific PSU account.
ASPSPs must advise PSUs that they should contact the associated CBPII to fully understand the potential implications of doing so.
ASPSPs must allow PSUs to confirm that they want to revoke CoF access of their account to a specific CBPII.
ASPSPs should inform PSUs that once CoF access is revoked, the CBPII will no longer be able to check the availability of funds in their account. This may cause their CBPII transactions to be declined.
ASPSPs must advise PSUs that they should contact the associated CBPII to inform them of the cancellation of CoF access to their account and/or fully understand the potential implications of doing so.
ASPSPs should confirm to PSUs that CoF access 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 are advised to 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.
Re-Authentication of CoF Access at the ASPSP
There are exceptional circumstances where an ASPSP invalidates a token after PSU explicit consent has been obtained, for example due to suspicion of fraud. The reauthentication that is required is covered in the Customer Experience Guidelines section Re-Authentication of CoF Access at ASPSP.
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.
Where the PSU has cancelled the permission, or the consent has expired, the ASPSP should provide a list of these previous connections as shown below. If the ASPSP does not provide an archive on the Dashboard it must nevertheless be available on request.
Figure 6: ASPSP Access Dashboard for CBPII history example
ASPSPs must make all the historic CBPII 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.
ASPSPs must make available all the details of the consent
- Consent granted
- Consent expired/cancelled date
- Consent status (Expired/Cancelled)
Additionally, the ASPSP 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 funds checks that were performed for a now-expired consent. This is shown below
Figure 7: ASPSP Access Dashboard for CBPII funds check history example
ASPSPs should make available a list of all funds check history associated with each CBPII consent on the CoF history page for all the active CBPII consents.
- Please note that the wireframes have been created as if the date that the PSU is viewing their CBPII access dashboard is 30/07/2022. For clarity:
- The PSU authenticated with their ASPSP and granted CBPII 1 access to request CoF responses with respect to 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 respond to any CoF requests the CBPII makes until the PSU withdraws their consent at the CBPII or revokes access at their ASPSP.
- The PSU authenticated with their ASPSP and granted CBPII 2 access to request CoF responses with respect to the PSU’s current account on 05/04/2022. This is ongoing permission without a set expiry date i.e. the ASPSP will need to respond to any CoF requests the CBPII makes until the PSU withdraws their consent at the CBPII or revokes access at their ASPSP.
|Customer-facing entity name /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 Trades||ABC Company Ltd||ABC Trades|
|ABC Company Ltd||ABC Company Ltd||ABC Company Ltd|
|ABC Company Ltd||ABC Company Ltd||OBO Ltd||OBO Ltd on behalf of ABC Company Ltd|
|ABC Trades||ABC Company Ltd||OBO Ltd||OBO 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]|