# Sweeping

# Where can we find the definition of sweeping?

Refer to CEG - VRPs for sweeping (opens new window)

# Where can we find Sweeping requirements?

Refer to Proposition - Proposition - Variable Recurring Payments (VRPs) | 9.-Requirements-for-VRP-Sweeping-Access (opens new window)

# Where can we find VRP for Sweeping Access Journey?

Refer to CEG - VRP Payments under Sweeping Access (opens new window)

# Where can we find VRP specifications for sweeping?

Refer to Specifications - Variable Recurring Payments API Profile - v3.1.9 (opens new window)

# Where can we find more guidelines for sweeping?

Refer to Implementation guidelines in CEG VRPs for sweeping (opens new window)

# Where can we find a sweeping journey?

Refer to CEG - VRP Payments under Sweeping Access (opens new window)

# Where can we find more information on dashboards for VRP/sweeping

The PISP asserts it is sweeping and so would need to be able to prove that it is if questioned.

# Is event notification mandatory for sweeping when the linked account is no longer available either temporarily or permanently??

This is optional under the current versions of the specifications. However, the functionality can be supported.

It is recommended that the ASPSP inform the TPP using events.

# Can ASPSP define their specific list of VRP types for sweeping?

Yes, as per current specifications two default enumerations are enabled - sweeping and others. The ASPSPs may define more specific enumerations related to sweeping and make this information available to the PISPs.

# Can ASPSP allow only Sweeping VRP type if they implement only sweeping?

The specification supports the selection of both sweeping and others in the VRP type field. However, if an ASPSP is only implementing sweeping then they only need to accept sweeping.

Yes, there is a CEG checklist requirement where the PISP must ensure that the PSU sees the T&Cs while giving sweeping consent.

Yes, creditor account details must be specified and cannot be changed.

PISP may ask the PSU to re-authenticate at any time if required but if there is a long-lived consent given by the PSU to the PISP then the token should be valid until the validity of the consent.

# Can an ASPSP revoke access token if there are no payments made for a period of time?

No, the ASPSP should not revoke access tokens given to a PISP for the sole reason that no payments have been made using the VRP consent for a set amount of time. It is the responsibility of the PISP to ensure that they have the appropriate consent from the PSU to initiate a payment order within a VRP consent (see "Setting the appropriate consent parameters" section in VRPS for Sweeping Guidance document). Ensuring appropriate management of potentially dormant VRP consents should form part of the PISPs operational risk management processes."

# Do we need any additional checks or handling for payments to hopper accounts such as credit card accounts and/or PayPal accounts to reduce payment failures or reversals?

This should be treated similar to any Open banking SIP payment via PISP.

# VRP

# What is VRP?

VRP means Variable Recurring Payment. For more refer to the Proposition paper- Definition of VRP (opens new window)

# Where can we find VRP requirements?

Refer to Proposition - Proposition - Variable Recurring Payments (VRPs) | 8.-Requirements-for-the-VRP-Standards (opens new window)

# Where can we find VRP Specifications?

Refer to Specifications - https://openbankinguk.github.io/read-write-api-site3/v3.1.9/profiles/vrp-profile.html

Yes. The PISP is expected to provide a mechanism within their domain to enable the PSU to revoke their consent for initiation of any future payment orders, by revoking the authorisation of VRP consent.

Once the PSU revokes consent at the PISP, the PISP will use the DELETE endpoint to inform the ASPSP that consent is revoked. The ASPSP must delete the resource and respond to subsequent GET requests with an HTPP status of 400.

No. The PSU will have to give new consent to the PISP and go through a new authentication journey at their ASPSP in order to set up a new VRP consent.

Yes. The PISP will have to take the PSU to the ASPSP to re-authenticate the same consent, however, the PISP/PSU must not change any parameters previously agreed upon within the consent.

# Can PSU revoke the VRP payment order once it has been initiated by the PISP?

No, the specifications do not support the revocation of a payment order once it has been initiated by the PISP (as contemplated in PSR 83(2)) Note that this is different from revoking a VRP consent - this can be done at any point in time by the PSU. When a VRP consent is revoked, payments that are in-flight (ie initiated but not yet completed) may still get paid. The exact behaviour of such payments may differ between ASPSPs.

# Can PSU revoke VRP access at ASPSP?

ASPSPs are expected to provide a mechanism within their domain to enable the PSU to revoke their VRP consent access. This will not revoke any inflight VRP payments orders that have already been initiated by the PISP but will preclude the initiation of future payment orders within the VRP consent.

ASPSP must not revoke VRP consent given by the PSU to the PISP. They must not change the status of the consent either. They must, however, take necessary action to revoke access e.g. by revoking/expiring the access token provided to the PISP or any other action that will stop the PISP from accessing the PSU’s account and making payment using the specific VRP consent, when requested to by the PSU.

# Does 90-day re-authentication apply to VRP?

The “90-day rule” arises from Article 10 of the RTS. This applies specifically to account information services only and VRPs consents are not in the scope of this.

