Single Future Dated Payment Consent

Basic Consent Parameters

TPPs MUST:

1.1 Enable Users to provide and review the parameters related to the FDP 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).

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

  • 1.1.1 Use the Confirmation of Payee (COP) service, as defined in Confirmation of Payee, if the Creditor Identification details have been provided by the User or if the Creditor is not a business onboarded by the TPP.

• Debtor Reference (as per Common Rules and Guidelines | 5. Debtor Reference) (Optional).

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

• Purpose of Payment (as per Common Rules and Guidelines | 20. Purpose of Payment).

• Requested Execution Date, as per the following:

  • 1.1.2 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.3 Specify the Requested Execution Date to a date in the future and cannot use the same day or a day in the past.

Additional Consent Parameters

TPPs MUST:

1.2 Set/clear the “Is Single Authorization” flag as appropriate (as per Common Rules and Guidelines | 7. Is Single Authorization flag).

1.3 Set the Authorization Expiration Date Time (as per Common Rules and Guidelines | 8. Authorization Expiration DateTime) 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 Expiration Date Time MUST be less than the Requested Execution Date.

1.4 Set/clear the “Is Pay By Account” flag as appropriate in the case the initiated payment is a payment at POS or e-commerce payment.

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 (i.e. scheduling) of a Single Future Dated payment from their online payment account held at their LFI as per 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 authorize your payment setup“.

Authentication

LFI Authentication Only

LFIs MUST:

4.1 Enable Users to perform authentication with their LFIs, as per the following sections:

• Authentication by LFI | 2. Redirection

• Authentication by LFI | 3. Decoupled Redirection

4.2 Re-direct Users back to the TPPs, with information that the Consent has not been authorized, if User Authentication has failed or Users opted to cancel the authentication/authorization process.

Centralized Authentication and Authorization (Federated) Only

4.3 As per Centralized Authentication and Authorization

Authorization

LFIs MUST:

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

5.2 Retrieve from the OFP the Future Dated Payment (FDP) Consent details staged by the TPP and present to Users the relevant details included in this.

5.3 Allow Users to select a payment account for the initiation of the Future Dated Payment (FDP), if this was not provided in the retrieved staged Payment Consent details as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210800446/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' “Is Single Authorization” flag, as per Common Rules and Guidelines | 7. Is Single Authorization flag.

5.6 Display to Users the TPP Trading Name of the TPP that initiated the Single Future Dated Payment (FDP) 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 Single Future Dated Payment (FDP) Consent:

• User Payment Account

• Payment Amount & Currency

• Creditor Identification details including:

  • Creditor Name

  • Creditor Account (IBAN)

  • Creditor Account Holding LFI

• Debtor Reference (Optional)

• Creditor Reference

• Purpose of Payment

• Requested Execution Date

5.8 Request Users to authorize the Future Dated Payment (FDP) Consent, so that the future dated payment can be scheduled and warehoused by the LFI.

5.9 Provide Users the ability to cancel the payment journey, if Users decide 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 Future Dated Payment (FDP) 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 Future Dated Payment (FDP) Consent details stored in the OFP.

OFP MUST:

5.12 Check the Authorization Time window is valid as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210800446/Common+Rules+and+Guidelines#19.-Check-Authorization-Time-Window.

5.13 Confirm back to the LFIs that the Future Dated Payment (FDP) Consent details have been updated successfully.

Multi-Authorization Journey Only

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

TPPs MUST:

5.15 Submit to OFP the FDP payment initiation requests with the same parameters as per the FDP Payment Consent authorized by the User(s).

• 5.15.1 Submit to OFP the FDP payment initiation request immediately after they receive the FDP Payment Consent authorization confirmation. The FDP payment initiation request MUST be received by the OFP within the Max FDP Payment Initiation Time Interval as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850897/Limits+and+Constants#A.-Limits.

Hand-off back to the TPP

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

FDP Warehousing & Scheduling

TPPs MUST:

7.1 Submit to OFP the FDP payment initiation requests with the same parameters as per the FDP Payment Consent authorized by the User(s).

• 7.1.1 Submit to OFP the FDP payment initiation request immediately after they receive the FDP Payment Consent authorization confirmation. The FDP payment initiation request MUST be received by the OFP within the Max FDP Payment Initiation Time Interval as defined in Limits and Constants | A. Limits.

OFP MUST:

7.2 Allow the TPPs to submit the individual FDP payment initiation request under the FDP Payment Consent authorized by the User, without any additional MFA or authorization from the User.

7.3 Check that the received FDP payment initiation request relates to a valid FDP Payment Consent authorized by the User. The Consent MUST be in the Authorized state. The OFP MUST reject a, FDP payment initiation message related to a FDP Payment Consent in a different state and respond back to the TPP with the appropriate error message/code.

7.4 Check the FDP payment initiation request parameters against the authorized FDP Payment Consent. All parameters MUST match exactly.

• 7.4.1 Reject the FDP payment initiation and provide the necessary error message to the TPP if any checks of the FDP payment initiation request parameters fail against the Consent parameters of the authorized FDP Payment Consent.

7.5 Send the FDP payment initiation request to the LFI for warehousing the FDP payment using the payment parameters included in the FDP payment initiation request including:

• Authorized Payment Consent Identifier

• Payment Amount & Currency

• Debtor Reference (if provided)

• Creditor Reference

• Purpose of Payment

• Requested Execution Date

LFIs MUST:

7.6 Trigger the FDP Payment warehousing process in their systems for it to be scheduled for initiation, processing and execution on the Requested Execution Date as per BAU future dated payments processing, immediately after receiving the FDP payment initiation request from the OFP.

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

• 7.6.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.

Confirmation to User

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

FDP Initiation, Processing & Execution

LFIs MUST:

9.1 Allow the FDP Payment to be initiated on the Requested Execution Date without any additional MFA or authorization from the User.

9.2 Schedule the initiation, processing and execution time at the future Requested Execution Date to occur as per their existing BAU process for Future Dated Payments initiated via other LFI channels.

9.3 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.

9.4 Follow existing BAU processing rules in cases the payment account selected for the payment has insufficient funds. LFIs may reject the FDP payment completely or may have processes in place that would allow the retry of the FDP payment at a later time on the same day, to allow Users to place funds to the account so that sufficient balance is available for the execution of the Future Dated Payment (FDP).

9.5 Subject to successful BAU checking, validation and payment processing, proceed with the execution of the Future Dated Payment (FDP) by either submitting the payment to the underlying payment rails or executing internally as Intra-bank payment.

Payment Notifications

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