Variable Recurring Payments (VRPs)

1. Executive Summary

Variable Recurring Payments (VRPs) are an emerging and novel way of securely instructing payments through an API. VRPs enable innovation in payment experiences and the creation of new types of financial services for customers. 

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

By enabling PISPs to move money on behalf of customers, VRPs enable new forms of financial automation, improved end-user experiences, and greater levels of consumer transparency and control.

ASPSPs and PISPs are beginning to use their API channels to engage in VRP activities through bespoke VRP APIs. To date, this activity has been conducted within the FCA’s regulatory sandbox on open banking VRPs.

By creating a standard for VRPs, the Open Banking Implementation Entity (“OBIE”) will establish a uniform interface for VRP that:

• Reduces the cost for firms delivering and using VRP APIs.
• Is compatible with the regulatory treatment of VRP.
• Adequately controls risk and protects consumers.
• Establishes a consistent and suitable VRP customer experience across the UK market.

The Revised Roadmap for Open Banking requires the OBIE to develop a VRP Standard as a non-mandatory Standard (Roadmap Item A2(b)(i)). Separately, Roadmap Item A10 requires the OBIE to evaluate how to deliver Sweeping.  If the conclusion of the Sweeping Evaluation is that VRPs are required in order to deliver Sweeping, VRPs could become a mandatory requirement of the CMA9 for the purposes of Sweeping only.

This document provides an analysis of VRPs from a regulatory, risk, and product perspective. Finally, this document distils a set of requirements upon which the materials for a VRP Standard will be based.

2. Introduction

2.1 Purpose of this paper

The purpose of this paper is to form the basis of the OBIE Variable Recurring Payments Standard.

The CMA Order “Agreed Timetable and Project Plan” (see Notice of proposed changes to the open banking roadmap CMA May 2020) published on May 15, 2020, requires the OBIE to develop VRP Standards, specifically:

A2(b)(i) – Variable Recurring Payment, VRP Standards Development: Including functional specifications, Customer Experience Guidelines, consumer protection framework, and dispute management.

3. VRP Concepts

3.1 Definition of Variable Recurring Payments (VRPs)

VRPs are defined as a series of payments initiated by a PISP using a long-held consent (“VRP Consent”), where:

1. the VRP Consent must be authorised by the Payment Service User (“PSU”) via Strong Customer Authentication (“SCA”) at their ASPSP (“VRP Consent Setup”), however, each individual payment instructed (“VRP Payment”) using the VRP Consent does not require SCA of the PSU by the ASPSP;
2. the timing or amount of each payment need not be fixed during the VRP Consent Setup but is instead subject to the constraints of certain parameters (“VRP Consent Parameters”), agreed between the PISP and the PSU, which are enforced by the ASPSP; and
3. the VRP Consent Parameters are included within the VRP Consent and are therefore subject to SCA of the PSU by the ASPSP as part of the VRP Consent Setup.

From an open banking perspective, there are two different ways of managing SCA under VRP:

3.1.1 VRP Payments with an SCA exemption

VRPs with an SCA exemption is defined as “VRP Payments instructed under a VRP Consent with Consent Parameters that qualify for an SCA Exemption such that, following successful VRP Consent Setup, subsequent individual VRP Payments can be made without further authorisation from the PSU.”

ASPSPs are allowed not to apply SCA provided that there is an available SCA exemption^[1].

We recognise there may be instances where an ASPSP may require SCA, even if the payment is made could qualify for an exemption, for example, suspicion of fraud. However, it is expected that the ASPSP would only do so in exceptional circumstances with an objective approach and in line with the proportionality requirements of the PSRs.

3.1.2 VRP Payments with delegated SCA

VRPs with delegated SCA is defined as “VRP Payments that are initiated by the PISP and do not rely on the application of an SCA exemption by the ASPSP, but rather the application of delegated SCA to each individual VRP Payment.” This will provide explicit consent for each payment instruction, dynamically linking the amount and a payee, allowing for flexibility on the VRP Consent Parameters provided that the applicable SCA requirements are met.

