Dashboards

AIS Consent Dashboard

This version is:

Published 2 years ago 21 Oct 2021

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.

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 18/01/2022 at 11:46 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 a refresh. The PSU will need to refresh access 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 18/01/2022 at 11:46 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 therefore access expired on 14/01/2022. The access needs to be refreshed by the PSU in order for the AISP to retrieve up to date information from ASPSP 2.

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)

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.

CEG Checklist Requirements u0026amp; CX Considerations
CEG Checklist Reference

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
CEG Checklist Reference

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 each ASPSP access requires a 90-day refresh (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 ASPSP access, 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 which is either “Active” or “Refresh” (see below on status messages)
  • Warnings or alerts if an access is close to expiry (i.e. at 90 days). The AISP can define how close to the refresh date it should start to alert the PSU depending on their business model.

The AISP must also provide a manage button which allows the PSU to revoke or refresh consents.

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 “Refresh”. 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.

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

AISPs must not show different status messages at their Consent Dashboard to those that a PSU would see at their ASPSP Access Dashboard. There are a variety of methods that an AISP can use to check that their access token is still valid. See this 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 refresh 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.

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 refreshed for more than 90 days, and therefore access is expired but can be refreshed, it should not be placed in the history, but listed on the Consent Dashboard homepage with a “Refresh” 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 OBIE 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 (the same as shown on the Consent Dashboard Homepage)
  • The expiry of the consent (in situations where the consent is not aligned to access 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 may include the following at their discretion:

  • The date when the customer last refreshed their access as part of the 90 day re-authentication.

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.rnrnOnce 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.rnrnA 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.rnrnAfter 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 u0026amp; Customer Experience Considerations
CEG Checklist Reference

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.

Refreshing access 90 days

The Consent Dashboard plays a key role in encouraging and reminding PSUs to refresh access to their connected accounts. The section on PSU Notifications shows several ways in which AISPs can remind their customers of the need to refresh access and explain why they are required to obtain it, and the information in the Consent Dashboard should make clear when refresh is required.

We note that some AISPs may wish to encourage PSUs to refresh access more frequently than every 90 days depending on their proposition.

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 the refreshing journey can be utilised. If this is not done, then the 90-day refresh is effectively a new consent request which requires a long journey. This is explained further below.

We also encourage AISPs to consider 90-days reauthentication enhancement as an option to further streamline the customer experience.

The PSRs require strong customer authentication to be performed each time the PSU accesses its online payment account, either directly or using the services of an AISP. The frequency of authentication can be reduced if an ASPSP applies the exemption relevant to account information access (RTS, Article 10).  However, this will still require the PSU to be authenticated at least every 90 days.

This section describes the customer journey when a PSU needs to refresh AISP 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. (It should be noted that the API specification allows the AISP to inform the ASPSP that the request is a refresh rather than a new request).

Figure 9: Refreshing AIS access from the AISP from a customer alert or directly from the Dashboard

Figure 10: Refreshing AIS access 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.rnrnIf 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.rnrnIf the PSU is notified that they need to reconfirm consent, the AISP can take the PSU straight to the Summary of reconfirmation page.rnrnIf 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 u0026 Confirmation completion after authentication at AISP.rnrnAISPs must not access data if the PSU has not reconfirmed consent.

2

CEG Checklist Requirements 2
rnAISPs should allow the PSU to select all the payment accounts across ASPSPs that may or may not be due for reconfirmation.rnrnAISPs 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.rnrnIf 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. rnrnAISPs 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.rnrnThe 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
rnAISPs 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
rnAISPs 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.

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

CEG Checklist Requirements & Customer Experience Considerations
CEG Checklist Reference

1

AISPs should alert the PSU when authentication needs to be performed to refresh AISP access. 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 refreshes via their Consent Dashboard, the customer journey would be as set out in the wireframes: Consent Dashboard Homepage à Detailed Consent Page à Summary of Reauthentication Details.

If the PSU is notified that they need to refresh access, the AISP can take the PSU straight to the Summary of Reauthentication page

16

2

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.

3

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 OBIE 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

4

ASPSPs must not replay the data requested (as a default) or seek re-confirmation of consent

17

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 OBIE 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 #2, and should in the case of requirement #5 be made aware of this within the consent journey.

Please see details in requirements #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 then they need to support their service proposition. Article 10 requires SCA to be performed by the ASPSP prior to the AISP’s first access and subsequently re-performed at least every 90 days (where the ASPSP is applying the Article 10 exemption) or otherwise where required by the ASPSP.

For example, let’s say the PSU (on 14 September 2019) consents to AISP1 accessing the last three years of account information (i.e., from 15 September 2016 – 14 September 2019) from ASPSP2 with the consent validity lasting until 14 September 2020. If ASPSP2 is applying the Article 10 exemption, AISP1 can then continue to access either or both of the account balance and/or the last 90 days of executed payment transactions without SCA having to be performed again until 13 December 2019, when the 90-day period expires, unless otherwise where required by the ASPSP. Practically, within the 90day period after the PSU has been authenticated with SCA, when an ASPSP2 applies the Article 10 exemption, the AISP1 may request periodic account information, using the 90-day access token within the parameters of Article 10 i.e., balances and/or transactions executed within the last 90 days.

However, when an AISP1 request includes account information which falls outside the parameters of the 90 days and Article 10 (e.g., scheduled payments) using the 90-day access token, the OBIE Standard supports application of SCA to receive any additional account information (other than balance(s) and transactions executed within the last 90 days). Upon the expiry of the 90-day access token period, the application of SCA by the ASPSP is the only step required by the ASPSP refreshing AISP access and the PSU must not be required to go through the same account(s) selection process to confirm the access. In this example, the PSU will need to provide a new consent for the AISP to access the account information after 14 September 2020.

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 in section 3.1.1) as the API specifications do not support the ability to edit specific elements of a 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.

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 11: AIS Consent Dashboard history example

Main content image

CEG Checklist Requirements & Customer Experience Considerations
CEG Checklist Reference

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 12: AIS Consent Dashboard when using an agent

CEG Checklist Requirements & Customer Experience Considerations
CEG Checklist Reference

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 13: AIS Consent Dashboard when onward sharing is occurring

 

CEG Checklist Requirements & Customer Experience Considerations
CEG Checklist Reference

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