Dashboards

AIS Consent Dashboard

This version is:

Published 1 year ago 16 Mar 2023

Dashboards play an important role in managing the data for which a PSU has provided access consent to an AISP. PSUs may have consented to share data from several ASPSPs with a single AISP. AISPs must provide PSUs a dashboard to view and revoke their ongoing consents.

Other pages in this section

 

Overview

AISPs must provide PSUs with a Dashboard to view and revoke ongoing consents that they have given to that AISP. They may have consented to share data from several ASPSPs with a single AISP. This section describes:

Dashboards play an important role in clearly and transparently setting out what data a PSU has provided consent for an AISP to access. They, therefore, play a role in multiple user journeys, including:

The AISP Consent Dashboard should therefore be easy to find and our research demonstrates that being able to find the AISP Consent Dashboard easily and making it easy to understand plays a key role in building trust with open banking-enabled services.

Principle 1: Easy to find and locate

The placement of the Dashboard within the AISP 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 the channel being used and the offering of the AISP may determine its positioning to some extent. For example, for account aggregators, it is more likely to be zero or one click, while accountancy packages may not need to provide such a direct link to it. See examples of these models below.

If it is nested, the name of where it is located is also important; generally, “settings” was considered to be the logical place as opposed to “account” when used on its own (see examples below). Wherever it is positioned, and whatever it is called, AISPs should design and build while testing with real customers.

Note

Please note that the wireframes have been created as if the time and date that the PSU is viewing their AIS consent dashboard is 31/03/2022 at 11:43 am. For clarity:

  • Consent was given by the PSU to the AISP to access the PSU’s current account at ASPSP 1 on 17/01/2022 and is currently active i.e. within 90 days / not requiring reconfirmation. The PSU will need to reconfirm consent by 17/04/2022.
  • As the PSU has logged into the AISP to view their consent dashboard, the AISP requested up to date data from the ASPSP and hence the last connection is shown as 31/03/2022 at 11:43 am.

  •  Consent was given by the PSU to the AISP to access the PSU’s current account at ASPSP 2 on 16/10/2021 and access expired on 31/03/2022. The consent needs to be reconfirmed by the PSU in order for the AISP to retrieve up to date information from ASPSP 2.
  • As the PSU has not yet reconfirmed their consent since 14/01/2022, the last connection is shown as 14/01/2022 at 15.34.
  • Consent was also given by the PSU to the AISP to access the PSU’s current account at ASPSP 3 on 29/12/2021. The consent needs to be reconfirmed by the PSU in order for the AISP to retrieve up to date information from ASPSP 3.
  • As the PSU has not yet reconfirmed their consent since 31/03/2022, the last connection is shown as 29/03/2022 at 09:11 am

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 an AISP is “Open Banking connections” and/or “Open Banking connected accounts.” If the provider is operating as both AISP 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.

AIS Consent Dashboard examples

Expand sections to view dashboard examples:

Figure 1: AIS Consent Dashboard – zero-clicks from home page (desktop)

Figure 2: AIS Consent Dashboard – one-click from home page (desktop and app)

 

Figure 3: AIS Consent Dashboard – two-clicks from home page (app)

CEG Checklist Requirements & CX Considerations

1

AISPs must provide PSUs with a facility to view and revoke ongoing consents that they have given to that AISP. They may have consented to share data from several ASPSPs with a single AISP.

9b,9c

2

Consent 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 AISP’s Home Screen

9b

3

AISPs 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 PSUs didn’t understand what they meant.

AISPs must use the preferred term “open banking connections” and/or “open banking connected accounts” for a Consent Dashboard specifically.

9a

Principle 2: Intuitive to use and understand

Whilst the specific design of a Consent Dashboard sits in the competitive space, the Dashboard must provide PSUs with control by ensuring they are well informed and can easily manage the connections they have consented to.

Figure 4: AIS Consent Dashboard home page with information bubble

Figure 5: AIS Consent Dashboard detailed page

