Customer Journey

A critical component of the customer journey is the way in which customers share their data, granting, managing and revoking their consent with the Third Party Provider (TPP) and revoking access at ASPSP specifically in relation to the provision of their payment service. It is essential to empower individuals with the information, tools and protections to actively share their data with trustworthy organisations and importantly, that organisations understand their legal and regulatory obligations, as applicable both under PSD2 and  GDPR..

Overview

For the purposes of the Customer Experience Guidelines, for each core use case customer journey, interaction and hand off have been broken into a set of clear, highly simplified white-label ‘wireframes’. These are intended to be platform-agnostic, to place focus on only the key elements within (e.g. messages, fields, checkboxes) and the specific number of steps that the customer must navigate. In all cases, they are constructed around the primary Open Banking Customer Journey, which is illustrated below.

At the core of all Open Banking, customer journeys is the mechanism by which the PSU gives consent to a TPP (AISP or PISP or CBPII) to access account information held at their ASPSP or to initiate payments from their ASPSP account.

In general, simplified terms, the consent request is initiated in the TPP domain (step 1). The PSU is then directed to the domain of its ASPSP for authentication (step 2). Then, once authentication is complete, the ASPSP will be able to respond to the TPP’s account information or payment initiation request and redirect the PSU back to the TPP for confirmation and completion of the journey (step 3).

Customer Data Sharing Journey

The Data Sharing Customer Journey is outlined below and consists of five stages: Set Up, Consent, Consent Management, Revocation and Off-Boarding. We now examine these stages and their requirements. You must familiarise yourself with the regulatory requirements for GDPR and PSD2 at each stage.

These are shown illustratively, and we use this pattern within these guidelines, although we recognise that this is not linear. This journey should be regarded as one overall experience and will vary from TPP to TPP. TPPs should consider how each part can work alongside the next, and not in separation. It is important that the number of screens is kept to a minimum, and the journey is designed to feel intuitive and seamless. All wireframes have been created to illustrate the key principles of the customer journey and illustrate important regulatory points only.

  1. Set Up. This includes having sight of the TPPs Privacy Notice, which must confirm details of any onward sharing of personal data and importantly: the recipients or categories of recipients who will receive that data.  It must also include agreeing to a set of terms and conditions which confirm the provision of services being offered. Setting up a new service should not only be simple, but the key terms of the service being offered and the use of, and the lawful basis for processing personal data must be clear and transparent to the customer prior to any personal data being processed This is where GDPR comes to the fore.
2. Providing Consent, where the customer consents to allow the TPP to access their account for the provision of an AIS or PIS service. Here the relevant regulation is PSD2. The purpose, data being shared and duration of TPP access must be very clear.

3. Consent Data Sharing Management and Revocation stages, where PSD2 apply and Off-Boarding where both PSD2 and GDPR apply. The customer should be able to view, manage and revoke their consent easily with controls that are easily found.

The relationship between GDPR & PSD2

A key consideration throughout the Customer Journey is the regulatory requirements at each stage. TPPs will need to consider the application of the provisions of each regulation at each stage to ensure they meet the relevant requirements.

To find out more about your legal and regulatory obligations under GDPR, please see https://ico.org.uk

The principles of transparency and control to build trust are critical. In particular, when the customer is in the Set-Up phase, if and how the TPP onward shares data with other parties must be clear so customers have knowledge about what will happen to their data.

From the customer’s perspective, we can summarise the key aspects that are important.

TPPs must ensure that their terms and conditions and Privacy Notice outline applicable rights and responsibilities to their customer in the context of relevant regulation and legal principles.

