Single Future Dated Payment Consent

Basic Consent Parameters

TPPs MUST:

1.1 Enable Users to provide and review the parameters related to the SIP they need to consent to. These parameters include:

• User Payment Account or User LFI (as per Common Rules and Guidelines | 2. User Payment Account Selection).

• Payment Amount & Currency (as per Common Rules and Guidelines | 3. Payment Amount & Currency).

• Payee Identification details (as per Common Rules and Guidelines | 4. Payee Identification).

Note: Depending on the use case, the Payee details may not be displayed to Users in full. However, these still need to be part of the payment Consent request sent by the TPP.

• Payer Note (as per Common Rules and Guidelines | 5. Payer Note) (Optional).

• Payment Reference (as per Common Rules and Guidelines | 6.Payment Reference).

• Requested Execution Date, as per the following:

  • 1.1.1 Either allow Users to manually enter the date when the payment needs to be executed or pre-populate it for Users based on the specific business case and the receiving beneficiary party.

  • 1.1.2 Specify the Requested Execution Date to a date in the future and cannot use the same day or a day in the past. The maximum date in the future that can be specified is up to Limits and Constants | Max Consent Validity Period from the day of the Consent of the User to the TPP.

  • 1.1.3 NOT allow Users to select the time of the future date for the payment to be initiated. This is to prevent Users entering time values that could lead to either sub-optimal payment load balancing or limited time available for retries of payments which have failed due to funds checking, unavailability.

Additional Consent Parameters

TPPs MUST:

1.2 Set the Accepted Authorization Type (as per Common Rules and Guidelines | 7. Accepted Authorization Type).

