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).
Other pages in this section
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.
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:
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.
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.
VRPs are defined as a series of payments initiated by a PISP using a long-held consent (“VRP Consent”), where:
From an open banking perspective, there are two different ways of managing SCA under VRP:
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.
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.
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).
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:
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.
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:
Through the FCA Sandbox, Open Banking has developed the following understanding of the regulatory treatment of VRP:
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:
The PSU should be able to cancel a VRP Consent at any time, through either the PISP or the ASPSP.
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:
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.
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.
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.”
VRP has applications across many different use cases. The following is a list of example use cases that demonstrate the wide applicability of VRP:
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:
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.
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:
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.
The more permissive a given VRP Consent’s. consent parameters are, the greater the risk associated with managing that VRP Consent, for example:
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.
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.
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.
PISPs are regulated financial institutions and are obligated to control all MLTF risks relating to their regulated activities.
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:
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.
Under the VRP model, there are several levers available to control risks associated with different types of VRP use case:
Because VRP is a regulated PISP activity, PSD2/ PSRs provides a base liability framework.
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.
A service contract between the PISP and PSU can provide additional protections and assurances to customers on top of the PSD2 liability model.
A framework contract between the ASPSP and PSU can provide additional protections and assurances to customers.
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).
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.
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.
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.
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.
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.
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.
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:
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.
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.
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:
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.
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”:
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”.
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:
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.
The following are extracts referencing the scope of VRP & Sweeping taken ‘as-is’ from the published roadmap: