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 |
|---|---|---|---|---|---|
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) | Fixed-defined | Fixed (known) | Fixed (known - predefined list of dates) |
| |
Variable Recurring Payments (VRPs) | Variable-defined | Variable (unknown) | Fixed (known - predefined list of dates) |
| |
Combined Payments (Recurring Payments with a One-Time Setup) | Combined | Known and Fixed or Variable | Instant and Fixed or Variable |
|
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 | ||||
|---|---|---|---|---|---|
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:
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 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.
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 |
|---|---|---|---|---|
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/8f0faec0e6b142f9a297da314b668b93/pages/edit-v2/277940444#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
%20AlexD%20v3.png?version=1&modificationDate=1734519293194&cacheVersion=1&api=v2&width=1574&height=578)
3. Customer Experience
3.1 Consent Setup
3.1.1 Variable Recurring Payments (VRPs) - Variable On-demand Consent
3.2 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/8f0faec0e6b142f9a297da314b668b93/pages/277942495/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/8f0faec0e6b142f9a297da314b668b93/pages/277942495/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/8f0faec0e6b142f9a297da314b668b93/pages/277942495/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 | |
MPCS-3 | 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 Centralized Authentication and Authorization | ||
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.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/8f0faec0e6b142f9a297da314b668b93/pages/277942495/Common+Rules+and+Guidelines#12.-Payment-Account-Selection-at-LFI
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/8f0faec0e6b142f9a297da314b668b93/pages/277942495/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.7 Present to Users the following minimum required information for authorizing the long-lived payments Consent:
5.8 Request Users to authorize the Multi-payments Consent, so that TPP can initiate payments from the payment account.
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/8f0faec0e6b142f9a297da314b668b93/pages/277940444/Multi-Payments#8.3.2-VRP-Consent-Control-Period-%26-Start-Date. | ||
Multi-Authorization Journey Only | ||
MPCS-6 | Hand-off back to the TPP | |
MPCS-7 | Confirmation to User |
3.3 Journey Variations
3.3.1 Fixed Recurring Payments (FRPs) Consent
3.3.2 Variable Recurring Payments (VRPs) - Fixed On-demand Consent
3.3.3 Variable Recurring Payments (VRPs) - Variable Recurring Consent
3.3.4 Variable Recurring Payments (VRPs) - Fixed-defined Consent
3.3.5 Variable Recurring Payments (VRPs) - Variable-defined Consent
3.3.6 Variable-defined Beneficiary (IAVDB) Multi-Payments
3.3.7 Variable Beneficiary (EAVB) Multi-Payments
3.4 COP Service for Multi-Payments Consent
3.4.1 COP Service for fixed or variable-defined Beneficiaries
TTPs MUST:
3.4.1.1 Be able to use the COP Service as defined in Confirmation of Payee.
3.4.2 COP Service for variable Beneficiaries
TTPs MUST:
3.4.2.1 Verify variable beneficiaries related to a long-live multi-payments consent either through:
Performing KYC/KYB of the available beneficiaries as per https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277942495/Common+Rules+and+Guidelines#9.3.1-Details-Verification-for-Merchants-onboarded-by-TPPs.
Performing CoP of the beneficiary account details when the beneficiary is specified (i.e.. at point of payment initiation).
4. Balance Check
Prior to Payment Initiation, TPPs can optionally check the balance of the account for sufficient funds for the payment and display the balance to Users, subject to have received Balance Check permission during the Multi-Payments Consent setup.
# | Step | Rules & Guidelines |
|---|---|---|
MPBAL-1 | Balance Check | TPPs MUST: 1.1 Be able to request balance information using the authorized Multi-payment Consent before initiating a payment. 1.2 Use this capability only in relation to the Payment initiation steps to follow. 1.3 NOT use this capability as an alternative for Account Information Service, for example, to satisfy use cases like Personal Finance Manager (PFM), where the account balance is being refreshed periodically. 1.4 Make the Balance Check request not earlier than 24 hours from when a scheduled payment is to be initiated. |
MPBAL-2 | Balance Check Request Processing | LFIs MUST: 2.1 Provide the OFP with the the information related to the balance of the User's account, which was used for authorizing the Multi-Payment Consent. This information MUST be the same information as defined under the Balances permission in https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277942144/Customer+Data#6.3-Data-Cluster-Structure-%26-Language. |
OFP MUST: 2.2 Provide TPPs with all the available information in relation to the Balance Check request. 2.3 Send an appropriate error response to TPPs in case the Balance Check request was not successful. |
5. 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’ authorization factors with the payment details (i.e. amount and creditor 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, Fixed-defined and Variable-defined Consent) TPPs MUST: 1.6 Submit to OFP payment initiation requests on the scheduled dates defined in the Periodic or the Fixed-defined 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 Fixed-defined or the Variable-defined Payment Schedule to occur during time periods of low payment volume such as the early hours of the day as defined in https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/edit-v2/277942588#Schedule-Payments-Time-Window, 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. 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 Debtor Reference as specified in the authorized long-lived Payment Consent, as the default value, if previously provided. However, this may be overwritten by a new Debtor Reference 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 Creditor 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 Creditor Identification details included in the Pre-defined Beneficiary List, as defined in https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277940444/Multi-Payments#8.5.1-Payee-Identification-for-Variable-defined-Beneficiaries | ||
Variable Beneficiaries Only 1.18 Include in each of the payment initiation requests the Creditor 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 OFP 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 creditor 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 Fixed-defined Payment Schedule of the authorized Consent for the Fixed-defined Payments.
2.9 Increment the cumulative Total Number and the cumulative Total Value of payments under the VRP Consent after the payment resource has been created and it is in ‘Pending’ status and has not been rejected. This will prevent multiple payments being initiated that could exceed the Maximum values of the respective Consent Control parameters. The initial value of the cumulative Total Number and the cumulative Total Value of payments 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 resource has been created and it is in ‘Pending’ status and has not been rejected. This will prevent multiple payments being initiated that could exceed the Maximum values of the respective Consent Control parameters. The cumulative Total Number and the cumulative Total Value of all payment initiations per Control Period 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. | ||
OFP MUST: 2.12 Allow the description of the Creditor Reference in the submitted payment initiation request to be different than the one defined in the Consent Reference of the long-lived Payment Consent. 2.13 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.14 Send a payment initiation request to the LFI for initiating an instant payment using the payment parameters included in the payment initiation request including:
| ||
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:
Variable Beneficiaries Only
| ||
LFIs MUST: 2.16 Trigger the payment initiation process for the payment Consent immediately after receiving the payment initiation request from the OFP. Fixed Beneficiaries Only
Variable Beneficiaries Only
Variable-defined Beneficiaries Only
2.17. Allow the OFP to submit the payment initiation request without any additional MFA or authorization from the User. 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 |
6. Combined Payments (Recurring Payments with a One-Time Setup)
6.1 Customer Experience
6.2 Rules & Guidelines
# | Step | Rules & Guidelines |
|---|---|---|
MPCOMB-1 | Combined Payments Consent | TPPs MUST: 1.1 Enable Users to provide a single explicit consent for both a Single Instant Payment and the setup of FRPs and all types of VRPs. More specifically, Users MUST be allowed to combine in a single consent the following options:
1.2 Request both the single instant payment and the FRPs or VRPs setup within a single explicit consent. There MUST be a single Authorization step for this request with the LFI. |
MPCOMB-2 | Combined Payments Consent Processing | LFIs MUST: 2.1 Process the Combined Payments Consent as a single Authentication and Authorization request. LFIs MUST NOT request Users to authenticate twice to authorize both parts of the Consent. 2.2 Enable Users to authorize Combined Payment Consents in a single authentication flow. 2.3 Respond back to TPPs with a failure for the entire request, if there is a failure in processing either part of the Combined Payment Consent request. |
Note: The combination of the Single Instant Payment with any Multi-Payment type in a single Combined Payments consent, does not impact the processing and calculation of any of the cumulative VRP consent control parameters.
7. Consent Updates
Note: The parameters of the long-lived Multi-Payments Consent that Users are able to update depend on the use case and the business requirements of each TPP. There may be scenarios where the TPPs are fine to allow Users to update one or more of the Consent parameters and other scenarios where Users are not allowed to make any changes to the Consent Parameters. In any case, Users are always able to revoke their Consent.
8. Multi-Payments Common Rules & Guidelines
8.1 Consent Reference
TTPs MUST:
8.1.1 Allow Users to manually enter the Consent Reference or pre-populate it for the Users (depending on the Use Case). Consent Reference is mandatory due to being the default value to be used for the Creditor Reference of the Payment Initiation Requests. The Consent Reference is populated either by the User (i.e. debtor) or the TPP using information requested by the beneficiary or any other information that can be provided to the beneficiary to assist in identifying and reconciling any payments initiated using this consent. This information may be mapped to the Creditor Reference of each Payment Initiation Request and thus may be transferred via the payment rails to the beneficiary LFI. However, the TPP might not be using this and may be populating the Creditor Reference of each of the initiated payment Requests with different information.
8.1.2 Validate that the format of the Consent Reference is according to the Bank Service Initiation OpenAPI.
8.2 Period & Payment Schedule
8.2.1 Periodic Payment Schedule
TTPs MUST:
8.2.1.1 Either allow Users to manually enter/select the details of the Periodic Payment Schedule defining when the payments need to be initiated or pre-populate it for the Users based on the specific business case and the receiving beneficiary party. This information includes the following:
The Start Date of the payments Periodic Schedule, as defined in https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277940444/Multi-Payments#8.2.2-Period-Type-%26-Start-Date. This is the date of the first payment in the Periodic Schedule. This MUST be a date in the future after consent authorization. This date MUST less than https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277942588/Limits+and+Constants#Max-Consent-Validity-Period.
The Period Type of the payments Periodic Schedule, as defined in https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277940444/Multi-Payments#8.2.2-Period-Type-%26-Start-Date. This defines how often the payments in the Periodic Payment Schedule will be be initiated by the TPP.
The Total Number of Payments that can be initiated during the Periodic Payment Schedule or the End Date of the Periodic Payment Schedule. In the case of the latter, TPPs MUST calculate the Total Number of Payments that will be initiated during the Periodic Payment Schedule as this is the parameter that TPPs will be providing to LFIs for the Payment Consent.
8.2.1.2 NOT allow Users to select the time of the day of the future Periodic Schedule for the payment to be initiated. This is to prevent Users entering time values that could lead to sub-optimal immediate payment load balancing, limited time for retries of payment which have failed due to funds checking, unavailability or cases where payment value is not applied on the selected date.
8.2.2 Period Type & Start Date
TPPs & OFP MUST:
8.2.2.1 Enable their systems to support the following definitions:
Start Date: The date that the first repeating Period starts. It is defined at the start of the date at midnight (00:00:00).
Period Type: This MUST be one of the following:
Day: A continuous period of time, consisting of 24 consecutive hours, staring from midnight (00:00:00) and finishing at 23:59:59 of the same day. The Period will be repeating every day from the Start Date.
For example, if the Start Date is the 10th of the month, then the Period will be repeating on the 11th, 12th, 13th etc.
Week: A continuous period of time, consisting of seven consecutive days, staring from midnight (00:00:00) of the Start Date and finishing at 23:59:59 of the 7th day elapsed from the Start Date. The Period will be repeating at the same day every week from the Start Date.
For example, if the Start Date is the Thursday 10th October 2024, then the Period will be repeating on Thursday the 17th October 2024, Thursday the 24th October 2024, Thursday the 31st October 2024, Thursday the 7th November 2024 etc.
Month: A continuous period of time starting from midnight (00:00:00) of the Start Date and finishing at 23:59:59 of the day before the same date of the next month. The Period will be be repeating at the same date every month from the Start Date.
For example, if the Start Date is the 10th October 2024, then the Period will be repeating on the 10th November 2024, the 10th December 2024, the 10th January 2025 etc. The exceptions to this rule are the following:
if Start Date is a date not available every month, then the Period will be adjusted to the end date of the month which does not have the Start Date available. For example:
If Start Date is 31st, then the Period will be initiated on the 31st for January, March, May, July, August, October and December, on the 30th for April, June, September and November and on the 28th or 29th (depending on leap year) for February.
If Start Date is 30th, then the Period will be initiated on the 30th for all months apart from February, for which it will be the 28th or 29th (depending on leap year) for February
If Start Date is 29th, then the Period will be initiated on the 29th for all months on leap year or for all months expect February on leap year, for which it will be the 29th
Year: A continuous period of time, consisting of 12 months, starting from midnight (00:00:00) of the Start Date and finishing at 23:59:59 of the day before the same date of the next year. The Period will be be repeating at the same date every year from the Start Date.
For example, if the Start Date is the 10th October 2024, then the Period will be repeating on the 10th October 2025, the 10th October 2026 etc. The exceptions to this rule are the following:
if Start Date is a date not available every year, then the Period will be adjusted to the end date of the month which does not have the Start Date available: For example:
If Start Date is 29th of February on a leap year, then the Period will be initiated on the 28th of February on non-leap years and the 29th on leap years.
8.2.3 Fixed-defined & Variable-defined Payments & Schedule
TTPs MUST:
8.2.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:
A. For Fixed-defined Payments
Fixed Predefined Payment Schedule: This is a list of pre-defined pairs of dates and payment amounts. TPPs MUST use this schedule and for each pair of (date, amount) a payment of the associated amount will be initiated on the specific date. For example:
For a Fixed Predefined Payment Schedule of { (1st Jan-24, AED 10), (15th Apr-24, AED 50), (25 Sep-24, AED 1000), } the following payments will be initiated by the TPP:
Payment of 10 AED on the 1st Jan-24
Payment of 50 AED on the 15th Apr-24
Payment of 1000 AED on the 25th Sep-24
B. For Variable-defined Payments
Variable Predefined Payment Schedule: This is a list of pre-defined pairs of dates and payment amount limits. TPPs MUST use this schedule and for each pair of (date, amount limit) a payment of amount less or equal to the associated amount limit, will be initiated on the specific date. For example:
For a Variable Predefined Payment Schedule of { (1st Jan-24, AED 10), (15th Apr-24, AED 50), (25 Sep-24, AED 1000), } the following payments will be initiated by the TPP:
Payment of 5 AED on the 1st Jan-24 - (i.e. 5 AED < 10 AED)
Payment of 25 AED on the 15th Apr-24 - (i.e. 25 AED < 50 AED)
Payment of 999 AED on the 25th Sep-24 - (i.e. 999 AED < 1000 AED)
8.2.3.2 Limit the entries in the Fixed Predefined Payment Schedule & Variable Predefined Payment Schedule to https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/edit-v2/277942588#Max-Fixed-defined-%26-Variable-defined-Schedule-Entries.
8.2.3.3 Limit each date in the Fixed Predefined Payment Schedule & Variable Predefined Payment Schedule to be less or equal to https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277942588/Limits+and+Constants#Max-Consent-Validity-Period.
8.2.3.4 Limit each payment amount or amount limit in the Fixed Predefined Payment Schedule & Variable Predefined Payment Schedule to be less or equal to https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/edit-v2/277942588#Max-Fixed-defined-%26-Variable-defined-Payment-Amount.
8.2.3.5 Allow entries in the Fixed-defined & Variable-defined Payment Schedule to have the same payment amount or amount limit.
8.2.3.6 Enforce different dates in each entry of a Fixed-defined & Variable-defined Payment Schedule
8.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.
TTPs MUST:
8.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:
The Maximum Payment Amount per payment initiation: This is required if the payment amount is variable instead of fixed. This is related to VRPs that use the Long-lived Consent of the type Variable Recurring Consent and Variable On-demand Consent. This is the maximum amount a variable payment related to the Consent can take. All payment amounts must be smaller or equal to this value. This is limited to https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277942588/Limits+and+Constants#Max-VRP-Payment-Amount.
The Maximum Cumulative Value of all payment initiations for the entire Consent validity period. This is related to all types of VRP payments. Every payment amount related to the Consent that is successfully initiated and executed is added to the Total Cumulative Value of the Consent which cannot exceed the Maximum Cumulative Value agreed with the User at the point of consent. Any payment amount resulting to a Total Cumulative Value exceeding the Maximum MUST be rejected by the TPP and the LFI. This is limited to https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277942588/Limits+and+Constants#Max-VRP-Consent-Cumulative-Value.
The Maximum Cumulative Number of all payment initiations for the entire Consent validity period. This is related to all types of VRP payments. Every payment initiation related to the Consent that is successfully initiated and executed is added to the Total Cumulative Number of payment initiations of the Consent which cannot exceed the Maximum Cumulative Number agreed with the User at the point of consent. Any payment initiation resulting to the Total Cumulative Number of initiations exceeding the Maximum MUST be rejected by the TPP and the LFI. This is limited to https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277942588/Limits+and+Constants#Max-VRP-Consent-Cumulative-Payments.
The Consent Control Period Type & Start Date (as defined in https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277940444/Multi-Payments#8.3.2-VRP-Consent-Control-Period-%26-Start-Date)
The Maximum Cumulative Value of all payment initiations per Consent Control Period. This is related to VRPs that use the Long-lived consent of the type Variable On-demand Consent and Fixed On-demand Consent. During each repeating Consent Control Period, the Total Cumulative Value of all payment initiations under Variable On-demand Consent and Fixed On-demand Consent MUST NOT exceed the Maximum Cumulative Value agreed by the User during the Consent. The Total Cumulative Value is reset on every new Consent Control Period. This is limited to https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277942588/Limits+and+Constants#Max-VRP-Cumulative-Value-per-Control-Period.
The Maximum Cumulative Number of all payment initiations per Consent Control Period. This is related to VRPs that use the Long-lived consent of the type Variable On-demand Consent and Fixed On-demand Consent. During each repeating Consent Control Period, the Total Cumulative Number of all payment initiations under Variable On-demand Consent and Fixed On-demand Consent MUST NOT exceed the Maximum Cumulative Number agreed by the User during the Consent. The Total Cumulative Number of payment initiations is reset on every new Consent Control Period. This is limited to https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277942588/Limits+and+Constants#Max-VRP-Cumulative-Payments-per-Control-Period.
8.3.2 VRP Consent Control Period & Start Date
TTPs MUST:
8.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:
Control Period: This is a rolling Period as defined in https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277940444/Multi-Payments#8.2.2-Period-Type-%26-Start-Date. During each rolling Period specific Consent Control limits are applied. The rolling Control Period may occur one or more times during the Long-lived Consent duration depending on the Period Type and the Control Period Start Date. For example, for a Consent of expiry after 30 days, a Consent Control Period of 1 Day may be repeating up to 30 times, depending on the Period Start Date. Similarly, for a Consent of expiry after 1 year a Control Period of 1 Week may be repeating up to 52 times depending on the Period Start Date.
Control Period Start Date: This is the first date of the rolling Control Period, as defined in https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277940444/Multi-Payments#8.2.2-Period-Type-%26-Start-Date. For Fixed and Variable On-Demand payments and Periodic Schedule payments the Control Period Start Date is mandatory. The Control Period Start Date MUST be a date in the future to reflect when the User wants to start initiating Fixed or Variable On-Demand payments or Periodic Schedule payments. This date MUST less than https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277940444/Multi-Payments#8.4.3-Consent-Expiration-for-Unscheduled-VRPs-(Fixed-and-Variable-On-demand-Consent).
8.4 Consent Expiration Date & Time
8.4.1 Consent Expiration for FRPs (Fixed Recurring Consent)
TTPs MUST:
8.4.1.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 Periodic Payments Schedule as defined in https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277940444/Multi-Payments#8.2.1-Periodic-Payment-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/8f0faec0e6b142f9a297da314b668b93/pages/277942588/Limits+and+Constants#Max-Consent-Validity-Period.
8.4.2 Consent Expiration for Periodic Scheduled VRPs (Variable Recurring Consent)
TTPs MUST:
8.4.2.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 Periodic Payments Schedule as defined in https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277940444/Multi-Payments#8.2.1-Periodic-Payment-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/8f0faec0e6b142f9a297da314b668b93/pages/277942588/Limits+and+Constants#Max-Consent-Validity-Period.
8.4.3 Consent Expiration for Unscheduled VRPs (Fixed and Variable On-demand Consent)
TTPs MUST:
8.4.3.1 Either allow Users to manually enter/select the period of the Fixed On-demand Consent/Variable On-demand Consent during which the payments can be executed OR pre-populate it for the Users based on the specific business case and the receiving beneficiary party.
8.4.3.2 NOT specify the time of the day for payments to be initiated using the On-demand consents. These payments can take place at any point in time during the consent period subject to the Consent Control Parameters.
8.4.3.3 Set the Payment Consent Expiration Date & Time to the end of day (23:59:59) of the last day of the consent period as set per 8.4.3.1. 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/8f0faec0e6b142f9a297da314b668b93/pages/277942588/Limits+and+Constants#Max-Consent-Validity-Period.
8.4.4 Consent Expiration for Fixed-defined & Variable-defined Consent
TTPs MUST:
8.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 Fixed-defined & Variable-defined Payments Schedule as defined in https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/edit-v2/277940444#8.2.3-Fixed-defined-%26-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/8f0faec0e6b142f9a297da314b668b93/pages/277942588/Limits+and+Constants#Max-Consent-Validity-Period.
8.5 Creditor Identification for Variable Beneficiary Consent
8.5.1 Creditor Identification for Variable-defined Beneficiaries
TTPs MUST:
8.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:
Predefined Beneficiary List: This is a list of pre-defined beneficiaries (i.e. creditor identification details). Each creditor identification details MUST be populated as per https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277942495/Common+Rules+and+Guidelines#4.-Creditor-Identification and can be in any of the supported creditor identification formats. For example:
Predefined Beneficiary List as follows:
Creditor #1: IBAN, Name
8.5.1.2 Limit the entries in the Predefined Beneficiary List to https://openfinanceuae.atlassian.net/wiki/spaces/8f0faec0e6b142f9a297da314b668b93/pages/277942588/Limits+and+Constants#Max-Predefined-Beneficiary-List-Entries.
8.5.2 Creditor Identification for Variable Beneficiaries
TTPs MUST:
8.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 agree that one or more “factors” (i.e. conditions) stated in the Consent will be used by the TPP as their explicit authorization for each payment initiation.