The existing OBIE Standard already allows for an ASPSP to delegate SCA to another party to support use cases such as allowing the AISP to re-authenticate the PSU every 90 days (please see https://openbankinguk.github.io/read-write-api-site3/v3.1.6/profiles/read-write-data-api-profile.html#consent-re-authentication). 

3.2 How VRP Consent Parameters Work

VRP Consent Parameters are a set of constraints included within a VRP Consent that restrict the way in which it can be used to make payments. The restrictions are enforced both by the ASPSP and the PISP.

Examples of VRP Consent Parameters are:

• Name of the payee
• Payee account identification details
• The maximum cumulative value of payments initiated under the VRP Consent.
• The maximum cumulative number of payments initiated under the VRP Consent.
• The maximum payment value per payment
• The maximum cumulative payment value per time window
• The maximum frequency of payments per time window
• Expiry Date of the VRP Consent

VRP Consent Parameters can be used by PISPs to minimise risk exposure by tailoring constraints on the VRP Consent to the specific minimal needs of a given activity and to create transparency for the customer on the extent of risk associated with granting a given consent.

Please see section 4.2.1 below for details of how VRP Consent Parameters must be applied when relying on an SCA exemption.

3.3 Definition of Sweeping

Sweeping is a generic term for the automatic movement of funds between accounts.  For the purpose of the CMA Order, OBIE has proposed a specific definition, limited to the movement of a customer’s own funds between accounts owned by them.  Payments made to other individuals or other companies, e.g. paying for goods or services, would be excluded under this definition.   

For a VRP transaction to be able to meet the definition of “Sweeping” it needs to meet the following criteria:  

1. The source account needs to be a PCA or BCA.
   (PCAs or BCAs which require multi-authorisation are explicitly excluded from the definition. Joint accounts typically do not require multi-authorisation as both parties have full authority to make payments and so would be included in the definition.) 
2. The destination account is an account into which a domestic payment can be made by the payer’s bank’s direct channel.^a 
3. Both accounts are UK sterling accounts.  
4. The payment can be an unattended payment, not requiring any interaction by or presence of the PSU at the time of making the payment.^b  
5. The transaction is between two accounts belonging to the same person or legal entity.^c 

Footnote

4. Regulatory treatment of VRP

Through the FCA Sandbox, Open Banking has developed the following understanding of the regulatory treatment of VRP:

4.1 VRP classification as PISP activity

VRP is a regulated PISP activity. A PISP is able to initiate VRP Payments provided that the PSU has given their ‘explicit consent’. From a PSRs perspective the PSU can give their explicit consent for VRP Payments either through:

• VRP Consent Parameters (e.g., payee, maximum amount, frequency of payments and duration) strongly authenticated by the ASPSP during the VRP Consent Setup, allowing for an SCA exemption for individual VRP Payments, or;
• Delegated SCA of the PSU by the PISP or another party for individual VRP Payments.

The PSU should be able to cancel a VRP Consent at any time, through either the PISP or the ASPSP.

4.2 Explicit consent

PSR, Regulation, 69(2) requires ‘explicit consent’ for the instruction of payment orders. Under VRP, explicit consent for payment instructions can be achieved in two ways:

4.2.1 VRP Payments with an SCA exemption

Once the Initial VRP Consent Setup is successfully complete, which includes the application of SCA covering the VRP Consent Parameters, the PISP may initiate, on the PSU’s behalf, a series of VRP Payments within those VRP Consent Parameters and without the PSU being required to authenticate again.

These payments must rely on the application of an available exemption. The type of exemption that an ASPSP may choose to apply will be largely dependent on the payment attributes. For example, where the payee in a VRP Consent remains the same, the ASPSP will likely rely on the Article 13 exemption set out in the SCA-RTS (by setting up the payee as a trusted beneficiary) or another available exemption (e.g., Transaction Risk Analysis or low value).

The customer can be treated as having given explicit consent for each VRP Payment under a VRP Consent, provided that:

a)     the payee is fixed;

