/
Multi-Payments

Multi-Payments

1. Description

Multi-Payments are defined as a series of payments initiated by a TPP based on either a fixed, variable or no schedule with each payment being either of fixed or variable amount. Multi-Payments use a long-lived Payment Consent, which enables Users to grant TPPs with long-lived access to their payment accounts for the purpose of instructing a series of such payments on their behalf, without the need for the User to authenticate each individual payment with the LFI.

The main payment types supported by the Multi-Payments functionality are:

  • Fixed Recurring Payments (FRPs)

  • Variable Recurring Payments (VRPs)

  • Combined Payments (Recurring Payments with a One-Time Setup)

1.1. Long-Lived Payment Consent

The Long-lived consent type is further categorized based on the consent payment parameters as shown in the following table:

Consent Type

Relevant Use Cases

Multi-Payments Type

Payment Amount

Payment Schedule

Typical Usage Examples

Consent Type

Relevant Use Cases

Multi-Payments Type

Payment Amount

Payment Schedule

Typical Usage Examples

Long-lived

Fixed Recurring Payments (FRPs)

 

Fixed Recurring

Fixed (known)

Fixed (known)

  • Person-to-Person (P2P) standing orders

  • Person-to-Merchant (P2M) monthly subscription

  • Installment payments

  • Buy Now, Pay Later (BNPL)

Variable Recurring Payments (VRPs)

 

Fixed On-demand

Fixed (known)

Variable (unknown)

Account top-up

Variable Recurring Payments (VRPs)

 

Variable Recurring

Variable (unknown)

Fixed (known)

P2M utility payments

Variable Recurring Payments (VRPs)

 

Variable On-demand

Variable (unknown)

Variable (unknown)

  • Account Sweeping

  • Cab booking App

Variable Recurring Payments (VRPs)

 

Fixed-defined

Fixed (known)

Fixed (known - predefined list of dates)

  • Installment payments (payment plan)

Variable Recurring Payments (VRPs)

 

Variable-defined

Variable (unknown)

Fixed (known - predefined list of dates)

  • Project completion-based payments

Combined Payments (Recurring Payments with a One-Time Setup)

Combined

Known and Fixed or Variable

 Instant and Fixed or Variable

  • Instalments with a different initial payment (payment plan with down-payment)

  • Two P2M payments (instant & future)

1.2 Debtor and Creditor Segments

The scope of the Multi-Payments bank service initiation related to the segments of debtors and creditors is shown below:

Debtor

Creditor

Debtor

Creditor

Consumer

SME

Corporate

Consumer

SME

Corporate

1.3 Fixed Recurring Payments (FRPs) - Example User Story

User Story

As a User (Consumer or Business),

I want to provide my consent to a TPP to set up a sequence of future recurring payments of fixed amounts with a fixed schedule to a domestic beneficiary account owned by a business or an individual,

so that I can arrange to pay the relevant beneficiary automatically without the need for me to initiate the payment every time.

Fixed Recurring Payments (FRPs) are defined as a series of fixed payments initiated by a TPP based on a periodic schedule, using a long-lived Fixed Recurring Payment (FRP) Consent. The Fixed Recurring Payment Consent enables Users to grant a long-lived consent to a TPP for the purpose of instructing a series of payments on their behalf, without the need for the User to authenticate each individual payment with the LFI.

1.4 Variable Recurring Payments (VRPs) - Example User Story

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 a domestic beneficiary account owned by a business or an individual,

so that I can arrange to pay the relevant beneficiary automatically without the need for me to initiate the payment every time.

VRPs are defined as a series of payments initiated by a TPP using a Long-lived payment consent. The Multi-Payments type for this use case may be one of the following types:

  • Fixed On-demand Consent: A long-lived consent that MUST be used for a series of future payments occurring on an unspecified schedule and each payment is of the same amount.

  • Variable Recurring Consent: A long-lived consent that MUST be used for a series of future payments occurring at a predefined periodic schedule and each payment is of different amount which is unknown at the point of consent.

  • Variable On-demand Consent: A long-lived consent that MUST be used for a series of future payments occurring on an unspecified schedule and each payment is of different amount which is unknown at the point of consent.

  • Fixed-defined Consent: A long-lived consent that MUST be used for a series of future payments occurring on a predefined schedule (predefined list of dates) AND each payment is of different amount which is pre-defined and known at the point of consent.

  • Variable-defined Consent: A long-lived consent that MUST be used for a series of future payments occurring on a predefined schedule (predefined list of dates) AND each payment is of different amount which is not known at the point of consent, but it is capped to a maximum pre-defined value.

In summary, for VRPs:

  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 creditor is fixed but the timing or amount of each payment does not need to 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 OFP.

  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 Combined Payments (Recurring Payments with a One-Time Setup)

