Dashboards play an important role in managing the data for which a PSU has provided access consent for an AISP to access from their ASPSP. PSUs may have consented to share data from several accounts with a single AIS. ASPSPs must provide PSUs a dashboard to view and revoke the ongoing access for each account.
Other pages in this section Dashboards Overview AIS Consent Dashboard AIS Access Dashboard PIS VRP Consent Dashboard PIS VRP Access Dashboard CBPII Consent Dashboard CBPII Revocation of Consent CBPII Access Dashboard CBPII Access Revocation PSU Notifications
AIS Access Dashboard Examples An important aspect of ensuring that the Dashboard 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 AISP. The preferred name when acting solely as an AISP is “open banking connections” and/or “open banking connected services.” If the provider is operating as both ASPSP and AISP, 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 of where and what the Dashboard is, and the role it plays, would be a useful tutorial for new customers after they have signed up. While this is left to the discretion of participants, we have provided guidelines on PSU Notifications for reference. ASPSP Access Dashboard for AIS – as home page Figure 1: ASPSP Access Dashboard for AIS – zero-clicks from home page (desktop) ASPSP Access Dashboard for AIS – one click Figure 2: ASPSP Access Dashboard for AIS – one-click from home page (desktop) ASPSP Access Dashboard for AIS – two clicks Figure 3: ASPSP Access Dashboard for AIS – two clicks from home page (desktop)
CEG Checklist Requirements & CX Considerations 1 ASPSPs must make available on all digital channels an Access Dashboard, with the same name across channels, which allows PSUs to view access that has been previously granted and it must be easy and intuitive for PSUs to find and use. Careful consideration should be given to ensure that Dashboards are positioned logically and ideally placed no more than two clicks from the ASPSP’s Home Screen. 10b 2 ASPSPS must use the preferred term “open banking connections” and/or “open banking connected services” for an Access Dashboard specifically. 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. 10a
CEG Checklist Requirements & CX Considerations 1 To aid clarity whilst providing detailed information if the PSU needs it, and Access Dashboard should provide an overview screen (Access Dashboard Home Page) which lists high-level information for all AISP access arrangements, and a detailed page for a more detailed view of each access (Access Dashboard Detailed Page). 2 ASPSPs must display the AISP’s trading name/brand name (i.e., the Client Name in the software statement) to the PSU during authentication screens and on any Access Dashboards. They do not need to display the registered company name of the AISP even if it is different. 3 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: AISPs’ trading name/brand name Account type The expiry date of each consent. A status flag “Active” or ‘Connected’ The ASPSP should display when data was last shared with the TPP (this may be a specific date and time, or a range (e.g. within the last [x] days)). Note: Refer to alternate ways of how this information can be displayed on Dashboards – Figure 3: Access Dashboards that handle AIS (Data), VRP (Payments) and CBPII (Funds check) The ASPSP must provide a button that allows the PSU to revoke (stop sharing) ongoing access arrangements. 10d 4 ASPSP should offer functionality (e.g. search, sort, filter) to enable a PSU to search for the relevant access. This will be of particular benefit as the number of consents for different ASPSPs/ accounts given by a PSU to AISPs increases. 5 ASPSPs must use just one status flag: “Active” or ‘Connected’ as they deem appropriate. Consent is defined as active i.e. connected if the consent expiry date has not elapsed or the PSU has not revoked consent at the AISP. The ASPSPs must advise PSUs that they should contact the associated AISP to check the current status of the consent as the ASPSP does not have information on whether consent has been reconfirmed or not. 10d 6 ASPSPs should provide additional explanatory text to help PSUs understand 90-day reconfirmation of consent is now only required at the AISP and how to revoke access; using information bubbles helps to keep information manageable. 7 ASPSPs must provide a history of old connections. This should include any access which has previously been revoked at the ASPSP, consent that has been revoked at the AISP, and consent that has expired. This gives the PSU a record of old accesses and consents. 10e 8 ASPSPs must provide a Detailed Page for each access, which includes: AISP Trading Name Account type (e.g. current account) of accounts being shared with TPP Sort Code and Account Number (or other product identifier depending on the account type e.g. PAN for credit cards) Data clusters being accessed: using the structure and language recommended by OBL following customer research (see Data Cluster Structure & Language) The date the AISP was first granted access The expiry of the consent or ongoing permission from [DATE] if it is an ongoing permission ASPSPs may also provide detail about: Where the request is for multiple product types, the detail should explain to the customer the product type to which it applies or state that it is shared across multiple product types Which party provided the AISP access, in the case of joint/ multiple account holders 10d 13a
This content is best viewed on a desktop browser. 1 CEG Checklist Requirements 1The ASPSP must provide a manage button that takes the PSU to the detailed view where they are able to revoke access. 2 CEG Checklist Requirements 2ASPSPs should make the status of TPP access clear using “Active” or “Connected” and either emboldened words or other design options like colouring as shown in the wireframe.ASPSPs should show as a minimumwhen data was last shared with the TPP (this may be a specific date and time, or a range (e.g. within the last [x] days)).the expiry date of the consent.Note: Refer to Dashboards – Figure 3: Access Dashboards that handle AIS (Data), VRP (Payments) and CBPII (Funds check) on alternate ways in which ‘Last data shared’ can be shown to the PSU. 3 CEG Checklist Requirements 3The Access Dashboard must allow a PSU to revoke the access they have consented to easily and without obstruction or excessive barriers. 4 CEG Checklist Requirements 4ASPSPs must advise PSUs that they should contact the associated AISP to inform them of the cancellation of access and/or understand the consequences of revoking access. Select to scroll left Select to scroll right
CEG Checklist Requirements & CX Considerations 1 The ASPSP must provide a manage button that takes the PSU to the detailed view where they are able to revoke access. 10c 2 ASPSPs should make the status of TPP access clear using “Active” or ‘Connected’ and either emboldened words or other design options like colouring as shown in the wireframe. ASPSPs should show as a minimum when data was last shared with the TPP (this may be a specific date and time, or a range (e.g. within the last [x] days)). the expiry date of the consent. Note: Refer to Dashboards – Figure 3: Access Dashboards that handle AIS (Data), VRP (Payments) and CBPII (Funds check) on alternate ways in which ‘Last data shared’ can be shown to the PSU. 3 The Access Dashboard must allow a PSU to revoke the access they have consented to easily and without obstruction or excessive barriers. 10c 4 ASPSPs must advise PSUs that they should contact the associated AISP to inform them of the cancellation of access and/or understand the consequences of revoking access. 10f
CEG Checklist Requirements & CX Considerations 1 ASPSPs must make all the historic AIS 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. 10e 2 ASPSPs must make available all the details of the consent Consent granted Consent expired/cancelled date Ability to expand consent parameters Ability to expand consent from an account and to account details Consent status (Expired/Cancelled) 10e
CEG Checklist Requirements & CX Considerations 1 ASPSPs must display the agent name (‘on behalf of’ in the software statement) along with the AISP trading name (‘client name’ in software statement) on the access dashboard. We note that ASPSPs can only show the agent name/On Behalf of field when this information has been provided by AISP
AIS Consent Dashboard Previous Related articles Please select API specifications Access Revocation Changes to an Intent's Authorized State PIS VRP Consent Dashboard Next