| 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.
...
| 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
...
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 |
...
) |
...
| 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. |
...
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 set up setup a sequence of future payments of fixed or variable amounts from my payment account with on a fixed or variable schedule, to any a predefined list of domestic beneficiary account accounts owned by one or more a business businesses or an individualindividuals, so that I can arrange to transfer funds or 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.
...
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.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
...
| 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
...