Figure 6: AIS Consent Dashboard detailed page expanded with information bubble

CEG Checklist Requirements & Customer Experience Considerations

1

To aid clarity whilst providing detailed information if the PSU needs it, a Consent Dashboard should provide an overview screen (Consent Dashboard Home Page) which lists high level information for all consents, and a detailed page for each consent (Consent Dashboard Detailed Page).

2

The customer-facing entity must provide PSUs with sufficient information to enable them to make an informed decision on the Consent Dashboard Home Page. As a minimum, AISPs must show on the Consent Dashboard Home Page:

  • ASPSP Name (or nickname if used)
  • Account type (if provided)
  • The date on which AISP requires a 90-day reconfirmation of the consent (Note: Some PSUs find a countdown to when action is required helpful, but most found an expiry date for when access will end clearer. A countdown is an optional element. If provided it should be used in addition to an expiry date not instead of it. Note this refers to the AISP reconfirmation of consent required by date and not the expiry of the consent agreed with the AISP.)
  • The date and time of the last occasion when data was synced from the connected account
  • A status flag that is either “Active” or “Reconfirm” (see below on status messages)
  • Warnings or alerts if access is close to expiry (i.e. at 90 days). The AISP can define how close to the reconfirmation date it should start to alert the PSU depending on their business model.

The AISP must also provide a manage button that allows the PSU to revoke (disconnect) or reconfirm consent.

9d

3

AISP 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 ASPSPs/ accounts given by a PSU to AISPs increases.

4

AISPs must use just two status flags: “Active” or “Reconfirm”. Consent is defined as active if it has a valid access token that has not expired and the consent expiry date has not elapsed.

AISPs must be mindful that a PSU could have revoked access at the ASPSP.

There are a variety of methods that an AISP can use to check that their access token is still valid. See the PSU Notifications page for further details.

9d

5

AISPs should provide the ability for a PSU to edit the ASPSP Name so that it can be replaced with a ‘nickname’ (such as “Household Account” or “Holiday Savings Pot”) to help PSUs identify their accounts easily.

6

AISPs should provide additional explanatory text to help PSUs understand complex areas such as 90-day reconfirmation of consent and how to cancel. Using information bubbles helps to keep information manageable. In the example provided we use the language “at least every 90 days” but AISPs can decide how best to explain this point.

The AISP should also explain to the PSU that the PSU must reconfirm their consent only with the AISP at least every 90 days in order to enable the AISP to continue to access their account and provide services.

The AISP should also explain to the PSU that PSU may be required to re-authenticate with their ASPSP in permitted circumstances.

7

AISPs must make available a list of consents that have been cancelled or expired (NB: this refers to expiry or cancellation of the consent, not access) so that the PSU has a record of old consents. Where the connection has not been reconfirmed for more than 90 days, and therefore access is expired but can be reconfirmed, it should not be placed in the history, but listed on the Consent Dashboard homepage with a “Reconfirm” status.

9e

8

AISPs must provide a Consent Dashboard, Detailed Page, for each Consent, which includes:

  • ASPSP Name (or nickname if used)
  • 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)
  • Data clusters being accessed: using the structure and language recommended by Open Banking Ltd (OBL) following customer research (see Data Cluster Structure & Language section)
  • The purpose of the data sharing
  • The date the consent was granted
  • The expiry date of the access (i.e. reconfirm connection by date the same as shown on the Consent Dashboard Homepage)
  • The expiry of the consent (in situations where the consent is not aligned to reconfirm duration)
  • The purpose for which the data will be used
  • 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

AISPs should include the following at their discretion:

  • The date when the customer last reconfirmed their consent.

9d

 

Revocation Journey

Figure 7: AIS Consent Dashboard revocation user journeyOne of the most important User Journeys is to use the Consent Dashboard to cancel a long-lived consent. This guidance sets out how AISPs should make this PSU journey clear and straightforward for PSUs to build trust and confidence.

