...
The following table summarizes the various available combinations, the naming conventions used and the scope of the IP Payments:
Domestic Same Currency | Foreign Different Currency | |
---|---|---|
Same Country | Domestic Payment (supported by SIP) | FX-Payment (not in scope) |
Different Country | International Payment (in scope) | International-FX Payment (in scope) |
...
# | Step | Rules & Guidelines |
---|---|---|
IP-1 | Single IP details collection | TPPs MUST: 1.1 Enable Users to provide the parameters related to the IP payment order they want to initiate. These parameters include:
|
International-FX & International Payments Only
| ||
IP-2 | FX Rate Request | International-FX Payments Only TPPs MUST: 2.1 Determine if FX conversion is required for the payment by checking the currency of the Users' payment account and the currency selected for the payment order. 2.2 Initiate a FX Rate Request to the OFP, if FX conversion is required for the payment order. TPPs MUST provide the following details to the OFP:
|
OFP MUST: 2.3 Check the FX Rate Request parameters and validate their format and compliance to the UAE Standard. OFP MUST reject the FX Rate Request and provide the appropriate error message to TPPs, if any of these validations performed fail. 2.4 Connect to the User’s LFI and request the LFI to provide a FX rate based on the following information:
| ||
LFIs MUST: 2.5 Use the information provided by the OFP to provide a FX rate for the transaction and prepare the FX rate response and charges.
2.6 Set the Indicative flag for the FX Rate Request, if LFIs cannot lock the exchange rate for a period of time. Alternatively, if LFIs have the capability, they MUST lock the FX rate for a period of time to allow Users to complete the transaction by going through the journey of providing their consent to the TPP and then authenticating and authorizing the payment Consent with the LFI. In this case, LFIs MUST start the timer and provide the remaining time period to the OFP and MUST set the Actual flag for the FX Rate Response. 2.7 Determine the charges for the International-FX Payment based on the information provided by the OFP, as follows:
2.8 Provide the OFP with all the FX Rate and charges information in relation to the FX Rate Request.
| ||
OFP MUST: 2.9 Return back to the TPP the FX Rate Response, as follows:
| ||
TPPs MUST: 2.10 Present all the information of the FX Rate to the User. 2.11 Provide the appropriate message to the User, if the FX Rate was based on an indicative FX rate. 2.12 Initiate the FX Rate Request process again for all FX Rate Responses with actual FX rate that their validation time has expired and the User has not provided a single IP payment Consent.
| ||
IP-3 | Single IP Consent | Basic Consent Parameters TPPs MUST: 3.1 Enable Users to review the parameters related to the IP they need to consent to. These parameters include:
|
International-FX & International Payments Only
| ||
International-FX Payments Only FX Rate
| ||
Additional Consent Parameters TPPs MUST: 3.2 Set the Accepted Authorization Type (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#7.-Accepted-Authorization-Type). 3.3 Set the Authorization Time Window (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#8.-Authorization-Time-Window) if there are specific timing requirements that must be met for the consent authorization. This is also relevant to cases where multiple authorizers are required to authorize the payment consent (Please refer to https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#18.-Multi-User-Authorization-Flow).
3.4 Set the Risk Information Block (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#9.-Risk-Information-Block) | ||
TPPs MUST: 3.5 Enable Users to provide explicit consent for the initiation of a single IP payment order from their online payment account held at their LFI as per the payment details specified in the payment Consent. | ||
IP-4 | Consent Staging | |
IP-5 | Hand-off to LFI | Example wording to use: ‘We will securely transfer to YOUR LFI to authenticate and make the payment“. |
IP-6 | Authentication | LFI Authentication Only LFIs MUST: 6.1 Enable Users to perform authentication with their LFIs, as per the following sections:
6.2 Re-direct Users back to the TPPs, with information that the Consent has not been authorized, if User Authentication has failed or Users opted to cancel the authentication/authorization process. |
Centralized Authentication and Authorization (Federated) Only 6.3 As per https://openfinanceuae.atlassian.net/wiki/x/HoBBAw | ||
IP-7 | Confirmation/ Authorization | Standard Journey LFIs MUST: 7.1 Enable Users to authenticate using Multi-Factor Authentication (MFA) in order to review and authorize the single IP Consent. 7.2 Retrieve from the OFP the single IP Consent details staged by the TPP using the unique Consent Identifier and present to Users all the details included in this. 7.3 Allow Users to select a payment account for the initiation of the single IP, if this was not provided in the retrieved staged payment Consent details, as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#12.-Payment-Account-Selection-at-LFI
7.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/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#13.-Check-Accepted-Authorization-Type |
7.6 Present to Users the following minimum required information for authorizing the single IP payment Consent:
7.7 Initiate the FX Rate Request process again if the FX Rate was Indicative or the remaining time for an Actual FX Rate has expired.
7.8 Request Users to authorize the single IP payment Consent, so that a single IP payment can be initiated. 7.9 Provide Users the ability to abort the payment journey, if Users decided to terminate the request. The LFI MUST hand-off the Users back to the TPP, providing the necessary error message to the OFP and reject the single IP payment Consent. 7.10 Check the Authorization Time window is valid as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#20.-Check-Authorization-Time-Window. 7.11 Change the state of the single IP payment Consent from Awaiting Authorization to Authorized, when all Authorizers (one or more) have authorized the payment Consent. 7.12 Update the single IP payment Consent details stored in the OFP with all the information included in the single IP payment Consent authorized by the User. | ||
OFP MUST: 7.13 Confirm back to the LFIs that the single IP payment Consent details have been updated successfully. | ||
Multi-Authorization Journey Only | ||
IP-8 | Payment Initiation | LFIs MUST: 8.1 Trigger the payment initiation process for the payment Consent immediately after the single IP Consent has been fully authorized by all required authorizers (one or more). 8.2 Additionally apply all existing BAU payment account controls and limits such as single transaction value limit, total transaction value limit, AML checking (if applicable) and others, as if the payment request has been initiated by the existing channels of the LFI. LFIs MUST send an appropriate error response to the OFP in case the payment is rejected due to violating any of these limits. 8.3 Reject the payment initiation if the payment account selected for the payment has insufficient funds. The OFP MUST be notified about this rejection with an appropriate error message. 8.4 Subject to successful BAU checking, validation and payment processing, proceed with the execution of the payment by either submitting the payment to the underlying payment rails or executing internally as Intra-bank payment. 8.5 Provide the OFP with all the available information in relation to the initiated payment instruction including the payment’s unique identifier Payment Transaction ID. The format of the Payment Transaction ID can be found in the UAE Open Finance Standard specifications. 8.6 Ensure that the Payment Reference provided in the single IP Consent is made available to the Beneficiary’s account information in the case of Intra-bank payments within the same LFI. |
OFP MUST: 8.7 Return back to the TPP in the single IP Consent response the IBAN of the Payee identification returned by the Proxy resolution, if the single IP Consent was submitted for User Authorization using a Proxy as the Payee Identification. 8.8 Send an appropriate error response to the TPPs in case the payment is rejected due to violating any of the LFIs' BAU payment accounts checks or limits. 8.9 Send to the TPP the appropriate error message in case the payment initiation was rejected by the LFI due to insufficient funds in the selected payment account. 8.10 Provide the TPP with all the available information in relation to the initiated single IP instruction including the payment’s unique identifier Payment Transaction ID. | ||
IP-9 | Payment Status Update | |
IP-10 | Hand-off back to the TPP | |
IP-11 | Confirmation to User | |
IP-12 | Payment Notifications |
...
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
TPPs MUST: 4.2.1 Either allow Users to manually enter the payment currency or pre-populate it for the Users, depending on the use case.
4.2.2 Either allow Users to manually enter the payment amount or pre-populate it for the Users. This is dependent on the use case.
Note: The payment amount in the currency specified before any FX conversion will be the actual consented amount for the IP/FXP payment Consent. This is because the FX rate provided by the FX Quote Rate Request cannot be guaranteed that will not change before the User provides authorization of the payment Consent at the LFI. 4.2.3 Ensure that Users clearly understand the currency of the payment amount. This would be as follows:
4.2.4 Ensure and validate that the payment amount MUST be specified with max 2 decimal digits, if required. 4.2.5 Ensure that the maximum allowable amount is equal to https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528887/Limits+and+Constants#Max-Inter-bank-IP%2FFXP-Payment-Amountfor any payments to payee accounts managed by a different account holding entity than the User’s LFI.
4.2.6 Display a message to Users informing them that the payment amount cannot exceed the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528887/Limits+and+Constants#Max-Inter-bank-IP%2FFXP-Payment-Amount value for all Inter-bank payments. |
...
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
LFIs MUST: 4.6.1 Provide a message to the User that the displayed FX rate is indicative and that the actual rate that will be used for the Future Dated IP /FXP Payment or each of their Fixed Recurring IP payments will be the spot rate on the date of each of the payment initiation, if the FX Rate was Indicative type. 4.6.2 Provide to the User the details of the forward FX rate agreement (e.g. future contract) and request User to consent to the T&Cs of the agreement, if required, before payment Consent authorization, if the FX was Forward type. LFIs MUST also display to the User the date that the Forward FX rate is valid. |