1.1 Purpose and approach

1. Illustrative guide: The Guidelines provide illustrative examples, and there is no requirement on API Standards Users to comply with these Guidelines. The Guidelines help provide a starting point for API Standards Users to develop their own propositions and implementations may differ in practice.

2. Illustrative but not exhaustive: These Guidelines provide the main scenarios that the v2.1 API Standard supports. There are other scenarios, flows or variants that are supported by the v2.1 API Standard that are not illustrated in these Guidelines.

3. Iterative guidance: The Guidelines will evolve, and iterations will be frequently released, based on additional functionality, ongoing feedback received and changing Customer expectations.

1.2 Relationship to the API Centre terms and conditions

The Guidelines cover the Customer journey, interaction and hand off separately. The Guidelines include suggested steps that the Customer should navigate, including in relation to consent. The Guidelines refer to consent and authentication. The steps which API Standards Users are required to take in relation to consent and authentication are set out in clause 7 of the API Terms. In these Guidelines:

Third Party Consent in relation to Customer Data Consent refers to the consent given by the Customer to a Third Party under which the Customer authorises:

• a Third Party to contact the Customer’s API Provider; and

• the use of the Customer Data for the purposes specified in the Customer Data Consent.

Third Party Consent in relation to Customer Payment Consent refers to the consent given by a Customer to a Third Party under which the Customer authorises:

• a payment under which funds will be debited from the Customer’s account and credited to the beneficiary nominated in the consent; and

• a Third Party to contact the Customer’s API Provider.

Authentication in relation to Customer Data Consent refers to the consent given by the Customer to an API Provider under which the Customer authorises an API Provider to act on an instruction received from the Third Party in relation to Customer data.

Authentication in relation to Customer Payment Consent refers to the consent given by the Customer to an API Provider under which the Customer authorises an API Provider to act on an instruction received from a Third Party, on behalf of the Customer in respect of that payment transaction.

1.3 Relationship with the v2.1.0 API standard

The API Centre has attempted to align the Customer Experience Guidelines to the v2.1.0 API Standard. Generally, where the Customer journey diagrams use the term ‘must’, it reflects a requirement of the v2.1.0 API Standard. The ‘must’ and ‘should’ settings described in the Guidelines document are not to be relied upon as a description of the API Standard and do not impose any obligation on API Standards Users to comply with these Guidelines.

1.4 Document structure

The following principles underpin the core Customer journey described in three sections:

1. Authentication Methods: The primary forms of Authentication, in generic form, that may be used through a variety of services and interactions.

2. Account Information Services (AIS): Service propositions that are enabled or initiated by Customers consenting to share their payment account data with Third Parties.

3. Payment Initiation Services (PIS): Service propositions enabled by Customers consenting to Third Parties initiating payments from their payment accounts.

API Providers should be familiar with their own role and that of others across all these proposition types.

Third Parties will naturally focus on the proposition types that are relevant to their business model, but they should still be aware of the roles of all others to ensure they understand the lines of demarcation and differences between each type.

The Customer journey is described for each of the core use cases. It is important to note that the Guidelines do not set out every variation or possible scenario that the API Standards support. The Guidelines provide illustrative examples of the key Customer journeys. In some cases, the Guidelines indicate where there could be other variations on the Customer journey, but the Guidelines will not go into the identified variation in any detail.

Each unique journey has been broken out and described over a number of stages. They can then be referenced in a number of ways according to individual priority e.g., whether the reader is, for example, a Regulatory Expert, Product Owner, Technical Lead or CX Designer. The stage types are:

1. Journey Description: A high-level description of the specific account information, payment initiation or confirmation of funds Customer journey.

2. Journey Map: This is a macro view of the Customer journey, broken down by optimal steps and Customer interaction points e.g., from payment initiation through authentication to completion.

3. Wireframe Journey: This is represented by annotated ‘screens’ to identify key messages, actions, interactions and information hierarchy, as well as process dependencies.

4. Journey Annotations: This is the annotation detail referenced in the wireframes. These consist of CX considerations, where research has raised specific Customer priorities or concerns that should be addressed through the eventual solution.

1.5 The API standard customer journey

The Guidelines have been separated into a set of clear, highly simplified white label wireframes that cover the Customer journey, interaction and hand off separately.

These are intended to be platform agnostic, to place focus on only the key elements (e.g., messages, fields, checkboxes) and the steps that the Customer should navigate.

In all cases they are constructed around the primary API Standard Customer journey, which is illustrated below.

At the core of each API Standard Customer journey is the mechanism by which the Customer gives consent to a Third Party to access account information held at their API Provider or to initiate payments from their API Provider account.

In general, simplified terms:

1. the consent request is initiated in the Third Party domain (step 1 below).

1. the Customer is then directed to the domain of its API Provider for authentication (step 2 below).

then, once authentication is complete, the API Provider will be able to respond to the Third Party’s account information or payment initiation request and redirect the Customer back to the Third Party for confirmation and completion of the journey (step 3 below).p