Variable Recurring Payments

VRP Payments under Sweeping Access

This version is:

Published 2 years ago 04 Apr 2022

VRP Payments under sweeping access are a subset of VRP payments with SCA exemption that also has additional constraints.

Other pages in this section

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

1. Requires the PISP to attest that the activity meets the standardised definition of sweeping.

2. Requires the use of a specific set of sweeping consent parameters.

3. Requires the application of the ‘Trusted Beneficiary’ or ‘Payment to Self’ SCA exemption by the ASPSP for each VRP Payment.

For the purpose of simplicity, we have defined the term ‘Sweeping Consents’ and ‘Sweeping Payments’ to refer to ‘VRP Consents’ & ‘VRP Payments’ respectively when they are dealt with under sweeping access.

Main content image

Sweeping Payments User Journey

Main content image

This journey demonstrates Sweeping payment initiation by the PISP where the PSU is not required to be in session for each payment.

This core journey will enable the PISP to initiate an ongoing variable recurring sweeping payment(s) within the agreed set of consent parameter(s) which will result in a single domestic payment being processed by the ASPSPs as a Single Immediate Payment (SIP) via Faster Payments where the customer is not required to be in session for consequent payments.

This content is best viewed on a desktop browser.

Sweeping Payments Wireframe

This content is best viewed on a desktop browser.

2

CEG Checklist 2
ASPSP must apply for the ‘Trusted Beneficiary’ exemption when the PISP initiates a Sweeping payment within the Sweeping consent parameters. Note: There may be instances where an ASPSP may require SCA, even if the payment is made is to a trusted beneficiary, for example, suspicion of fraud. However, the ASPSP must only do so in exceptional circumstances with an objective approach and 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.

3

CEG Checklist 3
ASPSP must apply the ‘Trusted Beneficiary’ or ‘Transfer to Self’ SCA exemption when the PISP initiates a Sweeping payment within the Sweeping consent parameters. Note: There may be instances where an ASPSP may require SCA, even if the payment is made is to a trusted beneficiary, for example, suspicion of fraud. However, the ASPSP must only do so in exceptional circumstances with an objective approach and in line with the proportionality requirements of the PSRs.

4

CEG Checklist 4
PISPs must provide messaging to inform PSUs that Sweeping payment has been successfully initiated with their ASPSP. PISPs must provide the PSU with all information related to the Sweeping payment after the payment has been successfully initiated. The PISP should provide the PSU with a notification for a failed payment initiation. Note: PISPs may notify the PSU before initiating each Sweeping payment.

CEG Checklist Requirements & CX Considerations

1

 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. 

In order for the PSU to provide their explicit consent to setup a Sweeping Payment, the PISP must present the  required consent parameters listed below:

Required set of Sweeping Consent Parameters[1]Setting the appropriate consent parameters https://standards.openbanking.org.uk/tpp-guidelines/vrp-guidelines/v3-1-11/#setting_cp

  • Payee Account Name.
  • Payee Account Identification details (e.g. account number and sort code or additionally roll number or full IBAN).
  • Maximum amount per payment and Currency (GBP for UK implementations).
  • Maximum amount per time window* and Currency (GBP for UK implementations).
  • Expiry Date (Ongoing or a Specific Date).

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

Note: Max amount per time window can be aligned to start from the date of consent creation or lined up with a calendar period.

If the max amount per time window is aligned to the calendar period, the calculation of the limit is pro-rated in the first period to the remaining number of days. For example, refer to the link in the API specifications section below.

22b  

2

PSU payment Account Selection

PISPs must provide PSUs at least one of the following options:

• Enter their Payer’s payment Account Identification details.
• PISPs must allow PSUs to enter their payment Account Identification details in at least one of the ways specified in the Open Banking Standard V3 Read/Write API Specifications (e.g. account number and sort code – with additional roll number if required, IBAN, PAN, Paym and other formats).
• Select their Account Identification details (this assumes they have been saved previously).
• Select their ASPSP in order to select their PSU payment Account from there later on in the journey.

 

Note 1: In some of the above cases, PISPs may also need PSUs to provide their ASPSP name so that PISPs can check whether ASPSPs will be able to match the account identifier to the underlying PSU payment account.

Note 2: The use of IBAN as an identification of the payer account for UK ASPSPs is not expected to be heavily used as account and sortcode are the main account identifiers used in the UK. IBAN however will be used by non UK ASPSPs implementing Open Banking Standard and offering their services in the UK. 

24

3

Use of clear language to the PSU that they will be consenting to give the PISP the ability to initiate payment on a (sporadically or periodically) recurring basis.

PISPs must display the company’s trading name/brand name (i.e. the Client Name) to the PSU during the setup and revocation of consent. If the PISP is only trading with its registered company name then it must display that name to the PSU.

If there is a customer-facing service provider (e.g., Sweeping service provider) who is not a PISP but has a commercial relationship with a PISP and is providing the end service to the end-user, the PISP must ensure the software statement reflects this information correctly so that it can be displayed accurately to the PSU on the PIS-VRP ASPSP Dashboard.

