Customer Experience Guidelines

Propositions

Other pages in this section

Overview

The following proposition papers are based on the Open Banking Roadmap, published by Open Banking Limited (OBL), the Implementation Entity described in the CMA Order, of 23 Jul 2018. See https://www.openbanking.org.uk/wpcore/wp-content/uploads/Open-Banking-Revised-Roadmap-July-2018.pdf. These papers define the scope for the Open Banking Standard (which includes API Specifications, Customer Experience Guidelines, and Operational Guidelines), and have been approved at IESG.

Core Propositions

P1 • Open Data for standardised back-book products

The purpose of this paper is to define the overall proposition for item P1, so that participants (ASPSPs and TPPs) and stakeholders (FCA, HMT, CMA) are clear about what is and is not in scope for this item, and how this will support regulatory requirements and key use cases.

This version was published 6 Years & 2 Months ago 22 Feb 2018

P2 • Two way notification of revocation

Two-Way Notification of Revocation enables ASPSPs to notify TPPs when PSUs revoke TPP access using their ASPSP dashboards. It also enables TPPs to notify ASPSPs, when PSUs revoke their consent using their TPP dashboard.

This version was published 4 Years & 7 Months ago 02 Sep 2019

P3 • Efficacy of consumer authentication step

'App-to-App' redirection allows the TPP to redirect a PSU from the TPP application to the ASPSP’s mobile app, where the TPP is able to transmit details of the request along with PSU preferences (e.g. product type, one-step authentication) and deep link the PSU into the ASPSP app login screen or function.

This version was published 5 Years & 9 Months ago 20 Jul 2018

P4 • Authentication step aligned to PSD2

A Decoupled authentication allows a TPP to have the PSU authenticate with their ASPSP app when the PSU is consuming the TPP service on a device other than the one which has the ASPSP app, or even when the PSU is not present on the TPP channel.

This version was published 5 Years & 9 Months ago 13 Jul 2018

P5a • Future-dated payments and standing orders

The roadmap item P5 will be addressed in two stages. P5a is the first, and covers the PSD2 compliance requirements to extend the write functionality of v1.1 to support Future Dated Payments and Standing Orders.

This version was published 6 Years ago 16 Apr 2018

P6 • Confirmation of funds

Open Banking APIs need to be extended to enable ASPSPs to confirm availability of funds to a special group of TPPs: Card Based Payment Instrument Issuers (CBPIIs). CBPIIs are payment service providers which issue card based instruments which are linked to an account or accounts held at one or more different ASPSPs.

This version was published 5 Years & 6 Months ago 08 Oct 2018

P6b • Confirmation of Funds – PISP

The current published Version 3.0 of the OBIE read/write API standard allows a CBPII to receive 'yes/no' responses to a Confirmation of Funds (CoF) request. This functionality is required by PISPs to assist them to reduce settlement risks.

This version was published 5 Years & 5 Months ago 21 Nov 2018

P7 • Reverse payments (Refunds)

In the case that refunds are to be fulfilled via Open Banking, a refund payment would require the submission of a new payment order (either a single or bulk order) via a PISP to the merchant's ASPSP, to facilitate the refund back to the purchaser, relating to a previous transaction.

This version was published 4 Years & 4 Months ago 30 Nov 2019

P8 • Trusted beneficiaries exemption under SCA

As an enhanced security measure, PSD2 requires that ASPSPs apply strong customer authentication (SCA) where a payer initiates an electronic payment, including via a PISP, unless an exemption applies.

This version was published 5 Years & 2 Months ago 19 Feb 2019

P9 • Status of payment

A meaningful payment status is critical to underpin the successful operation of the Open Banking ecosystem for PISP initiated payments. This roadmap item entails the extension of the Write PIS functionality of the OB R/W APIs to enable ASPSPs to communicate the appropriate payment statuses to PISPs.

This version was published 5 Years & 2 Months ago 19 Feb 2019

P10 • International Payments

From a regulatory compliance perspective the Open Banking PIS functionality of the Write APIs needs to be extended to enable PISPs to initiate international payments from online payment accounts.

This version was published 5 Years & 6 Months ago 08 Oct 2018

P11 • BACS, CHAPS, Bulk and Batch payments

