1. Description
The Bank Service Initiation functionality of the Open Finance Standard can become an enabler for additional functionality to be implemented by TPPs. One example of functionality is the implementation of Payment Request (PR). This funtionality enables TPPs to initiate Payment Requests (PRs) from a Sender (Payee) to a Recipient (Payer) business or a person. The Payment Request includes all the information in relation to the payment including the Payee’s payment account which will be used to receive the funds, if the Payment Request is accepted by the Recipient (Payer). The Payment Request is then fullfiled using the existing Bank Service Initiaiton functionality defined in the Open Finance Standard.
The PR scope can be initially targeted to domestic payee accounts (i.e. payee accounts offered by LFIs located in UAE) and payments in local currency as used by the local payment systems infrastructure for domestic payments.
Note: Payment Request (PR) can be initiated by all UAE account holding users (Payees) and sent to all UAE account holding owners (Payers) without any requirement for enrollment with the UAEIPP Overlay Service directory service, provided that users have a valid email address and/or a valid mobile phone number to receive the Payment Requests.
1.1 Payer and Payee Segments
The scope of the Payment Request functionality related to the segments of payers and payees is shown below:
PR Sender (Payee) | PR Recipient (Payer) | ||||
|---|---|---|---|---|---|
Consumers | SME | Corporates | Consumers | SME | Corporates |
|
|
|
|
|
|
There are no restrictions on who can send PRs to whom. All possible combinations are available including individual to individual, individual to business, business to individual and business to business.
1.2 Payment Request (PR) - Example User Story
User Story
As a User (Consumer, Business or Corporate),
I want to have the ability to send a Payment Request with all the payment details to a debtor (payer),
so that I can get paid directly to my payment account when the payer accepts the request and initiates a payment using Open Finance.
Note: It is in the competitive space of TPPs to innovate further supporting services, in addition to these guidelines. For example:
Sending multiple Payment Requests to multiple Users who should split a certain payment (e.g. friends dinner) using various splitting methods (e.g. percentage or custom split)
Creating predefined groups of Users who frequently split & share certain payments (e.g. weekly, monthly or yearly)
Schedule Payment Requests to be triggered at a specific date & time in the future.
2. Process Flow
The below diagram depicts the process flow from initiating a Payment Request to fullfilment with a payment via an Open Finance Standard Payment Initiation.
3. Rules & Guidelines
# | Step | Rules & Guidelines |
|---|---|---|
PR-1 | 1. Payment Request Start | TPPs COULD: In cases where TPPs have long-term contractual relationships with the Users, and subject to acquiring Users' consent, TPPs COULD store the below payment details, if the LFIs' response indicated that they are correct. Users, can easily access this stored information for future payment setups.
|
Basic Consent Parameters TPPs MUST: 1.1 Enable Users to provide and review the parameters related to the Consent for the initiation of a series of Requests-to-Pay (RTPs) they need to consent to. These parameters include:
| ||
RTP Consent Control Parameters
| ||
| ||
Additional Consent Parameters 1.2 Set the Accepted Authorization Type (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#7.-Accepted-Authorization-Type). 1.3 Set the Authorization Time Window (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#8.-Authorization-Time-Window) if there are specific timing requirements that must be met for the RTP 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 time of the RTP Consent Expiration Date & Time. 1.4 Set the Risk Information Block (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#9.-Risk-Information-Block) | ||
1.5 Enable Users to provide explicit consent for the initiation of a series of future Requests-To-Pay (RTPs) of variable amounts based on variable schedule (on-demand) to be received in their online payment account held at their LFI as per the RTP Consent Control Parameters specified in the RTP Consent. | ||
RTPCS-2 | Consent Staging | |
RTPCS-3 | Hand-off to LFI | Example wording to use: ‘We will securely transfer to YOUR LFI to authenticate and authorize your Consent setup“. |
RTPCS-4 | Authentication | LFI Authentication Only As per the following sections: |
Centralized Authentication and Authorization (Federated) Only | ||
RTPCS-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 RTP Consent. 5.2 Retrieve from the OFP the RTP Consent details staged by the TPP using the unique Consent Identifier. 5.3 Allow Users to select a payment account for receiving of the RTP payments, if this was not provided in the retrieved staged RTP Consent details as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#12.-Payment-Account-Selection-at-LFI 5.4 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/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#13.-Check-Accepted-Authorization-Type. 5.5 Present to Users the following minimum required information for authorizing the long-lived RTP Consent:
5.6 Request Users to authorize the RTP Consent, so that TPPs can send RTP requests from the payment account. After the long-lived RTP consent has been authorized, LFIs MUST allow TPPs to submit RTPs requests under the long-lived RTP Consent without any additional MFA or authorization from Users. 5.7 Provide Users the ability to abort the RTP Consent setup journey, if Users decided to terminate the process. The LFI MUST hand-off the Users back to the TPP, providing the necessary error message to the OFP and reject the RTP Consent. 5.8 Check the Authorization Time window is valid as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#20.-Check-Authorization-Time-Window 5.9 Change the state of the RTP Consent from Awaiting Authorization to Authorized when all Authorizers (one or more) have authorized the RTP Consent. 5.10 Update the RTP Consent details stored in the OFP with all the information included in the RTP Consent authorized by the User. |
OFP MUST: 5.11 Confirm back to the LFIs that the RTP Consent details have been updated successfully. 5.12 Start tracking the RTP Consent Control Parameters for the RTP Control Period at the RTP Control Period Start Date, if provided, or the RTP Consent creation Date otherwise. The RTP Control Period starts from 00:00:00 of the day and ends at 23:59:59 of the RTP Control Period end day, calculated based on the RTP Control Period type as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109414866/Request+to+Pay#8.4-RTP-Consent-Control-Period-%26-Start-Date. | ||
Multi-Authorization Journey Only | ||
RTPCS-6 | Hand-off back to the TPP | |
RTPCS-7 | Confirmation to User | TPPs MUST: 7.1 Confirm to Users the outcome of their RTP Consent Authorization with the LFI. TPPs MUST include the Consent ID provided by the OFP in their confirmation for reference. The Consent ID presented to Users MUST be user-friendly. 7.2 Inform Users if further authorizations are required for the RTP Consent and provide additional information about the Authorizers supplied by the OFP as described in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#18.-Multi-User-Authorization-Flow. |
RTPCS-8 | RTP Notifications | LFIs MUST: 8.1 Send a notification to Users when a a Long-lived RTP Consent is set up by Users, including information of the TPP which acquired the User Consent. |
3.1 Payment Request Status
For each Payment Request, there are multiple statuses as described below:
RTP Status | Description | Aani Status Mapping |
|---|---|---|
Pending | The RTP request is pending. The RTP has been sent successfuly by the Payee LFI and it is sitting in a temporal state waiting to be processed by the Recipient (Payer). Further checks and status update will be performed. | “PND” (Request pending) |
Accepted | The RTP request has been accepted by the RTP Payer. Further checks and status update will be performed. | |
Paid | The RTP Payer has fulfilled and paid the RTP request. This is a terminal state. | “OK” (Request paid) |
Rejected | The RTP Payer has rejected (i.e. “refused to accept”) the RTP request. This is a terminal state. | “RIF” (Request rejected/refused by the recipient) |
Cancelled | The Payee has cancelld (i.e. “annulled”) the RTP request before being accepted or rejected by the RTP Payer. This is a terminal state. | “ANN” (Request canceled/annulled by the RTP sender, who has decided to annul it before |
Expired | The RTP request has expired due to no action from the RTP Payer during the validity period (i.e. the RTP Payer has not accepted, paid or rejected it within the validity period). This is a terminal state. | “SCD” (Request expired due to time out); |
Failed | The RTP request has failed due to error either on the Sender’s (Payer’s) LFI or the RTP Payer’s receiving LFI. This is a terminal state. | |
Not Submitted | The Payee cancels the RTP request before this is submitted to the RTP Payer’s LFI. This is a terminal state. |
TPPs COULD:
CRG-19.1 In cases where TPPs have long-term contractual relationships with the Users, and subject to acquiring Users' consent, TPPs COULD store the below payment details, if the LFIs' response indicated that they are correct. Users, can easily access this stored information for future payment setups.
Payer Account Provider Name (LFI Name).
Payer Account Identification.
Beneficiary LFI Name.
Beneficiary Name.
Beneficiary Account Identification details (e.g., account number, full IBAN, any proxies supported by the LFI selected).
3.1. Consent Setup
This user journey requires a Long-lived Consent of type Request to Pay Payment Consent. This Consent will allow a series of future RTPs of variable amounts to be sent to different recipients (payers) on a variable schedule (on-demand). As part of the long-lived RTP Consent, Users need to authenticate and authorize with their LFIs once to setup the long-lived RTP Consent. Any RTPs initiated using the authorized long-lived consent do not require any further User authentication and authorization with their LFIs.
# | Step | Rules & Guidelines |
|---|---|---|
RTPCS-1 | RTP Consent | Basic Consent Parameters TPPs MUST: 1.1 Enable Users to provide and review the parameters related to the Consent for the initiation of a series of Requests-to-Pay (RTPs) they need to consent to. These parameters include:
|
RTP Consent Control Parameters
| ||
| ||
Additional Consent Parameters 1.2 Set the Accepted Authorization Type (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#7.-Accepted-Authorization-Type). 1.3 Set the Authorization Time Window (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#8.-Authorization-Time-Window) if there are specific timing requirements that must be met for the RTP 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 time of the RTP Consent Expiration Date & Time. 1.4 Set the Risk Information Block (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#9.-Risk-Information-Block) | ||
1.5 Enable Users to provide explicit consent for the initiation of a series of future Requests-To-Pay (RTPs) of variable amounts based on variable schedule (on-demand) to be received in their online payment account held at their LFI as per the RTP Consent Control Parameters specified in the RTP Consent. | ||
RTPCS-2 | Consent Staging | |
RTPCS-3 | Hand-off to LFI | Example wording to use: ‘We will securely transfer to YOUR LFI to authenticate and authorize your Consent setup“. |
RTPCS-4 | Authentication | LFI Authentication Only As per the following sections: |
Centralized Authentication and Authorization (Federated) Only | ||
RTPCS-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 RTP Consent. 5.2 Retrieve from the OFP the RTP Consent details staged by the TPP using the unique Consent Identifier. 5.3 Allow Users to select a payment account for receiving of the RTP payments, if this was not provided in the retrieved staged RTP Consent details as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#12.-Payment-Account-Selection-at-LFI 5.4 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/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#13.-Check-Accepted-Authorization-Type. 5.5 Present to Users the following minimum required information for authorizing the long-lived RTP Consent:
5.6 Request Users to authorize the RTP Consent, so that TPPs can send RTP requests from the payment account. After the long-lived RTP consent has been authorized, LFIs MUST allow TPPs to submit RTPs requests under the long-lived RTP Consent without any additional MFA or authorization from Users. 5.7 Provide Users the ability to abort the RTP Consent setup journey, if Users decided to terminate the process. The LFI MUST hand-off the Users back to the TPP, providing the necessary error message to the OFP and reject the RTP Consent. 5.8 Check the Authorization Time window is valid as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#20.-Check-Authorization-Time-Window 5.9 Change the state of the RTP Consent from Awaiting Authorization to Authorized when all Authorizers (one or more) have authorized the RTP Consent. 5.10 Update the RTP Consent details stored in the OFP with all the information included in the RTP Consent authorized by the User. |
OFP MUST: 5.11 Confirm back to the LFIs that the RTP Consent details have been updated successfully. 5.12 Start tracking the RTP Consent Control Parameters for the RTP Control Period at the RTP Control Period Start Date, if provided, or the RTP Consent creation Date otherwise. The RTP Control Period starts from 00:00:00 of the day and ends at 23:59:59 of the RTP Control Period end day, calculated based on the RTP Control Period type as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109414866/Request+to+Pay#8.4-RTP-Consent-Control-Period-%26-Start-Date. | ||
Multi-Authorization Journey Only | ||
RTPCS-6 | Hand-off back to the TPP | |
RTPCS-7 | Confirmation to User | TPPs MUST: 7.1 Confirm to Users the outcome of their RTP Consent Authorization with the LFI. TPPs MUST include the Consent ID provided by the OFP in their confirmation for reference. The Consent ID presented to Users MUST be user-friendly. 7.2 Inform Users if further authorizations are required for the RTP Consent and provide additional information about the Authorizers supplied by the OFP as described in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#18.-Multi-User-Authorization-Flow. |
RTPCS-8 | RTP Notifications | LFIs MUST: 8.1 Send a notification to Users when a a Long-lived RTP Consent is set up by Users, including information of the TPP which acquired the User Consent. |
3.2.RTP Consent Revocation
In addition to the rules stated in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109412866/TPP+Consent+Management+Interfaces#3.-Consent-Revocation-Journey and https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109413013/LFI+Consent+Management+Interfaces#3.-Consent-Revocation-Journey, the following rules also hold:
TPPs & LFIs MUST:
3.2.1 Provide Users the following options, in the cases they want to revoke a long-lived RTP Consent and there exist active RTPs related to the RTP Consent which are still waiting to be accepted, paid or rejected by the RTP Payer and have not yet expired:
Either select to cancel the active RTPs together with the revocation of the long-lived RTP Consent
Or select to revoke the RTP long-lived Consent without cancelling the active RTPs
4. RTP Initiation
# | Step | Rules & Guidelines |
|---|---|---|
RTPIN-1 | RTP Initiation | TPPs MUST: 1.1 Enable Users to initiate a Request-To-Pay (RTP) by providing the below required information:
|
Additional Parameters | ||
TPPs MUST: 1.2 Submit to OFP RTP requests with parameters within the allowable limits of the RTP Consent Controls as per the long-lived RTP Consent authorized by the User. 1.3 Include in each one of the RTP requests the same RTP Payment Reference as specified in the authorized long-lived RTP Consent, as the default value, if previously provided. However, this may be overwritten by a new RTP Payment Reference provided by the User or the TPP, if relevant, for each RTP request. 1.4 NOT submit any RTP request of amount greater than the Maximum Payment Amount per each RTP request, if specified in the long-lived RTP Consent. 1.5 Keep track of the cumulative value of all RTP payments successfully received and NOT submit any RTP requests that will result in exceeding the Maximum Cumulative Value of all RTP requests for the entire RTP Consent validity period. , if specified in the long-lived RTP Consent. 1.6 Keep track of the cumulative number of all RTP requests and NOT submit any RTP requests that will result in exceeding the Maximum Cumulative Number of all RTP requests for the entire RTP Consent validity period, if specified in the long-lived RTP Consent. 1.7 Keep track of the cumulative value of all RTP payments successfully received during the Control Period time window and NOT submit any RTP requests that will result in exceeding the Maximum Cumulative Value of all RTP requests per RTP Consent Control Period, if specified in the long-lived RTP Consent. 1.8 Keep track of the cumulative number of all RTP requests during the Control Period time window and NOT submit any RTP requests that will result in exceeding the Maximum Cumulative Number of RTP requests RTP Consent Control Period, if specified in the long-lived RTP Consent. | ||
RTPIN-2
| Processing of Payment Initiation Requests | OFP MUST: 2.1 Allow TPPs to submit individual RTP requests under the long-lived RTP Consent authorized by the User, without any additional MFA or authorization from the User. 2.2 Check that the received RTP requests relate to a valid long-lived RTP Consent authorized by the User. The Consent MUST be in the Authorized state. The OFP MUST reject any RTP request messages related to an RTP Consent in a different state (e.g. expired) and respond back to TPPs with the appropriate error message/code. 2.3 Check the RTP request parameters against the authorized long-lived RTP Consent. More specifically, the OFP MUST check the following:
2.4 Check the RTP request parameters against the authorized long-lived RTP Consent. More specifically, the OFP MUST check the following:
2.5 Increment the cumulative Total Number and the cumulative Total Value of RTP requests under the RTP Consent after the RTP payment successfully received in the User’s payment account from the RTP Payer’s LFI. The initial value of these parameters should be zero for each authorized RTP Consent. 2.6 Increment the cumulative Total Number and the cumulative Total Value of all RTP requests per RTP Control Period after the RTP payment successfully received in the User’s payment account from the RTP Payer’s LFI. These parameters are reset to zero when a new RTP Consent Control Period starts at 00:00:00 of the first day of the RTP Control Period. 2.7 Set the long-lived RTP Consent state to a terminal state (Finished), if the cumulative total number of RTP requests becomes equal to the Maximum Cumulative Number of all RTP requests for the entire RTP Consent validity period. 2.8 Set the long-lived RTP Consent state to a terminal state (Finished), if the cumulative Total Value of the successfully recieved RTP payments becomes equal to the Maximum Cumulative Value of all RTP requests for the entire RTP Consent validity period. 2.9 Check that the RTP request contains valid RTP Payer Identification details. |
OFP MUST: 2.10 Allow the description of the RTP Payment Reference in the submitted RTP request to be different than the one defined in the RTP Payment Reference of the long-lived RTP Consent. 2.11 Reject the RTP request and provide the necessary error message to the TPP, if any other checks of the RTP request parameters fail against the RTP Consent parameters of the authorized long-lived RTP Consent. 2.12 Send a, RTP request to the LFI for initiating a single RTP request using the RTP parameters included in the RTP request received from the TPP including:
| ||
LFIs MUST: 2.13 Allow the OFP to submit the RTP request without any additional MFA or authorization from the User. 2.14 Add to the RTP request the IBAN of the RTP Payer returned by the Proxy resolution process, if the RTP request was submitted using a Proxy as the RTP Payer Identification. The RTP request is thereafter tied to the IBAN of the RTP Payer rather than the proxy itself.
2.15 Additionally apply all existing BAU payment account controls and limits that are relevant, as if the RTP request has been initiated by the existing LFI channels. LFIs MUST send an appropriate error response to the OFP in case the RTP request is rejected due to violating any of these BAU checks for RTPs. 2.16 Subject to successful BAU checking, validation and processing, proceed with the execution of the RTP request by either submitting the RTP request to the underlying payment rails or executing internally as Intra-bank RTP request. 2.17 Provide the OFP with all the available information in relation to the requested RTP including any unique identifiers generated for this. | ||
OFP MUST: 2.18 Send an appropriate error response to the TPPs in case the RTP request is rejected due to violating any of the LFIs BAU payment accounts checks for RTPs. 2.19 Provide the TPP with all the available information in relation to the initiated RTP request including the RTP request’s unique identifier. | ||
RTPIN-3 | Confirmation to User | TPPs MUST: 3.1 Confirm the outcome of each RTP request initiation to Users using confirmation screens inline with the customer journey, for every RTP request initiation that Users are present. |
RTPIN-4 | RTP Notifications | TPPs MUST: 4.1 Confirm to Users using notifications the outcome of each RTP request, if Users are not present during the RTP request initiation. The notifications MUST also include the following information:
|
LFIs MUST: 4.2 Send a notification to Users on the success or failure of an RTP request when the RTP submitted by the TPP is either successfully sent by the LFI or there is an error in processing the RTP request. 4.3 Use SMS as a minimum channel to notify Users and optionally any other allowable channels (e.g. email, app notifications) currently used for account access or payment related notifications to their customers depending on UAE rules and regulations, for all Open Finance related notifications to Users. | ||
TPPs COULD: 4.4 Provide notifications to Users 5 days before the expiry of each RTP, if they have not received any updates from the Users' LFIs. |
5. RTP Status Update
# | Step | Rules & Guidelines |
|---|---|---|
RTPST-1 | RTP Status Update | TPPs MUST: 1.1 Check with the OFP for the status of an RTP request at various points in time throughout its validity period. The frequency of these queries to the OFP MUST be subject to fair usage policies. This is applicable in cases where TPPs are using the method of querying the RTP status from the OFP (aka “polling” method). 1.2 Have the option to be notified by the OFP of the RTP request status change when it occurs without requiring to query the OFP. This is only applicable in cases where TPPs selected to use the method of requesting the OFP to notify them asynchronously on the event of changes in the status of a payment (aka “webhook” method).
|
OFP MUST: 1.3 Update the status of each RTP request initiated by the TPP throughout its validity period with the appropriate status value based on its processing and fullfillment as provided by the LFI. 1.4 Be able to notify the TPPs, asynchronously, about any changes in the status of the RTP request. This is applicable when TPPs setup asynchronous event notifications (i.e. webhooks) with the OFP. 1.5 Respond to an RTP status query requests from a TPP or provide asynchronous notification, by sending the RTP status as defined in as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109414866/Request+to+Pay#8.8-RTP-Status. 1.6 Return to the TPP, in addition to the RTP status, other payment system specific status codes and payment rejection reasons codes as specified in the UAE Open Finance Standard specifications. | ||
LFIs MUST: 1.7 Update the status of each RTP request initiated by the OFP throughout its validity period with the appropriate status value based on its processing and fullfillment as provided by the LFI. 1.8 Be able to notify the OFP asynchronously about any changes in the status of the RTP request. More specifically, LFIs MUST provide asynchronous notification to the OFP by sending the RTP status as defined in as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109414866/Request+to+Pay#8.8-RTP-Status. 1.9 Return to the OFP in addition to the RTP status, and other payment system specific status codes and payment rejection reasons codes as specified in the UAE Open Finance Standard specifications. | ||
RTPST-2 | RTP Notifications | TPPs MUST: 2.1 Notify Users in relation to any changes in the RTP status. |
LFIs MUST: 2.2 Send notifications to Users on any RTP status updates. 2.3 Use SMS as a minimum channel to notify Users and optionally any other allowable channels (e.g. email, app notifications) currently used for account access or payment related notifications to their customers depending on UAE rules and regulations, for all Open Finance related notifications to Users. |
6. RTP Consent Parameters Update
Note: The parameters of the long-lived RTP Consent that Users are able to update depend on the use case and the business requirements of each TPP. There may be scenarios where the TPPs are fine to allow Users to update one or more of the RTP Consent parameters and other scenarios where Users are not allowed to make any changes to the RTP Consent Parameters. In any case, Users are always able to revoke their RTP Consent.
7. RTP Cancelation Process
# | Step | Rules |
|---|---|---|
RTPCAN-1 | RTP Cancellation Request | TPPs MUST: 1.1 Enable Users to cancel an active RTP before the before the RTP is accepted by the RTP Payer. 1.2 Authenticate Users within their application with Multi Factor-Authentication (MFA) before allowing Users to cancel an active RTP. |
RTPCAN-2 | Processing of RTP Cancellation Request | OFP MUST: 2.1 Allow TPPs to submit an RTP cancellation request for an active RTP, without any additional MFA or authorization from Users. 2.2 Check the RTP cacellation request is related to an active RTP which has been initiated and not expired. Provide the necessary error message to the TPP, if the cancellation request checks fail.
2.3 Send the RTP Cancellation request to the LFI for initiating an RTP Cancellation request of the active RTP. |
LFIs MUST: 2.4 Allow the OFP to submit the RTP Cancellation request without any additional MFA or authorization from the User. 2.5 Respond with a “Reject” status to the RTP Cancellation request, if the LFI has already received a response to the RTP Request from the RTP Payer’s LFI or the RTP Request status is in a terminal state. 2.6 Additionally apply all existing BAU RTP cancellation checks that are relevant, as if the RTP cancellation request has been initiated by the existing LFI channels. LFIs MUST send an appropriate error response to the OFP in case the RTP request is rejected due to violating any of these BAU checks for RTPs. 2.7 Subject to successful BAU checking and validation proceed with the RTP Cancellation request by either submitting the RTP Cancellation request to the underlying payment rails or executing internally as Intra-bank RTP Cancellation request. 2.8 Provide the OFP with all the available information in relation to the requested RTP including any unique identifiers generated for this. 2.9 Set the status of the RTP to ‘Cancelled’ if RTP cancellation request has been validated. | ||
OFP MUST: 2.10 Send an appropriate error response to the TPPs in case the RTP Cancellation request is rejected due to violating any of the LFIs BAU payment accounts checks for RTPs. 2.11 Provide the TPP with the outcome fo the RTP Cancellation request. | ||
RTPCAN-3 | Confirmation to User | TPPs MUST: 3.1 Confirm the outcome of the RTP cancellation request to Users using confirmation screens inline with the customer journey, for every RTP cancellation request that Users initiate. |
RTPCAN-4 | RTP Notifications | LFIs MUST: 4.1 Send notifications to Users for any RTPs status updates via their existing channels (BAU). |
8. RTP Common Rules & Guidelines
8.1 RTP Payer (Recipient of RTP) Info
TTPs MUST:
8.1.1 Provide a message to Users clearly stating that:
The Payer (RTP Recipient) will not be specified as part of the RTP Consent and instead will be defined during the RTP initiation.
The Payer (RTP Recipient) will be confirmed when specified before the actual RTP initiation takes place
8.2 RTP Payment Reference
TPPs MUST:
8.2.1 Allow Users to manually enter an RTP Payment Reference or pre-populate it for the Users (depending on the use case). RTP Payment Reference is optional for Users. RTP Payment Reference may be populated by the User (i.e. the RTP Sender and actual Beneficiary of the RTP payment) using information requested by the Payer or any other information the User wants to provide to the Payer to assist in identifying and reconciling the payment request. This information will be transferred via the payment rails from the Users' LFI to the Payers' LFI and will be presented to the Payers.
Note: TPPs may make the RTP Payment Reference mandatory based on their specific use cases or business requirements (for example invoice payments).
8.2.2 Validate that the format of the RTP Payment Reference is according to the UAE Open Finance Standard specifications. The RTP Payment Reference length is limited to https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415296/Limits+and+Constants#Max-RTP-Payment-Reference-Length
8.2.3 Include the RTP Payment Reference in each RTP request message as the default value. The RTP Payment Reference will be used by the LFI to populate the Remittance Information of the RTP message sent to the Payer LFI.
8.3 RTP Consent Control Parameters
TPPs MUST:
8.3.1 Either allow Users to specify the below set of RTP Consent Control parameters or pre-populate them for the Users based on the specific use-case or their own business requirements:
The Maximum Payment Amount per each RTP request: This is the maximum payment amount an RTP related to the RTP Consent may request. All RTP payment amounts requested MUST be smaller or equal to this value. This is limited to https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415296/Limits+and+Constants#Max-RTP-Payment-Amount.
The Maximum Cumulative Number of all RTP requests for the entire RTP Consent validity period. Every RTP request related to the RTP Consent that is successfully initiated is added to the Total Cumulative Number of RTP requests of the RTP Consent which cannot exceed the Maximum Cumulative Number agreed with the User at the point of Consent. Any additional RTP request resulting to the Total Cumulative Number of RTP requests exceeding the Maximum MUST be rejected by the TPP and the LFI. This is limited to https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415296/Limits+and+Constants#Max-RTP-Consent-Cumulative-Requests.
The Maximum Cumulative Value of all RTP requests for the entire RTP Consent validity period. Every RTP payment amount related to the RTP Consent that is successfully received in the User’s payment account is added to the Total Cumulative Value of the RTP Consent which cannot exceed the Maximum Cumulative Value agreed with the User at the point of Consent. Any additional RTP payment amount resulting to a Total Cumulative Value exceeding the Maximum MUST be rejected by the TPP and the LFI. This is limited to https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415296/Limits+and+Constants#Max-RTP-Consent-Cumulative-Value.
The RTP Consent Control Period Type & Start Date (as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109414866/Request+to+Pay#8.4-RTP-Consent-Control-Period-%26-Start-Date).
The Maximum Cumulative Number of RTP requests RTP Consent Control Period. During each repeating RTP Consent Control Period, the Total Cumulative Number of all RTP requests MUST NOT exceed the Maximum Cumulative Number agreed by the User during the RTP Consent. The Total Cumulative Number of RTP requests is reset on every new Consent Control Period. This is limited to https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415296/Limits+and+Constants#Max-RTP-Cumulative-Requests-per-Control-Period.
The Maximum Cumulative Value of all RTP requests per RTP Consent Control Period. During each repeating RTP Consent Control Period, the Total Cumulative Value of all RTP payment amounts successfully received in the User’s payment account MUST NOT exceed the Maximum Cumulative Value agreed by the User during the RTP Consent. The Total Cumulative Value is reset on every new RTP Consent Control Period. This is limited to https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415296/Limits+and+Constants#Max-RTP-Cumulative-Value-per-Control-Period.
8.4 RTP Consent Control Period & Start Date
TTPs MUST:
8.4 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:
Control Period: This is a rolling Period as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109413991/Multi-Payments#8.2.2-Period-Type-%26-Start-Date. During each rolling Period specific Consent Control limits are applied. The rolling Control Period may occur one or more times during the long-lived RTP Consent duration depending on the Period Type and the Control Period Start Date. For example, for an RTP Consent of expiry after 30 days, a Consent Control Period of 1 Day may be repeating up to 30 times, depending on the Period Start Date. Similarly, for an RTP Consent of expiry after 1 year a Control Period of 1 Week may be repeating up to 52 times depending on the Period Start Date.
Control Period Start Date: This is the first date of the rolling Control Period, as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109413991/Multi-Payments#8.2.2-Period-Type-%26-Start-Date. The Control Period Start Date is optional and if not set by TPPs, the OFP MUST align the starting point of the Control Period to the Consent creation Date. The Control Period Start Date, if specified, MUST take values of dates in the future. This capability allows Users to select a day in the future when they want to start sending RTP requests instead of from the RTP Consent creation date. This date MUST less than the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109414866/Request+to+Pay#8.5-RTP-Consent-Expiration.
8.5 RTP Consent Expiration
TTPs MUST:
8.5.1 Either allow Users to manually enter/select the period of the RTP Consent during which RTP requests can be initiated OR pre-populate it for the Users based on the specific use case.
8.5.2 NOT specify the time of the day for RTP requests to be initiated. These RTP requests can take place at any point in time during the RTP Consent period subject to the RTP Consent Control Parameters.
8.5.3 Set the RTP Consent Expiration Date & Time to the end of day (23:59:59) of the last day of the consent period as set per 4.5.1. The RTP Consent validity period MUST be less or equal to https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415296/Limits+and+Constants#Max-Consent-Validity-Period.
8.6 RTP Validity Period
TTPs MUST:
8.6.1 Either allow Users to manually enter/select the window during which each RTP request is valid OR pre-populate it for the Users based on the specific use case. RTPs are only valid during this period. RTPs outside this window are expired and can no longer be processed. The RTP Validitiy Period is measured in hours and MUST be less than https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415296/Limits+and+Constants#Max-RTP-Validity-Period.
8.7 RTP Payer (Recipient of RTP) Identification
TPPs MUST:
8.7.1 Either allow Users to manually enter/select their RTP Payer Identification details or pre-populate them for the Users if available.
8.7.2 Allow the RTP Payer Identification using one of the following options:
8.7.2.1 RTP Payer identified by IBAN: In this case the information required for the RTP Payer is:
IBAN of the Payer
Name of the Payer
8.7.2.2 RTP Payer identified by domestic Account number: In this case the information required for the RTP Payer is:
Account number (domestic) of the Payer. This is the 12 or 14 digits domestic account number of the RTP Payer with their LFI.
Name of the Payer.
The RTP Payer account holding entity. TPPs MUST enable Users to identify the holding entity using its trading name which is familiar to Users. The trading name MUST correspond to a valid IBAN Bank Code.
8.7.2.3 RTP Payer identified by Alias: In this case the information required for the RTP Payer is:
Alias of the Payer. The acceptable Aliases for the Payer are the following:
Mobile phone number
Email
Any other proxy available in UAE
The RTP Payer account holding entity. TPPs MUST enable Users to identify the holding entity using their trading name which is familiar to Users. The trading name MUST correspond to a valid IBAN Bank Code.
8.7.3 Ensure that the format and other validation rules of the RTP Payer Identification details are correct in case Users manually enter the RTP Payer Identification details. If incorrect, TPPs MUST request Users to review and re-enter the information.
8.8 RTP Status
For each RTP request, there are multiple statuses as described below:
RTP Status | Description | Aani Status Mapping |
|---|---|---|
Pending | The RTP request is pending. The RTP has been sent successfuly by the Payee LFI and it is sitting in a temporal state waiting to be processed by the Recipient (Payer). Further checks and status update will be performed. | “PND” (Request pending) |
Accepted | The RTP request has been accepted by the RTP Payer. Further checks and status update will be performed. | |
Paid | The RTP Payer has fulfilled and paid the RTP request. This is a terminal state. | “OK” (Request paid) |
Rejected | The RTP Payer has rejected (i.e. “refused to accept”) the RTP request. This is a terminal state. | “RIF” (Request rejected/refused by the recipient) |
Cancelled | The Payee has cancelld (i.e. “annulled”) the RTP request before being accepted or rejected by the RTP Payer. This is a terminal state. | “ANN” (Request canceled/annulled by the RTP sender, who has decided to annul it before |
Expired | The RTP request has expired due to no action from the RTP Payer during the validity period (i.e. the RTP Payer has not accepted, paid or rejected it within the validity period). This is a terminal state. | “SCD” (Request expired due to time out); |
Failed | The RTP request has failed due to error either on the Sender’s (Payer’s) LFI or the RTP Payer’s receiving LFI. This is a terminal state. | |
Not Submitted | The Payee cancels the RTP request before this is submitted to the RTP Payer’s LFI. This is a terminal state. |