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 Pay Request (PR). This funtionality enables TPPs to initiate payment requests from a Sender (Payee) to a Recipient (Payer) business or a person. The 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 Pay Request is accepted by the Recipient (Payer). The Pay 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: 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 Pay Requests.
1.1 Payer and Payee Segments
The scope of the Pay 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 Pay 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. Example Process Flow
The below diagram depicts the process flow from initiating a Pay Request to fullfilment with a payment via an Open Finance Standard Payment Initiation.
3. Example Rules & Guidelines
# | Step | Rules & Guidelines |
|---|---|---|
PR-1 | Pay Request Start | TPPs MAY: 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. Check if the User is already onboarded or not:
|
PR-3 | Get User Account Details | TPPs MAY: 3. 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. Check if the User is a business or not:
|
PR-5 | Request Confirmation of Payee (COP) | TPPs MAY:
|
PR-6 | Check COP Response | TPPs MAY: 6. Check if the Response from the COP Service:
|
PR-7 | Apply Busines onboarding process (KYB) | TPPs MAY:
|
PR-8 | Get Pay Request Recipient(s) | TPPs MAY:
|
PR-9 | Get Pay Request details | TPPs MAY:
|
PR-10 | Generate Pay Request Info | TPPs MAY:
|
PR-11 | Set Pay Request state to Pending | TPPs MAY:
|
PR-12 | Get method to send Pay Request | TPPs MAY:
|
PR-13 | Foward Pay Request | TPPs MAY:
|
PR-14 | Receive Pay Request link | Recipients (Users) MAY:
|
PR-15 | Open Pay Request (Y/N) | Recipients (Payers) MAY:
|
PR-16 | Check Request Validity Period when no action | TPPs MAY:
|
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:
|
PR-19 | Display Pay Request to Recipient | TPPs MAY:
|
PR-20 | Get Accept/Reject of Pay Request | TPPs MAY:
|
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:
|
PR-23 | Check long-lived consent exists | TPPs MAY: 23. Check if Recipient (Payer) has provided long-lived consent to the TPP for the selected LFI or not:
|
PR-24 | Single Instant Payment Consent | TPPs MUST:
|
PR-25 | Acquire User Consent for Single Instant Payment Initiation | TPPs MUST:
|
PR-26 | Proceed with Payment Initiation Journey | TPPs MUST:
|
PR-27 | Authentication with LFI | TPPs MUST:
|
PR-28 | Check Single Payment Consent Authorized (Y/N) | TPPs MAY:
|
PR-29 | Check long-lived consent selected | TPPs MAY: 29. Check if Recipient (Payer) has selected to use the existing long-lived consent provided to the TPP for the selected LFI or not:
|
PR-30 | Check Single Payment Authorized with TPP (Y/N) | TPPs MAY:
|
PR-31 | Proceed with Payment Initiation using Long-lived Consent | TPPs MUST:
|
PR-32 | Pay Request Accepted | TPPs MAY: 32.1 Set the Pay Request state to Accepted. 32.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-33 | Check Payment Status | TPPs MAY:
|
PR-34 | Pay Request Paid | TPPs MAY: 34.1 Set the Pay Request state to Paid. 34.2 Send a notification to the Sender (Payee) that the Pay Request has been Paid to the Recipient’s payment account. |
PR-35 | Pay Request Failed | TPPs MAY: 35.1 Set the Pay Request state to Failed. 35.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. |
4. Example Pay Request Status
For each Pay Request, there are multiple statuses as described below:
RTP Status | Description |
|---|---|
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). |