b)     the number and/or frequency of payments is fixed (or capped); and

c)     although the amount cannot be fixed in advance, there are clear parameters around the permitted value, such as maximum individual payment amount, maximum total value in a month or year etc.

Once the VRP is set up and the appropriate exemption applied, the application of the wider PSR framework, together with FCA regulation of PISPs and ASPSPs, ensures appropriate provisions are in place to govern every single immediate payment that is made under the VRP Consent.

PSRs, Reg 69(3)(h) states that a PISP is not permitted to “change the amount, the payee or any other feature of a transaction notified to it by the payer”. In the context of VRP, the ‘amount’ referred to should be treated as the cap or range agreed to by the payer in the original VRP Consent. The PISP cannot change or exceed this value, and the payee and frequency (or maximum number) of transactions are fixed.

4.2.2 VRP Payments with delegated SCA

Once the Initial VRP Consent Setup is successfully complete, the PISP can initiate, on the PSU’s behalf, a series of VRP Payments within the VRP Consent Parameters with the application of delegated SCA for each individual VRP Payment. This provides explicit consent for each payment instruction and dynamically links the amount and a payee, providing flexibility on the VRP Consent Parameters provided that the applicable SCA requirements are met.

This method is designed to enable smoother customer experience and increased innovation and has received significant interest from several large TPPs and merchants. However, delegated SCA requires some form of contract between the ASPSP and PISP and, to date, there have been no reported examples of delegated SCA being implemented.

However, delegating SCA under a VRP Consent offers several distinct advantages to delating SCA without a VRP Consent, specifically:

a)     the VRP Consent can contain one or more VRP Consent Parameters, which the ASPSP can use to limit/mitigate risk (e.g., frequency and amount of payments);

b)     the flexibility of using these VRP Consent Parameters in different combinations can meet a wide number of different use cases; and

c)     the PSU will have full visibility and control in the case they need to view and potentially revoke access at the ASPSP.

Therefore, this category of VRP is more likely to gain traction with ASPSPs and PISPs who wish to offer delegated SCA.

4.3 Liability model of PSD2 in relation to VRP

VRP is considered a PISP activity and consequently, the PSRs liability framework applies.

This topic is covered in more detail in section 6.6 “Liability and Dispute management.”

5. VRP Use Cases

VRP has applications across many different use cases. The following is a list of example use cases that demonstrate the wide applicability of VRP:

6. Risks & Mitigations in VRP Activity

6.1 Introduction

To date, while the OBIE specification supports a wide variety of payments, PISPs in the UK have mostly engaged in this regulated activity using the Single Immediate Payment (SIP) APIs standardised by Open Banking, in which each payment undergoes SCA of the PSU by the ASPSP.

As a novel PISP activity, VRPs introduce a new set of challenges with regard to risk and liability. This is because, unlike the existing SIPs, subsequent VRPs do not undergo SCA of the PSU by the ASPSP. When instructing payments under the VRP model, the PISP will either:

• Make a decision to instruct the payment order on behalf of the customer without SCA by reliance on an available exemption (“unattended payments”). This activity is classified as a VRP payment with an SCA exemption (Section 4.2.1), or;
• Carry out SCA of the PSU either themselves or via another party to whom the ASPSP has delegated the responsibility for SCA (“customer in session”). This activity is classified as a VRP payment with delegated SCA (Section 4.2.2).

6.2 Customer Protection Framework

Given that VRP is a regulated PISP activity, the market can derive assurance on PISPs ability to control risk, and appropriately protect customers, through the regulatory oversight afforded to it as a regulated activity.

As a regulated financial institution, PISPs are required to have appropriate risk controls in place for the activities they engage in, and this is assured to market through their regulatory supervision.