Additionally, it is essential that AISPs make clear what will happen to the already-obtained data in their possession once the consent is cancelled by the PSU. Further information is provided in PSU Notifications regarding how AISPs can best inform customers about what happens to data that has already been retrieved in a fair and transparent way.

Figure 8: AIS consent revocation journey

This content is best viewed on a desktop browser.

1

CEG Checklist Requirements 1
The Consent Dashboard must allow a PSU to cancel the access they have consented to easily and without obstruction or excessive barriers.

2

CEG Checklist Requirements 2
The AISP should make the exact consequences of cancelling the consent clear to the PSU – i.e., they will no longer be able to provide the specific service to the PSU.

Once the PSU has clicked “Disconnect”, the AISP should only provide one screen prior to cancelling/revoking access, which clearly sets out the implications of cancelling to ensure that they want to proceed with the cancellation.

A confirmation screen should be provided after this to confirm that the connection is no longer active.

3

CEG Checklist Requirements 3
The confirmation screen must confirm what happens to any existing data which the AISP has already retrieved. AISPs must ensure that they are fair and transparent about how existing data is processed and that data that is no longer required is deleted, where appropriate.

5

CEG Checklist Requirements 5
AISPs should inform the PSU that the connection to their account has been cancelled and no further account information will be provided by the ASPSP to the AISP as the PSU has withdrawn its access given to the AISP.

After the Delete endpoint is called by the AISP to remove the account-access-consent resource, the 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 AISP will no longer have access to their account. This is an additional confirmation to the PSU that the AISP has completed the delete endpoint process correctly.

CEG Checklist Requirements & Customer Experience Considerations

1

The Consent Dashboard must allow a PSU to cancel the access they have consented to easily and without obstruction or excessive barriers.

9c

2

The AISP should make the exact consequences of cancelling the consent clear to the PSU – i.e., they will no longer be able to provide the specific service to the PSU.

Once the PSU has clicked “Disconnect”, the AISP should only provide one screen prior to cancelling/revoking access, which clearly sets out the implications of cancelling to ensure that they want to proceed with the cancellation.

A confirmation screen should be provided after this to confirm that the connection is no longer active.

3

The confirmation screen must confirm what happens to any existing data which the AISP has already retrieved. AISPs must ensure that they are fair and transparent about how existing data is processed and that data that is no longer required is deleted, where appropriate.

8g

4

AISPs must inform the ASPSP that the PSU has withdrawn consent by making a call to DELETE the account-access-consent resource as soon as practically possible (as described in Version 3 of the API specifications). This will ensure that no further account information is shared.

ASPSPs must support the Delete process as described in the Version 3 API specifications. (This is not visible to the PSU but will ensure no further account information is provided by the ASPSP to the AISP).

9c

5

AISPs should inform the PSU that the connection to their account has been cancelled and no further account information will be provided by the ASPSP to the AISP as the PSU has withdrawn its access given to the AISP.

After the Delete endpoint is called by the AISP to remove the account-access-consent resource, the 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 AISP will no longer have access to their account. This is an additional confirmation to the PSU that the AISP has completed the delete endpoint process correctly.

 

Reconfirm consent at the AISP

The Consent Dashboard plays a key role in encouraging and reminding PSUs to reconfirm their consent to the AISP to ensure their accounts are ‘Active’ and ‘Connected’. The section on PSU Notifications shows several ways in which AISPs can remind their customers of the need to reconfirm their consent and explain why they are required to obtain it, and the information in the Consent Dashboard should make clear when reconfirmation or re-authentication is required.

We note that some AISPs may wish to encourage PSUs to reconfirm their consent more frequently than every 90 days depending on their proposition. Further, AISPs may want to advise the PSU that they may still need to re-authenticate with their ASPSP in permitted circumstances.

