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.
Other pages in this section
The Open Banking API’s v1.1 covered single immediate payments (write functionality) where a PSU can initiate, through a PISP, a one off payment to be initiated immediately from their PCA/BCA account held with an ASPSP.
The roadmap item P5 will be addressed in two stages. This paper is titled as P5a and covers the PSD2 compliance requirements to extend the write functionality of v1.1 to support the following payment types:
Further, under the CMA Order, Variable Recurring Payments (VRPs), which are required to meet the sweeping use case are dependent on the application of SCA exemptions, and in particular the exemption for Trusted Beneficiaries. SCA exemptions will be covered by roadmap item P8 (Trusted beneficiary exemptions under SCA), and hence VRPs will be addressed alongside P8 and not included as requirements for P5 at this time but rather under an additional paper which will be titled P5b.
This paper defines the overall proposition to support the extended write functionality so that participants (ASPSPs and TPPs) and stakeholders (FCA, HMT, CMA) have a common understanding about what is and is not in scope, and how this proposition will support regulatory requirements and key use cases.
Please refer to the Appendix (10.1 Roadmap item definition) for the complete definition of “P5 Future Dated Payments and Standing Orders” within the “Notice of approval of changes to the Agreed Timetable and Project Plan“.
To satisfy use cases identified in this paper, TPPs currently use:
74% of consumer recurring payments are made by Direct Debits where as 4% are made through cards. 9% of these recurring payments are Standing Orders, though currently these can only be setup on an ASPSP channel.
Ability to setup a SO and FD through a TPP offers:
The following are some example use cases which have been considered for this proposition.
We will focus P5 initially on just the setup of SO and FDP – so that this can be built ahead of the RTS application date. The other requirements of P5 will be covered alongside P8 in a subsequent release. Hence this proposition paper is titled P5a, and we will create a further paper (P5b) which will outline the requirements and scope for these additional requirements.
The table below includes example use cases covering all P5 requirements and indicates how well each use case will be met by a combination of BOTH future dated payments/standing orders (P5a) AND the use of single immediate payments (which are already covered/available).
These use cases can only be met ‘partially’ or ‘not at all’ because there is no capability for PSU to manage these instructions through the TPP once set up. Furthermore, there is no support for variability of the amount for recurring payments. Hence PISPs may have to rely on (a series of) single immediate payments in favour of FDPs or SOs, and this may create a less smooth user experience as PSU may need to be present to undergo SCA for each payment.
The OBIE interpretation of the key regulatory requirements is that in relation to payment accounts that are accessible online, the ASPSP should allow PSUs to initiate via a PISP the same payments which the PSU can initiate directly via the existing online interface.
The payment functionality available to a PSU directly may vary from account to account depending on the online functionality provided by the ASPSP to the PSU.
Key evaluation criteria that OBIE have applied for this proposition (that respect the objectives of meeting regulatory requirements as well as being effective and proportionate)
In order to allow all ASPSPs to comply with the regulatory requirements OBIE understands that the write APIs will need to support at least the following functionality:
In either case, the application of Strong Customer Authentication (or application of an exemption where available) for the setup of this instruction is a matter for the ASPSP.
As stated above, VRPs will be considered at a later date alongside roadmap item P8.
The following are not considered to be regulatory requirements for this specific proposition:
The structure of a SO and FDP instruction and the execution of payment for these (e.g. business hours only) can vary across the ASPSPs. The TPPs will need a mechanism to discover the structure and the execution supported by each ASPSP.
The following metrics will be required to measure adoption:
In addition, OBIE would like to get metrics back from FPS as to the volume of transactions through FPS for each payment type on a monthly basis
The following table is taken ‘as-is’ from the published roadmap: (https://www.openbanking.org.uk/wpcore/wp-content/uploads/2017/11/FAO-CMA_Proposed-Amendments-to-Agreed-Arrangements_v_final-1.pdf)
These are stated as requirements of the OBIE solution to enable implementers to meet regulatory compliance and/or customer use cases.
Requirements marked as ‘M'(Must) are in scope of the OBIE solution. All other requirements are listed for future consideration. The final column indicates whether each requirement is ‘mandatory’, ‘conditional’ or ‘optional’ for implementation by ASPSPs and/or TPPs. These terms are defined here: Categorisation of requirements for standards and implementation.
As stated above, the Implementation Trustee instructed OBIE to develop a standard for decoupled authentication. Hence the majority of the requirements below are considered a ‘regulatory must’ for the OBIE standards under the CMA Order.
Open Banking has conducted quantitative and qualitative research to gauge the customer feedback on a few payment journeys for this proposition to identify areas of improvement.The following prototypes were tested
The research was specifically conducted to test the journeys for
The overall outcome of the research is as follows
Detailed findings from the customer research conducted by OBIE can be found in the attached report below
The following regulatory references are relevant considering the scope of this proposition:
PSD2 Article 4.12 states:‘payment account’ means an account held in the name of one or more payment service users which is used for the execution of payment transactions;
PSD2 Article 66.1 states:Member States shall ensure that a payer has the right to make use of a payment initiation service provider to obtain payment services as referred to in point (7) of Annex I. The right to make use of a payment initiation service provider shall not apply where the payment account is not accessible online.
PSD2 Annex 1 point (7):7. Payment initiation services
PSD2 Annex 1.3 defines payment services as:Execution of payment transactions, including transfers of funds on a payment account with the user’s payment service provider or with another payment service provider:
PSR 2017, 69(1)Reg: This regulation applies only in relation to a payment account which is accessible online.
RTS Art. 36(4):Payment initiation service providers shall provide account servicing payment service providers with the same information as requested from the payment service user when initiating the payment transaction directly.
HMT Consultation (6.26) states:ASPSPs are expected to provide to a PISP access to the same functionality that is available to the user when accessing their payment account online directly with the ASPSP. For the majority of online payment accounts this is likely to include credit transfers and the establishment of standing orders, but not the establishment of direct debit mandates if this is not already available to the user online.
HMT Consultation (7.26) states:The government recognises the demand from some TPPs to be able to establish (and terminate) direct debits. The government maintains its view that direct debits are out of scope of payment initiation services unless this facility already exists within a user’s online payment account. The PSDII definition of payment initiation also does not extend to cancelling or amending existing direct debits or standing orders.
CMA Order 24.7.2 has only the following reference to future dated payments and standing orders:‘Scheduled payments’ are: (a) direct debits; (b) standing orders; and (c) future dated bill payments.
FCA Approach Document17.28 For PIS, ASPSPs are required to treat the payment order in the same way, in particular in terms of timing, priority or charges, as a payment order initiated by the customer directly.17.29 In order to meet this requirement, we expect ASPSPs to allow each customer to initiate a payment via a PISP to the same level of functionality that is available to a customer if they initiate a payment directly with their ASPSP. ASPSPs are not, however, required to provide functionality via a PISP that exceeds the functionality they offer to their customers directly. For example, if an account only has the functionality to initiate payments online to another account in the name of the customer, the ASPSP would not be required to build functionality to allow the customer to initiate payments to a third party via a PISP. An ASPSP does not need to allow customers access via a PISP to any online functionality other than initiating payments.