Under supervision, PISPs will ensure that adequate consumer protections and other risk controls are in place to cover their VRP activities, and this would be guided under the FCA’s Principles for Business. PISPs that do not sufficiently protect consumers or control risk will be detected and corrected through the regulator’s monitoring and supervision of PISP activity, as well as, through dispute mechanisms like the FOS, which are available to their customers.

This model allows PISPs to adopt risk controls suited to their specific activities whilst regulatory supervision provides assurance that consumers remain adequately protected and risks are sufficiently controlled.

FCA Principles for businesses that regulated firms must adhere to 

PISPs should ensure consumers are aware of the terms of the consumer protections afforded to them under contract. PISPs should mitigate any risk that customers mistakenly assume consumer protections from other existing payment methods apply.

6.3 Factors that impact risk in VRP use cases

Our analysis has identified some key factors affecting the levels of risk associated with different types of VRP use case, which PISPs will need to address through their risk controls:

6.3.1 Customer presence for VRP payment

If the use case requires that the customer is “not in session” for the instruction of an individual VRP payment (i.e., does not perform SCA of the PSU and relies on the application of an available SCA exemption), then there is an increased risk of customer dispute because the PISP may instruct a payment on behalf of the PSU which the PSU would dispute. We note that this risk factor does not apply to VRP Payments with delegated SCA.

6.3.2 Permissiveness of consent parameters

The more permissive a given VRP Consent’s. consent parameters are, the greater the risk associated with managing that VRP Consent, for example:

• a large maximum amount per payment
• a very distant expiry date (or no expiry date at all)

PISPs should ensure that the consent parameters they negotiate with the PSU are not unnecessarily or unreasonably permissive. Consent parameters that are unreasonably permissive would be inappropriate for VRP Payments with an SCA exemption (Section 4.2.1) since that would compromise the PISP’s ability to treat each payment as if it had explicit consent from the PSU.

6.3.3 Payments to a counterparty

VRP Payments to a counterparty (i.e., where the payer is different from the payee) involve counterparty risks and therefore increased likelihood for dispute. This is particularly true for “consumer payment” use cases, where contracts should set out terms to both parties and establish a suitable dispute process with sufficient protections.

6.3.4 Recoverability of funds

If the destination account of the VRP Payment carries with it more difficulty in recovering funds (e.g., long term savings accounts), then the increased challenge in reversing the flow of funds for payments made in error represents an increased risk.

6.3.5 Money Laundering and Terrorist Financing (MLTF)

PISPs are regulated financial institutions and are obligated to control all MLTF risks relating to their regulated activities.

6.3.6 Erosion of PSU consent over time

The risk is that a PSU loses awareness of a VRP Consent or is unable to manage it appropriately over time. This forms part of a PISP’s duty of care to customers, and they should ensure:

• PSUs are notified appropriately of VRP Payments (before and/or after, dependent on use case).
• PSUs are offered appropriate mechanisms for managing the VRP Consent over time (e.g., by offering the consent dashboard interface defined in the OBIE VRP Standard).

6.3.7 Misattribution of destination account ownership & APP scams

The risk that the ownership of the destination account is misattributed, a payment is made to an account that is not in the name of the recipient intended by the PSU, and the potential for customer detriment to arise as a result. Failing to control for this risk could facilitate APP scams. PISPs must develop risk controls that appropriately mitigate these risks as part of their duty of care to the customer.

6.4 Available risk control mechanisms in VRP

Under the VRP model, there are several levers available to control risks associated with different types of VRP use case:

6.4.1 PSD2 liability model

Because VRP is a regulated PISP activity, PSD2/ PSRs provides a base liability framework.

6.4.2 Consent parameters

The VRP consent that is granted by the PSU to the PISP can include a set of agreed parameters that constrain the use of the consent (e.g., specifying the destination account, limiting the amount, expiry date, etc). This provides transparency and assurance to the PSU by allowing them to agree to payments within specific limitations.

6.4.3 PISP-PSU contract