There may be exceptional circumstances (e.g. suspect risk or fraud situations) where the PSU will be required to undergo strong customer authentication at their ASPSP, following the initial VRP consent set up. In instances where the ASPSP has revoked the access token, the PSU will need to go through a re-authentication journey.

There are two ways in which PSU can provide their debtor account. The debtor account can firstly be provided in the domain of the PISP as part of the consent journey or alternatively in the domain of the ASPSP as part of the authentication journey, where the ASPSP will present the PSU with an option to select an account.

# How does PISP ensure that the source and destination account belong to the same PSU while performing a sweeping activity?

PISP must ensure that they have satisfied themselves that source and destination accounts belong to the same PSU, and this includes instances where account selection happens at the ASPSP. It is in the competitive space of each PISP to ensure that they have created the appropriate mechanism to achieve this based on their service offering. PISPs must ensure that they attest that the activity is sweeping when making VRP payments in this context.

# Can the ASPSP apply ‘Transfer to Self’ exemption over ‘Trusted Beneficiary’ SCA exemption when the PSU is transferring funds between their own accounts at the same ASPSP?

Yes, the ASPSP may apply ‘Transfer to Self’ over ‘Trusted Beneficiary’ or any other relevant SCA exemption if it is more appropriate.

Note: The VRP payments under sweeping access (opens new window) journey in CEG, demonstrates an example where sweeping is happening between two accounts of the same PSU but at different ASPSP and hence Trusted Beneficiary SCA exemption is demonstrated.

# What proof do ASPSPs need to provide to PISP in order to claim money back from customer disputes?

The regulatory requirements relating to ASPSP and PISP disputes, including the burden of proof are outlined in the PSRs. While OBIE is unable to provide advice on this issue, there is useful information on this in the June 2019 FCA Approach document, specifically in paragraphs (8.189 -8.330) (opens new window)

# Do ASPSPs need to differentiate between sweeping VRPs and non-sweeping VRPs from a customer perspective?

No, as long as the requirements for sweeping and non-sweeping are met.

# Can an ASPSP issue an open-ended access token or should they also issue a refresh token?

ASPSP could issue a long-lived access token that expires along with the consent expiry in which case a refresh token is not required.

ASPSP could also issue a refresh token that is long-lived (expires with the consent expiry) where the PISP can use it to request an access token, in case the access tokens are short lived.

# Is event notification mandatory for non-sweeping when the linked account is no longer available either temporarily or permanently?

This is optional under the current versions of the specifications. However, the functionality can be supported.

It is only a recommendation that the ASPSP inform the TPP using events.

TPP may specify one more PSU authentication method within the VRP consent. The TPP must specify the specific ‘PSU authentication method’ applied for each individual payment.

  • Authentication not required - indicates authentication is not required for individual payments and payments can be made without the PSU being present. This is useful for sweeping but may be used for other situations.
  • SCA by TPP - This indicates SCA is carried out by the TPP. However, the ASPSP and TPP are expected to have a contract in place to accept this method.

The specifications are open to enable both sweeping and non-sweeping as part of one consent. The PISP can indicate all the types of payments that can be made under a specific VRP consent including sweeping payment or other payments. However, the ASPSP and TPP will likely need to have a contract in place to accept sweeping and non-sweeping in one consent.

# Can ASPSP define their specific list of VRP types for non-sweeping?

Yes, as per current specifications two default enumerations are enabled - sweeping and others where others is for non-sweeping. The ASPSPs may define enumerations that are more specific and make this information available to the PISPs.

Yes, PISP can specify more than one PSU authentication method along with each VRP consent.

e.g. Authentication not required, SCA by TPP etc.

# Can PISP specify a list of authentication methods for a single VRP payment?

No, PISP must provide one authentication method from the acceptable list of authentication methods that the PISP indicated at the VRP consent level.

Yes, there is a CEG checklist requirement where the PISP must ensure that the PSU sees the T&Cs while giving VRP consent.

For VRP there are two ways in which a VRP can be set up. that are proposed in the VRP Proposition and the specification is enabled to handle these types

  1. VRP Payments with an SCA exemption (opens new window) - creditor (payee) details are fixed in the VRP consent

  2. VRP Payments with delegated SCA (opens new window) - creditor (payee) details are not part of the VRP consent but have to be specified each time VRP payment is initiated by the PISP.

Yes.

Yes, there is no limit on the number of consents a PSU can give to a PISP to pay the same beneficiary. There is also no limit on the PSU paying the same beneficiary via multiple PISPs.

Each consent should be treated as a separate consent and not in conjunction. It should be noted that a single consent may contain more than one periodic limit (e.g. a daily value limit and a weekly value limit and a monthly value limit)

# Are VRP and sweeping payments, domestic single immediate payments?

Yes

# What is the maximum number of transactions expected to show on the Access Dashboard History?

It is up to the ASPSP. However, it would be recommended to keep it consistent with how many transactions the PSU would see on their online portal.

# Will VRP be extended to BACS/CHAPS for non-FPS enabled accounts?

There are no plans at present to extend VRP capability to non-FPS enabled accounts.

