icon_search Search

Variable Recurring Payments / Sweeping FAQs

# Sweeping

# Where can we find the definition of sweeping?

The Competition and Markets Authority (CMA) has published further clarification on the definition of sweeping. You can view this here (opens new window). Please also refer to CEG - Definition of VRP for sweeping (opens new window)

# Where can I find more clarification on destination accounts?

Several questions have arisen regarding the interpretation of this clarification, so the OBL has published answers to key questions. Refer to the below queries under heading "Sweeping-destination account queries" or download from here (opens new window)

# Sweeping-destination account queries

These Q&As concern destination accounts for sweeping transactions which the nine mandated banks under the CMA Order (the “CMA9”) are required to grant sweeping access for under the Order. We anticipate that in addition to sweeping, individual CMA9 firms and Third Party Providers (“TPPs”) may wish to enter into commercial arrangements to access VRPs for purposes other than sweeping. Nothing in the Q&As restrict this.

# What account features are required for an e-money account to be a valid sweeping destination account?

The guidance provided by the CMA clarified that “e-money accounts that are used by consumers and SMEs as substitutes for current accounts [are in] scope”1 (opens new window). Therefore, the destination account should have all the following characteristics:

  • The account should have the features of a current account.
    The account should have the features typically provided by a current account including supporting day-to-day payment transactions , for example receiving salary payments, setting up Direct Debits, receiving one off payments, using a debit card for purchases, making ATM withdrawals, setting up standing orders, and paying in funds.

  • The account should be promoted and marketed as an alternative to a traditional current account

  • The account should be used as an alternative to a traditional current account.
    The product should typically be used for day-to-day transactions such as paying-in funds, withdrawing cash, executing and receiving payment transactions to and from third parties including credit transfers.

# Is a Buy Now Pay Later account a valid sweeping destination?

It is unlikely that a transfer into a Buy Now Pay Later (BNPL) account would meet the definition of sweeping. These transactions are invariably linked to the purchase of goods or services and so would be excluded from the definition of sweeping because “sweeping to make e-commerce purchases” was identified by the CMA as clearly outside of the scope of the Order1 (opens new window).

Even where the BNPL facility is potentially a form of credit providing a competitor to an overdraft, because the level of borrowing and repayment terms are directly linked with an e-commerce transaction it is out of scope.

# Can sweeping be used to repay an agreement under the Consumer Credit Act?

This depends on the nature of the proposition to the customer. The CMA clearly states1 that one of the intended purposes of sweeping is to introduce competition for overdraft customers such as provision “of alternative forms of credit that closely compete with overdrafts”. Some agreements under the Consumer Credit Act would meet the criteria but others would not. For example, hire purchase (HP) or personal contract purchase (PCP)are unlikely to be considered sweeping as they are facilitating a purchase (which is explicitly ruled out) and it would be difficult to argue that these agreements provide a credible alternative to an overdraft, as an overdraft provides a line of credit with no formal repayment schedule.

# Can sweeping be used to repay a business loan?

This depends on the nature of the of the proposition to the customer. The CMA clearly states1 (opens new window) that one of the intended purposes of sweeping is to increase competition for overdraft customers such as provision “of alternative forms of credit that closely compete with overdrafts”. The proposition for the business loan would therefore need to be an alternative to an overdraft to qualify as a valid destination account for sweeping.

# Is sweeping into a collection account allowed under the definition of sweeping?

For a transaction to be considered sweeping it needs to be between two accounts belonging to the same person or legal entity. There is nothing in the definition that prevents financial institutions from using collection accounts to facilitate the movement of funds if this ultimately results in a transaction between two accounts belonging to the same person.

It is worth noting that some savings accounts, credit card accounts and other lending accounts use collection accounts to facilitate the processing of payments into customers’ accounts.

For clarity, the ultimate destination account must be such that the definition of sweeping can be met. There will be collection accounts that are NOT valid destination accounts for sweeping, for example mortgage accounts.

# Does a destination account for sweeping have to have a unique sort code and account number?

No. Destination accounts which fall within the definition of sweeping and fulfil the sweeping objectives set out in the letter1 (opens new window) must belong to the same customer as the source account, but there is no need for a valid sweeping destination account, to have a unique sort code and account number.

# Can you sweep from a current account into a savings account from which funds can be transferred into investments?

A cash savings account is a valid destination account if it satisfies the following criteria:

  • The cash savings destination account itself should support the intended outcomes of sweeping One of the intended outcomes of sweeping was to help customers earn higher interest on their cash balances. The destination account will need to help customers achieve this outcome and fall within the definition of sweeping.

  • The cash savings destination account must NOT be used as a transfer mechanism to enable sweeping into investments.
    The CMA has stated that sweeping into investments is not within the scope of the Order1 (opens new window). For example, if the destination account enabled the automatic transfer of funds into investments on receipt of a sweeping transaction, then the account is being used as a transfer mechanism to support sweeping into investments. However, if a customer decided to manually move funds from the savings account into investments, that would not invalidate the account from being a valid destination account for sweeping as the transfer into investments was completely independent from the sweeping transaction.

