Changes are indicated as follows. Copy that has been removed isstruck outand copy which has been added is inblue.
ID/Section
Sub section/Location
Change
Reason for Change
1
Homepage
The Open Banking Read/Write API specifications support Account Information Services (AIS). They enable an Account Information Service Provider (AISP) to access account information from online payment accounts held at Account Service Payment Service Providers (ASPSPs), in order to provide account information services to a Payment Service User (PSU), provided they have obtained the PSU’s explicit consent.
This section describes the core journeys that support the set-up and management of AIS. The key components are:
Account Information Consent - PSU giving consent to an AISP to request account information from their ASPSP Refreshing AISP Access - PSU authenticating at their ASPSP to refresh on-going access they previously given consented to
Consent Dashboard and Revocation - AISP facility to enable a PSU to view and revoke consents given to that AISP
Access Dashboard and Revocation - ASPSP facility to enable a PSU to view all AISPs that have access to their account(s) and the ability to revoke that access. This must be available on all channels that a PSU could access via the ASPSP directly and be easy and intuitive for PSUs to find and use. This facility should not include unnecessary steps, superfluous information or language which could discourage the use of TPP services or divert the PSU from the access management process.
Generic guidance around the effective use of re-direction screens (when the PSU is transferred to and from the ASPSP domain) is included in section Effective use of redirection screens.
Access Status Notifications by ASPSPs – Notifications by ASPSPs to inform AISPs about access revocation and other access status changes related to the PSUs account(s).
AIS Access for PSUs from Corporate Entities – PSU acting with delegated user authority on behalf of a corporate entity, may only be able to use AISP services, if this is permitted within the parameters of that delegated user authority.
(Note: This section does not include guidance around scenarios when more than one TPP is involved in the delivery of a service - sometimes referred to as "Onward Provisioning". This subject will be addressed as part of the on-going OBIE evaluations of eIDAS and Consent/Access Dashboards.)
Errata fix as these sections were moved to Dashboard
Open Banking API specifications support Payment Initiation Services (PIS) that enable a PISP to initiate a payment order, with the PSU’s explicit consent, from their online payment account held at their ASPSP. The PISP is then further able to retrieve the status of a payment order. This section describes how each of the Participants (PISPs and ASPSPs) in the delivery of these services can optimise the customer experience for these services. Furthermore, it provides some clarifications to these Participants on the usage of the APIs which are not covered by the technical specifications, and some best practice guidelines for implementation of the customer journeys.
Please note that ASPSPs do not need to support the initiation of certain payment methods described in this section by a PISP, where the ASPSP does not support such transactions through any of their own online channels (such as future-dated foreign transactions and bulk payment files).
If the customer is able to initiate, for example, international payments, recurring transactions or a batch file of payments online, they should also be able to do so via a PISP, irrespective of the channel the customer has used to access the PISP1. 1FCA consultation on updated Approach to RTS and EBA guidelines under revised PSD2 CEG Checklist Reference
Add new CX Consideration (4) - “Additional Info - From 26 March 2022, the rules for access to account information are changing. This means that in the future you won't need to regularly re-authenticate with your bank to continue to use our service, except in certain circumstances when they may need additional reassurance to check that it is you.
You will instead need to reconfirm your consent with us every 90-days. We will remind you when you need to do this.
90 days &
Consumer & SME Rep feedback #3
4
Table-New CX Consideration #4
The AISP should make the PSU aware that every 90 days the PSU need to reconfirm their consent to the AISP in order to continue to use their service.
The AISP should also inform the PSU that they no longer are required to re-authenticate with their bank, unless there are permitted circumstances.
90 days
5
Wireframe & Table
Change CX Consideration #4 to #5, #5 to #6, #8 to #9.
Change CEG Checklist #6 to #7, #7 to #8, #9 to #10.
Additional Info -
From the 26 March 2022, the rules for access to account information are changing. This means that in the future you won't need to regularly re-authenticate with your bank to continue to use our service, except in certain circumstances when they may need additional reassurance to check that it is you.
You will instead need to reconfirm your consent with us every 90-days. We will remind you when you need to do this
90 days &
Consumer & SME Rep feedback #3
7
Table-New CX Consideration #4
The AISP should make the PSU aware that every 90 days the PSU need to reconfirm their consent to the AISP in order to continue to use their service.
The AISP should also inform the PSU that they no longer are required to re-authenticate with their bank, unless there are permitted circumstances.
90 days
8
Wireframe & Table
Add new CX Consideration #4, Changed #4 to #5
Change CEG Checklist requirement #5 to #6
90 days reauthentication enhancement90 days re-authentication with (delegated SCA)
moved this journey to Appendix. Renamed to 90 days re-authentication (delegated SCA)
Rename refresh on all the wires and table
This journey is not relevant to UK hence moving it to Appendix
10
Overview
The PSRs requireIn the European Union, PSD2 requires Strong Customer Authentication (SCA) 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. Moreover, the 90-day exemption doesn’t apply if the AISP wants to access more than the last 90 days’ worth of transactions.
11
Removed For more details on 90 day access period refer to Reconfirming AISP access
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:
How to make these Dashboards effective tools for PSUs
How the revocation journey should be constructed
How to inform the PSU that consent requires refresh reconfirmation with the AISP at least every 90 days.at their ASPSP
How to inform the PSU that they may be required to re-authenticate at their ASPSP only in permitted circumstances.
Additional requirements if an AISP is using an agent
Additional guidance if a regulated party is sharing data with another non-PSD2 party
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:
Checking that a connection is live
Reminding a PSU which accounts they are sharing data from and for how long
Informing a PSU how long access will continue for
Clarifying what data the AISP can access
Revoking access to one or more payment accounts
Refreshing access Reconfirming consent at the AISP, provided the consent is valid i.e. has not expired
Re-authenticate at their ASPSP in permitted circumstances.
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.
90 days
13
Principle 1: Easy to find and locate
Section -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.
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
14
All figures changed to align with dates for AISP1, AISP2 as per the above note
15
Principle 2: Intuitive to use and understand
Figure 4: AIS Consent Dashboard home page with information bubble
Update wireframe screen 1, 2
Open banking connected accounts
These are the account providers we are getting your data from
For your protection, rRegulation requires you to refresh reconfirm your consentconnection with your account providers us at least every 90 days if you wish us to continue accessing your data.
90 days &
Truelayer feedback #1 - removed - For your protection
16
Update wireframe screen 2
Open banking connected accounts
These are the account providers we are getting your data from
For your protection, rRegulation requires you to refresh reconfirm your consentconnection withyour account providers us at least every 90 days if you wish us to continue accessing your data.
Info bubble change
This page gives you an overview of all the accounts you have connected.
You can click on the Manage button to find out more. You can disconnect the account at any time if you change your mind.
For your protection, rRegulation requires that you refresh reconfirm each of your consents connection every 90 days.
From the 26 March 2022, the rules for access to account information are changing. This means that in the future you won't need to regularly re-authenticate with your bank to continue to use our service, except in certain circumstances when they may need additional reassurance to check that it is you.
You will instead need to reconfirm your consent with us every 90-days. We will remind you when you need to do this
17
Figure 5: AIS Consent Dashboard detailed page
Wireframe 1
del>For your protection, rRegulation requires that you refresh
reconfirm your consent every 90 days
18
Figure 6: AIS Consent Dashboard detailed page expanded with information bubble
Update wireframe screen 2 - Info bubble.
For your protection, you are required by regulation to refresh each of your connections at least every 90 days.
From the 26 March 2022, the rules for access to account information are changing. This means that in the future you won't need to regularly re-authenticate with your bank to continue to use our service, except in certain circumstances when they may need additional reassurance to check that it is you.
You will instead need to reconfirm your consent with us every 90-days. We will remind you when you need to do this but if you want to do it now then you can click on 'Reconfirm'
19
Table-CEG Checklist requirement #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 each ASPSP access requires a 90-day refresh reconfirmation of 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 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 that is either “Active” or “Refresh Reconfirm” (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 refreshreconfirmation date it should start to alert the PSU depending on their business model.
The AISP must also provide a manage button whichthat allows the PSU to revoke (disconnect) or refreshreconfirm consent.
20
Table-CEG Checklist requirement #4
AISPs must use just two status flags: “Active” or “Refresh" "Reconfirm”. 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 the PSU Notifications page for further details.
21
Table-CX Consideration #6
AISPs should provide additional explanatory text to help PSUs understand complex areas such as 90-day refresh 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.
Nationwide feedback #3 - Replace bank with ASPSP
22
Table-CX Consideration #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 reconfirmed for more than 90 days, and therefore access is expired but can be refreshed reconfirmed, it should not be placed in the history, but listed on the Consent Dashboard homepage with a “Refresh” status.
90 days
23
Table-CEG Checklist requirement #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 (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 access 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 refreshed reconfirmed their access consent
24
Revocation journey
Figure 8: AIS consent revocation journey
Screen 1 updated to replace refresh status with reconfirm and dates changed as per note
Default button on screen 2 changed to 'Stop sharing'
25
Refreshing access every 90 days Reconfirm consent at the AISP
The Consent Dashboard plays a key role in encouraging and reminding PSUs to refresh access reconfirm their consent to the AISP or re-authenticate with their ASPSP to ensure their connected accounts are 'Active' and 'Connected'. The section on PSU Notifications shows several ways in which AISPs can remind their customers of the need to refresh access reconfirm their consent and explain why they are required to obtain it, and the information in the Consent Dashboard should make clear when refresh reconfirmation or re-authentication is required.
We note that some AISPs may wish to encourage PSUs to refresh access 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 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. 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 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.
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 refresh reconfirm consent 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).
90 days &
Truelayer feedback #1 - removed - For your protection
26
Figure 9: Reconfirm single / multiple AIS access from a AISP customer alert or directly from the Dashboard
New Tubemap Journey to reconfirm consent to AISP to multiple ongoing ASPSP connections.
90 days
27
Figure 10: Reconfirm single / multiple AIS access from the Consent Dashboard
New Wireframe to reconfirm consent to AISP to multiple ongoing ASPSP connections.
28
Table-CEG Checklist requirement #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 reconfirm 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 of completion after authentication at AISP.
AISPs must not access data if the PSU has not reconfirmed consent.
29
Table-CX Considerations #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 reconfirm 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.
30
Table-CEG Checklist requirement #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).
31
Table-CEG Checklist requirement #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.
32
Table-CEG Checklist requirement #5
AISPs must allow the PSU to explicitly reconfirm their consent with equal prominence given to continue or discontinue the service.
33
CX consideration #6
AISPs should provide confirmation to the PSU that reconfirmation of consent has been successfully completed.refreshed
34
Re-authentication of access
New section
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 reauthenticate 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. 100days of data.
35
Figure 911: Refreshing Reauthenticate AIS access from AISP customer alert or directly from the Dashboard
Updated Tubemap journey
Confirmation of Refresh - Reconfirmation of consent
Refresh complete - Authentication complete
36
Figure 1012: RefreshingRe-authenticate AIS access from the Consent Dashboard
Updated wireframe
Screen 2- Replace Refresh by [DATE] with Reconfirm by [DATE]
and Consent expiry [DATE]
Screen 4- Authenticate to refresh connection
Screen 5- Connection refreshed to Connected to
37
Table-CEG Checklist requirement #1
In circumstances where re-authentication needs to be performed by the ASPSP to refresh AISP access, AISPs should alert the PSU. 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 re-authenticates at their ASPSP 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 followed by a confirmation page.
If the PSU is notified that they need to refresh re-authenticate with their ASPSP, the AISP can take the PSU straight to the Summary of reauthentication page
38
Swapped #2 and #3 on wireframe and table
Errata fix
39
Table-CEG Checklist requirement #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.-17c
New checklist reference -17c
90 days
40
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 for 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 for 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 for 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 that 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 the 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.
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 OBIE specification.
90 days &
Nationwide feedback #6 - Rephrased section
41
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. This will also require a new application of SCA by the ASPSP
90 days
42
Figure 11: AIS Consent Dashboard history example
Renumbered to Figure 13
43
Figure 12: AIS Consent Dashboard when using an agent
Renumbered to Figure 14
44
Figure 13: AIS Consent Dashboard when onward sharing is occurring
Renumbered to Figure 15
45
Examples
Note: 'On behalf of' field should be the customer-facing entity name if it is different from the TPP Trading name
Figure 2: Consent Dashboards that handle AIS (Data), PIS-VRP (Payments) and CBPII (Funds check)
Figure 2 screen 1
Update wireframe screen 1.
Open banking connected accounts
These are the account providers we are getting your data from For your protection, rRegulation requires you to refresh reconfirm your consent connection with your account providers us at least every 90 days if you wish us to continue accessing your data
ASPSP2 align the same as Figure 4
Rename Refresh with Reconfirm
Rename connection with consent
Screen 2 and screen 3 - Aligned to new dates
90 days &
Truelayer feedback #1 - removed - For your protection
47
Figure 3: Access Dashboards that handle AIS (Data), VRP (Payments) and CBPII (Funds check)
Screen 1
For AIS 2 Remove refresh connection by date and Tap Manage to refresh.
Add Consent Expiry and date 15/10/2022
Replace Refresh status with Active status
Screen 2 and screen 3 - Aligned to new dates and language around data last shared by
90 days & Consumer & SME rep feedback #8- Alternate ways to display 'Last data shared by'
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
How an ASPSP could allow a PSU to refresh multiple connections at the ASPSP Dashboard in order to synchronise 90-day access for TPP connections
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 revoke AISP access to payment accounts
Providing the ability to refresh access
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.
90 days
49
Note
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 AIS 1 access to their current account on 17/01/2022 and this connection is currently active until 17/02/2024 i.e. within 90 days / not requiring a refresh. The PSU will need to refresh access by 17/04/2022.
The AISP 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 For AISP 2 AIS 2 access to their current account on 16/10/2021 and therefore access this connection is currently active expired on 14/01/2022 until 15/10/2022. The access needs to be refreshed by the PSU in order for the AISP to retrieve up to date information from ASPSP 2.
50
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)
In all wireframe, for AIS 2 Remove refresh connection by date and Tap Manage to refresh.
Add Connection Expiry and date 15/10/2022
Replace Refresh status with Active status
51
Principle 2: Intuitive to use and understand
Figure 4: ASPSP Access Dashboard for AIS home page
For AISP 2 Remove refresh connection by date and Tap Manage to refresh.
Add Connection Expiry and date 15/10/2022
Replace Refresh status with Active status
52
Figure 5: ASPSP Access Dashboard for AIS detailed page
On screen 1, For AISP 2 Remove refresh connection by date and Tap Manage to refresh stop sharing
Consent Expiry and date 15/10/2022
Replace Refresh status with Active status
Screen 2 : Remove button ‘Refresh now’ and make stop sharing default button
90 days
53
Figure 6: ASPSP Access Dashboard for AIS detailed page expanded
Screen 1 and Screen 2
Remove button ‘Refresh now’ and make stop sharing default button
Screen 1 - Change text on info bubble
For your protection, you are required by regulation to refresh each of your connections at least every 90 days with your AISP.
From the 26 March 2022, the rules for access to account information are changing. This means that in the future you won't need to regularly re-authenticate with us except in certain circumstances when we may need additional reassurance to check that it is you.
You will instead need to reconfirm your consent with your AISP every 90-days.
You can refresh or stop sharing at any time using the manage or stop sharing button
90 days &
Truelayer feedback #1 - removed - For your protection
54
Table-CEG Checklist requirement #3
The ASPSP must provide PSUs with sufficient information to enable them to make an informed decision on the Access Dashboard Home Page. As a minimum, ASPSPs must show on the Access Dashboard Home Page:
AISPs’ trading name/brand name
Account type
The expiry date of each access consent. (Note: Some PSUs find an access countdown helpful, but most found an expiry date clearer. ASPSPs may choose to provide a countdown but it should be used in addition to an expiry date not instead of it.)
A status flag which is either “Active”or "Connected" or “Refresh” (see #5 below on status messages; where access needs refreshing, this should be highlighted through e.g. red text or a warning message)
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)).
90 days &
Consumer & SME rep feedback #8- Alternate ways to display 'Last data shared by'
55
Table-CEG Checklist requirement #5
ASPSPs must use just two one status flags: “Active” or "Connected" as they deem appropriate.or “Refresh”. A consent is defined as active i.e. connected if it has a valid access token that has not expired due to 90 days and the consent expiry date has not elapsed and the PSU has not revoked consent at the AISP.
ASPSPs should provide additional explanatory text to help PSUs understand that 90-day reconfirmation of consent refresh is now only required at the AISP and how to revoke access; using information bubbles helps to keep information manageable.
90 days
57
Table-CEG Checklist requirement #7
ASPSPs must provide a history of old connections. This should include any access which has previously been revoked at the ASPSP, consent which that has been revoked at the AISP, and consent which that 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.
58
Table-CEG Checklist requirement #8
ASPSPs must provide a Detailed Page for each access, which includes:
AISP Trading Name
Account type (e.g. current account) of accounts being shared with TPP
Sort Code and Account Number (or other product identifier depending on the account type e.g. PAN for credit cards)
Data clusters being accessed: using the structure and language recommended by OBIE following customer research (see Data Cluster Structure & Language)
The date the AISP was first granted access
The expiry date of the access (the same as shown on the Dashboard Homepage)
The expiry of the consent or ongoing permission from [DATE] if it is an ongoing permission(in situations where the consent is not aligned to access duration and is not indefinite, for example where consent is for a fixed period such as 1 year)
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
The date when the customer last refreshed their access as part of the 90 day re-authentication.
Which party provided the AISP access, in the case of joint/ multiple account holders
90 days &
Consumer & SME rep #10
Sub section - Revocation Journey
59
Figure 8: ASPSP access revocation journey for AIS
Screen 1 - Info bubble
From the 26 March 2022, the rules for access to account information are changing. This means that in the future you won't need to regularly re-authenticate with us except in certain circumstances when we may need additional reassurance to check that it is you.
You will instead need to reconfirm your consent with your AISP every 90-days.
You can stop sharing at any time using the manage or stop sharing button
On screen 1, For AISP 2 Remove refresh connection by date. and Tap Manage to refresh stop sharing
Add Connection Expires - 15/10/2022
Replace Refresh status with Active status
Screen 2: Replace Refresh connection by with Connection expires
90 days
60
CX Consideration #2
ASPSPs should make the status of TPP access clear using “Active” or “Refresh” 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.
61
Refreshing access
Section removed
62
Examples
Note: 'On behalf of' field should be the customer-facing entity name if it is different from the TPP Trading name
Clarification
63
All relevant wireframes
Replaced word 'Stop access' and 'Disconnect' with 'Stop sharing' on all relevant wires
Figure 2: Example notification from ASPSP confirming a successful connection
Rephrased notification
65
Figure 3: Example reminder from TPP about need to refresh
Rephrased notification
Consumer & SME rep feedback #6
66
Reminding customers about upcoming 90-days expiration or already passed – TPP and ASPSP
At the very least, both TPPs and ASPSPs must display on the Consent and Access Dashboard respectively when a connection has gone past 90 days but still has a valid consent and need to be refreshed reconfirmed by the PSU.
67
If ASPSPs do choose to do inform a PSU about an upcoming expiry, it would also provide a good opportunity to educate them about the Access Dashboard specifically and/or Open Banking more generally.
68
Remove Figure 4 and renumbered Figure 5 to 9
69
Figure 4: Example notification to start a refresh journey
Screen1 - update notification example
Remove Screen 3
If performed as an app notification it can also be used as a starting point for the refresh reconfirmation of the consent journey as shown in Customer Alert.
70
Synchronicity between Consent and Access Dashboards
It is important that PSUs are not presented with contrasting information on their Consent and Access Dashboards when it comes to the status of the connection.
Due to the regulatory changes in the UK RTS, the ASPSPs does not need to authenticate the PSU every 90 days as the AISP will reconfirm consent every 90 days with the PSU instead. Since there is no requirement on the AISP to inform the ASPSP when they have reconfirmed consent with the PSU, it may be challenging for the ASPSP to show the PSU whether consent is active or not on their Access Dashboard.
We recommend that the ASPSP provides information on when data was last shared with the AISP (e.g. shown as ‘data last shared’ – date & time, today, yesterday, 7 days ago or 24 hrs ago, etc.) as this gives the greatest clarity to the PSU.
The ASPSP must ensure any messaging provided to the PSU is clear and consistent and presented in a manner that does not cause confusion
There are a series of technical solutions in place that are designed to ensure the TPP is notified of a change made through the Access Dashboard, particularly revocation of access. The most common issue that occurs today is where a PSU revokes access at the ASPSP Dashboard and the TPP consent dashboard is not updated at the same time.
These solutions can be split into “push” notifications from ASPSP to TPP, and “pull” notifications whereby the TPP “asks” the ASPSP if there have been any changes to the status of access tokens.
Moved content from 'Reference Library' to Appendix
Terminology guide introduced as part of CEG
72
Recommended Language - Access Dashboards
New term
Reconfirmation of consent
Reconfirm, reconfirmation
Reconsent
Following the FCA Policy Announcement, TPPs seeking to reconfirm consent with their customers should use the language of reconfirm or reconfirmation. This was supported in discussion at the Expert Advisory Group held in Q1 2022 and including a range of TPPs, ASPSPs and End User Representatives.
Do: “Please reconfirm your consent”
“If you wish to continue allowing us to get data from [ASPSP], please review and reconfirm the consent"
Avoid: “Please reconsent”
“After 90 days you will need to reconsent”"
Recommended Language - Variable Recurring Payments (VRPs)
New term
Term to describe this form of payment
Payment permission, Variable Recurring Payment
VRPVariable Recurring Payment
VRP or Variable Recurring Payment is technical language and is very unhelpful for consuers, particularly given that payments may not recur automatically and may not vary
There is not an ideal term to describe a Variable Recurring Payment to a consumer and we, therefore, recommend that clear explanations are used to help consumers understand what they are setting up. This could be via information bubbles or FAQ guides.
In a VRP setup journey, we recommend using the full term “Variable Recurring Payment”. Until the term is established we do not recommend using the abbreviation VRP.
On a dashboard, providers can choose whether to use Variable Recurring Payment Permissions or abbreviate to Payment Permissions. In this context, the phrase “Payment Permissions” will be clear to most consumers, although explanatory text will still be required
We recommend the use of the phrase "payment permission", subject to additional testing review as the VRP Standard is rolled out
Do: “You have given us payment permissions for these accounts” (PISP VRP Access Dashboard)
“Cancel payment permission”
“Permission from [date] to [date]”
“Tap manage to view more detail or cancel the permission”
“Permission cancelled”
“Setup payment permissionVariable Recurring Payment”
Avoid: “You are setting up a Variable Recurring PaymentVRP”
“This VRP will continue until [date]”
“Set up VRPVariable Recurring Payment Consent”
PISPs must provide PSUs with a facility to view and revoke VRP consent(s) that they have given to that PISP. PSUs may have agreed to several VRP consents for different ASPSPs with a single PISP. This section describes:
How these consents should be displayed
How the revocation journey should be constructed
How to inform the PSU that consent is set to expire
Additional requirements if the PISP is not customer facing
Dashboards play an important role in clearly and transparently setting out what conditions a PSU has provided consent for a PISP to do on their behalf. They, therefore, play a role in multiple user journeys, including:
Allowing the PSU to easily navigate to PISP Consent Dashboard if PISP is not customer facing
Checking that a connection is live
Reminding a PSU which account(s) are involved
Making clear to a PSU what VRP Consent parameters were set
Informing a PSU how long the arrangement will continue for (i.e. consent expiry)
Allowing the PSU to easily cancel consent
Re-authenticate at their ASPSP in permitted circumstances.
The VRP Consent Dashboard should therefore be easy to find and our research demonstrates that being able to find the Dashboard easily and making it easy to understand plays a key role in building trust with open banking-enabled services.
In instances where the PSU is giving consent to a PISP via a third party because the PISP is not directly customer-facing, it should be easy to find the PISP Consent Dashboard.
The customer-facing service provider should make it clear that consent is given to the PISP.
OBIE Internal Review
75
Sub section-Re-authentication of access
There may be instances where an ASPSP may require SCA, even if the payment is made is to a trusted beneficiary, for example, suspicion of fraud. However, the ASPSP must only do so in permitted circumstances with an objective approach and in line with the proportionality requirements of the PSRs.
This section describes the customer journey when a PSU needs to re-authenticate with their ASPSP in order to enable further Variable recurring payments within a pre-existing VRP consent. All other elements of the VRP consent remain unchanged.
OBIE Internal Review
76
Figure 6: Re-authenticate PIS-VRP access from PISP customer alert or directly from the Dashboard
New tube map to demonstrate re-authentication of VRP
77
Figure 7: Re-authenticate PIS-VRP access from the Consent Dashboard
New journey to demonstrate reauthentication of VRP
78
Table-CEG Checklist #1
In circumstances where re-authentication needs to be performed by the ASPSP to refresh PISP access, PISPs 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 PISP can take the PSU straight to the Summary of reauthentication page
79
Table-CEG Checklist #2
PISPs must present a high-level summary of the consent parameters and make it clear that this data and the purpose for which it will be used are the same as when originally requested.
PISPs should not redirect the PSU to their ASPSP without first summarising the reauthentication.
80
Table-CX Consideration #3
PISPs should make it clear that the PSU is being asked to authenticate to refresh the PISP access to continue to make payment and that no other element of the consent (e.g., the consent parameters, expiry date etc.) will change.
If the customer-facing entity is acting on behalf of a PISP, the PSU must be made aware that it is acting on behalf of the PISP. The customer-facing entity must also display the PISP’s full trading name.
81
Table-CEG Checklist #4
ASPSPs must not replay the Variable recurring payment requested (as a default) or seek reconfirmation of consent
82
Table-CX Consideration #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 variable recurring payment details like consent parameters and payment account details they have chosen to share with the PISP.
ASPSPs must display the PISPs’ trading name/brand name (i.e., the Client Name in the software statement) to the PSU during authentication screens. They do not need to display the registered company name of the TPP even if it is different.
If there is a customer-facing entity acting on behalf of the PISP, ASPSPs must also display that name (as captured in the ‘On behalf of’ field of the software statement) to the PSU.
83
Table-CX Consideration #6
PISPs should confirm the successful completion of the refreshing access to the PSU.
Authenticating to refresh accessReauthentication of access
There an example in Refreshing AISP Reauthentication of access that clarifies this. In this example, nothing in the consent request has changed (e.g. the PSU gave consent for account information to be shared for the payment account and wishes the TPP to continue to have access to the account).
If the PSU has an opportunity to reselect or change the consent request and accounts being shared, this requires a full end to end the journey as per the initial consent journey including account selection as in Account Information Consent.
The point of this question is to ensure that the journey in Refreshing AISP accessReauthentication of access is shorter than that in Account Information Consent.
ASPSPs must support all the periodic limits and be capable to handle multiple periodic limits in a single consent.
The ASPSPs may restrict to one-period alignment (i.e. consent or calendar) for a single periodic limit in a single consent.
Note – e.g.: Max cumulative amount per calendar year and Max cumulative amount per consent year may not be an acceptable combination in one VRP consent, however, Max cumulative amount per calendar year and Max cumulative amount per consent month is acceptable.
OBIE Internal Review
92
Table-CX Consideration #11
The ASPSP should not put restrictions when the consent is set up but can apply restrictions if the amount(s) in the individual payment orders submitted exceed the limits in the direct, online channels.
OBIE Internal Review &
Changed requirement from may to should not based on Nationwide feedback #9
HSBC feedback #12
93
Renumbered #10 onwards
OBIE Internal Review
94
Wireframe
Changes on Screen1
Setup VRP VRP setup Payee name Payment to Debto Reference
Addition of subhead: Payment rules Period Expiry date
Changes on Screen2
Permission to initiate Variable Payments Setup Variable Recurring Payment TPP TRADING NAME need your permission to setup VRP with YOUR ASPSP to make variable payment(s) within the consent parameter(s) you have agreed below
We need your permission to setup a Variable Recurring Payment (VRP) with [YOUR ASPSP] within the payment rules below:
Addition of subhead: Payment Rules
Additional field: Payment to Payee name Payment To Debtor Reference
Maximum amount per MONTH
Maximum amount per payment Payee information To Account Payer information From Account
We will can make payments until
Changes on Screen 3
Addition of main head:Variable Recurring Payment
TPP TRADING NAME need your permission to make VRPpayment(s) from your account within the payment limits below:
[TPP TRADING NAME] needs your permission to make payment(s) from your account within the payment rules below:
Addition of subheads:
Who you're paying
Payment Rules
From account Payee namePayment To Debtor Reference
Maximum amount per Month
Maximum amount per payment
We will add MERCHANT to yourtrusted beneficiary list of payees..
Authenticate to setup VRP
Changes on Screen 4
VRP setup confirmation Setup successful
You have successfully setup a Variable Recurring Payment VRP with YOUR ASPSP
Remove: VRP Details
View the details Payment Rules
ASPSPs must support all the periodic limits and be capable to handle multiple periodic limits in a single consent.
The ASPSPs may restrict to one-period alignment (i.e. consent or calendar) for a single periodic limit in a single consent.
Note – e.g.: Max cumulative amount per calendar year and Max cumulative amount per consent year may not be an acceptable combination in one VRP consent, however, Max cumulative amount per calendar year and Max cumulative amount per consent month is acceptable.
OBIE Internal Review
96
CX Consideration #11
The ASPSP should not put restrictions when the consent is set up but can apply restrictions if the amount(s) in the individual payment orders submitted exceed the limits in the direct, online channels.
OBIE Internal Review Changed requirement from may to should not based on Nationwide feedback #9
HSBC feedback #12
97
Renumbered #10 onwards
OBIE Internal Review
98
Wireframe
Changes on Screen 1
Setup Sweeping Consent Sweeping Transfer Setup Payee bankAccount Provider Payee namePayment to Debtor Reference
Addition of subhead: Payment rules
Maximum amount per MONTH
Maximum amount per payment PeriodExpiry Date
Changes on Screen 2
Permission to initiate Variable Payments Setup Variable Recurring Payment
TPP TRADING NAME need your permission to setup VRP with YOUR ASPSP to make variable payment(s) within the consent parameter(s) you have agreed below
We need your permission to setup a Variable Recurring Payment (VRP) with [YOUR ASPSP] to make transfers between your accounts, within the payment rules below:
Addition of subhead: Payment rules
DebtorReference
Maximum amount per MONTH
Maximum amount per payment Payee informationTo Account Payer informationFrom Account
We will can make payments until
Changes on Screen 3
Addition of main head: Variable Recurring Payment TPP TRADING NAME need your permission to setup Variable Recurring Payment to make variable payments from your account within the below payment criteria:
[TPP TRADING NAME] needs your permission to make payment(s) from your account within the payment rules below:
Addition of subheads:
Who you're paying
Payment rules
From account Payee bank Account Provider Debtor Reference
Maximum amount per MONTH
Maximum amount per payment Payee information To Account Payee name Payment to
We will add MERCHANTYOUR ACCOUNT to your trusted beneficiary list of payees.
Authenticate to setup VRP
Changes on Screen 4
VRP setup confirmation Setup successful
You have successfully setup a Variable Recurring PaymentVRP with YOUR ASPSP
Remove: VRP Details View the details Payment Rules
ASPSPs must support all the periodic limits and be capable to handle multiple periodic limits in a single consent.
The ASPSPs may restrict to one-period alignment (i.e. consent or calendar) for a single periodic limit in a single consent.
Note – e.g.: Max cumulative amount per calendar year and Max cumulative amount per consent year may not be an acceptable combination in one VRP consent, however, Max cumulative amount per calendar year and Max cumulative amount per consent month is acceptable.
OBIE Internal Review
100
CX Consideration #11
The ASPSP should not put restrictions when the consent is set up but can apply restrictions if the amount(s) in the individual payment orders submitted exceed the limits in the direct, online channels.
OBIE Internal Review Changed requirement from may to should not based on Nationwide feedback #9
HSBC feedback #12
101
Renumbered #10 onwards
OBIE Internal Review
102
Wireframe
Changes on Screen1
Setup VRP VRP setup Payee name Payment to Debto Reference
Addition of subhead: Payment rules Period Expiry date
Changes on Screen2
Permission to initiate Variable Payments Setup Variable Recurring Payment
TPP TRADING NAME need your permission to setup VRP with YOUR ASPSP to make variable payment(s) within the consent parameter(s) you have agreed below
We need your permission to setup a Variable Recurring Payment (VRP) with [YOUR ASPSP] within the payment rules below:
Addition of subhead: Payment Rules
Maximum amount per MONTH
Maximum amount per payment
We will can make payments until
Changes on Screen 3
Addition of main head:Variable Recurring Payment
TPP TRADING NAME need your permission to make VRPpayment(s) from your account within the payment limits below:
[TPP TRADING NAME] needs your permission to make payment(s) from your account within the payment rules below:
Addition of subheads:
Payment Rules
From account
Maximum amount per MONTH
Maximum amount per payment
Authenticate to setup VRP
Changes on Screen 4
VRP setup confirmation Setup successful
You have successfully setup a Variable Recurring Payment VRP with YOUR ASPSP
Remove: VRP Details
View the details Payment Rules
Updated one paragraph with a link
Security: PISPs must have robust procedures in place to ensure account details are stored in a secure manner, in order to minimise the risk of these details being compromised. For additional information, please refer to TPP Operational Guidelines, section TPP Information Security. OBIE Security & Counter Fraud Guide
