Propositions

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.

Other pages in this section

1. Version Control
2. Roadmap Definition
3. Market analysis
4. Customer use cases
5. Regulatory references
6. Evaluation criteria
7. Product requirements
8. Considerations
9. Measuring adoption
10. Appendix

1. Version Control

Version	Date	Authors	Comments
V1.1	05 Oct 2018	OBIE API Delivery Team	CR to Update MoSCoW, Rationale and add Implementation for Detailed Product Requirements based on Categorisation of requirements for standards and implementation
V0.1	05 Apr 2018	OBIE API Delivery Team	Draft for internal review
V1.0	23 Apr 2018	OBIE API Delivery Team	Final version, approved at IESG on 23 Apr 2018 (no changes from v0.3).
V0.2	06 Apr 2018	OBIE API Delivery Team	For review RLWG, PMG, PAG, SWFG, DWG
V0.3	16 Apr 2018	OBIE API Delivery Team	Update based on consultation feedback for approval at IESG. See change log for details of all changes.

2. Roadmap Definition

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:

Future Dated Payments – setup through a PISP and initiated and executed by the ASPSP
Standing Orders – setup through a PISP where individual payments in the series are initiated and executed by the ASPSP

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“.

3. Market analysis

To satisfy use cases identified in this paper, TPPs currently use:

Debit/Credit card for setting up a future dated payment and
Debit/Credit card or a Direct Debit for setup of recurring payments of a fixed amount.

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:

PSUs more visibility and control on the payments as compared to cards and
TPPs an option which is cheaper with quicker fulfilment of funds.

4. Customer use cases

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.

ID	Single Future Dated Payments	Met
UC1 Personal Finance Manager	As a consumer, I want to use a Personal Finance Manager (PFM) tool to move a specific amount from one PCA account in credit to my PCA account from another provider in debit sometime in the future, so that I can avoid overdraft charges.	Partly
UC2 Invoice payments	As an SME I want to use a third party invoice management tool to approve my invoices by setting up the payments for dates in the future so that I can manage my cash flow.	Partly
UC3 Ecommerce	As a retailer, I want to create a single future dated payment for a purchase, from a customer's account to mine, so that I can receive the funds closer to the date when I am able to dispatch the good.	Partly
ID	Standing Orders	Met
UC4 Smart Credit	As an SME I want to use a third party smart lending app that offers me flexible short term credit and also automates repayments of a fixed amount with a fixed schedule.	Partly
UC5 Pocket money	As a parent, I want to use a third party pocket money management product to setup a fixed amount to be paid every week into my child's prepaid card account, so that they can receive their pocket money.	Partly
UC6 Personal Finance Manager	As a consumer I want to use a personal finance manager tool to have a consolidated view of my accounts and be able to setup new standing orders against these.	Partly
UC7 Subscription service	As a subscription service provider, I want to setup a scheduled recurring payment for a fixed amount as part of the online signup process, so that I can make the subscription process simpler for the customer.	Partly
ID	Variable Recurring Payments(to be addressed as part of P8)	Met
UC8 Smart Savings	As a customer I want to use a third party smart saving app that moves money from my bank accounts to my investment account vehicle on a flexible/variable basis so that I can save money.	Not at all

5. Regulatory references

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.

6. Evaluation criteria

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)

Does the proposition meet the use cases from a PSU and a TPP perspective (from both an outcome and risk point of view)?
Is the proposition implementable at a reasonable cost?
Does the proposition comply with all relevant regulations?

7. Product requirements

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:

Future Dated Payment (FDP): A PSU can set up, through a PISP, an instruction to their ASPSP to make a one-off payment for a specific amount to a specific payee on a specific future date.
Standing Order (SO): A PSU can set up, through a PISP, an instruction to their ASPSP to make a series of payments of a specific amount to a specific payee on a number of specified future dates or on a regular basis.

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:

Cancelling or editing an FDP or SO via a PISP
Setup, initiation, amendment and revocation of direct debits from a PSU account
Setup of direct debit collections to the PSU account

8. Considerations

8.1 Assumptions

A single immediate payment cannot be cancelled (as per current version 1 specification).
Cancellation of any instruction with the ASPSP is subject to sufficient notice (business day -1) being given by the PSU for any payments not yet initiated.

8.2 Dependencies

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.

8.3 Constraint