1.3 Set the Authorization Time Window (as per 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. The Authorization Time Window MUST be less than the Requested Execution Date.

1.4 Set the Consent Expiration Date & Time to be the end of day (23:59:59) of the Requested Execution Date. This will allow the TPP to have a valid consent to be used for retries when looking for recovery from certain erroneous scenarios.

1.5 Set the Risk Information Block (as perCommon Rules and Guidelines | 9. Risk Information Block)

1.6 Enable Users to provide explicit consent for the initiation of a Single Future Dated payment from their online payment account held at their LFI as the payment parameters specified in the consent.

Consent Staging

As per Common Rules and Guidelines | 10. Consent Staging

Hand-off to LFI

As per Common Rules and Guidelines | 11. Hand off to LFI

Example wording to use: ‘We will securely transfer to YOUR LFI to authenticate and authorize your payment setup“.

Authentication

LFI Authentication Only

As per the following sections:

• Authentication by LFI | 2. Redirection

• Authentication by LFI | 3. Decoupled Redirection

Centralized Authentication and Authorization (Federated) Only

As per https://openfinanceuae.atlassian.net/wiki/x/HoBBAw

Confirmation/ Authorization

LFIs MUST:

5.1 Enable Users to authenticate using Multi-Factor Authentication (MFA) in order to review and authorize the long-lived Single Future Dated Consent.

5.2 Retrieve from the OFP the Future Dated 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 Future Dated Payment, if this was not provided in the retrieved staged Payment Consent details as per Common Rules and Guidelines | 12. Payment Account Selection at LFI

• 5.3.1 Allow Users to select the payment account for the initiation of the Future Dated Payment even if it has insufficient funds at the time of consent authorization. This allows Users to fund the payment accounts appropriately before the future dated payment is initiated.

5.4 NOT earmark (i.e. block) the funds related to the Future Dated Payment in the Users' payment account.

5.5 Check the authorization status of the selected payment account is in accordance with the TPPs' Accepted Authorization Type as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#13.-Check-Accepted-Authorization-Type.

5.6 Add to the Future Dated Payment Consent the IBAN of the Payee returned by the Proxy resolution process, if the Future Dated Payment Consent was submitted for User Authorization using a Proxy as the Payee Identification. The Consent is thereafter tied to the IBAN of the Payee rather than the proxy itself. This will allow the payment to be initiated to this IBAN even if the Payee changes the proxy between the time of the Future Dated Payment Consent and the initiation of the Future Dated Payment.

• 5.6.1 Return back to the OFP (and the TPP) in the payment Consent response the IBAN of the Payee identification returned by the Proxy resolution.

5.7 Present to Users the following minimum required information for authorizing the Long-lived Single Future Dated Consent:

• User Payment Account

• Payment Amount & Currency

• Payee Identification details

• Payer Note (Optional)

• Payment Reference

• Requested Execution Date

• Fees & VAT (if applicable): These are the charges that may be applied to the User account for making the payment in relation to the Long-lived Future Dated Consent. Both bank charges and VAT MUST be presented and stated separately, prior to the User Consent authorization. If applicable, LFIs MUST apply the charges on the date of the payment initiation and not at the point of Consent Authorization.

5.8 Check the Authorization Time window is valid as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#20.-Check-Authorization-Time-Window

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

5.10 Update the Future Dated Payment Consent details stored in the OFP with all the information included in the Future Dated Payment Consent authorized by the User.

OFP MUST:

5.11 Confirm back to the LFIs that the Future Dated Payment Consent details have been updated successfully.

Multi-Authorization Journey Only

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

Hand-off back to the TPP

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

Confirmation to User

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

7.2 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#19.-Payment-Details-Saving

Payment Notifications

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

Payment Initiation

TPPs MUST:

1.1 Schedule the execution time at the future Requested Execution Date 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. The acceptable time interval for scheduling the future dated payments would be as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528887/Limits+and+Constants#Schedule-Payments-Time-Window.

1.2 Submit to OFP a Single Future Dated Payment request with the same parameters as per the Future Dated Payment Consent authorized by the User. In case the Consent was setup using the Payee’s proxy, the payment request MUST also include the IBAN from the Payee Identification returned back to the TPP during the payment Consent setup.

1.3 Include in the Single Future Dated Payment request the same Payer Note as specified in the authorized Future Dated 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 the specific Single Future Dated Payment request.

1.4 Include in the Single Future Dated Payment request the same Payment Reference as specified in the authorized Future Dated Payment Consent, as the default value, if previously provided. However, this may be overwritten by a new Payment Reference provided by the User or the TPP, if relevant, for the specific Single Future Dated Payment request.

1.5 Submit to the OFP a Single Future Payment request on the date of the Requested Execution Date defined in the Future Dated Payment Consent authorized by the User.

Processing of Payment Initiation Requests

OFP MUST:

2.1 Allow TPPs to submit Single Future Dated Payment requests in relation to Single Future Dated Payment Consents authorized by Users, without any additional MFA or authorization by the Users.

2.2 Check that the received Single Future Dated Payment request relates to a valid Future Dated 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 date of the received Single Future Dated Payment request message against the specified Requested Execution Date in the related Future Dated Payment Consent. The dates MUST match exactly. If not, the request MUST be rejected and the appropriate error message/code MUST be provided to the TPP.

2.4 Reject the payment initiation and provide the necessary error message to the TPP, if any other checks on the Future Dated Payment request parameters fail against the authorized Future Dated Payment Consent.

2.5 Send a payment initiation request to the LFI for initiating an instant payment using the payment parameters included in the Future Dated Payment request including:

• User Payment Account (or account identifier)

• Payment Amount & Currency

• Payee Identification details

• Payer Note (If provided)

• Payment Reference

LFIs MUST:

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

2.7 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.8 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.9 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.10 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.11 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.12 Send to the TPP the appropriate error message in case the payment initiation was rejected by the LFI due to insufficient funds in the selected payment account.

2.13 Provide the TPP with all the available information in relation to the initiated payment instruction including the payment’s unique identifier Payment Transaction ID.

Payment Status Update

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

Payment Notifications

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

FDCU-1

Consent Update

TPPs MUST:

1.1 Enable Users to use the TPP Consent Management Interface (CMI) to amend one or more of the following parameters of a Future Dated Payment long-lived consent:

• User Payment Account (as per Common Rules and Guidelines | 2. User Payment Account Selection)

• Requested Execution Date

• Payment Amount & Currency (as per Common Rules and Guidelines | 3. Payment Amount & Currency)

• Payer Note (Optional) (as per Common Rules and Guidelines | 5. Payer Note)

• Payment Reference (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528328/Multi-Payments#5.1-Consent-Reference)

1.2 Require the Users to authenticate with their LFI and authorize the Consent update.