Customer Experience Guidelines

Change Log

This version is:

Published 2 years ago 20 Dec 2019
A detailed list of changes from V3.1.3 to V3.1.4 Changes are indicated as follows. Copy…

Other Journeys in ‘v3.1.4’.

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.

ItemSection ReferenceDescription of ChangeReason for Change
Section Introduction
1 AboutThe Customer Experience Guidelines form part of the Open Banking Standard Implementation Requirements (SIRs)

The Customer Experience Guidelines (and associated Checklist) form part of the Standards Implementation Requirements, and set out the customer experience required to deliver a successful Open Banking ecosystem, alongside technical, performance, non-functional requirements and dispute resolution practices.

The CEG Checklist has been developed for ASPSPs and TPPs to assess conformancecompliance towith this aspect of the OBIE Standards Implementation Requirements.

The CEG and CEG Checklist are consistent with:

  • The Revised Payment Services Directive (PSD2) (Transposed in the UK by the Payment Services Regulations 2017 (PSRs))
  • The Regulatory Technical Standards on Strong Customer Authentication and Common and Secure Communication (SCA- RTS))
  • The UK CMA Retail Banking Market Investigation Order which applies to the nine largest UK retail banks only (known as the CMA9)) in the context of open banking.


In developing its Standard Implementation Requirements, OBIE has undertaken extensive engagement with different market participants, and analysis to ensure that its standards have been designed in line with relevant regulatory and market requirements.

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 Implementation Requirements, we expect this will provide a level of assurance that the ASPSP meets the requirement of RTS Article 30(5). Conversely, when an ASPSP has deviated from the Standard Implementation Requirements, we expect that the NCA may require additional information to enable it to consider more closely whether the ASPSP’s implementation is compliant with the relevant regulatory requirements. This may include the NCA requesting additional details on how and why there has been a deviation.

For this purpose, we would expect an OBIE recommends that ASPSPs to complete and submit the CEG Checklist, providing supporting evidence as appropriate, to OBIE. This can then which can be provided to the NCA in support of its their application for an exemption.		Updated
2Introduction
Added new pages

Customer Journey

Customer Communication
Improving Comprehension

Added more guidance to Customer Journey for TPPs on Customer Journey & Customer Communication
3Introduction Removed submenus from Menu - Introduction
OBIE SIR
Vulnerable Customers
CX Principles		The content is rolled up on About page
4Introduction Renamed pages to Menu - Introduction
Design Principles to
Customer Experience Principles		The menu item is renamed.
5Introduction Moved Disclaimer under 'Disclaimer' block
Updated About page with Disclaimer
6Introduction 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

AISPs should must ask the PSU to identify their ASPSP before requesting consent so that the consent request can be constructed in line with the ASPSP's data capabilities (which the ASPSP must make available to all TPPs). ASPSP Implementation guides, which are located on the Open Banking Developer Zone will have information about the ASPSP's data capabilities.

Moved Checklist Reference 8 from CEG Checklist Requirement 2 to 1		NBS Feedback #3
8 Account Information ConsentAIS 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
9Refreshing AISP access
Click for Related API specifications
  • Cosent Consent Re-authentication
