| Expand | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||
|
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.
...
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 |
|
...
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
User StoryAs a User (Consumer or Business), I want to provide my consent to a TPP to use my payment account for initiating both:
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
...
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)
...
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
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
User StoryAs 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
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
User StoryAs 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.6.3 Prerequisites for Variable Beneficiary Multi-Payments
1.6.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.6.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.
...
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.
...
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/standardsv1dot1final/pages/edit-v2/210798542#8.2.3-Fixed-defined-%26-Variable-defined-Payments-%26-Schedule.
...
3.3.5 Variable Recurring Payments (VRPs) - Variable-defined Consent
...
3.3.6 Variable-defined Beneficiary (IAVDB) Multi-Payments
...
# | 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/standardsv1dot1final/pages/edit-v2/210800530#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/standardsv1dot1final/pages/210798542/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 imitated 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 |
...
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
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
B. For Variable-defined Payments
8.2.3.2 Limit the entries in the Fixed Predefined Payment Schedule & Variable Predefined Payment Schedule to https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/edit-v2/210800530#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/standardsv1dot1final/pages/210800530/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/standardsv1dot1final/pages/edit-v2/210800530#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 date or payment amount or amount limit. |
8.3 VRP Consent Control Parameters
...
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
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:
|
...
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
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:
|
8.4 Consent Expiration Date & Time
...