To provide customers with the most streamlined experience, AISPs should not limit their consent to 90 days on sign up but rather request a long-lived token so that reconfirm consent at the AISP journey can be utilised. If this is not done, then every 90 days the AISP will be required to create a new consent with the PSU, which will necessitate a full authentication with the ASPSP. This is explained further below.

We encourage AISPs to inform the PSU that in order to enable the AISP to access the PSUs account information until the consent expires, the PSU will have to reconfirm their consent at least every 90 days in order to enjoy uninterrupted services.

This section describes the customer journey when a PSU needs to reconfirm consent, so the AISP can continue to provide the service previously consented to. All other elements of the consent (data permissions required, purpose for which the data will be used, transaction history period and consent expiration date) remain unchanged.

Figure 9: Reconfirm single/multiple AIS consent from an AISP customer alert or directly from the Dashboard

Figure 10:Reconfirm single/multiple AIS consent from the Consent Dashboard

This content is best viewed on a desktop browser.

1

CEG Checklist Requirements 1
AISPs must alert the PSU when reconfirmation of consent is required. There are many ways a PSU could receive this notification: as an alert, a message from the homepage or when checking their consent dashboard.

If the PSU reconfirms a single consent via their consent dashboard, the customer journey would be consent dashboard homepage, detailed consent page, a summary of reconfirmation details.

If the PSU is notified that they need to reconfirm consent, the AISP can take the PSU straight to the Summary of reconfirmation page.

If the PSU reconfirms multiple consents via their consent dashboard, the customer journey would be as in figure 10: Consent Dashboard Homepage (select multiple consents), Summary & Confirmation completion after authentication at AISP.

AISPs must not access data if the PSU has not reconfirmed consent.

2

CEG Checklist Requirements 2

AISPs should allow the PSU to select all the payment accounts across ASPSPs that may or may not be due for reconfirmation.

AISPs should make it clear that the PSU is being asked to authenticate to extend the AISP access to their account data and that no other element of the consent (e.g., the data permissions required, the purpose for which it will be used etc.) will change.

3

CEG Checklist Requirements 3
AISPs must display the company’s trading name/brand name (i.e. the Client Name) to the PSU. If the AISP is only trading with its registered company name then it must display that name to the PSU.

If the AISP is not the customer-facing entity and there is an Agent who is acting on behalf of the AISP, then the Agent must make the PSU aware that they are acting as an agent on behalf of the AISP and must also, display the AISP’s full trading name/brand name or registered company name whichever is the customer-facing brand of the AISP.

AISPs must also, populate the Agent company name in the ‘On behalf of’ field of the software statement, in order to inform the ASPSP about the agency relationship and allow the ASPSP to be able to display this information to the PSU. Only in instances where there is an Agent acting on behalf of the AISP, the ‘On Behalf of’ name must be displayed to the PSU. AISPs must not populate the ‘ On behalf of’ field with the details of their TSP.

The customer-facing entity must provide PSUs with sufficient information to enable them to make an informed decision. For example, detail the purpose for which the data will be used (including whether any other parties will have access to the information), the period over which it has been requested and when the consent for the account information will expire (consent could be ongoing or one-off).

4

CEG Checklist Requirements 4

AISPs must also allow the PSU to select each consent and view the data permissions (clusters) that are associated with the consent without the need to change the consent.

5

CEG Checklist Requirements 5

AISPs must allow the PSU to explicitly reconfirm their consent with equal prominence given to continue or discontinue the service.

6

CEG Checklist Requirements 6
AISPs should provide confirmation to the PSU that reconfirmation of consent has been successfully completed.

CEG Checklist Requirements & Customer Experience Considerations

1

AISPs must alert the PSU when reconfirmation of consent is required. There are many ways a PSU could receive this notification: as an alert, a message from the homepage or when checking their consent dashboard.

If the PSU reconfirms a single consent via their consent dashboard, the customer journey would be consent dashboard homepage,  detailed consent page, a summary of reconfirmation details.

If the PSU is notified that they need to reconfirm consent, the AISP can take the PSU straight to the Summary of reconfirmation page.

