A detailed list of changes from V3.1.3 to V3.1.4
Changes are indicated as follows. Copy which has been removed is
struck out and copy which has been added is in blue.
|Item||Section Reference||Description of Change||Reason for Change|
|1||About||The Customer Experience Guidelines form part of the Open Banking Standard |
The Customer Experience Guidelines (and associated Checklist) form part of the Standards
The CEG Checklist has been developed for ASPSPs and TPPs to assess conformance
The CEG and CEG Checklist are consistent with:
In developing its Standard
On this basis, where an ASPSP seeking an exemption notifies their relevant National Competent Authority (NCA) (e.g. the FCA in the UK) that its dedicated interface follows the OBIE Standard
|2||Introduction ||Added new pages |
|Added more guidance to Customer Journey for TPPs on Customer Journey & Customer Communication|
|3||Introduction||Removed submenus from Menu - Introduction|
|The content is rolled up on About page|
|4||Introduction||Renamed pages to Menu - Introduction|
Customer Experience Principles
|The menu item is renamed.|
|5||Introduction||Moved Disclaimer under 'Disclaimer' block||Updated About page with Disclaimer|
|6||Introduction||Moved sections from old Design & Experience Principles page to Customer Journey page|
Useful elements in the customer journey
Unhelpful elements in the customer journey
|Moved content to relevant page|
|Section Account Information Services (AIS)|
|7|| Account Information Consent||Changed CX Consideration 1 to CEG Checklist Requirement 1|
Moved Checklist Reference 8 from CEG Checklist Requirement 2 to 1
|NBS Feedback #3|
|8||Account Information Consent||AIS Consent Changed wireframe|
Added inbound and outbound redirection bullets to wireframe and table.
4 AISP should make the PSU aware on the inbound redirection screen that they will be taken to their ASPSP for authentication for account access.
8 ASPSP should have an outbound redirection screen which indicates the status of the request and informs the PSU that they will be automatically taken back to the AISP.
|NBS Feedback #4|
|9||Refreshing AISP access ||Click for Related API specifications||Typos and removed duplicate links|
|10||90-Days Re-authentication||New Journey||New change to reflect 90 days re-auth journey|
|11||Permissions and Data Clusters for AIS journeys||Your Account Details||Balance||Balances||Your account balance||Amount, Currency, Credit/Debit, Type of Balance, Date/Time, ||Clarification to align to Decision 201|
|12||Permissions and Data Clusters for AIS journeys||Your Regular Payments||Scheduled Payments||Scheduled dates, amount, reference. ||Typo|
|13||Consent Dashboard & Revocation||AISPs must describe the data being shared through each consent using the structure and language recommended by OBIE following customer research (see Data Cluster Structure & Language below) and ensure this request is specific to only the information required for the provision of their account information service to the PSU.|
AISPs should present the data at a Data Cluster level and allow the PSU to expand the level of detail to show each Data Permission.
The Consent Dashboard should also describe:
• 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 consent was granted for the provision of the account information and the date when the service commenced.
• The period for which the account information
• The date the consent was granted.
If the customer-facing entity is acting on behalf of an AISP as its agent, the PSU must be made aware that the agent is acting on behalf of the AISP.
The consent dashboard must allow a PSU to view or cancel the access they have given consent to. The functions “Cancel
“Agent” means a person or entity who acts on behalf of an authorised payment institution or a small payment institution in the provision of payment services including account information services.
|NBS Feedback #9|
|14||AIS Access Dashboard & Revocation||Changed Checklist reference from 10 to 10a||NBS Feedback #14|
|15||Access Status notifications by ASPSPs||NBS Feedback #13-15|
|16||Access Status notifications by ASPSPs||Aggregated ‘Polling’ / Pull Notification of ASPSP by AISP|
• Similar to basic polling, aggregated Polling is about the provision of notification of revocations from ASPSPs to AISPs, upon AISP request, enabling AISPs to update their records and contact the PSUs, if required, at the point in time of the request. However, the key difference is that rather than focusing on a specific access resource’s status (via a GET request on that specific resource), aggregated polling allows an AISP to poll for the outstanding or awaiting events in the ASPSP’s events repository
• ASPSPs should provide to the polling AISP all the access resource status and other information stored in the repository for that specific AISP, upon AISP request. Please note that in case of in case of access revocation, there is no change to underlying consent resource. However, the event type, is same for both events, i.e. consent-authorization-revoked.
In addition to PSU revocation of access (event UK.OBIE.Consent-Authorization-Revoked), ASPSPs should be able to notify the AISPs for the below 2 events
1. UK.OBIE.Resource-Update - An event that indicates a resource has been updated.
2. UK.OBIE.Acount-Access-Consent-Linked-Account-Update - An event that indicates an account linked to a consent has move in/out of scope of the consent.
• is no longer available due to changes in the state of the access token for any valid reason (e.g. token has expired, token has been suspended by the ASPSP due to fraud etc.) and could provide the reason code, if appropriate.
Note: This functionality makes much more efficient usage of the ASPSPs and AISPs network bandwidth as multiple single polls, especially with no change of access status, are avoided. Moreover, it allows AISPs to receive all the required notifications without the need to implement systems with high availability (e.g. systems running 24×7) or systems based on real-time push notifications, providing full flexibility to AISPs about the timing they want to receive the notifications based on their business models.
|NBS Feedback #14-15|
|Section Payment Initiation Services|
|17||Payment Refunds||New Journey||New change to reflect Payment Refunds Journey|
|18||Single Domestic Payments – a/c selection @ PISP||Bullet 7 updated||Clarification to align to Decision 201|
|19||Single Domestic Payments – a/c Selection @ PISP (Supplementary Info)||Bullet 8 updated|
ASPSPs should display to PSUs any additional payment instruction information received from PISPs together with the supplementary information. This information may include the following:
|Clarification to align to Decision 201|
|20||Single Domestic Payments – a/c Selection @ ASPSP||Moved highlighted text from Bullet 9 to Bullet 8||Clarification to align to Decision 201|
|21||Confirmation of Funds for PISP – Y/N Response||The text below Process Diagram changed|
PISPs can request confirmation of funds on a PSU’s payment account for the amount necessary for the execution of the payment transaction initiated through the PISP. ASPSPs must respond to such request from a PISP with an immediate ‘Yes’ or ‘No’ confirmation and should take into account the same information (e.g.
• Single Immediate Domestic Payment (real time or for delayed booking executed not later than next working day).
• Single Immediate International Payment (Immediate Debit).
• Future Dated International Payment (Immediate Debit).
|Clarification to align to Decision 201|
|Section Card Based Payment Instrument Issuers (CBPIIs)|
|22||Revocation of Consent||Change to process wireframe - (3rd process)|
Confirm Consent Revocation
|23||Card-specific Permissions and Data Clusters for AIS journey||Your Card Details||Balances||Balances||Your account balance||Amount, Currency, Credit/Debit, Type of Balance, Date/Time, ||Clarification to align to Decision 201|
|24||Standard Error Codes||Please refer to Specs Section : OBErrorResponseError1Code||To remove duplicate content|
|25||Refund Payment Fullfillment||Supporting examples for Payment Refunds|
|Section The Customer Experience Checklist|
|26||Explanation of the Customer Experience Guidelines Checklist||Customer-Experience-Guidelines-Checklist-v3.1.4-Final.xlsx
The checklist is now called 3.1.4
|27||8a||Consent||PISP||Do you gather consent in a clear, specific and straightforward manner as per the principles described in Section - Payment Refunds of the Customer Experience Guidelines?||Answer must be "Yes"||Required||n/a||Mandatory||PSRs Reg. 69(3)(g)
•FCA Approach Document 17.68
|28||17a||Authenticating to refresh access||AISP||Do you allow the PSU to confirm their request to refresh access across multiple ASPSPs account(s)?|
When refreshing access across multiple ASPSPs, do you enable the PSU to select and confirm the relevant accounts(s) for refreshing access?
|Answer must be "Yes"||Required||n/a||n/a||*FCA Approach Document 20.47
|29||17b||Authenticating to refresh access||AISP||Do you apply SCA when the PSU confirms their selection of account(s) across the relevant ASPSPs account(s)?||Answer must be "Yes"||Required||n/a||n/a||*FCA Approach Document 20.24
•EBA opinion paper – 13th June 2018 38-39
|30||18a||Completion||AISP||Upon successful completion of SCA, do you confirm to the PSU that access has been refreshed?||Answer must be "Yes"||Required||n/a||n/a||n/a|
|31||Global||Changes to the background color of the CEG and OG menus.||HSBC Feedback #1|
|32||All Sections||Referenced all API spec links to v3.1.4 of the API specifications||OBIE Internal review|