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/Section | Location | Change | Reason for Change |
|---|---|---|---|
| Introduction | |||
| 1 | About these guidelines | Added 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 |
| 2 | Customer Experience principles | Added 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 | |||
| 3 | Decoupled Model C: TPP Generated Identifier | A decoupled authentication flow where the PSU provides a dynamic identifier generated This model is best suited to an | OBIE internal review - errata fix |
| 4 | Decoupled Model C: TPP Generated Identifier #3 | If PISPs and ASPSPs support Model C then PISPs must display an identifier generated from the |
|
| 5 | Decoupled Model C: TPP Generated Identifier #5 | After the PSU |
|
| 6 | Redirection with TPP Generated QR code | New journey | Roadmap item A7 Root Cause Analysis (RCA) on consent success - Trustee Action A10 |
| Payment Initiation | |||
| 7 | Payment Refunds | CEG 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. | Roadmap - A2(a)(iii) Reverse payments - Trustee Action 1 Additional language change based on Nationwide feedback #1 |
| 8 | Payment Refunds - wireframe screen 2 | We will ask your bank to share your sort code and account number with us. |
|
| 9 | Payment Refunds - wireframe screen 4 | We have saved your sort code and account number |
|
| 10 | VRP Payments under Sweeping access | VRP 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 |
| 11 | VRP Payments under Sweeping access | 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. 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 Expiry Date (Ongoing or a Specific Date). *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 |
| 12 | VRP Payments under Sweeping access | CEG Checklist Requirement #3 Changed CEG Checklist reference Use of clear language to the PSU that they will be consenting to give the PISP the ability to 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 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. PISPs must also, populate the | OBIE internal review - errata fix and clarification |
| 13 | VRP 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; 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 Expiry Date (Ongoing or a Specific Date). 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 |
| 14 | VRP 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 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 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. PISPs must also, populate the | OBIE internal review - errata fix and clarification |
| Dashboards | |||
| 15 | Dashboards | New Menu option Dashboards Moved existing dashboard journeys under Dashboards menu Moved from Moved | 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 |
| 16 | About Dashboards | New Section on Dashboards home menu | |
| 17 | AIS Consent Dashboard - Revocation & Refresh | 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 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 |
|
| 18 | AIS 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 |
|
| 19 | PIS-VRP Consent 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 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 |
|
| 20 | PIS-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 |
|
| 21 | CBPII Consent 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 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 |
|
| 22 | CBPII 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 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. |
|
| 23 | PSU Notifications | Overview 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 |
|
| 24 | CEG Checklist>>Explanation of CEG Checklist | 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 | |
| 25 | CEG Checklist>> 10a 10d 10e 10f | •Trustee action A1 from A2021/4 | OBIE internal review - updated Trustee action to checklist items |
| 26 | CEG Checklist>>10f | Do 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 |