TPPs MUST be able to support use cases where Users need to make an initial payment and then require the ability to make further payments on a recurring basis as part of a single Consent request.

A single request can include the consent for a SIP combined with the consent for FRPs or VRPs, which can be authorized by the User with the LFI in a single authentication/authorization flow. The User (Consumer or Business) makes one initial payment and authorizes further recurring payments of a fixed or variable amount with a fixed or variable schedule to a business or a personal beneficiary.

This functionality requires a Long-lived Consent. The consent parameter type for this functionality is Combined Payment Consent, which is a long-lived consent that MUST be used for a combination of a single instant payment and a series of future payments of fixed or variable amounts occurring at fixed or variable schedule.

1.5.1 Example User Story

User Story

As a User (Consumer or Business),

I want to provide my consent to a TPP to use my payment account for initiating both:

  • a Single Instant Payment of a fixed amount and;

  • a sequence of future recurring payments of fixed or variable amounts with a fixed or variable schedule to a domestic beneficiary account owned by a business or an individual,

so that I can pay an instant down-payment and allow the remaining future payments of my payment plan to the relevant beneficiary.

1.6 TPP and User Events to Agree to Initiate Payments

The TPPs MUST require Users to agree there will be one (or more) event(s) that the TPP will use to signal the User’s agreement for a payment initiation to be processed under the Multi-Payments consent.

 Examples of these events could be the following:

  • A User stating a single-purpose secret word / number string to a merchant, where the secret word / number string frequently changes and is known only to the User and the merchant via a secure channel

  • A User tapping a wrist band (that features a RFID feature) on a scanner of a merchant 

  • A user ordering a coffee at a merchant’s kiosk, where the User has registered with the merchant’s app via a smart device and where the merchant can detect the User’s device is present at the kiosk.

  • A User, and the license plate of their vehicle, both of which are registered with a merchant's mobile app, is having their vehicle refuelled at the same merchant’s petrol pump, and their vehicle's license plate is recognized by the merchant's cameras as being present while a fuelling request was made.

TPPs MUST require one (or more) event(s) to demonstrate the User's agreement for a payment initiation to be processed. The event(s) will be agreed between TPPs and Users to be the qualifying conditions for each payment initiation to be considered as agreed to be processed.

The nature of these agreement events MUST be presented to Users while providing the initial, explicit consent for the long-lived Multi-payment consent to exist with their designated LFI. 

The event(s) applicable to any payment initiated by TPPs under a Multi-Payment MUST be recorded and stored by the TPPs in the case of a dispute case being raised about the payment (initiation).

1.7 Multi-Payments to Variable Beneficiaries

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

Multi-Payment Type

Explicit Authorization

Beneficiary

Multi-Payments Type

Typical Usage Examples

Multi-Payment Type

Explicit Authorization

Beneficiary

Multi-Payments Type

Typical Usage Examples

Fixed Recurring Payments (FRPs)

or

Variable Recurring Payments (VRPs)

No

Variable-defined (known - predefined list of Beneficiaries)

Implicit-Auth Variable-defined Beneficiary (IAVDB)

Automated PFM/BFM & sweeping and account top-ups

Yes

Variable (unknown)

Explicit-Auth Variable Beneficiary (EAVB)

Payment app POS payments or sweeping

1.7.1 Implicit-Auth Variable-defined Beneficiary (IAVDB) Multi-Payments - Example User Story

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 or take any actions with the TPP for initiating the payment every time.

1.7.2 Explicit-Auth Variable Beneficiary (EAVB) Multi-Payments - Example User Story

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, subject to pre-agreed authorization conditions, without the need for me to authorize each payment with my LFI.

1.7.3 Prerequisites for Variable Beneficiary Multi-Payments

1.7.3.1 Liability Model

The liability model must be updated for the case of Variable Beneficiary Multi-Payment Consents. TPPs are expected to be fully liable for any disputes with Users in relation to unauthorized payments.

1.8 Balance Check Permission

The long-lived Multi-Payments Consent will also include the User’s consent (i.e. agreement) for Balance Check, which allows TPPs to check the balance of the User’s Payment account before initiating a payment as part of a long-lived Multi-Payments Consent.

This capability allows TPPs to:

  • check the balance in advance of payments to be initiated as part of the Multi-Payments Consent and ask Users to take remedial actions, if the funds are insufficient.

  • display the balance to Users at the point of initiating a payment.

1.9 Using Fixed-defined Consent for Single Future Dated Payment (FDP)

TTPs are able to use a Fixed-defined Payment Consent as an alternative way to setup a Single Future Dated Payments (FDP). To achieve this, TPPs can setup a Fixed-defined Payment Consent with a single entry in the Predefined Payments Schedule as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2dot0final/pages/edit-v2/361957968#8.2.3-Fixed-defined-%26-Variable-defined-Payments-%26-Schedule.