A service contract between the PISP and PSU can provide additional protections and assurances to customers on top of the PSD2 liability model.

6.4.4 ASPSP-PSU contract

A framework contract between the ASPSP and PSU can provide additional protections and assurances to customers.

6.4.5 ASPSP-PISP contract

A contract between ASPSP and PISP can establish terms of liability, risk controls, consumer protection rules, and dispute processes (see Section 6.6 for more on dispute management).

6.4.6 Non-repudiation between ASPSP and PISP for granting of consent and individual payments

The VRP standard requires PISPs and ASPSPs to sign their API requests and responses. Message signing provides PISPs and ASPSPs with cryptographic attestation and proof of their interactions, which acts as a risk control by establishing non-repudiation between ASPSP and PISP throughout the VRP consent setup and individual VRP payments.

6.4.7 PISP attestations to the nature of individual payment

When making a VRP Payment, PISPs can attest to the nature of the payment. This signalling helps assure ASPSPs that the nature of the activity is as agreed under the terms of access granted to the PISP.

6.4.8 PSU revocation of access at the ASPSP

PSUs are granted full visibility and control over all the variable recurring payment access given by the PSU to all PISPs on the access dashboard. This enables the PSU to review and revoke specific access given to PISPs.

6.4.9 PSU revocation of consent at the TPP

PSUs are granted full visibility and control over all VRP Consents given to an individual PISP at one or more ASPSPs on the consent dashboards. This enables the PSU to review and revoke specific VRP consents given at different ASPSPs.

6.4.10 Arbitration and dispute processes

PISPs can establish processes that define how arbitration and dispute are managed for VRP Payments that involve counterparty risk. Consumer protections should be included in these processes and afforded by the PISP to PSUs under contract.

6.4.11 Monitoring for dormant consents

PISPs should monitor for VRP Consents that are dormant and remain unused. When a dormant consent is identified, PISPs should make a risk-based decision about whether to notify the customer and/or revoke the consent.

6.4.12 Consent and Access Dashboards

To address the potential erosion of PSU consent over time, PSUs should be offered “dashboards” to review and manage VRP activities associated with their account. More specifically:

• ASPSPs should offer the PSU an access dashboard to manage all VRP access to accounts.
• PISPs should offer the PSU a consent dashboard to manage the VRP Consents granted to the PISP.

6.4.13 Notification of VRP Payments to PSU

PISPs should notify the PSU of VRP Payments once they have been initiated. Notifications must be issued after a VRP Payment is initiated and can also be issued prior to initiation to keep the PSU informed.

6.4.14 Validation of destination account ownership

In order to mitigate the risk that the ownership of the destination account is misattributed, PISPs should take reasonable steps to ensure that the ownership of the destination account is in line with the expectations of the PSU.

6.5 Types of VRP access

Whilst the VRP standard will set out how VRP Consents are setup and VRP Payments are initiated, it does not set out to prescribe the terms of the access by which PISPs may access a given ASPSP’s VRP API.

We have identified three main types of VRP access that may be afforded to PISPs:

6.6 Liability and Dispute management

VRP is a PISP activity and falls into the PSRs liability framework. PISPs and ASPSPs engaging in VRPs will also need to ensure that their dispute resolution procedures for their customers are designed to both identify and address specific VRP disputes in order to offer their customers appropriate protections. For example, if the customer claims that the transaction was unauthorised, they would be entitled to a refund (and if applicable the additional funds to restore their account state it would have been had the unauthorised transactions not taken place) provided the requirements are met from their ASPSP. The ASPSP would then have a right of recourse against the PISP for the losses incurred and the amount they have compensated to the customer.

 In addition to the customer protections available in the PSRs and DISP rules, it is also recommended that ASPSPs and PISPs create their own innovative and robust customer protections within VRP contractual agreements with each other. This is seen as a key driver in encouraging adoption and driving competition within the variable recurring payment landscape.