If the PSU reconfirms multiple consents via their consent dashboard, the customer journey would be as in figure 10: Consent Dashboard Homepage (select multiple consents),  Summary & Confirmation completion after authentication at AISP.

AISPs must not access data if the PSU has not reconfirmed consent.

16a 16d

2

AISPs should allow the PSU to select all the payment accounts across ASPSPs that may or may not be due for reconfirmation.

AISPs should make it clear that the PSU is being asked to authenticate to extend the AISP access to their account data and that no other element of the consent (e.g., the data permissions required, the purpose for which it will be used etc.) will change.

3

AISPs must display the company’s trading name/brand name (i.e. the Client Name) to the PSU. If the AISP is only trading with its registered company name then it must display that name to the PSU.

If the AISP is not the customer-facing entity and there is an Agent who is acting on behalf of the AISP, then the Agent must make the PSU aware that they are acting as an agent on behalf of the AISP and must also, display the AISP’s full trading name/brand name or registered company name whichever is the customer-facing brand of the AISP. 

AISPs must also, populate the Agent company name in the ‘On behalf of’ field of the software statement, in order to inform the ASPSP about the agency relationship and allow the ASPSP to be able to display this information to the PSU. Only in instances where there is an Agent acting on behalf of the AISP, the ‘On Behalf of’ name must be displayed to the PSU. AISPs must not populate the ‘ On behalf of’ field with the details of their TSP.

The customer-facing entity must provide PSUs with sufficient information to enable them to make an informed decision. For example, detail the purpose for which the data will be used (including whether any other parties will have access to the information), the period over which it has been requested and when the consent for the account information will expire (consent could be ongoing or one-off).

8e

4

AISPs must also allow the PSU to select each consent and view the data permissions (clusters) that are associated with the consent without the need to change the consent.

16b

5

AISPs must allow the PSU to explicitly reconfirm their consent with equal prominence given to continue or discontinue the service.

16d

6

AISPs should provide confirmation to the PSU that reconfirmation of consent has been successfully completed.

 

Re-authentication of access

This section describes the customer journey when a PSU needs to re-authenticate their access, so the AISP can continue to provide the service previously consented to by authenticating again at their ASPSP. All other elements of the consent (data permissions required, purpose for which the data will be used, transaction history period and consent expiration date) remain unchanged.

The AISP is not required to inform the ASPSP that the PSU has reconfirmed consent, nor is the ASPSP permitted to check the consent provided by the customer. Once the initial consent is set up, the ASPSP can only re-authenticate the customer in permitted circumstances i.e. when it has proportional and objective reasons for doing so e.g. fraud or unauthorised access or revoked access accidentally at the ASPSP or request more data than permitted under Art 10a e.g. 100 days of data.

Figure 11: Re-authenticate AIS access from AISP customer alert or directly from the Dashboard

Figure 12: Re-authenticate AIS access from the Consent Dashboard

This content is best viewed on a desktop browser.

1

CEG Checklist Requirements 1
In circumstances where re–authentication needs to be performed by the ASPSP to refresh AISP access, AISPs should alert the PSU. There are many ways a PSU could receive this notification: as an alert, a message from the homepage or when checking their Consent Dashboard.

If the PSU reauthenticates at their ASPSP via their Consent Dashboard, the customer journey would be as set out in the wireframes: Consent Dashboard Homepage, a Detailed Consent Page, a Summary of reauthentication details followed by a confirmation page.

If the PSU is notified that they need to reauthenticate with their ASPSP, the AISP can take the PSU straight to the Summary of reauthentication page

2

CEG Checklist Requirements 2
AISPs must present a high-level summary of the data that is being requested and make it clear that this data and the purpose for which it will be used are the same as when originally requested. This should be done using the structure and language recommended by OBL following customer research (see Data Cluster Structure & Language below). AISPs must ensure that this request is specific to only the information required for the provision of their account information service to the PSU.