There is no 13-month dormancy rule applicable for PISP payments (including VRPs). The consent must remain active unless ValidToDateTime has expired.

# How can ASPSPs and PISPs communicate in case of a dispute?

We encourage you to use DMS (Dispute Management System). For more refer to Dispute Management System - Open Banking (opens new window)

It provides details around a set of controls that are associated with a VRP consent that the PSU is authorising the PISP to initiate payments on their behalf.

# Whose responsibility is it to agree on the parameters?

It is the responsibility of the PISP to ensure the PSU explicitly agrees to the limit imposed by the consent parameters.

e.g. A VRP consent may have one parameter as Max Individual amount which is set to £100 which means the PISP can initiate payments up to £100 at a given time.

A VRP consent may have another parameter of Max amount per calendar month which is set to £1000 which means the PISP can initiate payments that total up to not more than £1000 in a calendar month.

It is the responsibility of the PISP to ensure that VRP payments are initiated within the consent parameters. It is the responsibility of the ASPSP to ensure that it does not execute VRP payment orders outside of the consent parameters.

# Can a PISP specify ‘Maximum cumulative amount per month /day/year etc’?

Yes, the specifications are flexible to set dynamic consent parameters as below:

  • Max cumulative amount per calendar day
  • Max cumulative amount per consent day
  • Max cumulative amount per calendar week
  • Max cumulative amount per consent week
  • Max cumulative amount per consent fortnight
  • Max cumulative amount per calendar month
  • Max cumulative amount per consent month
  • Max cumulative amount per calendar halfyear
  • Max cumulative amount per consent halfyear
  • Max cumulative amount per calendar year
  • Max cumulative amount per consent year

Yes, ASPSPs must support all the periodic limits (day, week, fortnight, month, half-year, year) and all periodic alignment (consent and calendar).

Note: Maximum cumulative amount per calendar fortnight is not recommended as the ISO calendar does not support or provide any guidance on when a fortnight should start.

Yes, PISPs can use all the periodic limits (day, week, fortnight, month, half-year, year) and all periodic alignment (consent and calendar).

ASPSPs must support all the periodic limits and be capable to handle multiple periodic limits in a single consent.

The ASPSPs may restrict to one-period alignment (i.e. consent or calendar) for a single periodic limit in a single consent.

e.g.: Max cumulative amount per calendar year and Max cumulative amount per consent year may not be an acceptable combination in one VRP consent however, Max cumulative amount per calendar year and Max cumulative amount per consent month is acceptable.

No, the ASPSP must be able to support the number of periodic limits that the PISP includes in a VRP consent. The maximum number of periodic limits that a PISP could include is 6 (one for each time period).

The rationale for this is that allowing ASPSPs to set a limit risks ASPSPs adopting different interpretations of the Standard and the lowest number of concurrent supported periodic limits would become the effective industry standard (it would be a race to the bottom). PISPs would have to develop propositions that are accepted at all ASPSPS and so would have to only offer the lowest number of concurrent periodic limits which effectively limits the control PSUs have over future payments.

# Where can I find examples on periodic limits and periodic type?

Examples of both consent and calendar types are in the specifications - Domestic VRP consents - v3.1.9 (opens new window)

PISPs should ensure that the consent parameters they agree with the PSU are appropriate for use cases and PSU’s individual circumstances.

PISPs must either allow PSUs to specify consent parameters or pre-populate them for the PSUs enabling the PSU to amend any of them as required.

# Can the periodic alignments be mixed and matched?

Yes.

e.g.: Max cumulative amount per calendar year and Max cumulative amount per consent month may be set in one VRP consent.

Yes, in order for the PSU to provide their explicit consent to set up a VRP/sweeping payment, the PISP must present all the required consent parameters to ensure that they obtain explicit consent from the PSU and any subsequent payments are initiated within those consent parameters. The PISP must also ensure that the consent parameters are ‘sufficiently narrow’ and in line with the service offering.

Yes, ASPSP must ensure that it does not execute VRP/sweeping payment orders outside of the payment parameters.

Yes, the PISP must not submit payment orders that are outside of the consent parameters.

# Can an ASPSP define additional control parameters for non-sweeping?

The standard provides a set of control parameters that may be specified as part of the VRP consent. These control parameters set limits for the payment orders that can be created by the PISP for a given VRP.

In addition to the control parameters defined in this standard ASPSPs may implement additional control parameters, limits and restrictions for non-sweeping VRPs.

These restrictions should be documented on ASPSP's developer portal.

# Can an ASPSP define additional control parameters for sweeping?

No, not for sweeping.

Yes. Pro-rata for the remaining period must be calculated for Max amount per time window.

e.g. Max amount per calendar month is set to £31 and ValidFromDateTime is 15/10/2020, then max allowable limit for the month of Oct will be £17

The ASPSP may not put restrictions when the consent is set up but should apply account restrictions when the payment order is submitted and not process that payment if it exceeds the limit on their online channels.

All the consent parameters have to be agreed upon between the PISP and the PSU and the PSU has to give explicit consent.

←