OBIE also is the facilitator of Dispute Management System (DMS), which is a unique platform that provides an end-to-end case management tool that enables Account Servicing Payment Service Providers (ASPSPs) and Third-Party Providers (TPPs) to connect and share information securely and safely for the purpose of answering customer enquiries, disputes or complaints. DMS currently supports a wide range of categorisations of potential customer disputes and complaints that could arise from open banking products and services. These categorisations could be extended to support VRP disputes, as well as, expanded to capture any new categorisations that may emerge as a result of VRPs.

7. Example Customer Journey

The following wireframes demonstrate how VRP could be applied to setting up recurring bill payments for a mobile phone contract:

The following wireframes demonstrate ongoing bill payment made with the above VRP Consent when the customer is not “in session”:

8. Requirements for the VRP Standards

These are stated as requirements of the OBIE solution to provide a standard for VRP.

Requirements marked as ‘M'(Must) are in the scope of the OBIE solution. All other requirements are listed for future consideration.

All requirements below are ‘optional’ for implementation by ASPSPs and/or TPPs for non-sweeping use cases. However, for sweeping, in the event any CMA9 is mandated to implement VRPs, these requirements are ‘conditional’ for implementation, as they will be ‘mandatory’ for in scope CMA Order (e.g., PCA and BCA) accounts and ‘optional’ for other accounts. These terms are defined in the document “Categorisation of requirements for standards and implementation”.

9. Requirements for VRP Sweeping Access

OBIE is establishing a standardised form of VRP access intended for sweeping activities (“Sweeping Access”) as per the recommendation contained in the sweeping consultation document.

The requirements for standardised sweeping access build on top of the above VRP standards requirements by introducing the following additional constraints:

1. Require the PISP to attest that the activity meets the standardised definition of sweeping.
2. Require the use of a specific set of consent parameters.
3. Require the application of
   1. the Trusted Beneficiary SCA exemption by the ASPSP for each Sweeping Payment. OR
   2. the ‘Transfer to Self’ SCA exemption by the ASPSP for each sweeping payment within the same ASPSP.

This standardised sweeping access is mandatory under the CMA Order and includes the implementation of Requirements for the VRP Standard, as well as Requirements for Sweeping Access, by the CMA9.

For simplicity, we will use “Sweeping Consents” and “Sweeping Payments” to refer to VRP Consents and VRP Payments under Sweeping Access.

10. Measuring VRP usage

10.1 Optional MI for VRP Standards

• The total number of PISPs that have setup VRP Consent for the first time.
• The total volume of VRP Consent set up through a PISP for non-sweeping.
• The total volume of successfully setup VRP Consent via PISPs for non-sweeping.
• The total volume of VRPs that failed to be authorised by the PSU for non-sweeping.
• The total volume of Variable Recurring Payment access that was cancelled by PSU at the ASPSP for non-sweeping.
• The total volume of successful VRP payments for non-sweeping.
• The total volume of failed VRP payments for non-sweeping.

10.2 Required MI for Sweeping Access

• The total number of PISPs that have setup Sweeping Consent for the first time.
• The total volume of Sweeping Consent set up through a PISP.
• The total volume of successfully setup Sweeping Consent via PISPs.
• The total volume of Sweeping VRPs that failed to be authorised by the PSU.
• The total volume of Sweeping Variable Recurring Payment access that was cancelled by PSU at the ASPSP.
• The total volume of successful VRP payments for Sweeping.
• The total volume of failed VRP payments for Sweeping.
• The total volume of VRP payments for sweeping where the ASPSP decided the Trusted Beneficiary Exemption could not be applied.

11. Appendix

11.1 Roadmap item reference

The following are extracts referencing the scope of VRP & Sweeping taken ‘as-is’ from the published roadmap:

11.2 Identifier reference

https://openbankinguk.github.io/read-write-api-site3/v3.1.6/profiles/payment-initiation-api-profile.html#identifier-fields

12. Version control