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. Learn more This version was published 6 Years & 10 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. Learn more This version was published 5 Years & 3 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. Learn more This version was published 6 Years & 5 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. Learn more This version was published 6 Years & 5 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. Learn more This version was published 6 Years & 8 Months 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. Learn more This version was published 6 Years & 2 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. Learn more This version was published 6 Years & 1 Month 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. Learn more This version was published 5 Years 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. Learn more This version was published 5 Years & 10 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. Learn more This version was published 5 Years & 10 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. Learn more This version was published 6 Years & 2 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. Learn more This version was published 6 Years & 2 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. Learn more This version was published 6 Years & 11 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. Learn more This version was published 6 Years & 2 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. Learn more This version was published 6 Years & 10 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. Learn more This version was published 6 Years & 2 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. Learn more This version was published 1 Year & 6 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. Learn more This version was published 5 Years & 10 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. Learn more This version was published 4 Years & 5 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). Learn more This version was published 3 Years & 2 Months ago 29 Sep 2021
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. Learn more This version was published 6 Years & 10 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. Learn more This version was published 5 Years & 3 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. Learn more This version was published 6 Years & 5 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. Learn more This version was published 6 Years & 5 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. Learn more This version was published 6 Years & 8 Months 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. Learn more This version was published 6 Years & 2 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. Learn more This version was published 6 Years & 1 Month 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. Learn more This version was published 5 Years 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. Learn more This version was published 5 Years & 10 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. Learn more This version was published 5 Years & 10 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. Learn more This version was published 6 Years & 2 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. Learn more This version was published 6 Years & 2 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. Learn more This version was published 6 Years & 11 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. Learn more This version was published 6 Years & 2 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. Learn more This version was published 6 Years & 10 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. Learn more This version was published 6 Years & 2 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. Learn more This version was published 1 Year & 6 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. Learn more This version was published 5 Years & 10 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. Learn more This version was published 4 Years & 5 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). Learn more This version was published 3 Years & 2 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. Read more This version was published 5 Years & 1 Month ago 18 Nov 2019
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. Read more This version was published 5 Years & 1 Month 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. Read more This version was published 2 Years & 1 Month ago 15 Nov 2022
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. Read more This version was published 2 Years & 1 Month ago 15 Nov 2022