Change Log

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

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.”
Roadmap - A2(a)(iii) Reverse payments - Trustee Action 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.
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.
10VRP 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 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
11VRP 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 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., 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 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
Dashboards
12DashboardsNew 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
13About DashboardsNew Section on Dashboards home menu
14AIS 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
15AIS 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
16PIS-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
17PIS-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
18CBPII 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
19CBPII 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.
20PSU 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
21CEG 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
v3.1.9