CBPII Access Dashboard

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.

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

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.

Revocation Request

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.

Confirmation

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.

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)

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.