Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Expand
titleMENU
Table of Contents
stylenone

...

  1. The Payment Consent must be authorized by the User via Multi-Factor Authentication (MFA) at their LFI (“VRP Consent Setup”). However, each individual payment instructed by the TPP using the Long-lived Consent does not require MFA of the User by the LFI.

  2. The payee is fixed but the timing or amount of each payment need not be fixed during the VRP Consent Setup. Instead, it is subject to the constraints of certain parameters (“Consent Control Parameters”), agreed between the TPP and the User, which are enforced by the LFI.

  3. The Consent Control Parameters are included within the Consent. Therefore, they are subject to the LFI requiring MFA of the User, as part of the Consent Setup.

1.5 Multi-Payments to

...

Variable Beneficiaries

The long-lived Multi-Payments Consent can be extended to include payments to multiple beneficiaries. This can be of one of 2 types:

Multi-Payment Type

User Present

Beneficiary

Consent Parameters Type

Typical Usage Examples

Fixed Recurring Payments (FRPs)

or

Variable Recurring Payments (VRPs)

No

Multiple Fixed

Variable-defined (known - predefined list of Beneficiaries)

User Not-Present

Multi

Variable-defined Beneficiary (

UNPMB

UNPVDB)

Automated PFM/BFM & sweeping

Yes

Multiple

Variable (unknown)

User Present

Multi-

Variable Beneficiary (

UPMB

UPVB)

Payment app POS payments

1.5.1 User Not-Present

...

Variable-defined Beneficiary (

...

UNPVDB) Multi-Payments - Example User Story

Panel
panelIconIdfc1ec21b-3d40-498b-93f8-df20afd1c4cf
panelIcon:asffd:
panelIconText:asffd:
bgColor#E6FCFF

User Story

As a User (Consumer or Business),

I want to use a TPP to setup a sequence of future payments of fixed or variable amounts on a fixed or variable schedule, to a predefined list of domestic beneficiary accounts owned by one or more a businesses or individuals,

so that I can arrange to transfer funds or pay the relevant beneficiaries automatically without the need for me to be present and initiate the payment every time.

1.5.2 User Present

...

Variable Beneficiary (

...

UPVB) Multi-Payments - Example User Story

Panel
panelIconIdfc1ec21b-3d40-498b-93f8-df20afd1c4cf
panelIcon:asffd:
panelIconText:asffd:
bgColor#E6FCFF

User Story

As a User (Consumer or Business),

I want to use a TPP to set up a sequence of future payments of fixed or variable amounts from my payment account with a fixed or variable schedule, to any domestic beneficiary account owned by a business or an individual,

so that I can arrange to pay the relevant beneficiary by initiating a payment from the TPP app without the need for me to authorize each payment with my LFI.

...

#

Step

Rules & Guidelines

MPCS-1

Multi-Payments Consent

Basic Consent Parameters

TPPs MUST:

1.1 Enable Users to provide and review the parameters related to the initiation of a series of Multi-Payments they need to consent to. These parameters include:

Note: Depending on the use case the Payee details may not be displayed to the User in full. However, these need to be part of the payment request sent by the TPP to the LFI.

Fixed Recurring Payments (FRPs) Consent

Variable Recurring Payments (VRPs) - Fixed On-demand Consent

Variable Recurring Payments (VRPs) - Variable Recurring Consent

Variable Recurring Payments (VRPs) - Variable On-demand Consent

Variable Recurring Payments (VRPs) - Variable-defined Consent

Additional Consent Parameters

