Proposition - Variable Recurring Payments (VRPs)

Disclaimer: The contents of this document do not constitute legal advice. Whilst the VRP Proposition Paper has been drafted with regard to relevant regulatory provisions and best practice, it is not a complete list of the regulatory or legal obligations that apply to Participants. Participants are responsible for their own compliance with all regulations and laws that apply to them, including without limitation, PSRs, PSD2, GDPR, consumer protection laws and anti-money laundering regulations.

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

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.

  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 

a - For example, savings accounts, building society savings accounts using a roll number, or personal credit card accounts are valid destination accounts. 

b - It should be noted that the customer will need to be present when the mandate for the payment service is set up. 

c - For the avoidance of doubt, it should be noted that the destination account may not have a unique sort code and account number, for example, e-money accounts, building society roll number accounts and head office collection accounts for loans and credit cards may have common sort code and account numbers but a unique reference in the transaction will ensure the payment is applied to the correct customer’s account. 

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.

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:

ID

Use case description.

1

As a homeowner, I want to allow my electricity provider to automatically take payments from my bank account but only up to a maximum of £100 per month.

2

As the user of a social network, I want to connect my bank account so that I can make quick and easy in-app authentication of payments to my friends and be able to easily disconnect it from an access dashboard with my bank if I change my mind.

3

As a new customer of a subscription service, I want to set up my subscription payments such that it expires after 6 months so that I don’t get caught in a subscription trap.

4

As a ride-hailing app customer, I want to connect my bank account so that payment is made automatically on my behalf as I arrive at my destination with a maximum payment size of £45.

5

As a customer using an online marketplace, I want to do a one-time payment setup for one-click payments offered by the marketplace to enable a quick checkout process.

6

As a customer looking to earn more interest, I want to use a third-party smart saving app that moves money from my bank accounts to my own saving account on a flexible/variable basis so that I can save money.

7

As a customer looking to avoid unnecessary fees, I want to use a third-party service that monitors my account to maintain a threshold balance in my account or avoid overdraft fees and moves funds as and when required between my accounts.

8

As a customer in financial difficulty, I want convenient short-term credit to avoid going overdrawn, and then to automate repayments so that I minimise both my overdraft fees and borrowing costs.

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 

Principle

Description

  1. Integrity

A firm must conduct its business with integrity.

  1. Skill, care and diligence

A firm must conduct its business with due skill, care and diligence.

  1. Management and control

A firm must take reasonable care to organise and control its affairs responsibly and effectively, with adequate risk management systems.

  1. Financial prudence

A firm must maintain adequate financial resources.

  1. Market conduct

A firm must observe proper standards of market conduct.

  1. Customers' interests

A firm must pay due regard to the interests of its customers and treat them fairly.

  1. Communications with clients

A firm must pay due regard to the information needs of its clients and communicate information to them in a way which is clear, fair and not misleading.

  1. Conflicts of interest

A firm must manage conflicts of interest fairly, both between itself and its customers and between a customer and another client.

  1. Customers: relationships of trust

A firm must take reasonable care to ensure the suitability of its advice and discretionary decisions for any customer who is entitled to rely upon its judgment.

10. Clients' assets

A firm must arrange adequate protection for clients' assets when it is responsible for them.

11. Relations with regulators

A firm must deal with its regulators in an open and cooperative way and must disclose to the appropriate regulator appropriately anything relating to the firm of which that regulator would reasonably expect notice.

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.

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.

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.

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

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.

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.

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:

 

Description

Impact on liability and risk

Bilateral contractual access

A bilateral agreement between each PISP and ASPSP that can define terms of VRP access including:

  • Liability shifts

  • Consumer protection rules

  • Dispute processes

  • Commercial model

A contract can establish liability shift from ASPSP to PISP in addition to PSD2 liability model when the VRP activity is high enough risk to require that.

ASPSP duty of care to customer provides additional assurance on quality of customer protections determined in the contract.

Multilateral contractual access

A multilateral contract between one or more ASPSPs and one or more PISPs that can define terms of access VRP including:

  • Liability shifts

  • Consumer protection rules

  • Dispute processes

  • Commercial model

The same as above, but including:

A predefined set of terms across all participants.

Terms can establish standardised set of consumer protections and liabilities across all participants.

Regulated
non-contractual access

Access afforded to a PISP as a regulatory right that does not require a contractual basis for access.

Without a contract in place the standard PSD2 liability model applies.

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

ID

Description

MoSCoW

ASPSP implementation for non-sweeping

CMA9 implementation for sweeping

1

The OBIE's Solution(s) must allow the PISP to transmit and confirm the PSU's VRP Consent to the ASPSP.

M

Optional

 Conditional

2