Structure of FDP and SO can vary across the ASPSPs which needs to be factored in while standardizing the APIs.
While some requirements are not in scope for the minimum compliance product (MCP), these may require changes to the design if addressed at a later stage. This needs to be factored in during the design phase, to ensure that the MCP is future-proof and allows for them at a later date if required.

9. Measuring adoption

The following metrics will be required to measure adoption:

Number of TPPs using the setup of FDP and SOs
Volume of FDPs and SOs setup through a TPP
Volume of failures for setup of FDPs and SOs by type of failure for each payment type
Volume of successful transactions generated by each of the above payment types
Volume of failed transactions by type of failure for each payment type
Volume of FDPs and SOs amended and deleted by PSUs in ASPSP interface

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

10. Appendix

10.1 Roadmap item definition

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)

Description	Rationale	Aligns with
Scope Item description: Extension of write (PIS) functionality of the OB R/W APIs to payment types other than non-single immediate payments (including but not limited to future-dated payments, recurring payments and standing orders) for sterling denominated current accounts and in alignment with the payment initiation services that apply under PSD2 Key activities: A discovery phase by the OBIE to understand the variety of payment models, understand gaps in existing functionality and create the business requirements for the standards The development of standards by the OBIE for the products and functionality referred to above The implementation of those standards by the CMA9 for Release 2	Regulatory alignment: Fulfils the requirements of the Order by aligning with PSD2 Open Banking adoption: Extends functionality of OB Standards use cases beyond single-immediate payments including recurring, sweeping and subscription propositions Consumer / SME utility: Consumers would be able to benefit from innovative use cases Security / Integrity: Consumers would be able to execute recurring payments without putting cards on file	PSD2

10.2 Detailed Product Requirements

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.