From a regulatory compliance perspective the Open Banking PIS functionality of the Write APIs needs to be extended to enable PISPs to initiate domestic and international payments other than faster payments from online payment accounts, provided and to the extent, that this functionality is available to the PSU, on their ASPSPs' online payment account, in alignment with the requirements of PSD2.

This version was published 5 Years & 6 Months ago 09 Oct 2018

P12 • Service Quality metrics

Caveat This document is currently the internal house view of the Open Banking Implementation Entity (OBIE) and does not yet represent the official view of the Open Banking programme. However due to the requirement to publish a specification for this item in Feb 2018, OBIE is progressing designs for this specification based on the requirements currently considered in scope below. We will work on these requirements first. We may (at a later date) work on other requirements, if these subsequently become part of the agreed scope. But for now we will not spend time on designing for requirements we consider may be in scope or not in scope.

This version was published 6 Years & 3 Months ago 09 Jan 2018

P13 • Multi-authorisation for SME

Open Banking API's v1.1 allowed a payment initiated by via a PISP to be authorised with the ASPSP by a single PSU. For certain payment accounts, for example SMEs, could have complex workflows around authorisation of a payment order, which may require multiple parties with delegated user authority to authorise a payment order.

This version was published 5 Years & 6 Months ago 15 Oct 2018

P20 • PSD2 in-scope accounts (sterling)

The purpose of this paper is to define the overall proposition for item P20 (PSD2 in scope accounts, sterling), so that participants (ASPSPs and TPPs) and stakeholders (FCA, HMT, CMA) are clear about what is and is not in scope for this item, and how this will support regulatory requirements and key use cases.

This version was published 6 Years & 2 Months ago 22 Feb 2018

P21 • PSD2 in-scope accounts (multi-currency)

Following the expansion of the Roadmap to cover all PSD2 payment accounts it was recognised that some payment accounts held by businesses with turnover exceeding the £6.5m threshold may include account information or payment functionality that had not yet been catered for.

This version was published 5 Years & 6 Months ago 10 Oct 2018

P21b • PSD2 in-scope multi-currency wallets

The purpose of this paper is to define requirements to support multi-currency wallets.

This version was published 10 Months ago 31 May 2023

P22 • Corporate Accounts

The purpose of this paper is to define the overall proposition for item P20 (PSD2 in scope accounts, sterling), so that participants (ASPSPs and TPPs) and stakeholders (FCA, HMT, CMA) are clear about what is and is not in scope for this item, and how this will support regulatory requirements and key use cases.

This version was published 5 Years & 2 Months ago 19 Feb 2019

Messaging to support CASS

CASS has given consideration to the impact of open banking on current account switching. PSD2 requires that PSUs must give explicit consent to TPPs to connect to their payment accounts and provide services, such as AIS, PIS and CBPII.

This version was published 3 Years & 10 Months ago 24 Jun 2020

Variable Recurring Payments (VRPs)

VRPs enable customers to grant a long-lived consent to a Payment Initiation Service Provider (PISP) for the purpose of instructing a series of payments on their behalf, without the need for the PSU to authenticate each individual payment with the Account Servicing Payment Service Provider (ASPSP).

This version was published 2 Years & 6 Months ago 29 Sep 2021

Premium APIs

Reducing the negative impact of 90 days re-authentication – Options Paper

Unintended consequences reported by ecosystem participants due to the requirement for the PSU to re-authenticate with their ASPSP at least every 90 days so that the AISP can maintain access for the provision of account information services. It also defines a number of possible solutions which could be used to reduce friction, reduce drop-off/churn and thereby mitigate potential customer detriment.

This version was published 4 Years & 5 Months ago 18 Nov 2019

Others

A2(c)(ii) Requirements for Enhanced MI Data Submission Mechanism and TPP MI Reporting Data

The proposed new mechanism for MI Data Submission is an enhancement to the existing mechanism which is currently in place and used by ASPSPs to submit MI Reporting Data to OBIE. The enhanced MI Submission Mechanism will be available to be used by both ASPSPs and TPPs for the automated, where possible, submission of MI Data to OBIE.

This version was published 1 Year & 5 Months ago 15 Nov 2022