1.2 Set the Accepted Authorization Type (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#7.-Accepted-Authorization-Type).

1.3 Set the Authorization Time Window (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#8.-Authorization-Time-Window) if there are specific timing requirements that must be met for the consent authorization. This is also relevant to cases where multiple authorizers are required to authorize the payment consent.

  • 1.3.1 For Fixed Recurring Consent and Variable Recurring Consent, the Authorization Time Window MUST be less than the time of the first payment in the Periodic Payment Schedule.

  • 1.3.2 For Variable-defined Consent, the Authorization Time Window MUST be less than the time of the first payment in the Variable-defined Payments Schedule.

1.4 Set the Risk Information Block (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#9.-Risk-Information-Block)

1.5 Enable Users to provide explicit consent for the initiation of a series of future Multi-Payments of fixed or variable amounts based on a fixed periodic schedule or a variable schedule from their online payment account held at their LFI as per the payment parameters specified in the consent.

MPCS-2

Consent Staging

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#10.-Consent-Staging

MPCS-3

Hand-off to LFI

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#11.-Hand-off-to-LFI

Example wording to use: ‘We will securely transfer to YOUR LFI to authenticate and authorize your payments setup“.

MPCS-4

Authentication

As per the following sections:

MPCS-5

Confirmation/ Authorization

LFIs MUST:

5.1 Enable Users to authenticate using Multi-Factor Authentication (MFA) in order to review and authorize the long-lived payment Consent.

5.2 Retrieve from the OFP the payment Consent details staged by the TPP using the unique Consent Identifier.

5.3 Allow Users to select a payment account for the initiation of the multi-payments, if this was not provided in the retrieved staged Payment Consent details as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#12.-Payment-Account-Selection-at-LFI

  • 5.3.1 Allow Users to select a payment account for the initiation of the multi-payments even if it has insufficient funds at the time of the payment Consent authorization. This allows Users to fund the payment accounts appropriately before the dates of the payment initiation. However, the LFIs MUST inform the User, if the selected payment account has insufficient funds.

5.4 Only present additional screens, if necessary to allow the validation and confirmation of the payment Consent (e.g., Beneficiary adding & activation and Proxy lookup).

5.5 NOT earmark (i.e. block) any funds related to the payment Consent in the Users' payment account at the point of Consent authorization.

5.6 Check the authorization status of the selected payment account is in accordance with the TPPs' Accepted Authorization Type as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#13.-Check-Accepted-Authorization-Type.

5.7 Add to the payment Consent the IBAN of the Payee returned by the Proxy resolution process, if the multi-payments Consent was submitted for User Authorization with one or more Beneficiaries using a Proxy as the Payee Identification. In these cases, the Consent is thereafter tied to the IBAN(s) of the Payee(s) rather than the proxies themselves. This will allow the future multi-payments to be initiated to these IBAN(s) even if the Payee(s) change proxy between the time of the Consent and the initiation of multi-payments related to the Consent.

  • 5.7.1 Include in the payment Consent response to the OFP the IBAN(s) of the Payee identification(s) returned by the Proxy resolution.

5.8 Present to Users the following minimum required information for authorizing the long-lived payments Consent:

  • User Payment Account

  • Payee Identification details (one or more if included in the Consent)

    • for Multiple Variable Beneficiaries, a message stating the payee will be specified and validated during the payment initiation

  • Payer Note (Optional)

  • Consent Reference

  • Payment Amount & Currency (if relevant, depending on the type of the long-lived payment Consent)

  • Consent Controls Parameters (if relevant, depending on the type of the long-lived payment Consent)

  • Consent Control Period & Start Date (if relevant, depending on the type of the long-lived payment Consent)

  • The Payment Schedule (Periodic or Variable-defined) (if relevant, depending on the type of the long-lived payment Consent)

  • Consent Expiration Date & Time

  • Fees & VAT (if applicable): These are potential charges that will be applied to the User account for making a payment in relation to the long-lived payment Consent. Both bank charges and VAT MUST be presented, stated separately, prior to the User Consent authorization. If applicable, LFIs MUST apply the charges on the date of each payment initiation and not at the point of payment Consent authorization.

5.9 Check the Authorization Time window is valid as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#20.-Check-Authorization-Time-Window

5.10 Change the state of the payment Consent from Awaiting Authorization to Authorized when all Authorizers (one or more) have authorized the payment Consent.

5.11 Update the payment Consent details stored in the OFP with all the information included in the payment Consent authorized by the User.

OFP MUST:

5.12 Confirm back to the LFIs that the payment Consent details have been updated successfully.

5.13 Start tracking the Consent Control Parameters for the Control Period at the Control Period Start Date, if provided, or the Consent creation Date otherwise. The Control Period starts from 00:00:00 of the day and ends at 23:59:59 of the Control Period end day, calculated based on the Control Period type as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528328/Multi-Payments#6.3.2-VRP-Consent-Control-Period-%26-Start-Date.

5.14 Return back to the TPP in the payment Consent response the IBAN(s) of the Payee identification(s) returned by the Proxy resolution, if the payment Consent was submitted for User Authorization with one or more Payees using a Proxy as the Payee Identification.

Multi-Authorization Journey Only

5.15 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#18.-Multi-User-Authorization-Flow

MPCS-6

Hand-off back to the TPP

6.1 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#14.-Hand-off-back-to-the-TPP

MPCS-7

Confirmation to User

7.1 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#16.-Confirmation-to-User

7.2 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#19.-Payment-Details-Saving

...

Panel
panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
panelIcon:rock:
panelIconText:rock:
bgColor#DEEBFF

TTPs MUST:

 6.3.1 Either allow Users to specify the below set of parameters or pre-populate them for the Users based on the specific use-case or the requirements of their receiving beneficiary customer:

...

Panel
panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
panelIcon:rock:
panelIconText:rock:
bgColor#DEEBFF

TTPs MUST:

6.3.2.1 Either allow Users to manually enter/specify the below parameters or pre-populate them for Users based on the specific use-case or the requirements of their receiving beneficiary customer:

6.4 Consent Expiration Date & Time

...

Panel
panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
panelIcon:rock:
panelIconText:rock:
bgColor#DEEBFF

TTPs MUST:

6.4.4.1 Set the Payment Consent Expiration Date & Time to the end of day (23:59:59) of the date of the last payment of the Variable-defined Payments Schedule as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528328/Multi-Payments#6.2.3-Variable-defined-Payments-%26-Schedule. This will allow the TPP to have a valid Consent to be used for retries when looking for recovery from certain erroneous scenarios. The consent validity period MUST be less or equal to https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528887/Limits+and+Constants#Max-Consent-Validity-Period.

6.5 Payee Identification for

...

Variable Beneficiary Consent

6.5.1 Payee Identification for

...

Variable-defined Beneficiaries

Panel
panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
panelIcon:rock:
panelIconText:rock:
bgColor#DEEBFF

TTPs MUST:

6.5.1.1 Either allow Users to specify the below set of parameters or pre-populate them for the Users based on the specific use-case or the requirements of their receiving beneficiary customers:

6.5.1.2 Limit the entries in the Predefined Beneficiary List to https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528887/Limits+and+Constants#Max-Predefined-Beneficiary-List-Entries.

6.5.2 Payee Identification for

...

Variable Beneficiaries

Panel
panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
panelIcon:rock:
panelIconText:rock:
bgColor#DEEBFF

TTPs MUST:

6.5.2.1 Provide a message to Users clearly stating that:

  • The payee will not be specified as part of the Consent and instead will be defined during the payment initiation.

  • The payee will be confirmed when specified before actual payment takes place

  • The User MUST be present in the TPP app when the payment will be initiated and may be required to take further actions in relation to the payment.

...

  • .

...