/AIS)
  • Consent Re-authentication (General)


    		• Typos and removed duplicate links
    1090-Days Re-authentication
    		New Journey New change to reflect 90 days re-auth journey
    11Permissions and Data Clusters for AIS journeysYour Account DetailsBalanceBalancesYour account balanceAmount, Currency, Credit/Debit, Type of Balance, Date/Time, Credit LineClarification to align to Decision 201
    12Permissions and Data Clusters for AIS journeysYour Regular PaymentsScheduled PaymentsPAN Scheduled Payments Detail
    		Your account balance Details of recurring and future dated payments
    		Scheduled dates, amount, reference. Includes Does not include information about the beneficiary information about the beneficiary
    		Typo
    13Consent Dashboard & RevocationAISPs 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:
    • The purpose of the data request  A description of the account information service that is being provided (including whether any other parties will have access to the information). 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.
    • 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.
    • If relevant, t The length of time for which this consent is valid (e.g. one off use, for a set period of time e.g. one year, or with no end date and the date of expiry).
    • The period for which the account information transaction data has been requested (e.g. transactions for the last 12 months).
    • When the TPP's access to the data will expire.
    • 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 assessConsent” and “back” should be displayed with equal prominence to the PSU.

    “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
    14AIS Access Dashboard & RevocationChanged Checklist reference from 10 to 10aNBS Feedback #14
    15 Access Status notifications by ASPSPsASPSP updates the access status on events RepositoryASPSP generates access revocation events in their events repository
    For all  In cases where the AISP has subscribed to access revocation events for aggregated polling (or push notifications) PSUs access revocations, the ASPSP should generate an access revocation event update the status of the access resources in an the events Repository organised per each AISP.    		NBS Feedback #13-15
    16 Access Status notifications by ASPSPsAggregated ‘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 repositoryrequest an aggregated set of access revocations and ot her account access events related to multiple access consents from multiple PSUs. during a specific period.
    • 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 when access to account(s):
    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.

    • has been suspended by ASPSP due to changes in the account access resource for any valid reason (e.g. CASS by PSU, joint holder revoking access, account closed, etc.) and could provide the reason code, if appropriate.
    • 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
    17Payment RefundsNew Journey New change to reflect Payment Refunds Journey
    18Single Domestic Payments – a/c selection @ PISPBullet 7 updated

    • ASPSPs should inform PSUs about their “point of no return” for making the payment and that their payment will be made after authentication occurs. Example wording: “Authenticate to make payment”.
    • For recognition based biometrics (e.g. Face ID) which can be more immediate the biometric authentication should be invoked after a delay or through a call to action to allow the PSU the ability to view the details.
    • ASPSPs could display the balance of PSUs payment account(not shown on the user journey ) as part of the authentication journey on any of the following screens:

      1 ASPSPs’ Authentication screen.
      2 ASPSP to PISP redirection screen.
      Displaying the balance in this instance need not require any additional strong customer authentication.

    • ASPSPs must ensure that they comply with their obligations relating to the FCA’s High Cost Credit Review: Overdrafts consultation paper and policy statement (CP18/42).
    		Clarification to align to Decision 201
    19Single 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:

    • Payment Reference, if it has been entered by PSUs or pre-populated by PISPs in item #1
    • PSU payment Account Identification and/or the selected ASPSP (based on item #2 options).
      Payee Account Identification details (e.g. account number and sort code or additionally roll number or full IBAN)
    • ASPSPs could display the balance of PSUs payment account (see section Authentication methods for clarification on SCA requirements).

    • ASPSPs must ensure that they comply with their obligations relating to the FCA’s High Cost Credit Review: Overdrafts consultation paper and policy statement (CP18/42).
    		Clarification to align to Decision 201
    20Single Domestic Payments – a/c Selection @ ASPSPMoved highlighted text from Bullet 9 to Bullet 8

    • ASPSPs should inform PSUs about their “point of no return” for making the payment and that their payment will be made after authentication occurs. Example wording: “Authenticate to make payment”.
    • For recognition based biometrics (e.g. Face ID) which can be more immediate the biometric authentication should be invoked after a delay or through a call to action to allow the PSU the ability to view the details.
    • ASPSPs could display the balance of PSUs payment account(not shown on user journey)as part of the authentication journey on any of the following screens:
      1 ASPSPs’ Authentication screen.
      2 ASPSP to PISP redirection screen.
      Displaying the balance in this instance need not require any additional strong customer authentication.

    • ASPSPs must ensure that they comply with their obligations relating to the FCA’s High Cost Credit Review: Overdrafts consultation paper and policy statement (CP18/42).
    		Clarification to align to Decision 201
    21Confirmation of Funds for PISP – Y/N ResponseThe 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. available balance, agreed overdraft, incoming and outgoing funds, any fees and charges) it would consider if the customer was executing a payment transaction directly with the ASPSP. The ‘Yes/No’ response is limited up to the point of initiation of the payment order and not up to the point of execution. The CoF check is available for the following payment order types:
     
    • 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)
    22Revocation of ConsentChange to process wireframe - (3rd process)
    Confirm Account Access Revocation
    Confirm Consent Revocation    		Clarification
    23Card-specific Permissions and Data Clusters for AIS journeyYour Card DetailsBalancesBalancesYour account balanceAmount, Currency, Credit/Debit, Type of Balance, Date/Time, Credit LineClarification to align to Decision 201
    Section Appendices
    24Standard Error CodesPlease refer to Specs Section : OBErrorResponseError1CodeTo remove duplicate content
    25Refund Payment FullfillmentSupporting examples for Payment Refunds
    Section The Customer Experience Checklist
    26Explanation of the Customer Experience Guidelines ChecklistCustomer-Experience-Guidelines-Checklist-v3.1.4-Final.xlsx

    The checklist is now called 3.1.4
    278aConsentPISPDo 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"Requiredn/aMandatoryPSRs Reg. 69(3)(g)
    •FCA Approach Document 17.68
    2817aAuthenticating to refresh accessAISPDo 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"Requiredn/an/a*FCA Approach Document 20.47
    2917bAuthenticating to refresh accessAISPDo you apply SCA when the PSU confirms their selection of account(s) across the relevant ASPSPs account(s)?Answer must be "Yes"Requiredn/an/a*FCA Approach Document 20.24
    •EBA opinion paper – 13th June 2018 38-39
    3018aCompletionAISPUpon successful completion of SCA, do you confirm to the PSU that access has been refreshed?Answer must be "Yes"Requiredn/an/an/a
    31GlobalChanges to the background color of the CEG and OG menus.HSBC Feedback #1
    32All SectionsReferenced all API spec links to v3.1.4 of the API specificationsOBIE Internal review