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 is not present in the TPP web or mobile applicationauthorization conditions have not been met.

1.2 Request User’s Authorization Present to Users for each payment initiation presenting the following minimum required information to the Users:

:

• Payment Amount & Currency (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#4Guidelines#3.-Payment-Amount-Payee%26-IdentificationCurrency)

• User Payment Account

• Payment Reference Payee Identification details (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#6Guidelines#4.Payment-Payee-ReferenceIdentification)

1.3 Request Users to authenticate with the TPP using Multi-Factor Authentication (MFA) for authorizing each payment initiation related to an authorized Multi-payment Consent to Variable Beneficiaries. (e.g. dynamic linking of User’s MFA to the payment details). Ensure that all required authorization conditions as agreed with the User during the Consent setup are met.

1.4 Generate a unique identifier related to the Users’s linking of MFA authentication to the authorized payment details and keep for the transaction that links the Users’s authorization factors with the payment details (i.e. amount and payee identification). TPPs MUST generate an audit trail of the User’s payment initiation actions during the session. TPPs MUST have all required records as evidence required as listed in the liability model.

1.5 Provide Users the ability to abort the payment journey, if Users decided to terminate the request.

Scheduled Multi-Payments Only (Fixed Recurring Payment Consent, Variable Recurring Consent and Variable-defined Consent)

TPPs MUST:

1.6 Submit to OFP payment initiation requests on the scheduled dates defined in the Periodic or the Variable-defined Payment Schedule of the long-lived Payment Consent authorized by the User.

1.7 Schedule the execution time of the payments related to the Periodic or the Variable-defined Payment Schedule to occur during time periods of low payment volume such as the early hours of the day, unless there are specific requirements based on their business case.

TPPs MUST:

1.8 Submit to OFP payment initiation requests with the same fixed parameters as per the long-lived Payment Consent authorized by the User. In case where the consent was setup using the Payee’s proxy, the payment request MUST also include the IBAN from the proxy Payee identification returned back to the TPP during the payment Consent setup.

1.9 Submit to OFP payment initiation requests with variable parameters within the allowable limits of the Consent Controls as per the long-lived Payment Consent authorized by the User.

1.10 Include in each one of the payment initiation requests the same Payer Note as specified in the authorized long-lived Payment Consent, as the default value, if previously provided. However, this may be overwritten by a new Payer Note provided by the User or the TPP, if relevant, for each payment initiation request.

1.11 Include in each of the payment initiation requests a Payment Reference. This MUST be populated as follows:

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

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

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

  • OR pre-populate the Payment 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.will result in exceeding the maximum limit, if specified in the long-lived Payment Consent for the VRPs.

Variable-defined Beneficiaries Only

1.17 Include in each of the payment initiation requests one of the Payee Identification details included in the Pre-defined Beneficiary List, as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528328/Multi-Payments#6.5.1-Payee-Identification-for-Variable-defined-Beneficiaries

Variable Beneficiaries Only

1.17 18 Include in each of the payment initiation requests the Payee Identification details, which was were not provided as part of the long-lived Payment Consent authorized.

1.18 19 Include in each of the payment initiation requests the unique identifier for the transaction related to the Users’s linking of MFA authentication to the authorized 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:

-lived Payment Consent. More specifically, the OFP MUST check the following:

• The Payee Identification details in the submitted payment initiation request matches exactly the Payee Identification in the authorized Payment Consent, except in the case of Variable Beneficiaries Consent.

  • 2.3.1 For Variable-defined Beneficiaris, the Payee Identification details in the submitted payment initiation request

  matches

  • MUST match exactly one of the Payee Identification entries in the authorized Payment Consent

  , except in the case of Variable Beneficiaries Consent

  • Predefined Beneficiary List.

• 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)

  • the period defined in the Periodic or Variable-defined Payment Schedule (for Fixed Recurring, Variable Recurring and Variable-defined Consent types). In this case, the dates of each payment initiation request MUST match exactly the dates in the Payment Schedule.

• 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 Variable-defined.

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

FRPs Only

OFT MUST:

2.4 Check the Fixed Recurring Payment initiation request parameters against the Fixed Recurring Payment Consent. More specifically, the OFP MUST:

• 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 payee Bank. The initial value of this parameter should be zero for each authorized Fixed Recurring Payment Consent.

2.6 Set the Fixed Recurring Payment Consent state to a terminal state (Finished), if the cumulative total number of payments requests becomes equal to the Total Number of Payments parameter of the Fixed Recurring Payment Consent.

VRPs Only

OFP MUST:

2.7 Check the payment initiation request parameters against the authorized long-lived VRP Payment Consent. More specifically, the OFP MUST check the following:

• 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 Variable-defined Payment Schedule of the authorized Consent for the Variable-defined Payments.

2.9 Increment the cumulative Total Number and the cumulative Total Value of payments under the VRP Consent after the payment successfully executed and received payment status confirmation from the payee Bank. The initial value of these parameters should be zero for each authorized VRP Consent.

2.10 Increment the cumulative Total Number and the cumulative Total Value of all payment initiations per Control Period after the payment successfully executed and received payment status confirmation from the payee Bank. These parameters are reset to zero when a new Consent Control Period starts at 00:00:00 of the first day of the Control Period.

2.11 Set the long-lived Payment Consent state to a terminal state (Finished), if the cumulative total number of payment requests becomes equal to the Total Number of Payments parameter of the VRP Consent.

Variable Beneficiaries Only

2.12 Check that the payment initiation request contains valid payee identification details and that there is a unique identifier related to the Users’s linking authorization of MFA authentication to the authorized payment details.

OFP MUST:

2.13 Allow the description of the Payment Reference in the submitted payment initiation request to be different than the one defined in the Payment Reference of the long-lived Payment Consent.

2.14 Reject the payment initiation and provide the necessary error message to the TPP if any other checks of the payment initiation request parameters fails against Consent parameters of the authorized long-lived Payment Consent.

2.15 Send a payment initiation request to the LFI for initiating an instant payment using the payment parameters included in the payment initiation request including:

• User Payment Account (or account identifier)

• Payment Amount & Currency

• Payee Identification details

• Payer Note (If provided)

• Payment Reference

LFIs MUST:

2.16. Allow the OFP to submit the payment initiation request without any additional MFA or authorization from the User.

2.17 Add to the payment initiation request the IBAN of the Payee returned by the Proxy resolution process, if the payment initiation request was submitted using a Proxy as the Payee Identification. The payment initiation request is thereafter tied to the IBAN of the Payee rather than the proxy itself.

• 2.17.1 Include in the payment initiation response to the OFP the IBAN of the Payee identification returned by the Proxy resolution.

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

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

MPPI-4

Payment Notifications

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