Customer Experience Guidelines

Change Log

This version is:

Published 2 years ago 04 Apr 2022
A summary list of changes from V3.1.9 to V3.1.10  Changes are indicated as follows. Copy…

Other pages in this section

A summary list of changes from V3.1.9 to V3.1.10 

Changes are indicated as follows. Copy that has been removed is struck out and copy which has been added is in blue.

ID/SectionSub section/LocationChangeReason for Change

1HomepageThe 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
Payment Initiation Services (PIS)
2PIS Core JourneysOpen 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		Errata fix to update missing or incorrect links
Account Information Consent
3WireframeScreen 2 changed

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
4Table-New CX Consideration #4The 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
5Wireframe & TableChange CX Consideration #4 to #5, #5 to #6, #8 to #9.

Change CEG Checklist #6 to #7, #7 to #8, #9 to #10.
AIS Access for PSUs from Corporate Entities
6WireframeScreen 2 changed.

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
7Table-New CX Consideration #4The 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
8Wireframe & TableAdd new CX Consideration #4, Changed #4 to #5
Change CEG Checklist requirement #5 to #6
90-Days Re-authentication (delegated SCA)
990 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
10OverviewThe 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.
11Removed
For more details on 90 day access period refer to Reconfirming AISP access
AIS Consent Dashboard – Revocation, Reconfirm,Re-auth
12Renamed page AIS Consent dashboard revocation and refreshAIS Consent Dashboard – Revocation, Reconfirm,Re-authOverview

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
    13Principle 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
    		•
    14All figures changed to align with dates for AISP1, AISP2 as per the above note
    15Principle 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
    16Update 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
    17Figure 5: AIS Consent Dashboard detailed page
    		Wireframe 1
    del>For your protection, rRegulation requires that you refresh
    reconfirm your consent every 90 days
    18Figure 6: AIS Consent Dashboard detailed page expanded with information bubbleUpdate 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'
    19Table-CEG Checklist requirement #2The 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 refresh reconfirmation 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.
    		•
    20Table-CEG Checklist requirement #4AISPs 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.
    21Table-CX Consideration #6AISPs 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
    22Table-CX Consideration #7AISPs 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
    23Table-CEG Checklist requirement #8AISPs 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
    		•
    24Revocation 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'
    25Refreshing access every 90 days Reconfirm consent at the AISPThe 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
    26Figure 9: Reconfirm single / multiple AIS access from a AISP customer alert or directly from the DashboardNew Tubemap Journey to reconfirm consent to AISP to multiple ongoing ASPSP connections.

    		90 days
    27Figure 10: Reconfirm single / multiple AIS access from the Consent DashboardNew Wireframe to reconfirm consent to AISP to multiple ongoing ASPSP connections.
    28Table-CEG Checklist requirement #1AISPs 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.
    29Table-CX Considerations #2AISPs 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.
    30Table-CEG Checklist requirement #3AISPs 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).
    31Table-CEG Checklist requirement #4AISPs 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.
    32Table-CEG Checklist requirement #5AISPs must allow the PSU to explicitly reconfirm their consent with equal prominence given to continue or discontinue the service.
    33CX consideration #6AISPs should provide confirmation to the PSU that reconfirmation of consent has been successfully completed.refreshed
    34Re-authentication of accessNew 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.
    35Figure 911: Refreshing Reauthenticate AIS access from AISP customer alert or directly from the DashboardUpdated Tubemap journey

    Confirmation of Refresh - Reconfirmation of consent

    Refresh complete - Authentication complete
    36Figure 1012: RefreshingRe-authenticate AIS access from the Consent DashboardUpdated wireframe

    Screen 2- Replace Refresh by [DATE] with Reconfirm by [DATE]
    and Consent expiry [DATE]

    Screen 3- Refresh connection Reauthentication required

    Screen 4- Authenticate to refresh connection
    Screen 5- Connection refreshed to Connected to
    37Table-CEG Checklist requirement #1In 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
    38Swapped #2 and #3 on wireframe and tableErrata fix
    39Table-CEG Checklist requirement #4ASPSPs 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
    4090-day access periodWith 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
    41Amending ConsentIn 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 ASPSP90 days
    42Figure 11: AIS Consent Dashboard history exampleRenumbered to Figure 13
    43Figure 12: AIS Consent Dashboard when using an agentRenumbered to Figure 14
    44Figure 13: AIS Consent Dashboard when onward sharing is occurringRenumbered to Figure 15
    45ExamplesNote: 'On behalf of' field should be the customer-facing entity name if it is different from the TPP Trading nameclarification
    Dashboards
    46Figure 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
    47Figure 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'
    AIS Access Dashboard & Revocation
    48OverviewASPSPs 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
    49NotePlease 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.
    		•
    50Figure 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
    51Principle 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
    52Figure 5: ASPSP Access Dashboard for AIS detailed pageOn 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
    53Figure 6: ASPSP Access Dashboard for AIS detailed page expandedScreen 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
    54Table-CEG Checklist requirement #3The 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)).

    Note: Refer to alternate ways of how this information can be displayed on Dashboards - Figure 3: Access Dashboards that handle AIS (Data), VRP (Payments) and CBPII (Funds check).
    The ASPSP must provide a button that allows the PSU to revokestop sharing ongoing access arrangements. The ASPSP should provide a button that allows the PSU to refresh any access arrangements that require a refresh.
    		• 90 days &
    Consumer & SME rep feedback #8- Alternate ways to display 'Last data shared by'
    55Table-CEG Checklist requirement #5ASPSPs 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.90 days &
    HSBC feedback #8
    AIB feedback #1
    BOI feedback #1
    56Table-CX Consideration #6ASPSPs 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
    57Table-CEG Checklist requirement #7ASPSPs 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.
    58Table-CEG Checklist requirement #8ASPSPs 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
    59Figure 8: ASPSP access revocation journey for AISScreen 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
    60CX Consideration #2ASPSPs 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.
    61Refreshing accessSection removed
    62Examples Note: 'On behalf of' field should be the customer-facing entity name if it is different from the TPP Trading nameClarification
    63All relevant wireframesReplaced word 'Stop access' and 'Disconnect' with 'Stop sharing' on all relevant wiresTerminology &
    Nationwide feedback #7
    PSU Notifications
    64Figure 2: Example notification from ASPSP confirming a successful connectionRephrased notification
    65Figure 3: Example reminder from TPP about need to refreshRephrased notificationConsumer & SME rep feedback #6
    66Reminding customers about upcoming 90-days expiration or already passed – TPP and ASPSPAt 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.
    67If 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.
    68Remove Figure 4 and renumbered Figure 5 to 9
    69Figure 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.
    70Synchronicity between Consent and Access DashboardsIt 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.    		90 days

    AND

    Consumer & SME rep feedback #7
    Common Terminology – Preferred Terms and Language
    71New sectionMoved content from 'Reference Library' to AppendixTerminology guide introduced as part of CEG
    72Recommended Language - Access DashboardsNew term
    Reconfirmation of consentReconfirm, reconfirmationReconsent
  • 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”    "
    		Moneyhub feedback #1
    Bottomline feedback #3
    Consumer & SME rep #1
    73Recommended Language - Variable Recurring Payments (VRPs)New term
    Term to describe this form of paymentPayment permission, Variable Recurring PaymentVRPVariable 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”
    		Bottomline feedback #7
    Consumer & SME rep #2
    PIS-VRP Consent Dashboard & Revocation
    75OverviewPISPs 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
    75Sub section-Re-authentication of accessThere 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
    76Figure 6: Re-authenticate PIS-VRP access from PISP customer alert or directly from the DashboardNew tube map to demonstrate re-authentication of VRP
    77Figure 7: Re-authenticate PIS-VRP access from the Consent DashboardNew journey to demonstrate reauthentication of VRP
    78Table-CEG Checklist #1In 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
    79Table-CEG Checklist #2PISPs 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.
    80Table-CX Consideration #3PISPs 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.
    81Table-CEG Checklist #4ASPSPs must not replay the Variable recurring payment requested (as a default) or seek reconfirmation of consent
    82Table-CX Consideration #5As 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. 
    83Table-CX Consideration #6PISPs should confirm the successful completion of the refreshing access to the PSU.
    84Renumbered Figure 6,7,8 as 7,8,9
    PIS-VRP Access Dashboard & Revocation
    85Figure 3: ASPSP Access Dashboard for PIS-VRP detailed page expanded
    Figure 5: ASPSP Access Dashboard revocation journey for PIS-VRP
    Figure 6: PIS-VRP Access Dashboard history example

    		Updated to include Payer account details (From account)HSBC feedback #19
    86Figure 8: ASPSP Access Dashboard for PIS-VRP when PIS is using a customer-facing service providerFix on the wireframe to display customer-facing entity nameErrata fix
    87Figure 3: ASPSP Access Dashboard for PIS-VRP detailed page expandedErrata fix to payment rules on wireframe
    88Figure 5: ASPSP Access Dashboard revocation journey for PIS-VRPFix on the wireframe to remove bubble 4
    Examples and Additional Detail for CEG Checklist Questions
    89#17
    		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.    		90 days
    Read/Write API Specification – Standard Error Codes
    90Fixed broken linkOBIE Internal Review
    VRP Payments with an SCA exemption
    91CEG Checklist requirement #10ASPSPs 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
    92Table-CX Consideration #11The 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
    93Renumbered #10 onwardsOBIE Internal Review
    94Wireframe 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
    VRP Payments under Sweeping Access
    95CEG Checklist requirement #10ASPSPs 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
    96CX Consideration #11The 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
    97Renumbered #10 onwardsOBIE Internal Review
    98Wireframe 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
    VRP Payments with delegated SCA
    99CEG Checklist requirement #10ASPSPs 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
    100CX Consideration #11The 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
    101Renumbered #10 onwardsOBIE Internal Review
    102Wireframe 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    		Terminology
    Payment Refunds
    103Table-CX Consideration #4Updated 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    		OBIE internal review
    Explanation of the Customer Experience Guidelines Checklist
    104An updated new version of the checklist. Items in orange are changedOBIE Internal Review and 90 days
    CBPII Access Dashboard & Revocation
    105Figure 2: ASPSP Access Dashboard for CBPII home page and information bubbleWireframe - replaced CEG Checklist requirement #1 with CX Consideration #1 OBIE internal review errata fix
    106Figure 3: ASPSP Access Dashboard for CBPII detailed pageWireframe and Table - replaced CX Consideration #4 with CEG Checklist requirement #4
    The Customer Experience Checklist
    107CEG ChecklistAdded new checklist reference 16a, 16b, 16c, 16d, 17c, 28e
    Updated 17a from required to customer required
    		OBIE Internal Review and 90 days
    108CEG ChecklistUpdated new FCA regulatory reference for most of the checklist items to align to the correct numbers in the FCA approach payment services electronic money 2017Change to regulatory reference number in checklist