# Are there limitations where money can be transferred after a sweep into a savings account?

There are no specific limitations on the use of funds after sweeping has taken place.
However, sweeping destinations must not be used as a transfer mechanism for destinations outside the scope of sweeping, so the onward transfer must be completely independent of the sweep. For example, the transfer takes place following a specific request from the customer. If the onward transfer is carried out automatically and triggered by the receipt of the sweeping transaction, it is likely that the account would be considered to be enabling the sweeping of funds into the onward destination account which may not be within the scope of the Order.

If this condition has been met, the limitations about onward transfer will be determined by the terms and conditions of the destination account receiving the sweeping transaction.

# What should a party do if it disputes that a transaction or use case is sweeping?

In the first instance, we would expect the Account Servicing Payment Service Provider (ASPSP) and the Payment Initiation Services Provider (PISP) to discuss the issue and where possible, reach a common understanding.

If the ASPSP and the PISP are unable to reach an agreement, we would expect both parties to do all they can to minimise any adverse impact on consumers and SMEs who are using sweeping-dependent services. For example, we would not expect ASPSPs to unilaterally switch off sweeping access to a PISP.

In addition, we would expect the parties to adopt the following process:

  1. The ASPSP or PISP to inform the OBL (including by raising a ticket via the Open Banking Service Desk) that they believe a particular use case does not meet the definition of sweeping within scope of the Order as clarified by the CMA in its March 2022 letter.

  2. OBL will investigate the matter. For example, by requesting evidence from the ASPSP as to why they believe the use case is not sweeping and asking the PISP for evidence to support their assertion that a particular use case meets the definition of sweeping.

  3. Based on the evidence provided, the OBL will make a recommendation as to whether a particular transaction meets the definition of sweeping. This recommendation would be provided to the ASPSP and the PISP involved in the dispute. The CMA will also be informed by OBL of its recommendation.

This process does not prevent the CMA from taking enforcement action against a breach of its remedy where appropriate, or for parties to undertake private enforcement action against a breach.

# All other Sweeping queries

# 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] (https://standards.openbanking.org.uk/customer-experience-guidelines/payment-initiation-services/vrp-payments-under-sweeping-access/latest/)

# Where can we find latest VRP specifications for sweeping?

