Versions Compared

Version Old Version 1 New Version 2
Changes made by

Chris Michael

Warren Handley

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Expand
titleMENU
Table of Contents
minLevel1
maxLevel6
include
outlinefalse
indent
stylenone
exclude
typelist
class
printabletrue

...

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/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/edit-v2/266373190#8277940444#8.2.3-Fixed-defined-%26-Variable-defined-Payments-%26-Schedule.

...

#

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/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/266375125277942495/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/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/266375125277942495/Common+Rules+and+Guidelines#8.-Authorization-Time-Window) if there are specific timing requirements that must be met for the consent authorization. This is also relevant to cases where multiple authorizers are required to authorize the payment consent.

  • 1.3.1 For Fixed Recurring Consent and Variable Recurring Consent, the Authorization Time Window MUST be less than the time of the first payment in the Periodic Payment Schedule.

  • 1.3.2 For Fixed-defined & Variable-defined Consent, the Authorization Time Window MUST be less than the time of the first payment in the Fixed-defined & Variable-defined Payments Schedule.

1.4 Set the Risk Information Block (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/266375125277942495/Common+Rules+and+Guidelines#9.-Risk-Information-Block)

1.5 Enable Users to provide explicit consent for the initiation of a series of future Multi-Payments of fixed or variable amounts based on a fixed periodic schedule or a variable schedule from their online payment account held at their LFI as per the payment parameters specified in the consent.

Balance Check Permission

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

MPCS-2

Consent Staging

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

MPCS-3

Hand-off to LFI

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

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

MPCS-4

Authentication

LFI Authentication Only

4.1 As per the following sections:

Centralized Authentication and Authorization (Federated) Only

4.2 As per 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/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/266375125277942495/Common+Rules+and+Guidelines#12.-Payment-Account-Selection-at-LFI

  • 5.3.1 Allow Users to select a payment account for the initiation of the multi-payments even if it has insufficient funds at the time of the payment Consent authorization. This allows Users to fund the payment accounts appropriately before the dates of the payment initiation. However, the LFIs MUST inform the User, if the selected payment account has insufficient funds.

5.4 NOT earmark (i.e. block) any funds related to the payment Consent in the Users' payment account at the point of Consent authorization.

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

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

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

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

  • User Payment Account

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

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

  • Debtor Reference (Optional)

  • Consent Reference

  • Purpose of Payment

  • Payment Amount & Currency (if relevant, depending on the type of the long-lived payment Consent)

  • Consent Controls Parameters (if relevant, depending on the type of the long-lived payment Consent)

  • Consent Control Period & Start Date (if relevant, depending on the type of the long-lived payment Consent)

  • The Payment Schedule (Periodic or Fixed-defined or Variable-defined) (if relevant, depending on the type of the long-lived payment Consent)

  • Consent Expiration Date & Time

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

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

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

5.10 Change the state of the payment Consent from Awaiting Authorization to Authorized when all Authorizers (one or more) have authorized the payment Consent.

5.11 Update the payment Consent details stored in the OFP with the relevant information.

OFP MUST:

5.12 Check the Authorization Time Window is valid as perhttps://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/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/266373190277940444/Multi-Payments#8.3.2-VRP-Consent-Control-Period-%26-Start-Date.

Multi-Authorization Journey Only

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

MPCS-6

Hand-off back to the TPP

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

MPCS-7

Confirmation to User

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

...

3.3.5 Variable Recurring Payments (VRPs) - Variable-defined Consent

...

3.3.6 Variable-defined Beneficiary (IAVDB) Multi-Payments

...

Panel
panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
panelIcon:rock:
panelIconText:rock:
bgColor#DEEBFF

TTPs MUST:

3.4.2.1 Verify variable beneficiaries related to a long-live multi-payments consent either through:

...

#

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/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/266374845277942144/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.

...

#

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/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/edit-v2/266375218#Schedule277942588#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:

  • 1.11.1 If the Creditor Reference in the authorized long-lived Payment Consent was provided by the User, TPPs MUST use the same Creditor Reference for every payment initiated under the long-lived Payment Consent.

  • 1.11.2 If the Creditor Reference in the authorized long-lived Payment Consent was pre-populated by the TPP, TPPs can:

    • EITHER use the same Creditor Reference for every payment initiated under the long-lived Payment Consent

    • OR pre-populate the Creditor Reference with different information for every payment initiated under the long-lived Payment Consent based on the requirements of the TPPs or their servicing customers.

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/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/266373190277940444/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:

  • The date of the submitted payment initiation request:

    • is within the validity period of the long-lived Payment Consent (i.e. Consent Expiration Date & Time)

    • MUST match exactly one of the dates defined by the Periodic Payment Schedule (for Fixed Recurring and Variable Recurring Payments) or the dates included in the Predefined Payment Schedule for the Fixed-defined & Variable-defined Multi-Payments.

  • The amount in the submitted payment initiation request:

    • matches exactly the payment amount for consents of type Fixed Recurring and Fixed On-demand.

    • matches exactly the payment amount for the date of the payment initiation for consents of type Fixed-defined.

    • is less or equal to the maximum payment value per payment initiation for consents of type Variable Recurring and Variable On-demand

    • is less or equal to the payment amount limit for the date of the payment initiation for consents of type Variable-defined.

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:

  • Check the cumulative Total Number of payment initiations including the submitted payment initiation request is less than the Total Number of Payments as defined in the authorized long-lived Fixed Recurring Payment Consent.

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:

  • The cumulative Total Value of all payment initiations including the amount of the submitted payment initiation request is less or equal to the Maximum Cumulative Value of all payment initiations defined in the authorized long-lived Payment Consent (For Variable Recurring and Variable On-demand Consent types).

  • The cumulative Total Number of all payment initiations including the submitted payment initiation request is less or equal to the Maximum Cumulative Number of all payment initiations defined in the authorized long-lived Payment Consent (For Variable Recurring Consent and Variable On-demand Consent types).

  • The cumulative Total Value of all payment initiations per Consent Control Period including the amount of the submitted payment initiation request is less or equal to the Maximum Cumulative Value of all payment initiations within the Consent Control Period as defined in the authorized long-lived Payment Consent (For Variable Recurring Consent and Variable On-demand Consent types).

  • The cumulative Total Number of all payment initiations per Consent Control Period including the submitted payment initiation request is less or equal to the Maximum Cumulative Number all payment initiations within the Consent Control Period as defined in the authorized long-lived Payment Consent (For Variable Recurring Consent and Variable On-demand Consent types).

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.8.1 Check that the date of the payment initiation matches exactly the date of the Variable-defined Payment Schedule of the authorized Variable-defined Consent AND that the payment amount of the payment initiation is less or equal to the payment amount limit of the Variable-defined Payment Schedule of the authorized Variable-defined Consent.

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.13.1 In this case:

    • For all payments related to a VRP Consent, the OFP MUST decrement:

      • the cumulative Total Number of payments by 1 and,

      • the cumulative Total Value of payments by the value of the payment

    • For all payments related to a VRP Consent where a Control Period is set, the OFP MUST decrement:

      • the cumulative Total Number of payments per Control Period and,

      • the cumulative Total Value of payments per Control Period.

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:

  • User Payment Account (or account identifier)

  • Payment Amount & Currency

  • Creditor Identification details

  • Debtor Reference (If provided)

  • Creditor Reference

  • Purpose of Payment

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:

  • Authorized Payment Consent Identifier

  • Payment Amount & Currency

  • Debtor Reference (If provided)

  • Creditor Reference

  • Purpose of Payment

Variable Beneficiaries Only

  • 2.15.1 Check that the payment initiation request contains valid creditor identification details and that there is a unique identifier related to the Users’s authorization of the payment details.

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

  • 2.16.1 Retrieve the Creditor Identification details from the encrypted PII information block included in the original Payment Consent message.

  • 2.16.2 Apply all existing BAU check and validation processes in relation to the Creditor Identification details. In case of failure. LFIs MUST reject the payment initiation request and notify the OFP about this rejection with an appropriate error message.”

Variable Beneficiaries Only

  • 2.16.3 Check that the payment initiation request contains valid Creditor Identification details and that there is a unique identifier related to the User’s authorization of the payment details. In case of failure. LFIs MUST reject the payment initiation request and notify the OFP about this rejection with an appropriate error message.”

Variable-defined Beneficiaries Only

  • 2.16.4 Check and validate the Creditor Identification details included in the payment initiation request against the Creditor details in the authorized Multi-Payment Consent. In case that the Creditor Identification details do not exactly match any of the Creditor Identification details in the authorized Multi-Payment with Variable-defined Beneficiaries Consent, LFIs MUST reject the payment initiation request and notify the OFP about this rejection with an appropriate error message.”

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.22.1 In this case:

    • For all payments related to a VRP Consent, the OFP MUST decrement:

      • the cumulative Total Number of payments by 1 and,

      • the cumulative Total Value of payments by the value of the payment

    • For all payments related to a VRP Consent where a Control Period is set, the OFP MUST decrement:

      • the cumulative Total Number of payments per Control Period and,

      • the cumulative Total Value of payments per Control Period.

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

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/266375125277942495/Common+Rules+and+Guidelines#15.-Payment-Status-Update

MPPI-4

Payment Notifications

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/266375125277942495/Common+Rules+and+Guidelines#17.-Payment-Notifications

...

#

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.

...

Panel
panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
panelIcon:rock:
panelIconText:rock:
bgColor#DEEBFF

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:

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.

...

Panel
panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
panelIcon:rock:
panelIconText:rock:
bgColor#DEEBFF

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/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/edit-v2/266375218#Max277942588#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/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/266375218277942588/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/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/edit-v2/266375218#Max277942588#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

...

Panel
panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
panelIcon:rock:
panelIconText:rock:
bgColor#DEEBFF

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
panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
panelIcon:rock:
panelIconText:rock:
bgColor#DEEBFF

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

...

Panel
panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
panelIcon:rock:
panelIconText:rock:
bgColor#DEEBFF

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/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/266373190277940444/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/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/266375218277942588/Limits+and+Constants#Max-Consent-Validity-Period.

...

Panel
panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
panelIcon:rock:
panelIconText:rock:
bgColor#DEEBFF

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/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/266373190277940444/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/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/266375218277942588/Limits+and+Constants#Max-Consent-Validity-Period.

...

Panel
panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
panelIcon:rock:
panelIconText:rock:
bgColor#DEEBFF

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/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/266375218277942588/Limits+and+Constants#Max-Consent-Validity-Period.

...

Panel
panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
panelIcon:rock:
panelIconText:rock:
bgColor#DEEBFF

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/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/edit-v2/266373190#8277940444#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/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/266375218277942588/Limits+and+Constants#Max-Consent-Validity-Period.

...

Panel
panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
panelIcon:rock:
panelIconText:rock:
bgColor#DEEBFF

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:

8.5.1.2 Limit the entries in the Predefined Beneficiary List to https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot2draft18f0faec0e6b142f9a297da314b668b93/pages/266375218277942588/Limits+and+Constants#Max-Predefined-Beneficiary-List-Entries.

...