AIS Access Dashboard & Revocation
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:
- How to make the Access Dashboards an effective tool for PSUs
- How the revocation journey should be constructed
- How information about how and what information should be displayed if an AISP is using an agent
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:
- Checking that a connection is live
- Reminding a PSU which accounts an AISP has consented to access
- Informing a PSU how long AISP access will continue for
- Clarifying what types of data the AISP can access
- Providing the ability to revoking AISP access to payment accounts
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 31/03/2022 shortly after 11:43 am. For clarity:
- The PSU authenticated with their ASPSP and granted AISP 1 access to their current account on 17/01/2022 and this connection is currently active until 17/02/2024.
- The AISP 1 last requested data from the ASPSP at 11:43 am and hence the last connection is shown as 31/03/2022 at 11:43
- The PSU authenticated with their ASPSP and granted AISP 2 access to their current account on 16/10/2021 and this connection is currently active until 15/10/2022.
- The AISP 2 last requested data from the ASPSP at 15:34 am and hence the last connection is shown as 16/10/2021 at 15:34
Principle 1: Easy to find and locate
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.
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)
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.
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.
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 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:
- 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.
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 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.
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.
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.
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 OBIE 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
The ability to revoke AISP access to connected accounts is one of the primary roles of the Access Dashboard.
Figure 7: ASPSP Access Dashboard revocation user journey for AIS
Figure 8: ASPSP access revocation journey for AIS
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 “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.
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.
Principle 3: Be as transparent as possible
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 9: 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
- 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)
Access Dashboards when the AISP is using an Agent
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 10: 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
|TPP 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]|
|Note: 'On behalf of' field should be the customer facing entity name if it is different from the TPP Trading name|