ASPSPs must provide PSUs with a facility to view and revoke ongoing access that they have given to any AISP for each account held at that ASPSP. The PSU may have consented to share data from several accounts with a single AISP.
Other pages in this section
ASPSPs must provide PSUs with a facility to view and revoke ongoing access that they have given to any AISP for each account held at that ASPSP. The PSU may have consented to share data from several accounts with a single AISP. This section describes:
Dashboards play an important role in clearly and transparently set out the data, to which a PSU has provided their consent to an AISP to access at their ASPSP. They, therefore, play a role in multiple user journeys, including:
Our research demonstrates that being able to find the ASPSP access Dashboard easily and making it easy to understand plays a key role in building trust with Open Banking-enabled services.
Please note that the wireframes have been created as if the time and date that the PSU is viewing their AIS access dashboard is 18/01/2022 shortly after 11:43 am. For clarity:
The placement of the Access Dashboard within the ASPSP domain is important. Research shows a direct correlation between the number of clicks from the home page and the ease with which PSUs can find their Dashboard.
We have provided examples of zero, one and two clicks from the home screen; such an important tool should not be nested in menus further than that, though we do note that for an ASPSP there are many more services that need to be offered through their website or app than for an AISP and therefore the two-click option is most likely. In the zero-click example, an overview of the connected accounts is provided on the home page but there is also a separate “Open Banking connections” space for the customer that would provide more detail and the functionality to manage the access arrangements in place.
It is therefore not expected that an ASPSP will give it as much prominence as an AISP, but it should still be easy to find and locate. If it is nested, the name of where it is located is important. Several examples in the market today place it under “profile” which did not test well. Generally, the term “settings” was considered to be the logical place for it. Wherever it is positioned, and whatever it is called, ASPSPs should design and build while testing with real customers.
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.
Figure 1: ASPSP Access Dashboard for AIS – zero-clicks from home page (desktop
Figure 2: ASPSP Access Dashboard for AIS – one-click from home page (desktop)
Figure 3: ASPSP Access Dashboard for AIS – two clicks from home page (desktop)
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.
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.
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 4: ASPSP Access Dashboard for AIS home page
Figure 5: ASPSP Access Dashboard for AIS detailed page
Figure 6: ASPSP Access Dashboard for AIS detailed page expanded
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).
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.
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 ASPSP should display the date and time when account data was last accessed by the AISP
The ASPSP must provide a button that allows the PSU to revoke ongoing access arrangements. The ASPSP should provide a button that allows the PSU to refresh any access arrangements that require a refresh.
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.
ASPSPs must use just two status flags: “Active” or “Refresh”. A consent is defined as active if it has a valid access token that has not expired due to 90 days and the consent expiry date has not elapsed.
ASPSPs should provide additional explanatory text to help PSUs understand 90-day refresh and how to revoke access; using information bubbles helps to keep information manageable.
ASPSPs must provide a history of old connections. This should include any access which has previously been revoked at the ASPSP, consent which has been revoked at the AISP, and consent which has expired. This gives the PSU a record of old accesses and consents. Where the connection has not been refreshed for more than 90 days, and therefore access is blocked but can be refreshed as the consent remains valid, this should not be placed in the history, but listed on the Access Dashboard homepage with a “Refresh” status.
ASPSPs must provide a Detailed Page for each access, which includes:
ASPSPs may also provide detail about:
Figure 7: ASPSP Access Dashboard revocation user journey for AIS
The ability to revoke AISP access to connected accounts is one of the primary roles of the Access Dashboard.
Figure 8: ASPSP access revocation journey for AIS
This content is best viewed on a desktop browser.
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.
CEG Checklist Requirements 2ASPSPs should make the status of TPP access clear using “Active” or “Refresh” and either emboldened words or other design options like colouring as shown in the wireframe.
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.
CEG Checklist Requirements 4ASPSPs 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.
The ASPSP must provide a manage button that takes the PSU to the detailed view where they are able to revoke access.
ASPSPs should make the status of TPP access clear using “Active” or “Refresh” and either emboldened words or other design options like colouring as shown in the wireframe.
The Access Dashboard must allow a PSU to revoke the access they have consented to easily and without obstruction or excessive barriers.
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.
While it is not a requirement, ASPSPs could offer functionality to refresh access directly through the Access Dashboard. Moreover, ASPSPs could allow multiple TPP access arrangements to be refreshed at once, thus synchronising them all on a 90-day cycle so the PSU is less likely to allow one or more to pass 90 days.
Figure 9: Refreshing access triggered by a customer alert
This functionality could be combined with intelligent notification about upcoming or already-past expiry of access at 90 days. Please refer to the PSU Notifications section for more information.
Note: There is a complication if one or more TPPs with active consent have less than 90 days of consent (not access) remaining. In instances where PSU have less than 90 days of consent left, it is advised that ASPSPs do not allow the PSU to refresh access, however, it is possible that an ASPSP would choose to allow refresh of access for the remaining period i.e. until the consent expires.
ASPSPs should provide PSUs with as much relevant information as possible.
Where the PSU has revoked access, or the consent has expired or been cancelled at the TPP, the ASPSP should archive these connections as shown below. The ASPSP could choose to make clear whether the reason is revocation of consent or expiry of access; otherwise, the information provided should match what is provided for active connections.
Figure 10: ASPSP Access Dashboard for AIS history example
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.
ASPSPs must make available all the details of the consent
If there is an Agent acting on behalf of the AISP, ASPSPs must also display the Agent company name (as captured in the ‘On behalf of’ field of the software statement) to the PSU. We note that ASPSPs can only show the Agency/On Behalf field in cases where this information has been provided by AISP.
Figure 11: ASPSP Access Dashboard for AIS when AISP is using an agent
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
PIS VRP Consent Dashboard 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.”