AISPs should only present those data clusters relevant to the product type in question. Where the request is for multiple product types then the detail shown in the data cluster should explain to the customer the product type to which it applies or state that it is shared across multiple product types.

AISPs should not redirect the PSU to their ASPSP without first summarising the reauthentication.

3

CEG Checklist Requirements 3
AISPs should make it clear that the PSU is being asked to authenticate to extend the AISP access to their account data and that no other element of the consent (e.g., the data permissions required, the purpose for which it will be used etc.) will change.

If the customer-facing entity is acting on behalf of an AISP as its agent, the PSU must be made aware that the agent is acting on behalf of the AISP. The customer-facing entity must also display the AISP’s full trading name.

This can be presented to the PSU by displaying both the agent’s name and the regulated AISP name as:

For you to use this service, acting on behalf of need to access information from your accounts at YOUR ASPSP.

4

CEG Checklist Requirements 4
ASPSPs must not replay the data requested (as a default) or seek reconfirmation of consent.

If an ASPSP is applying for the Art 10A exemption, following the application of initial SCA, ASPSPs must not apply SCA unless they have proportionate and objective reasons for doing so e.g. fraud or unauthorised access or revoked access accidentally at the ASPSP or request more data than permitted under Art 10a e.g. 100days of data.

5

CEG Checklist Requirements 5
As part of the authentication journey, the ASPSP could have a call to action, for example, to an expandable section that the PSU can click on for information purposes only.

If the ASPSP provides this option for the PSU as supplementary information, it will enable the PSU to view the data they have chosen to share with the AISP. This should be done using the structure and language recommended by OBL following customer research (see Data Cluster Structure & Language below).

ASPSPs must display the AISPs’ 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 TPP even if it is different.

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. (Please note that ASPSPs can show the Agency/On Behalf field only in cases where this information has been provided by AISPs).

For examples of what names should be displayed, please refer to the Examples section below.

6

CEG Checklist Requirements 6
AISPs should confirm the successful completion of the account information request to the PSU.

Please refer to the section on PSU Notifications for the journey that starts from a customer alert.

CEG Checklist Requirements & Customer Experience Considerations

1

In circumstances where re-authentication needs to be performed by the ASPSP to refresh AISP access, AISPs should alert the PSU. There are many ways a PSU could receive this notification: as an alert, a message from the homepage or when checking their Consent Dashboard.

If the PSU reauthenticates at their ASPSP via their Consent Dashboard, the customer journey would be as set out in the wireframes: Consent Dashboard Homepage, a Detailed Consent Page, a Summary of reauthentication details followed by a confirmation page.

If the PSU is notified that they need to reauthenticate with their ASPSP, the AISP can take the PSU straight to the Summary of reauthentication page

16

2

AISPs must present a high-level summary of the data that is being requested and make it clear that this data and the purpose for which it will be used are the same as when originally requested. This should be done using the structure and language recommended by Open Banking Ltd (OBL) following customer research (see Data Cluster Structure & Language below). AISPs must ensure that this request is specific to only the information required for the provision of their account information service to the PSU.

AISPs should only present those data clusters relevant to the product type in question.  Where the request is for multiple product types then the detail shown in the data cluster should explain to the customer the product type to which it applies or state that it is shared across multiple product types.

AISPs should not redirect the PSU to their ASPSP without first summarising the reauthentication.

13b

3

AISPs should make it clear that the PSU is being asked to authenticate to extend the AISP access to their account data and that no other element of the consent (e.g., the data permissions required, the purpose for which it will be used etc.) will change.

If the customer-facing entity is acting on behalf of an AISP as its agent, the PSU must be made aware that the agent is acting on behalf of the AISP. The customer-facing entity must also display the AISP’s full trading name.

This can be presented to the PSU by displaying both the agent’s name and the regulated AISP name as:

For you to use this service, <Agent trading name> acting on behalf of <AISP Trading Name> need to access information from your accounts at YOUR ASPSP.