ID	Description	MoSCoW	Rationale	Use Cases	Implementation
1	The OBIE's Solution(s) must allow a PISP to transmit or confirm the PSU's consent to the initiation of a payment order, which includes the setup of a FDP and a SO. A FDP is a one-off payment for a specific amount to a specific payee on a specific future date where the payment is warehoused with the ASPSP. A SO is a payment of a specific amount to a specific payee for a number of future dates or on a regular basis where the instruction is warehoused with the ASPSP and individual payments in the instruction are executed by the ASPSP.	M	Regulatory	UC1 to UC7	Conditional (Mandatory if provided by ASPSP in existing channel)
2	The OBIE's Solution(s) must enable PISPs to initiate payer-initiated payment transactions from all types of payment account, which could include the set-up of FDP and SOs, provided this functionality is available on the ASPSPs online channel to the PSU.	M	Regulatory	UC1 to UC7	Conditional (Mandatory if provided by ASPSP in existing channel)
3	The OBIE's Solution(s) must allow the ASPSP to apply SCA for setup of a FDP or a SO via a PISP (subject to ASPSP discretion to apply exemptions where available).	M	Regulatory	UC1 to UC7	Conditional (Mandatory if provided by ASPSP in existing channel)
4	The OBIE's Solution(s) must allow the PSU to setup a FD or SO instruction via the PISP with the same capability as that of a FD or SO instruction they setup directly via the ASPSP online channel (e.g. with a start and end date with a different amount to the recurring part of the SO).	M	Regulatory	UC1 to UC7	Conditional (Mandatory if provided by ASPSP in existing channel)
5	The OBIE's Solution(s) should allow the revocation of a future dated payment order up to and including the business day prior to execution of the payment order by the ASPSP.	M	Regulatory	UC1 to UC7	Refer to Customer Experience Guidelines
6	The OBIE's Solution(s) must allow the ASPSP to return the status of the payment to the PISP immediately after the receipt of the payment order for SOs and FDP.	M	Regulatory	UC1 to UC7	Conditional (Mandatory if provided by ASPSP in existing channel)
7	The OBIE's Solution(s) must enable the PISP to return a confirmation of successful initiation to the PSU and hence this must also enable the ASPSP to return this confirmation to the PISP (e.g. where this happens at some time after the receipt of the payment order).	M	Regulatory	UC1 to UC7	Mandatory (The GET on the status endpoint is mandatory and the call-backs are optional)
8	The OBIE's Solution(s) should provide information to the PSU (via PSU's PISP) on the applicable execution time and charges (with breakdown) for FDP & SOs from the payer's ASPSP if there is a framework contract in place.	M	Customer	UC1 to UC7	Optional Refer to Customer Experience Guidelines
9	The OBIE's Solution(s) must enable AISPs to access account information on all types of payment, including to enable AISPs to have read access to SOs and FDPs which were setup via the PISP to same extent as to SOs and FDPs set up directly.	M	Regulatory	UC1 and UC6	Conditional (Mandatory if provided by ASPSP in existing channel)
10	The OBIE's Solution(s) must allow for the CASS process so that when a PSU switches account, the FDPs and SOs setup via a PISP with the previous ASPSP can be ported to the new ASPSP.	M	Regulatory (not PSD2)	UC1 to UC7	Conditional (Mandatory if endpoint is implemented by ASPSP)
11	The OBIE's Solution(s) must allow a PISP to transmit or confirm the PSU's consent to the initiation of a payment order, which includes the setup of a FDP and a SO for international payments. Detailed requirements covered under P10 - International payments (GBP debtor accounts) and P21: PSD2 in-scope accounts (multi-currency debtor accounts).	M	Regulatory	UC1 to UC7	Conditional (Mandatory if provided by ASPSP in existing channel)
12	The OBIE's Solution(s) must allow a PISP to transmit or confirm the PSU's consent to the initiation of a payment order, which includes the setup of a FDP and a SO from accounts that require multiple parties to authorise. (Detailed requirements covered under P13).	M	Regulatory	UC1 to UC7	Conditional (Mandatory if provided by ASPSP in existing channel)
13	The OBIE's Solution(s) must enable the ASPSP to request the same information from the PISP as is requested from the PSU setting up an SO or FDP directly.	M	Regulatory	UC1 to UC7	Conditional (Mandatory if provided by ASPSP in existing channel)
14	The OBIE's Solution(s) must allow ASPSPs to publish the structure of a SO and FDP instruction and the execution of payment for these (e.g. business hours only) as supported by them as these may vary across ASPSPs.	M	Customer	UC1 to UC7	Mandatory (If endpoint is implemented by ASPSP)
15	The OBIE's Solution(s) should allow ASPSPs to provide MI on metrics and adoption as per section 9 above.	M	Customer		Refer to MI Template
16	The OBIE's Solution(s) could allow the PSU to amend and revoke a SO and FDP via the PISP through whom the SO or FDP was setup. The details of whether this will require SCA/Authorisation will be addressed in the design phase if this requirement is catered for in a subsequent iteration.	C	Customer	UC1 to UC7	Not in current scope.
17	The OBIE's Solution(s) could allow the ASPSP to return the status of each payment execution at any further time after the receipt of the payment order for SOs and FDP to the PISP. This is being evaluated as part of P9 - Status of payment.	C	Customer	UC1 to UC7	Future Consideration (To be covered under P9)
18	The OBIE's Solution(s) could allow the PISP to be notified when the PSU revokes a FDP or SO through their ASPSP. The exact design of the notification (push or pull) will be covered under proposition for roadmap item P2 - Two way notification of revocation.	C	Customer	UC1 to UC7	Future Consideration (To be covered under P2)

10.3 Market Analysis

**Volume of UK consumer payments**
*Source: 2015 data, Economics of Request for Payment (Accenture)*

Direct Debits and Credit/Debit cards are the two commonly used instruments by TPPs for setting up future dated and recurring fixed value payments.
Authentication of the PSU during setup for both is weak and hence vulnerable to fraud
These are limiting to TPP use cases as these incur cost and the fulfilment of funds is not immediate
Cards have no PSU control in terms of visibility and revocation of authorisations
Ability to set up a SO and FD through a TPP does offer PSUs more control on the authorisations as compared to cards and gives the TPPs an option which is cheaper with quicker fulfilment of funds.

10.4 Customer Research

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

FDP setup: https://invis.io/ZHF0ZAZ4R
SO setup: https://invis.io/MSF0UW8P2

The research was specifically conducted to test the journeys for

Ease of use, clarity and to identify frustrations
Review specific features
Understanding terms used

The overall outcome of the research is as follows

There wasn’t a spontaneous awareness of OB but the reactions were positive overall
There was confusion on the need to go through banking pages to make payments
Security concerns remain high and customers need better education and reassurance

Detailed findings from the customer research conducted by OBIE can be found in the attached report below

10.5 Regulatory references

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:

execution of direct debits, including one-off direct debits; (b) execution of payment transactions through a payment card or a similar device; (c) execution of credit transfers, including standing orders.

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 Document
17.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.

Cookie	Duration	Description
cookielawinfo-checkbox-analytics	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional	11 months	The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy	11 months	The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.