Refer to Specifications - Variable Recurring Payments API Profile (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/v4.0-draft1/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 OBL 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.

# **When a VRP payment is refunded (total amount or partial amount), should the ASPSP or PISP recalculate the pending amount per period limits?

No

Yes, the PISP may use the GET endpoint to check the status of the payment, enabling the PISP to get the information using the client credentials grant.

# **Can an ASPSP ask the PSU to re-authenticate if the trusted beneficiary was removed and need to be added back to the PSU’s trusted list?

Yes, the creation of or amendment of a trusted beneficiary list will require SCA. If the PSU has removed the payee from their trusted beneficiary (payee) list on their online channel after setting up a VRP/sweeping consent, the ASPSP will need the PSU to re-authenticate in order to enable future VRPs to that trusted beneficiary.

# Is there any guidance for the use of VRPType for payments in 3.1.11?

The 3.1.11 release introduced VRPType as a required field in a payment submission for a VRP, which is a breaking change for some participants. Payloads sent to the 3.1.11 endpoints should include this field, submissions not including it should be rejected.

In order to ease transition to 3.1.11 for existing VRP consents an ASPSP may optionally decide to accept both 3.1.10 and 3.1.11 payloads for a short time when processing payment submissions. ASPSPs opting to take this approach should ensure it is clearly documented on their developer portal and provide an end date indicating when support for the 3.1.10 payloads will end. Newly created VRPs must only use the 3.1.11 payload for payment submissions.

Note: This guidance applies to the POST /domestic-vrps endpoint only.

# Are multi-auth VRPs supported?

No, VRPs that require multiple authorisations are currently out of scope.

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 - v4.0 (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 should 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.

# ** While calculating the periodic limit amount, do we need to exclude the payments that have Rejected status?**

Yes, you should exclude those with Rejected status.

# Where can I find the latest version of VRP specifications?

Version 4.0 of specifications can be found here → Variable recurring payments API profile v4.0 (opens new window)

# Does VRP payment support standing order/future dated payment?

The sequence diagram Variable recurring payments API profile v4.0 (opens new window) is generic. At present only single immediate payments are supported in the specifications, standing orders and forward dated payments are not supported.

# Is the Data.Debtor block to be provided by the ASPSP in the response block optional?

Data.Debtor block is optional and outside the initiation block. In scenarios where account selection is done by the PSU during authentication, the ASPSP must be able to update the Data.Debtor block with the debtor details after successful authorisation. This will enable the PISP to make a GET call to get the debtor account details to make future payments using the VRP consent.

# Where can I find namespaced enumerations for VRP?

You can find all the namespaced enumerations for VRP here → OB Internal Codeset (opens new window)

# Does VRP support refunds? If yes, wherein the specs can we find this option?

PISP can request refund information by indicating yes/no in Domestic VRP consents - v4.0 (opens new window) Data.ReadRefundAccount

The actual refund details will be provided by ASPSP in Domestic VRPs - v4.0 (opens new window) Data.Refund

# Why is the FundsConfirmationId max length 40?

FundsConfirmationId - is 40 characters as it is just an identifier and a UUIDv4 (36-38 characters) which is used in modern systems would fit in that size.

ValidFromDateTime is an optional field which means if not provided the consent start date is when the consent is provided to the PISP by the PSU and successful authentication has taken place at the ASPSP. It must not be backdated because the PSU is only giving consent at that point. However, it could be a future date.

# Can ValidToDateTime be left blank?

ValidToDateTime can be left blank which means the validity of the consent is indefinite.

*Should the ValidToDateTime be populated by either the PISP or ASPSP when the consent is revoked?

No consent parameters remain unchanged and so does ValidToDateTime even after the expiry of the consent.

# Is there an expectation that ValidFromDateTime and ValidToDateTime must start at a specific time and does that need to be included in the pro-rata calculation?

Refer to specs section - OBDomesticVRPControlParameters - Domestic VRP consents - v4.0 (opens new window)

The time element of the date should be disregarded in computing the date range and pro-rating.

Yes, Once consent is expired, the PISP will not be able to access the PSU’s account to initiate payment orders however the status of the resource may be marked as 'Expired' by the ASPSP and same reflects on the access dashboard.

No, this was introduced in v3.1.8 of the specifications but has been removed in v3.1.9 of the specifications. Once consent is revoked by the PSU at the PISP, the PISP will need to ensure the DELETE endpoint is called 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.

# Can an ASPSP provide a specific status reason if the VRP/sweeping payment cannot be processed due to asynchronous check failure?

No, but this is being considered.

Yes. Reference is an optional field in the VRP consent which means if it is provided, then it has to be provided in the CoF check call and the ASPSP can reject CoF request if the reference does not match.

# What is a VRP Marker? What are the supported types?

VRP markers are introduced and defined by Pay.UK to identify and gather MI for different types of VRP payments. The various types that are required are classified in the below table.

Sweeping

Note: V05 and V06 has been reserved for ‘attended’ payments, although most VRPs will be ‘unattended’ at this time.

# **Who is required to provide the VRP Marker? **

All the ASPSPs to provide VRP Marker when each VRP payment (Sweeping [sVRP]or non sweeping [cVRP]) is submitted to the faster payments rail. OBL has enhanced existing guidance around VRP markers to provide additional guidance to PISPs and ASPSPs to support this requirement.

# Is there a marker for normal non VRP open banking payments?

Yes. All the non VRP open banking payments must have the marker [A**]. For more guidance refer to here.

# What if the sending ASPSP cannot derive the VRP marker due to insufficient information provided by the PISP?

The ASPSP must provide sufficient clarification on their developer portal for PISPs to provide the necessary information.

# Should the ASPSP reject a VRP payment if the PISP has not provided the necessary information (VRP Type or PSU Interaction Type)?

We recommend that ASPSPs do not hard reject VRP payments in cases where the PISP has not provided the necessary information, such as VRP Type or PSU Interaction Type. There may be unavoidable circumstances preventing the PISP from supplying this information. Instead, consider issuing a warning or providing guidance to the PISP to ensure the information is included in future transactions.

# ** Where we can find more guidance for VRP markers?**

The VRP markers are defined by Pay.UK (opens new window) and hence only required information is captured here (opens new window)

# Is a VRP marker required for all types of VRP payments?

Yes, the OB Standards do not mandate this but it is required to be provided by the sending ASPSP for all types of VRP payments that are processed as faster payments.

Remittance Information MAY be provided in the Initiation section when a VRP Consent is setup. This means the same Remittance Information MUST be provided by the PISP in the Initiation and Instruction section of each VRP Payment. If each VRP Payment requires dynamic Remittance Information for each VRP Payment then the Remittance Information at the VRP Consent level MUST NOT be captured. The Remittance Information in the Initiation section provided at the VRP Payment level MUST match the Initiation section provided at the VRP Consent level.

# Can the PISP populate a value in the Data.Instruction.RemittanceInformation.Reference, when "Data.Initiation.RemittanceInformation.Reference" is "blank?

Yes, they can populate a value. Please refer to this specification : Under the Instruction object for VRP (opens new window), it has a UML occurrence of 0..1, so it's a field that may or may not appear in this object. Under the definition that you referenced, if this field is populated in the initiation object, then the reference field in the instruction must match the initiation value. There are no other limitations placed on this field, so if the initiation reference field is left blank, then this field can be populated with a different reference.

Remittance information includes information related to the transaction which is helpful to the creditor to reconcile the payment against. There are two types of scenarios in which this information can be used. a. Static Reference in the Remittance Information that allows the same Remittance Information (like Credit card no) to be passed on to each VRP payment - (Setup at VRP consent level) or b. Dynamic Reference in the Remittance Information that allows different Reference values (like Invoice number) to be passed on to each VRP payment - (Not set at VRP consent level).

←