4

ASPSPs must not replay the data requested (as a default) or seek reconfirmation of consent.

If an ASPSP is applying for the Art 10A exemption, following the application of initial SCA, ASPSPs must not apply SCA unless they have proportionate and objective reasons for doing so e.g. fraud or unauthorised access or revoked access accidentally at the ASPSP or request more data than permitted under Art 10a e.g. 100days of data.

17 17c

5

As part of the authentication journey, the ASPSP could have a call to action, for example, to an expandable section that the PSU can click on for information purposes only.

If the ASPSP provides this option for the PSU as supplementary information, it will enable the PSU to view the data they have chosen to share with the AISP. This should be done using the structure and language recommended by Open Banking Ltd (OBL) following customer research (see Data Cluster Structure & Language below).

ASPSPs must display the AISPs’ 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 TPP even if it is different.

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. (Please note that ASPSPs can show the Agency/On Behalf field only in cases where this information has been provided by AISPs).

For examples of what names should be displayed, please refer to the Examples section below.

6

AISPs should confirm the successful completion of the account information request to the PSU.

NOTE

“Agent” means a person or entity who acts on behalf of an authorised payment institution or a small payment institution in the provision of payment services including account information services.

When an agent acts on behalf of the AISP, the PSU must in the case of requirement item 2, and should in the case of requirement 5 be made aware of this within the consent journey.

Please see details in requirements items 2 and 5.

 

90-day access period

With the PSU’s consent, the AISP can access account information covering any period of time going back, provided that the information is available to the PSU in their direct channels and the AISP does not request more account information than they need to support their service proposition.

For example, let’s say the PSU (on 26 March 2022) consents to AISP1 accessing the last three years of account information (i.e., from 27 March 2019 – 26 March 2022) from ASPSP2 with the consent validity lasting until 26 September 2023. If ASPSP2 applies for the Article 10A exemption, AISP1 can then continue to access either or both of the account balance and/or payment transactions executed in the last 90 days (including standing orders and direct debits) until 23 June 2022 unless otherwise where required by the ASPSP. Practically, when an ASPSP2 applies for Article 10A exemption, the AISP1 may request periodic account information, using the token within the parameters of Article 10A i.e., balances and/or transactions executed within the last 90 days(including standing orders and direct debits). On 23 June 2022, the AISP will be required to reconfirm consent with the PSU in order to continue to access the account information for a further 90 days.

There may be certain circumstances where the ASPSP2 apply SCA within the 90 day period for example, where information requested is outside the parameters of Article 10A exemption or where ASPSP2 has objective and proportionate reasons for applying SCA e.g. fraud or unauthorised access. This is supported by the Open Banking specification.

Amending Consent

In situations where a PSU wants to amend the consent they have given to an AISP (e.g., they want to allow the AISP access to additional data elements) the AISP will have to take the PSU through a new consent process as the API specifications do not support the ability to edit specific elements of consent. It is in the domain of the AISP to clearly explain this process to the PSU and develop customer journeys for each scenario where this might apply. This will also require a new application of SCA by the ASPSP.

Accounts associated with AISP long lived consent

From a technical perspective, the consent given by the PSU with respect to account information is bound to the data clusters requested by the AISP and the period over which access has been requested (including any expiry date). The actual selection of the designated payment account(s) then happens in the ASPSP space. The designated payment account(s) could subsequently change for the following reasons:

In these circumstances, the consent given to the AISP is still valid (provided it is “long-lived”), and the AISP should check the most updated list of designated payment accounts during subsequent requests for data access.

 

Principle 3: Be as transparent as possible

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 AISPs 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.

History example

Where the PSU has revoked access, or the consent has expired, the AISP should provide a list of these previous connections as shown below. The date this consent arrangement ended must be shown, and the other information provided should match what is provided for active connections. If the AISP does not provide an archive on the Dashboard it must nevertheless be available on request.

 

