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 Pay Request (PR). This funtionality enables TPPs to initiate Payment Requests (PRs) payment requests from a Sender (Payee) to a Recipient (Payer) business or a person. The Payment Pay 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 Pay Request is accepted by the Recipient (Payer). The Payment Pay Request is then fullfiled using the existing Bank Service Initiaiton functionality defined in the Open Finance Standard.
...
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
Note: Payment Pay 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 Pay Requests. |
1.1 Payer and Payee Segments
The scope of the Payment Pay Request functionality related to the segments of payers and payees is shown below:
...
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
...
Pay Request (PR) - Example User Story
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
User StoryAs a User (Consumer, Business or Corporate), I want to have the ability to send a Payment Request 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. |
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
Note: It is in the competitive space of TPPs to innovate further supporting services, in addition to these guidelines. For example:
|
2. Example Process Flow
The below diagram depicts the process flow from initiating a Payment Pay Request to fullfilment with a payment via an Open Finance Standard Payment Initiation.
...
3. Example Rules & Guidelines
# | Step | Rules & Guidelines | |||||
|---|---|---|---|---|---|---|---|
PR-1 | 1. Payment Pay Request Start | TPPs | COULD: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
| RTP Consent Expiration Date & Time (as per MAY: 1.1 Allow Users, after starting the TPP application, to select the option to send a Pay Request. | ||
PR-2 | Check User Onboarded | TPPs MAY: 2.1 Check if the User is already onboarded or not:
| |||||
PR-3 | Get User Account Details | TPPs MAY: 3.1 Allow Users to provide their payment account details to be used for receiving the Pay Request funds when paid by the recipients. These may be one of the following options:
| |||||
PR-4 | Check User is Business | TPPs MAY: 4.1 Check if the User is a business or not:
| |||||
PR-5 | Request Confirmation of Payee (COP) | TPPs MAY: 5.1 Invoke the Confirmation of Payee service provided by Open Finance as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109413626/Single+Instant+Payment#3.3-Using-Confirmation-of-Payee-(COP) in order to validate the User’s Name against the payment account provided. | |||||
PR-6 | Check COP Response | TPPs MAY: 6.1 Check if the Response from the COP Service:
| |||||
PR-7 | Apply Busines onboarding process (KYB) | TPPs MAY: 7.1 Apply the KYB processes for onboarding businesses. As part of this, TPPs should validate the business name and the payment account as defined in https://openfinanceuae.atlassian.net/wiki/spaces/ | standardsv1draft5109414866 | Request | to+Pay#8.5-RTP-Consent-Expiration) | 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
the Payer has accepted or refused it).
...
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.
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
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.
|
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:
User Payment Account or User LFI (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#2.-User-Payment-Account-Selection). This is the account of the Sender of the RTP (Creditor account) which will be used to receive the RTP payment.
Information about the RTP Payer (Recipient of the RTP) as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109414866/Request+to+Pay#8.1-RTP-Payer-(Recipient-of-RTP)-Info)
RTP Payment Reference (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109414866/Request+to+Pay#8.2-RTP-Payment-Reference)
Purpose of RTP Payment (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#21.-Purpose-of-Payment)
...
RTP Consent Control Parameters
RTP Consent Controls applicable (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109414866/Request+to+Pay#8.3-RTP-Consent-Control-Parameters)
Maximum Payment Amount per each RTP request
Maximum Cumulative Number of all RTP requests for the entire RTP Consent validity period.
Maximum Cumulative Value of all RTP requests for the entire RTP Consent validity period.
Maximum Cumulative Value of all RTP requests per RTP Consent Control Period.
Maximum Cumulative Number of RTP requests RTP Consent Control Period.
RTP Consent Control Period & Start Date (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109414866/Request+to+Pay#8.4-RTP-Consent-Control-Period-%26-Start-Date)
...
RTP Consent Expiration Date & Time (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109414866/Request+to+Pay#8.5-RTP-Consent-Expiration)
...
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
As per https://openfinanceuae.atlassian.net/wiki/x/HoBBAw
...
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:
User Payment Account
Purpose of RTP Payment
RTP Payment Reference
RTP Consent Control Parameters including:
Maximum Payment Amount per each RTP request
Maximum Cumulative Number of all RTP requests for the entire RTP Consent validity period.
Maximum Cumulative Value of all RTP requests for the entire RTP Consent validity period.
Maximum Cumulative Value of all RTP requests per RTP Consent Control Period.
Maximum Cumulative Number of RTP requests RTP Consent Control Period.
RTP Consent Control Period & Start Date
RTP Consent Expiration Date & Time
Fees & VAT (if applicable): These are potential charges that will be applied to the User account for making an RTP request in relation to the long-lived RTP Consent. Both bank charges and VAT MUST be presented, stated separately, prior to the User Consent authorization. If applicable, LFIs MUST apply the charges on the date of each RTP request and not at the point of the RTP Consent authorization.
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:
...
| panelIconId | 2734 |
|---|---|
| panelIcon | :eight_pointed_black_star: |
| panelIconText | ✴️ |
| bgColor | #B3F5FF |
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:
...
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:
Payment Amount & Currency (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#3.-Payment-Amount-%26-Currency)
RTP Payer (Recipient of the RTP) Identification details (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109414866/Request+to+Pay#8.7-RTP-Payer-(Recipient-of-RTP)-Identification)
RTP Payment Reference as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109414866/Request+to+Pay#8.2-RTP-Payment-Reference (Optional)
Purpose of RTP Payment (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#21.-Purpose-of-Payment)
...
Additional Parameters
RTP Validity Period (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109414866/Request+to+Pay#8.6-RTP-Validity-Period)
...
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:
The date of the submitted RTP request is within the validity period of the long-lived RTP Consent (i.e. Consent Expiration Date & Time)
The amount in the submitted RTP request request is less or equal to the Maximum Payment Amount per each RTP request.
2.4 Check the RTP request parameters against the authorized long-lived RTP Consent. More specifically, the OFP MUST check the following:
The cumulative Total Value of all RTP payments successfully received, including the amount of the submitted RTP request is less or equal to the Maximum Cumulative Value of all RTP requests for the entire RTP Consent validity period defined in the authorized long-lived RTP Consent.
The cumulative Total Number of all RTP requests, including the submitted RTP request is less or equal to the Maximum Cumulative Number of all RTP requests for the entire RTP Consent validity period, defined in the authorized long-lived RTP Consent.
The cumulative Total Value of all RTP payments successfully received during the RTP Consent Control Period, including the amount of the submitted RTP request, is less or equal to the per Maximum Cumulative Value of all RTP requests per RTP Consent Control Period, as defined in the authorized long-lived RTP Consent.
The cumulative Total Number of all RTP requests during the RTP Consent Control Period, including the submitted RTP request, is less or equal to the Maximum Cumulative Number of RTP requests RTP Consent Control Period, as defined in the authorized long-lived RTP Consent.
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:
User Payment Account (or account identifier) (Creditor account to receive the RTP payment)
Payment Amount & Currency
RTP Payer (Recipient of the RTP) Identification details
RTP Payment Reference
Purpose of RTP Payment
RTP Validity Period
...
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.14.1 Include in the RTP response to the OFP the IBAN of the RTP Payer identification returned by the Proxy resolution.
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:
RTP request unique identifier
User Payment Account (Creditor account to receive the RTP payment)
Payment Amount & Currency
RTP Payer (Recipient of the RTP) Identification details
RTP Payment Reference
Purpose of RTP Payment
RTP Validity Period
...
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).
1.2.1 Setup the asynchronous event notifications (i.e. webhooks) with the OFP during RTP Consent Staging step as defined inhttps://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#10.-Consent-Staging in case they want to use this method for status updates.
...
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
...
#
...
Step
...
Rules
...
RTPCU-1
...
RTP Consent Update
...
TPPs MUST:
1.1 Enable Users to use the Consent Dashboard to amend the following parameters of a long-lived RTP Consent:
User Payment Account (Creditor Account) (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#2.-User-Payment-Account-Selection).
RTP Payment Reference (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109414866/Request+to+Pay#8.2-RTP-Payment-Reference)
Purpose of RTP Payment (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109415230/Common+Rules+and+Guidelines#21.-Purpose-of-Payment)
RTP Consent Controls applicable (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109414866/Request+to+Pay#8.3-RTP-Consent-Control-Parameters)
RTP Consent Control Period & Start Date (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109414866/Request+to+Pay#8.4-RTP-Consent-Control-Period-%26-Start-Date)
RTP Consent Expiration Date & Time (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109414866/Request+to+Pay#8.5-RTP-Consent-Expiration)
1.2 Require the Users to authenticate with their LFI and authorize the RTP Consent update.
| Info |
|---|
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.2.1 Respond to the TPP with the failure message, if the RTP cancellation request fails.
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
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
TTPs MUST: 8.1.1 Provide a message to Users clearly stating that:
|
8.2 RTP Payment Reference
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
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
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
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:
|
8.4 RTP Consent Control Period & Start Date
...
| panelIconId | 068fdde3-c1f6-4759-9967-8a80e7ba7356 |
|---|---|
| panelIcon | :rock: |
| panelIconText | :rock: |
| bgColor | #DEEBFF |
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.
...
Rules+and+Guidelines#9.3.1-Details-Verification-for-Merchants-onboarded-by-TPPs. | ||
PR-8 | Get Pay Request Recipient(s) | TPPs MAY: 8.1 Allow Users to select Recipient(s) of the Pay Request by providing email, mobile phone number or any other user identification to be used for sending the Pay Request message to them. |
PR-9 | Get Pay Request details | TPPs MAY: 9.1 Allow Users to provide the Pay Request details or pre-popullate the details depending on the use case. The details required are:
|
PR-10 | Generate Pay Request Info | TPPs MAY: 10.1 Generate an actionable link that will be used to direct the Recipient (Payer) to the information about the Pay Request. |
PR-11 | Set Pay Request state to Pending | TPPs MAY: 11.1 Keep track of the state of each Pay Request Message throughout its lifecycle. When the Pay Request message is initiated, TPPs should set its state to Pending. |
PR-12 | Get method to send Pay Request | TPPs MAY: 12.1 Allow Users to select the method they want to use for sending the Pay Request message to the Recipient (Payer). This may include any standard methods available by Users devices for forwarding/sharing of information, including email, sms, messaging applications etc. Altenatively, if the Recipient (Payer) is also a user of the TPP application, TPPs may use their backend systems to forward the Pay Request message information to Recipients (Users). |
PR-13 | Foward Pay Request | TPPs MAY: 13.1 Altenatively to step 12, if the Recipient (Payer) is also a user of the TPP application, TPPs may use their backend systems to forward the Pay Request message information to Recipients (Users). |
PR-14 | Receive Pay Request link | Recipients (Users) MAY: 14.1 Receive the Pay Request message including the actionable link using the forwarding/sharing method selected by the Sender (User). Altenatively, Recipient (Payers) may receive a notification of a pending Pay Request message from the TPP directly, if they are also onboarded users of the TPP application. |
PR-15 | Open Pay Request (Y/N) | Recipients (Payers) MAY: 15.1 Decide to do the following:
|
PR-16 | Check Request Validity Period when no action | TPPs MAY: 16.1 Monitor the elapsed time from when the Pay Request message was sent to the Recipient (Payers) against the Validity Period.
|
PR-17 | Pay Request Expired | TPPs MAY: 17.1 Set the Pay Request state to Expired. 17.2 Send a notification to the Sender (Payee) that the Pay Request has expired and can no longer be actioned. |
PR-18 | Check Request Validity Period when Request Opened | TPPs MAY: 18.1 Monitor the elapsed time from when the Pay Request message was sent to the Recipient (Payers) against the Validity Period.
|
PR-19 | Display Pay Request to Recipient | TPPs MAY: 19.1 Display the details of Pay Request to the Recipients (Payers). This information includes:
|
PR-20 | Get Accept/Reject of Pay Request | TPPs MAY: 20.1 Allow Recipients (Payers) to either Accept or Reject the Pay Request.
|
PR-21 | Pay Request Rejected | TPPs MAY: 21.1 Set the Pay Request state to Rejected. 21.2 Send a notification to the Sender (Payee) that the Pay Request has been rejected by the Recipient (Payer) and that no payment will be received. |
PR-22 | Get LFI selection for Payment Initiation | Recipients (Payers) Accept the Pay Request TPPs MAY: 22.1 Allow Users to selects the LFI they want to use for Payment Initiation. |
PR-23 | Single Instant Payment Consent | TPPs MUST: 23.1 Allow Users to Initiate a Single Instant Payment as per the https://openfinanceuae.atlassian.net/wiki/spaces/ |
...
...
...
...
...
...
...
8.5 RTP Consent Expiration
...
| panelIconId | 068fdde3-c1f6-4759-9967-8a80e7ba7356 |
|---|---|
| panelIcon | :rock: |
| panelIconText | :rock: |
| bgColor | #DEEBFF |
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.
...
Standard-Journey of the Open Finance Standard, pre-populating the following information:
| ||
PR-24 | Acquire User Consent for Single Instant Payment Initiation | TPPs MUST: 24.1 Enable Users to provide explicit consent for the initiation of a SIP payment order from their online payment account held at their LFI as per the payment details specified in the payment Consent, as the as per the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1rc1/pages/121374011/Single+Instant+Payment#3.1-Standard-Journey of the Open Finance Standard.
|
PR-25 | Proceed with Payment Initiation Journey | TPPs MUST: 25.1 Proceed with the Single Instant Payment Initiation journey as per the https://openfinanceuae.atlassian.net/wiki/spaces/ |
...
...
...
...
8.6 RTP Validity Period
...
| panelIconId | 068fdde3-c1f6-4759-9967-8a80e7ba7356 |
|---|---|
| panelIcon | :rock: |
| panelIconText | :rock: |
| bgColor | #DEEBFF |
TTPs MUST:
...
Instant+Payment#3.1-Standard-Journey of the Open Finance Standard. | ||
PR-26 | Check Single Payment Consent Authorized (Y/N) | TPPs MAY: 26.1 Check the status of the Single Instant Payment consent, as per the https://openfinanceuae.atlassian.net/wiki/spaces/ |
...
...
8.7 RTP Payer (Recipient of RTP) Identification
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
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.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
...
/121372984/Consent+Setup#4.-Consent-States of the Open Finance Standard.
| ||
PR-27 | Pay Request Accepted | TPPs MAY: 27.1 Set the Pay Request state to Accepted. 27.2 Send a notification to the Sender (Payee) that the Pay Request has been rejected by the Recipient (Payer) and that no payment will be received. |
PR-28 | Check Payment Status | TPPs MAY: 28.1 Check the status of the Single Instant Payment Initiation, as per the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1rc1/pages/121375612/Common+Rules+and+Guidelines#15.-Payment-Status-Update of the Open Finance Standard.
|
PR-29 | Pay Request Failed | TPPs MAY: 29.1 Set the Pay Request state to Failed. 29.2 Send a notification to the Sender (Payee) that the Pay Request has Failed and the payment will not be received at the Recipient’s payment account, even if the User has Accepted the Pay Request. |
PR-30 | Pay Request Paid | TPPs MAY: 30.1 Set the Pay Request state to Paid. 30.2 Send a notification to the Sender (Payee) that the Pay Request has been Paid to the Recipient’s payment account. |
4. Example Pay Request Status
For each Pay Request, there are multiple statuses as described below:
RTP Status | Description |
|---|
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
the Payer has accepted or refused it).
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
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. |
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. |
Rejected | The RTP Payer has rejected (i.e. “refused to accept”) the RTP request. This is a terminal state. |
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. |
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. |
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. |
5. Example Pay Request Cancelation Process
# | Step | Rules |
|---|---|---|
PRCAN-1 | Pay Request Cancellation | TPPs MAY: 1.1 Enable Users to cancel an active Pay Request before it is actioned (accepted or rejected) by the Recipient (Payer). 1.2 Request Users to authenticate within their application using Multi Factor-Authentication (MFA) before allowing them to cancel an active Pay Request. |
PRCAN-2 | Pay Request Cancelled | TPPs MAY: 2.1 Set the Pay Request state to Cancelled.
2.2 Enable Users to send a cancellation message for the Pay Request to the Recipient (Payer). This may include any standard methods available by Users' devices for forwarding/sharing of information, including email, sms, messaging applications etc.
2.3 Altenatively, if the Recipient (Payer) is also a user of the TPP application, TPPs may use their backend systems to forward the cancellation message of the Pay Request to Recipients (Users). 2.4 Confirm the User that the Pay Request has been cancelled and can no longer be actioned by the Recipients (Payers). |