Customer Experience Guidelines

Change Log

This version is:

Published 9 months ago 21 Oct 2021

A summary list of changes from V3.1.8 to V3.1.9 Draft.

Other Journeys in ‘v3.1.9’.

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

ID/SectionLocationChangeReason for Change
Introduction
1About these guidelinesAdded below
PSU Dashboards
The principles of trust, transparency and security are captured by Consent and Access Dashboards, a fundamental tool to ensure PSUs are adequately informed and in control of the account information, they share with TPPs, particularly AISPs and CBPIIs.
Consent and Access Dashboards were introduced to the Open Banking Standards to ensure customers were able to view, refresh and revoke (i.e. cancel) TPP consents and ASPSP access arrangements they had agreed to. 		Trustee Actions A1, A3, A4, A6, A7, A12, A13, A15 and A16 from Revised Roadmap Item - A2(b)(iii) Evaluation of Efficacy of Consent and Access Dashboards
2Customer Experience principlesAdded below
An essential component of trust-building is the provision of a Consent Dashboard by the TPP and an Access Dashboard by the ASPSP. Dashboards encapsulate the Customer Experience principles below and research has consistently shown the fundamental role they play in reassuring customers about the security of open banking-enabled services. In terms of the experience of using a Dashboard, the principles that apply to an authentication journey can be extended to support simple and easy navigation by enabling informed decision making. Please refer to the Dashboards section to read more.
Authentication Methods/ Redirection
3Decoupled Model C: TPP Generated IdentifierA decoupled authentication flow where the PSU provides a dynamic identifier generated with their ASPSP to by the TPP (AISP/PISP/CBPII), which is then used by the ASPSP to identify the PSU through the ASPSP app to authenticate and action the TPP request.

This model is best suited to an TPP ASPSP app that can “capture” the code from the ASPSP TPP app (e.g. by scanning a QR code). Alternatively, the PSU can be prompted to type in an identifier in the TPP ASPSP App. This may be a long series of characters and may result in a sub-optimal customer experience.		OBIE internal review - errata fix
4Decoupled Model C: TPP Generated Identifier #3If PISPs and ASPSPs support Model C then PISPs must display an identifier generated from the ASPSP TPP app to the PSU (e.g. QR code) and information on how the identifier should be used within the ASPSP app (e.g scan QR code with the ASPSP app).
5Decoupled Model C: TPP Generated Identifier #5After  the PSU the scans the identifier from the PISP within the ASPSP app, then the ASPSP must display the payment request and clearly mention the amount and the payee and payment account.
6Redirection with TPP Generated QR codeNew journeyRoadmap item A7 Root Cause Analysis (RCA) on consent success - Trustee Action A10
Payment Initiation
7Payment RefundsCEG Checklist requirement
#2
PISPs should provide clear messaging to the PSUs in relation to providing consent to PISPs for requesting their debit account details for refund purposes. Example wording may be as follows:

“We will ask your bank to share your sort code and account number with us. We will only use these details if you ask for a refund for this transactionIf you ask for a refund, we will share these details with the payee or use them to process your refund request. We will not use these details for any other reason”		Roadmap - A2(a)(iii) Reverse payments - Trustee Action 1

Additional language change based on Nationwide feedback #1
8Payment Refunds - wireframe screen 2We will ask your bank to share your sort code and account number with us. We will only use these details if you ask for a refund for this transaction.If you ask for a refund, we will share these details with the payee or use them to process your refund request. We will not use these details for any other reason
9Payment Refunds - wireframe screen 4We have saved your sort code and account numberWe will only use these details if you ask for a refund for this transaction.If you ask for a refund, we will share these details with the payee or use them to process your refund request. We will not use these details for any other reason
10VRP Payments under Sweeping accessVRP Payments under sweeping access are a subset of VRP payments with SCA exemption that also has additional constraints:

1. Requires the PISP to attest that the activity meets the standardised definition of sweeping.

2. Requires the use of a specific set of sweeping consent parameters.

3. Requires the application of the 'Trusted Beneficiary' or 'Payment to Self' SCA exemption by the ASPSP for each VRP Payment.

For simplicity, we have defined the term 'Sweeping Consents' and 'Sweeping Payments' to refer to 'VRP Consents' & 'VRP Payments' respectively when they are dealt with under sweeping access.