This could occur in sweeping journeys for example, where a sweeping service provider contracts with a PISP to provide Variable Recurring Payment as a payment option on their platform.

PISPs must also, populate the customer-facing service provider company name in the ‘On behalf of’ field of the software statement, in order to inform the ASPSP about the relationship and allow the ASPSP to be able to display this information to the PSU (please refer to item #5). Only in instances where there is a customer-facing service provider acting on behalf of the PISP, the ‘On Behalf of’ name must be displayed to the PSU. PISPs must not populate the ‘ On behalf of’ field with the details of their TSP.

8f

4

PSU Consent to PISP 

PISPs must display the following information in the consent screen:

Consent Parameters (as provided in item 1.)

Payer Information

  • PSU payment Account Identification and/or the selected ASPSP (based on item 2 options).Note: if PSU payment Account identification is provided by PSUs in item 2, PISPs could use this to identify and display the ASPSP without having to ask PSUs.

8b

5

Terms 

PISPs must enable the PSUs to view their Terms on the consent screen.

8c

PISPs should provide messaging to inform PSUs that they will be taken to their ASPSPs to complete the payment.

Example wording: We will securely transfer to YOUR ASPSP to authenticate“.

Generic PISP to ASPSP redirection screen and message. Please refer to sections Browser based redirection – PISApp based redirection – PIS and Effective use of redirection screens.

8

Additional Parameters

ASPSPs must allow PSUs to select payment account to complete the Sweeping setup only if the PSU has not provided it to the PISP in item 1.

It is up to ASPSP to consider relevant obligations relating to the FCA’s High Cost Credit Review: Overdrafts consultation paper and policy statement (CP18/42) & (PS19/16)”.

23

9

ASPSPs must display all the consent parameter(s) provided by the PISP.

These details must be displayed as part of the authentication journey on at least one of the following screens without introducing additional confirmation screens (unless supplementary information is required, refer to section Single Domestic Payments – Supplementary info.

  1. ASPSPs’ Authentication screen (recommended).
  2. ASPSP to PISP redirection screen

28a

10

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.

Note – 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.

28e

The ASPSP should not put restrictions when the consent is set up but can apply restrictions if the amount(s) in the individual payment orders submitted exceed the limits in the direct, online channels.

12

ASPSPs must inform the PSU that the payee will be added to their Trusted Beneficiary list and must also add the payee to the PSU’s Trusted Beneficiary List.

OR

ASPSPs may choose to apply ‘Transfer to Self’ SCA exemption over ‘Trusted Beneficiary’ if it is more appropriate.

28b

For recognition based biometrics (e.g. Face ID) which can be more immediate the biometric authentication should be invoked after a delay or through a call to action to allow the PSU the ability to view the details. 

14

SCA Authentication must be the only action required at the ASPSPs (unless supplementary information required, refer to section Single Domestic Payments – Supplementary info.

The ASPSP authentication must have no more than the number of steps that the PSU would experience when directly accessing the ASPSP channel.

19 1

Generic ASPSP to PISP redirection screen and message. Please refer to section Effective use of redirection screens.

16

PISP Confirmation 

PISPs must display the information received from the ASPSP. This information may include:

The unique identifier assigned to the Sweeping setup by ASPSPs.

26a

Sweeping Payments

CEG Checklist Requirements & CX Considerations

The PISP must be able to submit a CoF request prior to making Sweeping payment and must receive a response back from the ASPSP.  Please refer to section Confirmation of Funds for PISP – Y/N Response – Requirements #5 to #9

2

ASPSP must reject the Sweeping Payment  and provide an appropriate response back to the PISP if :

  • The Sweeping payment submitted by PISP is outside the Sweeping Consent parameters.
  • The Sweeping consent setup access is revoked by the PSU at the ASPSP.

28d

3

ASPSP must apply for the ‘Trusted Beneficiary’ exemption when the PISP initiates a Sweeping payment within the Sweeping consent parameters.

Note: There may be instances where an ASPSP may require SCA, even if the payment is made is to a trusted beneficiary, for example, suspicion of fraud. However, the ASPSP must only do so in exceptional circumstances with an objective approach and 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.

28c

3a

ASPSPs must offer the same minimum and maximum payment limits for payment types, as they offer in their direct online channels.

28f

4

PISPs must provide messaging to inform PSUs that Sweeping payment has been successfully initiated with their ASPSP.

PISPs must provide the PSU with all information related to the Sweeping payment after the payment has been successfully initiated.

The PISP should provide the PSU with a notification for a failed payment initiation.

Note: PISPs may notify the PSU before initiating each Sweeping payment.

25 26

What the research says

 

Click for customer research

References

References
1 Setting the appropriate consent parameters https://standards.openbanking.org.uk/tpp-guidelines/vrp-guidelines/v3-1-11/#setting_cp