Figure 13: AIS Consent Dashboard history example

 

Main content image

CEG Checklist Requirements & Customer Experience Considerations

1

AISPs must make available all the cancelled or expired consent including details of consent parameters under history of consents.

Note: The duration of how long this is available on the Dashboard is in the competitive space of the AISP.

9e

2

AISPs must make all the details of the consent available:

  • Consent granted
  • Consent expired/cancelled date
  • Ability to expand consent from account and to account details
  • Consent status (Expired/Cancelled)

9d

 

Consent Dashboards When Using an Agent of an AISP

If a regulated AISP is using an agent when providing payment services, there are additional requirements for the Consent Dashboard. If you would like clarity on the FCA’s definition of agency arrangements under PSD2, see here for more detail.

To ensure control and transparency to PSUs, a PSU using an agent of an AISP should have the same ability to access a Consent Dashboard as if they were using the AISP services directly. It is imperative this information is provided to ASPSPs using the ‘On behalf of’ field of the software statement.

Apart from the detail set out below, all other requirements remain unchanged compared to a Dashboard when no agent is involved.

Figure 14: AIS Consent Dashboard when using an agent


CEG Checklist Requirements & Customer Experience Considerations

1

In addition to other requirements, if an AISP is using an agent when providing payment services, the AISP must ensure there are no additional obstacles to a PSU accessing the Consent Dashboard. The agent must provide a clear, easy to find the link to your Consent Dashboard so that the user is able to access this simply from within the agent’s website or app (or be seamlessly linked from it). It should not require additional logins or the creation of a separate account with the AISP. The PSU must be able to access the Consent Dashboard as simply as if they were using the service of the AISP directly.

The Consent Dashboard Home Screen should include text that clarifies that “[Agent Name] is an authorised agent of [AISP Name]” to prevent PSU confusion.

AISPs must populate the Agent company name in the ‘On behalf of’ field of the Software Statement, in order to inform the ASPSP about the agency relationship and allow the ASPSP to be able to display this information to the PSU. Only in instances where there is an Agent acting on behalf of the AISP should the ‘On Behalf of’ field be populated on the Software Statement. AISPs must not populate the ‘On behalf of’ field with the details of their TSP

8e

 

Consent Dashboards When Onward Sharing Open Banking data to a Third Party not providing AIS (TPNPA)

If a regulated AISP is onward sharing data to a Third Party not Providing AIS (TPNPA), there are additional requirements for the Consent Dashboard. If you would like clarity on the FCA’s definition of a TPNPA, see here.

Apart from the detail set out below, all other requirements remain unchanged compared to a Dashboard when no TPNPA is involved.

Figure 15: AIS Consent Dashboard when onward sharing is occurring


CEG Checklist Requirements & Customer Experience Considerations

1

In addition to the requirements set out above, if an AISP is sharing data it has obtained via their account information service with a Third Party not providing AIS (as defined by the FCA here), it should detail this onward sharing arrangement on the Consent Dashboard. This should include:

  • The party or parties who are receiving data from the AISP
  • The data which is being shared (if it is a sub-set of extraction from the overall data which is accessed from the ASPSP)
  • How long this onward sharing arrangement will continue
  • How the PSU can stop the onward sharing arrangement (if possible)
  • A reminder of why the data is being onward shared.

This onward sharing statement should be constructed as follows, with the AISP including all details which are relevant for their version of onward sharing:

“We are sharing [detail of data being shared] from your connected accounts with [list all other parties with who you share data] in order to [reminder of the service the TPNPA is providing]. This will continue until [insert date]. [Insert detail on how the PSU finds out more or manages this arrangement if appropriate]”

9f

Examples

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 TradesABC Company LtdABC Trades
ABC Company LtdABC Company LtdABC Company Ltd
ABC Company LtdABC Company LtdOBO LtdOBO Ltd on behalf of ABC Company Ltd
ABC TradesABC Company LtdOBO LtdOBO 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

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