The guidance in this document builds upon research commissioned by Open Banking and is designed to help Third Party Providers (TPPs) make informed decisions about how and where to focus their efforts.

    Set Up​

    The journey should feel like an experience and not a contract. Ensuring that the customer clearly understands your proposition, the key terms they must commit to, and the benefit they will receive is an essential part of the customer journey.

    When you are developing the Set-Up customer journey, ensure that you understand any relevant regulatory obligations, which must be included within your T&Cs and Privacy Notice.

    The design pattern for most Terms and Conditions and Privacy Notice  experiences is:

    • A link
    • A tick box, and
    • A legal document (accessed by actively clicking the link)

    Current research consistently shows that the majority of people skip a careful reading of terms and conditions, can misunderstand if these are not clearly presented, and as a remain poorly informed at the point of agreement (i.e. a decision to sign up for a new product or service).
    By actively designing terms and conditions to inform and empower your customers, they are better able to make an active and informed choice. This guidance is intended to help you deliver a simple, actionable and meaningful disclosure experience to customers.

    Set Up: Codification of the Customer Data Agreement

    Setting up a new service should be simple and the key terms and use of personal data must be clear, and meet GDPR requirements. ‘Codification’ is used here to describe the Agreement Parameters that should be included in T&Cs and Privacy Notices.

     Key parameter of agreement

    # Agreement Parameter Description
    1 Customer Outcome Statement Here’s what we aim to help you achieve by using this product or service
    2 Data Usage Statements This is how we will use (and limit the use of ) your data
    This is how we won’t use your data
    This is data that we can use to generate revenue (link to point 6)
    These are the other parties we share your data with: …
    (N.B. Ensure you are aware of your obligations under GDPR for Special Category Data and make this clear)
    3 Managing Your Data Statement This is how you can manage your data and revoke your consent if you no longer wish to use the service (N.B. This would be achieved through settings or a “dashboard”). Please ensure that any consequences of revocation are made clear to the customer.
    4 Business Monetisation Statement This is how we make money
    5 Complaints Handling Process Statement Here’s how you can get help
    How we and others will protect you if something goes wrong
    6 Processing Legal Basis Statement This is the legal basis we rely upon to lawfully process your data (Likely to be Legitimate Interest or Performance of Contract)
    7 Accountability Statement Here’s how we are regulated and how you can find out about the relevant regulation.

    Consent: Codification of AIS Consent (PSD2)

    When obtaining consent from the customer for the provision of an account information service an AISP must make it very clear why it’s needed, what’s being shared and for how long. This is where PSD2 is the regulatory driver.

    Codified Consent Parameters

    # Agreement Parameter Description
    1 Purpose Statement Why we need you to share your data
    2 Direct Benefit Statement What you will get from us in return
    3 Data Request Statement What we need you to share
    4 Duration Period Statement How long we will need access (unless you revoke access)
    5 Agreement Do you agree to share your data with us on the terms above?

    Important: The definition of ‘explicit consent’ under PSD2 is not the same as the definition of ‘consent’ under GDPR. The guidance in this section refers to the definition under PSD2. For more information refer to FCA Payment Services and Electronic Money – Our Approach document para 8.55 

    Purpose Statement for Consumer Use Cases​

    Clarity and consistency in the way that language is used are critical to comprehension. Depending on your proposition, the description of the Purpose Statement that we recommend uses the following structure ​
    “To provide a [ Proposition Classification ] service, we need to [ Data processing activity ]”​

    Examples of customer propositions

    Proposition classification Why we need you to share your data
    Consumer References To provide a [Consumer Referencing] service, we need to [analyse your income, spending and saving patterns]
    Debt Advice To provide you with a [Debt Advice] service, we need to [better understand your income as well as you fixed and discretionary spending]
    Personal Finance Manager To provide a [Personal Finance Manager] service, we need to [analyse your income, spending and saving patterns]

    Purpose Statement for SME Use Cases​

    Clarity and consistency in the way that language is used are critical to comprehension. Depending on your proposition, the description of the Purpose Statement that we recommend uses the following structure “To provide a [ Proposition Classification ] service, we need to [ Data processing activity ]​

    Examples for SME Propositions in this table

    Proposition classification Why we need you to share your data
    Cashflow Analysis To provide an [Cashflow Analysis] service, we need to [analyse your income, spending and saving patterns]
    Payment Tracking To provide a [Payment Tracking] service, we need to [analyse your income patterns]

     

    Useful elements in the customer journey

    Many customers are prone to skim through the information presented to them when setting up online products because the information is not well presented. In their desire to achieve the promised benefit, insufficient notice is taken of the implications of their actions, or the terms and conditions. It is commonplace to discover, once they have completed the customer journey, that they cannot spontaneously describe what they have just agreed to. The research has shown that a better understanding can be achieved by carefully designing the customer journey, and reveals that the solution is about the effective, intuitive presentation of information, and is not about introducing steps to slow the customer down or repeating information. The following methods have been found to be the most effective:

    • Effective messages and navigation appropriate to the redirection screens when the customer is redirected from the TPP to the ASPSP, and then again when the customer is redirected back from the ASPSP to the TPP. For a customer that has granted consent to the TPP, the redirection screen creates a clear sense of separation as they enter the ASPSP’s domain where they authenticate, before clearly being passed back to the TPP. This provides a familiar and trusted experience to the customer and signposts the customer’s journey from one domain to the other
    • Providing useful information presented in an intuitive and easily consumable way. The principle here is to ensure that the information that the customer is presented with is kept to a minimum. If it is unavoidably necessary for the TPP to convey more complex information, it is more likely to be read and understood when presented as a series of smaller amounts of information across more than one screen. This is a much more effective method than the use of a single text-heavy screen.
    • Providing supplementary information at specific points in the customer journey is useful, helping the customer to understand the process as well as ensuring comprehension of a product or offer and its implications. If executed well, it will enhance the customer journey and does not lead to an increased propensity to drop off.

    Unhelpful elements in the customer journey

    The research has shown that superfluous information, poor or confusing choice of words, repetition, large amounts of text, too many steps or avoidable delays in the customer journey can lead to frustration, an even greater tendency to skim, and ultimately increase customer drop off. The following unhelpful elements were identified in the research and must be avoided: 

    • A customer authentication journey that takes too long and requires the use of separate devices such as one-time password generators, especially if applied multiple times in the customer journey.
    • Where there are fewer screens but a significant amount of text on the screen. This is particularly evident when this requires customers to scroll up and down the screen to progress the customer journey.
    • Providing superfluous information that does not add to the customer’s understanding or trust, especially when presented in a separate step or screen.
    • Delays such as slow loading times, as well as web pages or apps that have not been effectively debugged, and unexpected crashing of web pages or apps.
    • Inappropriate use of language, particularly language which may create a level of concern, uncertainty and doubt when going through the customer journey.
    • The use of language that is too long, complex or legalistic to be easily understood when going through the customer journey.
    • Asking for the same information twice, and asking for information for which there is no obvious purpose, e.g. replaying the consent to the customer that was granted to the TPP, or asking for a PIN when it is not needed.
    • Forcing the customer to open a new browser window during the customer journey, and having to toggle between screens in order to progress.
    • Introducing the requirement for a customer to input information that they don’t readily have to hand, such as unique customer reference numbers
    • Requesting input of information that could reasonably be expected to be pre-populated once the customer has authenticated.
    • Failing to differentiate between new users and experienced regular users who may want to shorten the customer journey without exposing themselves to risk.
    v3.1.6