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.
Other pages in this section
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:
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:
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.
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.
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:
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.
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:
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:
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:
ASPSPs may include the following at their discretion:
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
This content is best viewed on a desktop browser.
CEG Checklist Requirements 1The Access Dashboard must allow a PSU to cancel the access they have consented to easily and without obstruction or excessive barriers.rnrnASPSPS must allow PSUs to revoke the CoF access for each CBPII to a specific PSU account.rnrnASPSPs must advise PSUs that they should contact the associated CBPII to fully understand the potential implications of doing so.
CEG Checklist Requirements 2Revocation RequestrnrnASPSPs must allow PSUs to confirm that they want to revoke CoF access of their account to a specific CBPII.rnrnASPSPs 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.rnrnASPSPs 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.
CEG Checklist Requirements 3ConfirmationrnrnASPSPs must confirm to PSUs that CoF access to their account has been cancelled.rnrnASPSPs must inform the PSU that no further CoF responses will be provided by the ASPSP to the CBPII.rnrnAfter 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.
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 must confirm to PSUs that CoF access to their account has been cancelled.
ASPSPs must 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.
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.
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
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.
CBPII Revocation of Consent Previous
PSU Notifications Next
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
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.”