This space is deprecated and no longer supported. Please use the latest available version here.
Multi-Payments
- Chris Michael
- Alexandros Dimitrakoudis
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 Multi-Payments scope is targeted to domestic payee accounts (i.e. payee accounts offered by LFIs located in UAE) and payments in local currency as used by the local payment systems infrastructure for domestic payments.
The main Use Cases supported by Multi-Payments are:
Fixed Recurring Payments (FRPs)
Variable Recurring Payments (VRPs)
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 | Consent Parameters Type | Payment Amount | Payment Schedule | Typical Usage Examples |
|---|---|---|---|---|---|
Long-lived | Fixed Recurring Payments (FRPs)
| Fixed Recurring | Fixed (known) | Fixed (known) |
|
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) |
| |
Variable Recurring Payments (VRPs)
| Variable-defined | Variable (Known) | Fixed (known - predefined list of dates) |
|
1.2 Payer and Payee Segments
The scope of the Multi-Payments bank service initiation related to the segments of payers and payees is shown below:
Payer | Payee | ||||
|---|---|---|---|---|---|
Consumers | SME | Corporates | Consumers | SME | Corporates |
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 own by a business or and 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 PSU 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 consent parameters 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 at 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 at an unspecified schedule and each payment is of different amount which is unknown at the point of consent.
Variable-defined Consent: A long-lived consent that MUST be used for a series of future payments occurring at 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.
In summary, for VRPs:
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.
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.
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 variable beneficiaries. This can be of one of 2 types:
Multi-Payment Type | Excplicit Authorization | Beneficiary | Consent Parameters 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 |
Yes | Variable (unknown) | Explicit-Auth Variable Beneficiary (EAVB) | Payment app POS payments |
1.5.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 forinitiating the payment every time.
1.5.2 Explicit-Auth Variable Beneficiary (EAVB) Multi-Payments - Example User Story
1.5.3 Prerequisites for Variable Beneficiary Multi-Payments
1.5.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.5.3.2 TPP T&Cs
The T&Cs of TPPs MUST request Users to agree that they will be one or more “factors” (i.e. conditions) that will be used by the TPP as their explicit authorization for each payment initiation of Multi-Payments to Variable Beneficiaries. Examples of these factors may be the following:
User biometrics, RFID token, Vehicle registration, mobile phone, plastic card, other User identification (e.g. Emirates ID), standard MFA process etc.
TPPs will have the option to require one or more factors for explicit authorization. The factors will be agreed between TPPs and Users to be the qualifying conditions for each payment initiation to be considered as authorized. The authorization factors MUST be presented to Users while providing explicit consent for the long-lived Variable Beneficiary Multi-payment Consent.
The factors used by TPPs MUST be in alignment with the list of required evidence that will be listed in the liability model.
2. User Journey
3. Wireframes
3.1. Consent Setup
# | 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.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 | |
MPCS-3 | 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 | LFI Authentication Only As per the following sections: |
Centralized Authentication and Authorization (Federated) Only | ||
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.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.8 Present to Users the following minimum required information for authorizing the long-lived payments Consent:
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 Multi-Payments | 6.3.2 VRP Consent Control Period & 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 | |
MPCS-6 | Hand-off back to the TPP | |
MPCS-7 | Confirmation to User |
4. Payment Initiation
# | Step | Rules & Guidelines |
|---|---|---|
MPPI-1 | Payment Initiation | Variable Beneficiaries Only TPPs MUST: 1.1 NOT submit to OFP any payment initiation requests in relation to an authorized Multi-payment Consent with Variable Beneficiaries if the User authorization conditions have not been met. 1.2 Present to Users for each payment initiation the following minimum required information:
1.3 Ensure that all required authorization conditions as agreed with the User during the Consent setup are met. 1.4 Generate a unique identifier for the transaction that links the Users’s authorization factors with the payment details (i.e. amount and payee identification). TPPs MUST generate an audit trail of the User’s payment initiation actions during the session. TPPs MUST have all required records as evidence required as listed in the liability model. 1.5 Provide Users the ability to abort the payment journey, if Users decided to terminate the request. |
| Scheduled Multi-Payments Only (Fixed Recurring Payment Consent, Variable Recurring Consent and Variable-defined Consent) TPPs MUST: 1.6 Submit to OFP payment initiation requests on the scheduled dates defined in the Periodic or the Variable-defined Payment Schedule of the long-lived Payment Consent authorized by the User. 1.7 Schedule the execution time of the payments related to the Periodic or the Variable-defined Payment Schedule to occur during time periods of low payment volume such as the early hours of the day, unless there are specific requirements based on their business case. | |
| TPPs MUST: 1.8 Submit to OFP payment initiation requests with the same fixed parameters as per the long-lived Payment Consent authorized by the User. In case where the consent was setup using the Payee’s proxy, the payment request MUST also include the IBAN from the proxy Payee identification returned back to the TPP during the payment Consent setup. 1.9 Submit to OFP payment initiation requests with variable parameters within the allowable limits of the Consent Controls as per the long-lived Payment Consent authorized by the User. 1.10 Include in each one of the payment initiation requests the same Payer Note as specified in the authorized long-lived Payment Consent, as the default value, if previously provided. However, this may be overwritten by a new Payer Note provided by the User or the TPP, if relevant, for each payment initiation request. 1.11 Include in each of the payment initiation requests a Payment Reference. This MUST be populated as follows:
| |
| VRPs Only TPPs MUST: 1.12 NOT submit any payment initiation requests of amount more than the maximum payment value per payment initiation, if specified in the long-lived Payment Consent for VRPs. 1.13 Keep track of the cumulative value of all payment initiations and NOT submit any VRP payment initiation requests that will result in exceeding the maximum limit, if specified in the long-lived Payment Consent for the VRPs. 1.14 Keep track of the maximum cumulative number of all payment initiation and NOT submit any VRP payment initiation requests that will result in exceeding the maximum limit, if specified in the long-lived Payment Consent for the VRPs. 1.15 Keep track of the cumulative payment value of all payment initiations per time window and NOT submit any VRP payment initiation requests that will result in exceeding the maximum limit, if specified in the long-lived Payment Consent for the VRPs. 1.16 Keep track of the cumulative payment volume of payment initiations per time window and NOT submit any VRP payment initiation requests that will result in exceeding the maximum limit, if specified in the long-lived Payment Consent for the VRPs. | |
|
| Variable-defined Beneficiaries Only 1.17 Include in each of the payment initiation requests one of the Payee Identification details included in the Pre-defined Beneficiary List, as defined in Multi-Payments | 6.5.1 Payee Identification for Variable defined Beneficiaries |
|
| Variable Beneficiaries Only 1.18 Include in each of the payment initiation requests the Payee Identification details, which were not provided as part of the long-lived Payment Consent authorized. 1.19 Include in each of the payment initiation requests the unique identifier for the transaction related to the User’s authorization of the payment details |
MPPI-2 | Processing of Payment Initiation Requests | OFP MUST: 2.1 Allow the TPPs to submit individual payment initiation requests under the long-lived Payment Consent authorized by the User, without any additional MFA or authorization from the User. 2.2 Check that the received payment initiation requests relate to a valid long-lived Payment Consent authorized by the User. The Consent MUST be in the Authorized state. The OFP MUST reject any payment initiation messages related to a Payment Consent in a different state (e.g. expired) and respond back to the TPP with the appropriate error message/code. 2.3 Check the payment initiation request parameters against the authorized long-lived Payment Consent. More specifically, the OFP MUST check the following:
|
FRPs Only OFT MUST: 2.4 Check the Fixed Recurring Payment initiation request parameters against the Fixed Recurring Payment Consent. More specifically, the OFP MUST:
2.5 Increment the cumulative total number of payments after the payment has been successfully executed and received payment status confirmation from the payee Bank. The initial value of this parameter should be zero for each authorized Fixed Recurring Payment Consent. 2.6 Set the Fixed Recurring Payment Consent state to a terminal state (Finished), if the cumulative total number of payments requests becomes equal to the Total Number of Payments parameter of the Fixed Recurring Payment Consent. | ||
VRPs Only OFP MUST: 2.7 Check the payment initiation request parameters against the authorized long-lived VRP Payment Consent. More specifically, the OFP MUST check the following:
2.8 Check that the date of the payment initiation and the payment amount match exactly the Variable-defined Payment Schedule of the authorized Consent for the Variable-defined Payments. 2.9 Increment the cumulative Total Number and the cumulative Total Value of payments under the VRP Consent after the payment successfully executed and received payment status confirmation from the payee Bank. The initial value of these parameters should be zero for each authorized VRP Consent. 2.10 Increment the cumulative Total Number and the cumulative Total Value of all payment initiations per Control Period after the payment successfully executed and received payment status confirmation from the payee Bank. These parameters are reset to zero when a new Consent Control Period starts at 00:00:00 of the first day of the Control Period. 2.11 Set the long-lived Payment Consent state to a terminal state (Finished), if the cumulative total number of payment requests becomes equal to the Total Number of Payments parameter of the VRP Consent. | ||
| Variable Beneficiaries Only 2.12 Check that the payment initiation request contains valid payee identification details and that there is a unique identifier related to the Users’s authorization of the payment details. | |
| OFP MUST: 2.13 Allow the description of the Payment Reference in the submitted payment initiation request to be different than the one defined in the Payment Reference of the long-lived Payment Consent. 2.14 Reject the payment initiation and provide the necessary error message to the TPP if any other checks of the payment initiation request parameters fails against Consent parameters of the authorized long-lived Payment Consent. 2.15 Send a payment initiation request to the LFI for initiating an instant payment using the payment parameters included in the payment initiation request including:
| |
| LFIs MUST: 2.16. Allow the OFP to submit the payment initiation request without any additional MFA or authorization from the User. 2.17 Add to the payment initiation request the IBAN of the Payee returned by the Proxy resolution process, if the payment initiation request was submitted using a Proxy as the Payee Identification. The payment initiation request is thereafter tied to the IBAN of the Payee rather than the proxy itself.
2.18 Additionally apply all existing BAU payment account controls and limits such as single transaction value limit, total transaction value limit, AML checking (if applicable) and others, as if the payment request has been initiated by the existing channels of the LFI. LFIs MUST send an appropriate error response to the OFP in case the payment is rejected due to violating any of these limits or checks. 2.19 Reject the payment initiation if the payment account selected for the payment has insufficient funds. The OFP MUST be notified about this rejection with an appropriate error message. 2.20 Subject to successful BAU checking, validation and payment processing, proceed with the execution of the payment by either submitting the payment to the underlying payment rails or executing internally as Intra-bank payment. 2.21 Provide the OFP with all the available information in relation to the initiated payment instruction including the payment’s unique identifier Payment Transaction ID. The format of the Payment Transaction ID can be found in the UAE Open Finance Standard specifications. | |
OFP MUST: 2.22 Send an appropriate error response to the TPPs in case the payment is rejected due to violating any of the LFIs BAU payment accounts checks or limits. 2.23 Send to the TPP the appropriate error message in case the payment payment initiation was rejected by the LFI due to insufficient funds in the selected payment account. 2.24 Provide the TPP with all the available information in relation to the initiated payment instruction including the payment’s unique identifier Payment Transaction ID. | ||
MPPI-3 | Payment Status Update | |
MPPI-4 | Payment Notifications |
5. Consent Updates
# | Step | Rules |
|---|---|---|
MPCU-1 | Consent Update | TPPs MUST: 1.1 Enable Users to use the Consent Dashboard to amend the following parameters of a long-lived Payment consent:
1.2 Require the Users to authenticate with their LFI and authorize the Consent update. |
6. Multi-Payments Common Rules & Guidelines
6.1 Consent Reference
6.2 Period & Payment Schedule
6.2.1 Periodic Payment Schedule
6.2.2 Period Type & Start Date
6.2.3 Variable-defined Payments & Schedule
6.3 VRP Consent Control Parameters
Consent Control Parameters for Variable Recurring Payments (VRPs) are a set of constraints included within the VRP Consent that restrict the way in which it can be used to make variable payments. The restrictions are enforced both by the TPP and the OFP.
6.3.2 VRP Consent Control Period & Start Date
6.4 Consent Expiration Date & Time
6.4.1 Consent Expiration for FRPs (Fixed Recurring Consent)
6.4.2 Consent Expiration for Periodic Scheduled VRPs (Variable Recurring Consent)
6.4.3 Consent Expiration for Unscheduled VRPs (Fixed and Variable On-demand Consent)
6.4.4 Consent Expiration for Variable-defined Consent
6.5 Payee Identification for Variable Beneficiary Consent
6.5.1 Payee Identification for Variable-defined Beneficiaries
6.5.2 Payee Identification for Variable Beneficiaries
© CBUAE 2024
Open License and Contribution Agreement | Attribution Notice
Please try out our Advanced Search function.