OBIE internal review - link to definition of sweeping
11VRP Payments under Sweeping accessCEG Checklist Requirement #1
PISPs must either allow PSUs to specify consent parameters or pre-populate them for the PSUs enabling the PSU to amend any of them as required. 

In order for the PSU to provide their explicit consent to set up a Sweeping Payment, the PISP must present the  required consent parameters listed below:

Required set of Sweeping Consent Parameters

Payee Account Name.
Payee Account Identification details (e.g. account number and sort code or additionally roll number or full IBAN).
Maximum amount per payment and Currency (GBP for UK implementations).
Maximum amount per frequency time window* and Currency (GBP for UK implementations).
Expiry Date (Ongoing or a Specific Date).
Consent Reference


*time window - Day/Week/Fortnight/Month/HalfYear/Year
Note: Max amount per time window can be aligned to start from the date of consent creation or lined up with a calendar period.

If the max amount per time window is aligned to the calendar period, the calculation of the limit is pro-rated in the first period to the remaining number of days. For example, refer to the link in the API specifications section below.		OBIE internal review - errata fix and clarification
12VRP Payments under Sweeping accessCEG Checklist Requirement #3
Changed CEG Checklist reference 88f

Use of clear language to the PSU that they will be consenting to give the PISP the ability to make initiate payment on a (sporadically or periodically) recurring basis.
PISPs must display the company’s trading name/brand name (i.e. the Client Name) to the PSU during the setup and revocation of consent. If the PISP is only trading with its registered company name then it must display that name to the PSU.
If the PISP is not the customer-facing entity and there is an Agent who is acting on behalf of the PISP, then the Agent must make the PSU aware that they are acting as an agent on behalf of the PISP and must also, display the PISP’s full trading name/brand name or registered company name whichever is the customer-facing brand of the PISP.
If there is a customer-facing service provider (e.g., Sweeping service provider) who is not a PISP but has a commercial relationship with a PISP and is providing the end service to the end-user, the PISP must ensure the software statement reflects this information correctly so that it can be displayed accurately to the PSU on the PIS-VRP ASPSP Dashboard.
This could occur in sweeping journeys for example, where a sweeping service provider contracts with a PISP to provide Variable Recurring Payment as a payment option on their platform.
We refer to these entities as customer-facing service providers, as these entities are providing the end service to the end-user, whereas the PISP is only undertaking the payment initiation element. This could occur in merchant journeys for example, where a merchant contracts with a PISP to provide Variable Recurring Payment as a payment option on their platform.
PISPs must also, populate the Agent customer-facing service provider 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 (please refer to item #5). Only in instances where there is an Agent customer-facing service provider acting on behalf of the PISP, the ‘On Behalf of’ name must be displayed to the PSU. PISPs must not populate the ‘ On behalf of’ field with the details of their TSP.		OBIE internal review - errata fix and clarification
13VRP Payments with an SCA exemption &
VRP Payments with delegated SCA		CEG Checklist Requirement #1
PISPs must either allow PSUs to specify consent parameters or pre-populate them for the PSUs enabling the PSU to amend any of them as required.

The PSU can be treated as having given explicit consent for each VRP Payment under a VRP Consent, provided that:

the payee is fixed;
the number and/or frequency of payments is fixed (or capped); and
although the amount cannot be fixed in advance, there are clear parameters around the permitted value, such as maximum individual payment amount, maximum total value in a month or year etc.
Standardised Set of Consent Parameters

Payee Account Name.
Payee Account Identification details (e.g. account number and sort code or additionally roll number or full IBAN).
Maximum amount per payment and Currency (GBP for UK implementations).
Maximum amount per month*time window
Expiry Date (Ongoing or a Specific Date).
Consent Reference
Any supplementary information required which the ASPSP has published as required and is specific to that ASPSP.

*time window – Day/Week/Fortnight/Month/Half Year/ Year

Note: Max amount per time window can be aligned to start from the date of consent creation or lined up with a calendar period.

If max amount per time window is aligned to the calendar period, the calculation of the limit is pro-rated in the first period to the remaining number of days. For examples refer to link in the API specifications section below.		OBIE internal review - errata fix and clarification
14VRP Payments with an SCA exemption &
VRP Payments with delegated SCA		Use of clear language to the PSU that they will be consenting to give the PISP the ability to make initiatepayment on a (sporadically or periodically) recurring basis.
PISPs must display the company’s trading name/brand name (i.e. the Client Name) to the PSU during the setup and revocation of consent. If the PISP is only trading with its registered company name then it must display that name to the PSU.
If the PISP is not the customer-facing entity and there is an Agent who is acting on behalf of the PISP, then the Agent must make the PSU aware that they are acting as an agent on behalf of the PISP and must also, display the PISP’s full trading name/brand name or registered company name whichever is the customer-facing brand of the PISP.

If there is a customer-facing service provider (e.g., Merchant) who is not a PISP but has a commercial relationship with a PISP and is providing the end service to the end-user, the PISP must ensure the software statement reflects this information correctly so that it can be displayed accurately to the PSU on the PIS-VRP ASPSP Dashboard.
This could occur in Merchant journeys for example, where the Merchant contracts with a PISP to provide Variable Recurring Payment as a payment option on their platform.
We refer to these entities as a customer-facing service provider, as these entities are providing the end service to the end-user, whereas the PISP is only undertaking the payment initiation element. This could occur in merchant journeys for example, where a merchant contracts with a PISP to provide Variable Recurring Payment as a payment option on their platform.
PISPs must also, populate the Agent customer-facing service provider 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 (please refer to item #5). Only in instances where there is an Agent customer-facing service provider acting on behalf of the PISP, the ‘On Behalf of’ name must be displayed to the PSU. PISPs must not populate the ‘ On behalf of’ field with the details of their TSP.		OBIE internal review - errata fix and clarification
Dashboards
15DashboardsNew Menu option Dashboards

Moved existing dashboard journeys under Dashboards menu
Account Information>>AIS Consent Dashboard & Revocation to Dashboards>>AIS Consent Dashboard - Revocation & Refresh
Payment Initiation>>VRP>>VRP Consent Dashboard & Revocation to Dashboards>>PIS-VRP Consent Dashboard - Revocation
CBPII>>CBPII Consent Dashboard & Revocation to Dashboards>>CBPII Consent Dashboard - Revocation
Account Information>>AIS Access Dashboard & Revocation to Dashboards>>AIS Access Dashboard - Revocation & Refresh
Payment Initiation>>VRP>>VRP Access Dashboard & Revocation to Dashboards>>PIS-VRP Access Dashboard - Revocation
Moved fromCBPII>>CBPII Access Dashboard & Revocation to Dashboards>>CBPII Access Dashboard - Revocation
'Access Notifications for ASPSPs' to Dashboards>>PSU Notifications

Moved Account Information>>Refreshing AISP access journey to section "Refreshing access 90 days" under Dashboards>>AIS Consent Dashboard - Revocation & Refresh		Trustee Actions A1, A3, A4, A6, A7, A12, A13, A15 and A16 from Revised Roadmap Item - A2(b)(iii) Evaluation of Efficacy of Consent and Access Dashboards
16About DashboardsNew Section on Dashboards home menu
17AIS Consent Dashboard - Revocation & RefreshOverview
Principle 1: Easy to find and locate
New Fig 1,2,3
New CEG Checklist requirements & CX considerations
Principle 2 Intuitive to use and find
Fig 4,5,6
Revised CEG Checklist requirements & CX considerations
Revocation Journey - This Journey is moved from Account Information>>AIS Consent Dashboard & Revocation. Revised CEG Checklist requirements & CX considerations.
Refresh access to 90 days - This Journey is moved from Account Information>>Refreshing AISP access
Amending Consent
Accounts associated with AISP long lived consent
Principle 3 Be as transparent as possible
History
Consent Dashboards when using an agent of an AISP
Consent Dashboards When Onward Sharing Open Banking data to a Third Party not providing AIS (TPNPA)
Note
Examples

Revised CEG Checklist requirements & CX considerations in all sections to include 8g,9a,9d,9e,9f
18AIS Access Dashboard - Revocation & RefreshA Overview
Principle 1: Easy to find and locate
New Fig 1,2,3
New CEG Checklist requirements & CX considerations
Principle 2 Intuitive to use and find
Fig 2,3
Revised CEG Checklist requirements & CX considerations
Revocation Journey - This Journey is moved from Account Information>>AIS Access Dashboard & Revocation. Revised CEG Checklist requirements & CX considerations.
Refreshing access
Principle 3 Be as transparent as possible
History
Access Dashboards when the AISP is using an agent
Note
Examples

Revised CEG Checklist requirements & CX considerations in all sections to include 10a,10d,10e,10f
19PIS-VRP Consent Dashboard & RevocationOverview
Principle 1: Easy to find and locate
New Fig 1
New CEG Checklist requirements & CX considerations
Principle 2 Intuitive to use and find
Fig 2,3
Revised CEG Checklist requirements & CX consideration
Revocation Journey - This Journey is moved from Payment Initiation>>VRP>>VRP Consent Dashboard & Revocation. Revised CEG Checklist requirements & CX considerations.
Making change to VRP Consent
Principle 3 Be as transparent as possible
Consent history
Payment history
Dashboards when the customer-facing service provider and the PISP are different entities
Note
Examples

Revised CEG Checklist requirements & CX considerations in all sections to include 8g,9a,9d,9e,9f
20PIS-VRP Access Dashboard & Revocation Overview
Principle 1: Easy to find and locate
New Fig 1
New CEG Checklist requirements & CX considerations
Principle 2 Intuitive to use and find
Fig 2,3
Revised CEG Checklist requirements & CX considerations
Revocation Journey - This Journey is moved from Payment Initiation>>VRP>>VRP Access Dashboard & Revocation. Revised CEG Checklist requirements & CX considerations.
Principle 3 Be as transparent as possible
Access History
Payment History
Access Dashboards when the customer-facing service provider and the PISP are different entities
Note
Examples


Revised CEG Checklist requirements & CX considerations in all sections to include 10a,10d,10e,10f
21CBPII Consent Dashboard & RevocationOverview
Principle 1: Easy to find and locate
New Fig 1
New CEG Checklist requirements & CX considerations
Principle 2 Intuitive to use and find
Fig 2,3
Revised CEG Checklist requirements & CX consideration
Revocation Journey - This Journey is moved from CBPIIs>>CBPII Revocation of Consent

Principle 3 Be as transparent as possible
Consent history
CoF history
Note
Examples

Revised CEG Checklist requirements & CX considerations in all sections to include 8g,9a,9d,9e,9f
22CBPII Access Dashboard & RevocationOverview
Principle 1: Easy to find and locate
New Fig 1
New CEG Checklist requirements & CX considerations
Principle 2 Intuitive to use and find
Fig 2,3
Revised CEG Checklist requirements & CX considerations
Revocation Journey - This Journey is moved from CBPIIs>>CBPIIs Access Dashboard & Revocation
Re-Authentication of CoF Access at the ASPSP
Principle 3 Be as transparent as possible
Access History
CoF History
Note
Examples


Revised CEG Checklist requirements & CX considerations in all sections to include 10a,10d,10e,10f.
23PSU NotificationsOverview
Educating customers about the existence of their Dashboard – TPP and ASPSP
Informing customers about a successful connection – ASPSP
Reminding customers about upcoming 90-days expiration or already passed – TPP and ASPSP
Deletion of already obtained data – TPP
Opt-out – TPP and ASPSP
Synchronicity between Consent and Access Dashboards - This Journey is moved from Account Information>>Access Status Notifications by ASPSPs
A Real time notifications ASPSP>TPP
B – Aggregated ‘Polling’ / Pull Notification
C – Real Time Notification from TPP to ASPSP on the cancellation of consent
Fig 10
CX and other processing requirements
D – Basic ‘Polling’ / Pull Notification of ASPSP from TPP
Fig 11
CX and other processing requirements
Additional Information
24CEG Checklist>>Explanation of CEG ChecklistCustomer Experience Guidelines Checklist – Version 3.1.8Customer Experience Guidelines Checklist – Version 3.1.9 Draft

Refer to changed checklist items in blue in the spreadsheet
New Checklist items - 5c,5d, 5e, 8e, 8f, 8g,9a,9d,9e,9f,10a,10d,10e,10f
Existing Checklist rephrased - 9b,9c,10b,10c
25CEG Checklist>>
10a
10d
10e
10f		•Trustee action A1 from A2021/4OBIE internal review - updated Trustee action to checklist items
26CEG Checklist>>10fDo you confirm to the PSU that the access has been cancelled and advise the PSU to contact their associated AISP or PISP to inform them of the cancellation of access and/or understand the consequences of doing so?
OBIE internal review - errata fix