This space is deprecated and no longer supported. Please use the latest available version here.
International Payments
- Alexandros Dimitrakoudis
1. Description
This bank service request enables TPPs to initiate one or more International (i.e. cross-border) Payments (IPs) with the Users' consent, from the Users' online payment accounts held at the LFI to a business or a personal beneficiary including the user’s own accounts. After initiation, TPPs are able to check and retrieve the status of the submitted payment order.
The IPs functionality scope is targeted to:
domestic payer accounts (i.e. payer accounts offered by LFIs located in UAE) of local currency or foreign currency
initiating payments in same or different currency than the currency of the payer’s account with the LFI
and payee accounts being cross-border (i..e located outside of UAE) only
The following table summarizes the various available combinations, the naming conventions used and the scope of the IP Payments:
| Same Currency | 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) |
Note: FX-Payments, International Payments and International-FX payments are all cross-border international payments. However, the above naming conventions are used to simplify the context of this page.
This functionality requires a Single Use Consent or a Long-lived Consent of type Single International/FX Payment Consent.
1.1 Payer and Payee Segments
The scope of the IP Payments bank service initiation related to the segments of payers and payees is shown below:
Payer | Payee | ||||
|---|---|---|---|---|---|
Consumers | SME | Corporates | Consumers | SME | Corporates |
2. International Payments - FX & Payment Execution by User’s LFI
2.1 Example User Story - International-FX Payment
User Story
As a User (Consumer, Business or Corporate),
I want to provide my consent to a TPP to use my payment account for initiating a single International Payment of a fixed amount and of different currency to a cross-border beneficiary account owned by a business or an individual,
so that I can pay the relevant beneficiary immediately.
2.2 User Journey
By providing their consent to TPPs, Users can initiate an IP payment order to their LFIs for making a one-off single payment of a specific amount to an international payee.
The above User Journey is applied in cases where:
a) the payment order submitted by TPPs to LFIs is incomplete, such as where the Users' account selection has not yet occurred. In these scenarios, the UAE Open Finance Standard considers that MFA only needs to be obtained once, as part of the initial interaction between LFIs and the Users. The fact that Users have to then carry out account selection or provide other information does not invalidate the MFA just performed by the LFI. Equally, the display of the account balance by the LFI as part of the account selection process in the payment initiation journey SHOULD not require an additional application of MFA. The application of MFA is a matter for individual LFIs.
b) the payment order submitted by TPPs to LFIs has all the required information for the payment, including the FX cross-border processing options and LFI charges, but, an additional step in the LFIs' journeys may be required to display supplementary information to Users. LFIs MUST determine the situations where and what supplementary information is required, under the consideration that the principle of maintaining parity between the Open Finance journeys and LFIs' online channel journeys MUST be applied. LFI’s MUST also ensure that this information does not constitute an obstacle or additional check on the Consent provided by the User to the TPP.
2.3 Wireframes
2.3.1 International-FX Payment
2.4 Rules & Guidelines
# | 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 Common Rules and Guidelines | 7. Accepted Authorization Type). 3.3 Set the Authorization Time Window (as per 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 Common Rules and Guidelines | 18. Multi User Authorization Flow).
3.4 Set the Risk Information Block (as per 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 | As per Common Rules and Guidelines | 11. 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 |
3. Long-lived International Payment Consents
Long-lived multi-payment consents can be combined with International Payments to enable Service Initiation capabilities for recurring cross-border payments. The initial scope of the Standard will supporting Fixed Recurring IP Payments as follows:
Fixed Payment Amount: This can either be in account currency or payment currency, if FX is involved in the payment
Recurring Schedule: Fixed periodic payment schedule as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528328/Multi-Payments#6.2.1-Periodic-Payment-Schedule
Initiated from a User’s payment account with the LFI of local or foreign currency
To a specific Payee (Beneficiary) owning a payment account located abroad (cross-border)
3.1 User Journey
3.2 Wireframes
3.2.1 Consent Setup
# | Step | Rules & Guidelines |
|---|---|---|
FRIP-1 | Fixed Recurring IP Payment details collection | TPPs MUST: 1.1 Enable Users to provide the parameters related to the Fixed Recurring IP payment order they want to initiate. These parameters include:
|
International-FX & International Payments Only
| ||
Fixed Recurring IP Payment (IP-FRPs) Consent
| ||
FRIP-2 | FX Rate Request | International-FX & FX Payments Only As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/58621958/International+Payments#FX-Rate-Request in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/58621958/International+Payments#2.4-Rules-%26-Guidelines subject to the following: LFIs MUST: 2.1 Set the FX Rate Flag to Forward if they have the capability to lock the FX rate for all the IP recurring payments during the Recurring Payment Schedule. In this case, LFIs MUST not return any timer value with the FX Rate. Instead, LFIs MUST return the date that the Forward FX rate is valid.
2.2 Provide an indicative FX rate in the FX Rate Response if they cannot forward lock the FX rate for the full duration of the Payment Schedule. |
FRIP-3 | Fixed Recurring IP Payment 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 & FX Payments Only FX Rate
TPPs MUST: 3.2 Provide a message to the User that the details of this FX rate agreement will be provided by their LFIs before payment Consent authorization, if the FX Rate flag is Forward 3.3. Provide a message to the User that this FX rate is indicative and that the actual rate that will be used for 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 is Indicative.
| ||
Additional Consent Parameters 3.4 Set the Accepted Authorization Type (as per Common Rules and Guidelines | 7. Accepted Authorization Type). 3.5 Set the Authorization Time Window (as per 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.
3.6 Set the Risk Information Block (as per Common Rules and Guidelines | 9. Risk Information Block) | ||
3.7 Enable Users to provide explicit consent for the initiation of a series of Future Recurring IP payments of fixed amounts based on a fixed periodic schedule from their online payment account held at their LFI as per the payment parameters specified in the consent. | ||
FRIP-4 | Consent Staging | |
FRIP-5 | Hand-off to LFI | As per Common Rules and Guidelines | 11. Hand off to LFI Example wording to use: ‘We will securely transfer to YOUR LFI to authenticate and authorize your payments setup“. |
FRIP-6 | Authentication | As per the following sections: |
FRIP-7 | Confirmation/ Authorization | LFIs MUST: 5.1 Enable Users to authenticate using Multi-Factor Authentication (MFA) in order to review and authorize the long-lived payment Consent. 5.2 Retrieve from the OFP the payment Consent details staged by the TPP using the unique Consent Identifier. 5.3 Allow Users to select a payment account for the initiation of the multi-payments, 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
5.4 Only present additional screens, if necessary to allow the validation and confirmation of the payment Consent (e.g., Beneficiary adding & activation and Proxy lookup). 5.5 NOT earmark (i.e. block) any funds related to the payment Consent in the Users' payment account at the point of Consent authorization. 5.6 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. 5.7 Add to the payment Consent the IBAN of the Payee returned by the Proxy resolution process, if the multi-payments Consent was submitted for User Authorization using a Proxy as the Payee Identification. The Consent is thereafter tied to the IBAN of the Payee rather than the proxy itself. This will allow the future multi-payments to be initiated to this IBAN even if the Payee changes the proxy between the time of the Consent and the initiation of multi-payments as part of that Consent.
5.8 Present to Users the following minimum required information for authorizing the long-lived payments Consent:
5.9 Check the Authorization Time window is valid as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#20.-Check-Authorization-Time-Window 5.10 Change the state of the payment Consent from Awaiting Authorization to Authorized when all Authorizers (one or more) have authorized the payment Consent. 5.11 Update the payment Consent details stored in the OFP with all the information included in the payment Consent authorized by the User. |
| LFIs MUST: 7.1 Enable Users to authenticate using Multi-Factor Authentication (MFA) in order to review and authorize the long-lived Fixed Recurring IP Consent. 7.2 Retrieve from the OFP the Fixed Recurring 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 Fixed Recurring IP payments, 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 Only present additional screens, if necessary to allow the validation and confirmation of the payment Consent (e.g., Beneficiary adding & activation and Proxy lookup). 7.5 NOT earmark (i.e. block) any funds related to the payment Consent in the Users' payment account at the point of Consent authorization. 7.6 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 | |
| International-FX & FX-Payments Only FX Rate 7.8 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 before payment Consent authorization, if the FX Rate was Forward type.
7.9. Provide a message to the User that the displayed FX rate is indicative and that the actual rate that will be used for 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. | |
| 7.10 Present to Users the following minimum required information for authorizing the long-lived Fixed Recurring IP payment Consent:
7.11 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.12 Request Users to authorize the single IP payment Consent, so that a single IP payment can be initiated. 7.13 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.14 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.15 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.16 Update the Fixed Recurring IP payment Consent details stored in the OFP with all the information included in the Fixed Recurring IP payment Consent authorized by the User. | |
| OFP MUST: 7.17 Confirm back to the LFIs that the payment Consent details have been updated successfully. | |
| Multi-Authorization Journey Only | |
FRIP-8 | Hand-off back to the TPP | |
FRIP-9 | Confirmation to User |
3.3 Payment Initiation
# | Step | Rules & Guidelines |
|---|---|---|
FRIPPI-1 | FX Quotation | International-FX & FX-Payments Only TPPs MUST: 1.1 Check, on the day of each payment initiation, if the authorized long-lived Fixed Recurring IP Payment Consent included an Indicative FX rate. 1.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: 1.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. 1.4 Connect to the User’s LFI and request the LFI to provide a FX quotation based on the following information:
| ||
LFIs MUST: 1.5 Use the information provided by the OFP to provide a FX rate for the transaction and prepare a quote with FX rate and charges.
1.6 Set the Indicative flag for the FX Rate, 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 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. 1.7 Determine the charges for the International-FX Payment based on the information provided by the OFP, as follows:
1.8 Provide the OFP with all the FX Rate and charges information in relation to the FX Rate Request.
| ||
OFP MUST: 1.9 Return back to the TPP the FX Rate Request response, as follows:
| ||
TPPs MUST: 1.10 Check if the User selected to authorize every payments with the TPP based on the FX Rate. 1.11 Send notification to the User presenting all the information of the FX Rate. 1.12 Provide the appropriate message to the User, if the FX Rate was based on an indicative FX rate. TPP MUST Request User to authorize the IP payment with the TPP. 1.13 Check if the the FX Rate variance is within a User configurable range, in the case the user selected the automated initiation of the IP payments. If the FX Rate is above the acceptable threshold, the TPP MUST notify the User and request authorization of the IP payment. Otherwise, TPPs MUST initiate the IP payment. 1.14 Initiate the FX Rate Request process again for all FX Rates with actual FX rate that their validation time has expired and the User has not provided a single IP payment Consent.
| ||
FRIPPI-2 | Payment Initiation | TPPs MUST: 2.1 Submit to OFP payment initiation requests on the scheduled dates defined in the Periodic Payment Schedule of the long-lived Fixed Recurring IP Payment Consent authorized by the User. 2.2 Schedule the execution time of the payments related to the Periodic or the Variable-defined Payment Schedule to occur during time periods of low payment volume. 2.3 Submit to OFP payment initiation requests with the same fixed parameters as per the long-lived Fixed Recurring IP Payment Consent authorized by the User. In case where the consent was setup using the Payee’s proxy, the payment request MUST also include the IBAN from the proxy Payee identification returned back to the TPP during the payment Consent setup. 2.4 Include in each one of the payment initiation requests the same Payer Note as specified in the authorized long-lived Payment Consent, as the default value, if previously provided. However, this may be overwritten by a new Payer Note provided by the User or the TPP, if relevant, for each payment initiation request. 2.5 Include in each of the payment initiation requests a Payment Reference. This MUST be populated as follows:
|
FRIPPI-3 | Processing of Payment Initiation Requests | OFP MUST: 3.1 Allow the TPPs to submit individual payment initiation requests under the long-lived Fixed Recurring IP Payment Consent authorized by the User, without any additional MFA or authorization from the User. 3.2 Check that the received payment initiation requests relate to a valid long-lived Fixed Recurring IP Payment Consent authorized by the User. The Consent MUST be in the Authorized state. The OFP MUST reject any payment initiation messages related to a Payment Consent in a different state (e.g. expired) and respond back to the TPP with the appropriate error message/code. 3.3 Check the payment initiation request parameters against the authorized long-lived Fixed Recurring IP Payment Consent. More specifically, the OFP MUST check the following:
3.4 Check the Fixed Recurring Payment initiation request parameters against the Fixed Recurring Payment Consent. More specifically, the OFP MUST:
3.5 Increment the cumulative total number of payments after the payment has been successfully executed and received payment status confirmation from the payee Bank. The initial value of this parameter should be zero for each authorized Fixed Recurring Payment Consent. 3.6 Set the Fixed Recurring Payment Consent state to a terminal state (Finished), if the cumulative total number of payments requests becomes equal to the Total Number of Payments parameter of the Fixed Recurring Payment Consent. 3.7 Allow the description of the Payment Reference in the submitted payment initiation request to be different than the one defined in the Payment Reference of the long-lived Payment Consent. 3.8 Reject the payment initiation and provide the necessary error message to the TPP if any other checks of the payment initiation request parameters fails against Consent parameters of the authorized long-lived Fixed Recurring IP Payment Consent. 3.9 Send a payment initiation request to the LFI for initiating an instant payment using the payment parameters included in the payment initiation request including:
|
| LFIs MUST: 3.10. Allow the OFP to submit the payment initiation request without any additional MFA or authorization from the User. 3.11 Additionally apply all existing BAU payment account controls and limits such as single transaction value limit, total transaction value limit, AML checking (if applicable) and others, as if the payment request has been initiated by the existing channels of the LFI. LFIs MUST send an appropriate error response to the OFP in case the payment is rejected due to violating any of these limits or checks. 3.12 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. 3.13 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. 3.14 Provide the OFP with all the available information in relation to the initiated payment instruction including the payment’s unique identifier Payment Transaction ID. The format of the Payment Transaction ID can be found in the UAE Open Finance Standard specifications. | |
OFP MUST: 3.15 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. 3.16 Send to the TPP the appropriate error message in case the payment payment initiation was rejected by the LFI due to insufficient funds in the selected payment account. 3.17 Provide the TPP with all the available information in relation to the initiated IP payment instruction including the payment’s unique identifier Payment Transaction ID. | ||
FRIPPI-4 | Payment Status Update | |
FRIPPI-5 | Payment Notifications |
3.4 Consent Updates
4. International Payments Common Rules & Guidelines
4.1 User Payment Account & Currency Selection
TPPs MUST:
4.1.1 Apply all rules for Users' payment account selection as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#2.-User-Payment-Account-Selection.
4.1.2 Provide Users' with the ability to specify the currency of the selected payment account, if Users' have specified an account identifier and not just the LFI that holds their payment account. TPPs MUST use local currency (i.e. AED) as the default value and allow the Users to select another currency for the payment account.
4.2 Payment Amount & Currency
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.1.1 Have the option to select which currencies that they want to support for their use cases. TPPs SHOULD check with the LFIs participating in the UAE Open Finance ecosystem which currencies they support in order to provide better customer experience and reduce payment initiation rejections.
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.
4.2.2.1 Allow Users to enter the payment amount either in the currency of their selected payment account or in the currency selected for the payment order. This is dependent on the use case and whether users are allowed to enter the payment amount manually or not.
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 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:
foreign currency for FX Payments, International-FX Payments and International Payments
local currency for International Payments in local currency
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.5.1 NOT apply any maximum amount limit for FX payments to payee accounts managed by the same LFI as the User’s LFI (i.e. Intra-bank payments). TPP MUST be able to identify the account holding LFI from the payee identification details.
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.
4.3 Payee Identification for International Payments
4.4 Payment Order Priority for International Payments
4.5 Payment Charge Model for International Payments
4.6 Multi-User Authorization for IP Payments
All rules for Multi-User Authorization apply as defined in Common Rules and Guidelines | 18. Multi User Authorization Flow.
© CBUAE 2024
Open License and Contribution Agreement | Attribution Notice
Please try out our Advanced Search function.