The OBIE's Solution(s) must define identifiers and semantics for the following VRP Consent Parameters that may be included in a VRP Consent:

  • Payee Account Name.

  • Payee Account Identification details (e.g., account number and sort code or additionally roll number or full IBAN).

  • The maximum amount of each VRP Payment

  • The maximum cumulative amount per time window*

  • Expiry Date

  • Consent Reference (Remittance Information)11.2(3)

*time window – Day/Week/Fortnight/Month/Half Year/ Year

Note: ASPSP should support all the time window enumerations for VRP.

M

 Optional

 Conditional

3

The OBIE Solution(s) must allow the PISPs to initiate domestic payments with the VRP Consent.

M

 Optional

Conditional

4

The OBIE's Solution(s) must allow the ASPSP to apply SCA during VRP Consent Setup.

M

 Optional

 Conditional

5

The OBIE's Solution(s) must enable the ASPSP to apply any relevant SCA exemption when the PISP initiates a VRP Payment within the VRP consent parameters.

M

 Optional

Conditional

6

The OBIE's Solution(s) must enable the PSU to select the payment account directly with the ASPSP as part of the

VRP consent set up process if not already provided via the PISP.

M

 Optional

 Conditional

7

The OBIE's Solution(s) must enable the ASPSP to return to the PISP, as part of VRP Consent Setup, the payment account if the PSU has selected one with the ASPSP.

M

Optional

 Conditional

8

The OBIE's Solution(s) must enable the PISP to transmit the following for each VRP Payment:

  • reference to identify the VRP consent (VRP Consent ID)

  • InstructionIdentification11.2(2)

  • Amount.

  • Currency.

  • Reference (Remittance Information)11.2(3)

  • Date.

  • *type of transaction (customer in an active session OR customer not in active session).

  • indicator to show whether the customer is in session or out of session.

Note:

*Customer not in active session: when the PSU is not in an active session of the PISP and the PISP has initiated the payment on behalf of the customer.

Customer in an active session: PSU was in an active session of the PISP service and has performed a Call to action to initiate the payment.

M

 Optional

 Conditional

9

The OBIE's Solution(s) must enable the PISP to indicate whether the customer is present in the session or out of session for each VRP payment initiated as part of a VRP Consent.

M

 Optional

 Conditional

10

The OBIE’s Solution(s) must enable the PISP to provide additional evidence to the ASPSP of customer attestation for specific VRP payment.

M

 Optional

 Conditional

11

The OBIE's Solution(s) must require the ASPSP to reject a VRP Payment if the payment would exceed the VRP Consent Parameters.

M

 Optional

 Conditional

12

The OBIE's Solution(s) must require the ASPSPs to provide accurate and structured error message when payment initiated by PISP is outside the VRP consent parameters, indicating the parameter that was breached and reason.

M

Optional

 Conditional

13

The OBIE's Solution(s) must allow ASPSPs to provide a specific error message when a VRP Payment cannot be instructed because it has been deemed to require SCA.

M

 Optional

 Conditional

14

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

M

 Optional

 Conditional

15

The OBIE's Solution(s) must enable the PSU to setup multiple VRP Consents, with varying Consent Parameters, for the same PISP at an ASPSP.

 

 Optional

 Conditional

16

The OBIE's Solution(s) must provide guidance to PISPs on notifying the PSU either prior or post-initiation of a VRP.

Note: This could vary based on the use case or bilateral between the PISP and the PSU.

M

 Optional

Conditional

17

The OBIE’s Solution(s) must enable PISPs and ASPSPs to refund the PSU the amount disputed by the PSUs.

M

 Optional

 Conditional

18

The OBIE's Solution(s) must enable the PSU to revoke a VRP Consent via the PISP.

M

 Optional

 Conditional

19

The OBIE’s Solution(s) must enable the PSU to revoke Variable Recurring Payment access directly with the ASPSP.

M

 Optional

 Conditional

20

The OBIE’s Solution(s) must allow the PISP to attest to the ASPSP about the types of activity the VRP Consent is intended to be used for.

M

 Optional

Conditional

21

The OBIE’s Solution(s) must allow the ASPSP to send a specific message to the PISP in response to an access request that they can no longer access if the account(s) has been fully switched to another ASPSP.

M

 Optional

 Conditional

22

