...
One-time payment scheduled for execution in the future. A Future Dated Payment (FDP) is initiated by a TPP from a payment account held at the LFI with the explicit consent of the User. The payment is initiated by the TPP which manages the scheduling of the paymentLFI on the date scheduled by the TPP. The TPP acquires explicit consent from the User for longa single-lived use access to the User’s payment account. The User MUST authenticate with the LFI and authorize the longsingle-lived use consent. The payment related to the authorized consent, is warehoused by the LFI and is initiated by the TPP to the LFI on the day it is due, as per the authorized consent.
This use case requires a LongSingle-lived Use Consent. The consent parameter type for this use case capability is Single Future Dated Payment Consent, which MUST be used for a single payment which will be initiated by the TPP LFI in the future after User authorization at 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 scheduling with my LFI a Single Future Dated payment of a fixed amount to a domestic beneficiary account owned by a business or an individual, so that I can pay the relevant beneficiary. |
2. User Journey
Users can initiateschedule, by providing their consent to TPPs, a payment order to their LFIs to make a one-off single payment of a specific amount to a specific payee on a specific date.
...
3. Wireframes
...
3.1.
...
Rules & Guidelines
#
Step
Rules & Guidelines
FDPI-1
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# | Step | Rules & Guidelines | ||||
|---|---|---|---|---|---|---|
FDCSFDP-1 | Single Future Dated Payment Consent | Basic Consent Parameters TPPs MUST: 1.1 Enable Users to provide and review the parameters related to the SIP FDP they need to consent to. These parameters include:
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.
| ||||
Additional Consent Parameters TPPs MUST: 1.2 Set the Accepted Authorization Type (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2standardsv1draft3/pages/5252883070092902/Common+Rules+and+Guidelines#7.-Accepted-Authorization-Type). 1.3 Set the Authorization Time Window (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2standardsv1draft3/pages/5252883070092902/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 (Expiry Date accordingly if the Authorization Time Window is set to more than 1 day. This is to avoid the consent expiring before all necessary authorizations are completed. Otherwise, the default value of the Consent Expiry Date MUST be set to the same day (i..e current day). The Consent Expiry Time MUST always be set to 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.Consent Expiry Date. 1.5 Set the Risk Information Block (as perhttps://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2standardsv1draft3/pages/5252883070092902/Common+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. | ||||||
FDCSFDP-2 | Consent Staging | |||||
FDCSFDP-3 | Hand-off to LFI | Example wording to use: ‘We will securely transfer to YOUR LFI to authenticate and authorize your payment setup“. | ||||
FDCSFDP-4 | Authentication | LFI Authentication Only As per the LFIs MUST: 4.1 Enable Users to perform authentication with their LFIs, as per the following sections: | ||||
Centralized Authentication and Authorization (Federated) Only | ||||||
FDCS-5 | 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 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/525288304.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 https://openfinanceuae.atlassian.net/wiki/x/HoBBAw | ||||||
FDP-5 | Confirmation/ 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 using the unique Consent Identifier and present to Users all the 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/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#12.-Payment-Account-Selection-at-LFI
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/standardsv1draft2standardsv1draft3/pages/5252883070092902/Common+Rules+and+Guidelines#13.-Check-Accepted-Authorization-Type. | ||||
Using Proxy for Beneficiaries Only 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.7 Present to Users the following minimum required information for authorizing the Long-lived Single Single Future Dated Payment (FDP) Consent:
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.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 abort 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 Future Dated Payment (FDP) Consent. | ||||||
OFP MUST: 5.10 Check the Authorization Time window is valid as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2standardsv1draft3/pages/5252883070092902/Common+Rules+and+Guidelines#18Guidelines#20.-Multi-UserCheck-Authorization-Flow | FDCS6 | Hand-off back to the TPP | FDCS-7 | Confirmation to User | 7.2 Window 5.11 Change the state of the payment Consent from Awaiting Authorization to Authorized when all Authorizers (one or more) have authorized the payment Consent. 5.12 Update the Future Dated Payment (FDP) Consent details stored in the OFP with all the information included in the Future Dated Payment (FDP) Consent authorized by the User. 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/standardsv1draft2standardsv1draft3/pages/5252883070092902/Common+Rules+and+Guidelines#19Guidelines#18.-PaymentMulti-DetailsUser-Authorization-SavingFlow | ||||||
FDCSFDP-8 | Payment Notifications |
4. Payment Initiation
6 | FDP Warehousing & Scheduling | LFIs MUST: 6.1 Warehouse the FDP Payment in their systems for it to be scheduled for inititiation, processing and execution on the Requested Execution Date. |
FDP-7 | Hand-off back to the TPP | |
FDP-8 | Confirmation to User |
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.
FDPI-2
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.
FDPI-3
Payment Status Update
FDPI-4
Payment Notifications
5. Consent Updates
#
Step
Rules & Guidelines
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 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#2.-User-Payment-Account-Selection)
Requested Execution Date
Payment Amount & Currency (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#3.-Payment-Amount-%26-Currency)
Payer Note (Optional) (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#5.-Payer-Note)
FDP-9 | 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 Futue Dated Payment (FDP) by either submitting the payment to the underlying payment rails or executing internally as Intra-bank payment. |
FDP-10 | Payment Notifications |
70092902/Common+Rules+and+Guidelines#17.-Payment-Notifications |