For example a Predefined Payment Schedule with a single entry of {(1st Jan-24, AED 10)}, will setup a Payment Consent for a single Future Dated Payment (FDP) of 10 AED to be initiated on the 1st Jan-24.

As with all long-lived consent Multi-Payments, the scheduling of the FDP payment will be the responsibility of the TPP. This provides additional flexibility and full control on the TPP allowing Users to manage the FDP from the TPP without having to use the LFI’s internet banking or mobile banking channels.

2. User Journey

image-20260210-112531.png

3. Customer Experience

3.1 Consent Setup

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

image-20260210-112557.png

 

3.2 Rules & Guidelines

#

Step

Rules & Guidelines

#

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 Creditor 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) - Fixed-defined Consent & Variable-defined Consent

 

Additional Consent Parameters

1.2 Set/no set Is Single Authorization flag as appropriate (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2dot0final/pages/361961620/Common+Rules+and+Guidelines#7.-Is-Single-Authorization-flag).

1.3 Set the Authorization Expiry Date Time (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2dot0final/pages/361961620/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 Fixed-defined & Variable-defined Consent, the Authorization Time Window MUST be less than the time of the first payment in the Fixed-defined & Variable-defined Payments Schedule.

1.4 Set the Risk Information Block (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2dot0final/pages/361961620/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.

 

Balance Check Permission

1.6 Acquire permission to check the balance of the payment account before initiating a payment.

MPCS-2

Consent Staging

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

MPCS-3

Hand-off to LFI

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

Example wording to use: ‘We will securely transfer you to YOUR LFI to authorize the payment setup“.

MPCS-4

Authentication

LFI Authentication Only

4.1 As per the following sections:

Centralized Authentication and Authorization (Federated) Only

4.2 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2dot0final/pages/361957032

MPCS-5

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.2.1 NOT reject the Multi-payment Consent, even if the Purpose of Payment violates any existing BAU rules for blocking/rejecting payments, as they use today for other digital channels. This is because the payment initiation messages send by TPPs may use a different Purpose of Payment code which may not violate these rules.

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/standardsv2dot0final/pages/361961620/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 NOT earmark (i.e. block) any funds related to the payment Consent in the Users' payment account at the point of Consent authorization.

5.5 Check the authorization status of the selected payment account is in accordance with the TPPs' Is Single Authorization flag as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2dot0final/pages/361961620/Common+Rules+and+Guidelines#7.-Is-Single-Authorization-flag.

5.6 Display to Users the TPP Trading Name of the TPP that initiated the long-lived payment Consent.

  • 5.6.1 If there are customer-facing service providers (e.g. Merchants) who are not TPPs but have commercial relationships with TPPs, the LFIs MUST display the customer-facing service provider name along with the TPP trading name.

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

  • User Payment Account

  • Creditor Identification details (one or more if included in the Consent e.g. for Variable-defined)

    • For Variable Beneficiaries, a message stating the Payee will be specified and validated during the payment initiation

  • Debtor Reference (Optional)

  • Consent Reference

  • Purpose of Payment

  • 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 Fixed-defined or Variable-defined) (if relevant, depending on the type of the long-lived payment Consent)

  • Consent Expiration Date & Time

5.8 Request Users to authorize the Multi-payments Consent, so that TPP can initiate payments from the payment account.

  • 5.8.1 Request Users to additionally authorize the Balance Check Permission, in the case that TPPs have requested permission to check the balance of the Users' payment accounts.

5.9 Provide Users the ability to cancel the payment journey, if Users decided to terminate the request. The LFI MUST hand-off the Users back to the TPP, providing the necessary error message to the OFP and reject the Multi-payments Consent.

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 the relevant information.

 

OFP MUST:

5.12 Check the Authorization Time Window is valid as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850813/Common+Rules+and+Guidelines#19.-Check-Authorization-Time-Window.

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

5.14 Start tracking the Consent Control Parameters for the Control Period at the mandatory Control Period Start Date. 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/standardsv2dot0final/pages/361957968/Multi-Payments#8.3.2-VRP-Consent-Control-Period-%26-Start-Date.

 

Multi-Authorization Journey Only

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

MPCS-6

Hand-off back to the TPP

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

MPCS-7

Confirmation to User

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

3.3 Journey Variations

3.3.1 Fixed Recurring Payments (FRPs) Consent

image-20260210-112751.png

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

image-20260210-112914.png

 

3.3.3 Variable Recurring Payments (VRPs) - Variable Recurring Consent

image-20260210-112937.png

 

3.3.4 Variable Recurring Payments (VRPs) - Fixed-defined Consent

image-20260210-113006.png

© CBUAE 2025
Open License and Contribution Agreement | Attribution Notice