The OBIE’s Solution(s) must allow the ASPSP to enable the above functionality (requirement #21) for all VRP consents given by the PSU to a PISP.

M

 Optional

 Conditional

23

The OBIE's Solution(s) must enable PISPs to receive, with a single API call (aggregated polling), specific messages of the account switch status for multiple PSUs with a specific ASPSP during a specific period.

Note: MVP is to support status ‘Account switch completed’.

M

 Optional

 Conditional

24

The OBIE’s Solution(s) must enable the ASPSP to notify the PISP when access is revoked by the PSU directly at the ASPSP.

M

 Optional

 Conditional

25

The OBIE's Solution(s) must allow ASPSPs to provide MI on metrics and adoption as per section 10.1 below.

M

 Optional

Conditional

26

The OBIE’s Solution(s) must allow the PISP to provide the ASPSP with multiple indicators to indicate the types of VRP payments.

M

 Optional

 Conditional

27

The OBIE’s Solution(s) must allow PISPs the ability to attach arbitrary metadata to VRP Consents.

M

Optional

 Conditional

28

The OBIE’s Solution(s) must allow PISPs the ability to attach arbitrary metadata to VRP Payments.

M

Optional

 Conditional

29

The OBIE’s Solution(s) must require the ASPSP to enable the functionality for Single & Joint accounts (this excludes multi-authorisation accounts).

M

Optional

Conditional

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.

ID

Description

MoSCoW

ASPSP implementation for  non-sweeping

CMA9 Implementation for sweeping

1

The OBIE Solution(s) must require a Sweeping Consent includes the following VRP Consent Parameters:

  • Payee Account Name.

  • Payee Account Identification details (e.g., account number and sort code or additionally roll number or full IBAN).

  • The maximum cumulative amount per time window*

  • The maximum amount of each Sweeping Payment.

*time window – Day/Week/Fortnight/Month/Half Year/ Year

Note: ASPSP must support all the time window enumerations.

M

n/a

 Conditional

2

The OBIE's Solution(s) must ensure the ASPSP informs the PSU that the payee will be added to their Trusted Beneficiary list.

M

 n/a

 Conditional

3

The OBIE's Solution(s) must require the ASPSP to add the payee to the PSU’s Trusted Beneficiary list once the Sweeping Consent Setup is complete.

M

 n/a

 Conditional

4

The OBIE's Solution(s) must require the ASPSP apply the Trusted Beneficiary SCA exemption* when the PISP initiates a Sweeping Payment within the Sweeping consent parameters. The ASPSP may choose not to apply the exemption in exceptional circumstances with an objective approach in line with the proportionality requirements of the PSRs.

*Note: The ASPSP may apply a ‘Transfer to Self’ exemption if the PISP initiates a Sweeping payment to an account held at the same ASPSP.

M

 n/a

 Conditional

5

The OBIE’s Solution(s) must allow the ASPSP to provide a specific error indicator to the PISP in response to a Sweeping Payment under a Sweeping Consent where the trusted beneficiary has been removed from the trusted beneficiary list and exemption can no longer be applied to Sweeping Payments.

M

 n/a

 Conditional

6

The OBIE's Solution(s) must require ASPSPs to provide MI on metrics and adoption as per section 10.2 below.

M

 n/a

 Conditional

7

The OBIE’s Solution(s) must require the PISP to attest to the ASPSP that the VRP Consent is a Sweeping Consent.

M

 n/a

 Conditional

8

The OBIE's Solution(s) must require ASPSPs to provide non-discriminatory access to Sweeping Consent Setup.

M

 n/a

 Conditional

9

The OBIE's Solution(s) must require ASPSPs to provide non-discriminatory access to instruct Sweeping Payment within the Sweeping Consent Parameters.

M

 n/a

 Conditional

10

The OBIE’s Solution(s) must require the ASPSP to enable the functionality for Single & Joint accounts (this excludes multi-authorisation accounts).

M

Optional

Conditional

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

ID

Identifier

Generated

Business Description

1

EndToEndIdentification

Merchant/PISP Sent in API Payload

The EndToEndIdentification reference is a reference that can be populated by the debtor (or merchant in the ecommerce space). This reference is important to the debtor (could be an internal reference Id against the transaction), it Is NOT the reference information that will be primarily populated on the statement of the creditor (beneficiary).

2

InstructionIdentification

Merchant/PISP Sent in API Payload

The PISP generates the InstructionIdentification which is a unique transaction Id and passes it to the ASPSP (this is mandatory), but this does not have to go any further in the payment flow. The flow of this identifier needs to align with payment scheme rules.

The expectation is that this is unique indefinitely across all time periods. The PISP can ensure this is indefinitely unique by including a date or date-time element to the field, or by inserting a unique Id.

3

RemittanceInformation

Merchant/PISP Sent in API Payload

The RemittanceInformation is the reference information that the creditor (or beneficiary) will need to reconcile (e.g., Invoice 123).

12. Version control

Version

Date

Authors

Comments

Version

Date

Authors

Comments

V1

Mar 25, 2021

OBIE API Delivery Team

Final version - approved by IESG with no changes

V1.1

Aug 13, 2021

OBIE API Delivery Team

New Section 3.3. - Definition of sweeping definition

Section 9 - ID #1 - added consent expiry attribute.

Section 9 #ID29 & Section 10 #10 - To explicitly scope out multi auth.

V1.2

Sep 29, 2021

OBIE API Delivery Team

Section 8 - ID #1 - removed consent parameter frequency per time window as a errata fix.