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. After initiation, TPPs are able to check and retrieve the status of the submitted payment order.
The IPs functionality scope is targeted to:
domestic debtor accounts (i.e. debtor 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 debtor’s account with the LFI
and creditor accounts are being located cross-border (i.e located outside of UAE) only
For IPs, ALL available currencies supported by LFIs MUST be supported for Open Finance payment initiation. For the avoidance of doubt, the following cases MUST be supported:
AED to Curreny A (cross-border International Payment with FX conversion)
Curreny A to Curreny A (cross-border International Payment without FX conversion)
Curreny A to Curreny B (cross-border International Payment with FX conversion)
Curreny A to AED (cross-border International Payment with FX conversion)
Note: Domestic (i.e. payment accounts within the UAE juristinction) FX payments, involving FX payment conversion at the debtor (initiating) payment account (for example from USD to AED or GBP to AED) before domestic payment initiation are NOT in the scope of the current version of the Open Finance Standard.
This functionality requires a Single Use Consent or a Long-lived Consent of type International Payment Consent.
1.1 Debtor and Creditor Segments
The scope of the IP Payments bank service initiation related to the segments of Debtors and Creditors is shown below:
Debtor | Creditor | ||||
|---|---|---|---|---|---|
Consumer | SME | Corporate | Consumer | SME | Corporate |
|
|
|
|
|
|
1.2 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.
2. User Journey
(2)%20updated.png?version=1&modificationDate=1728575413667&cacheVersion=1&api=v2&width=1441&height=529)
By providing their consent to TPPs, Users can initiate an International payment order to their LFIs for making a one-off single payment or a series of payments of a specific amount to an international Creditor.
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, apart from the FX conversion information (if applicable) and LFI charges, and a step in the LFIs' journey may be required to display supplementary information to Users, as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1rc2/pages/134843363/Common+Rules+and+Guidelines#22.-Supplementary-Information. 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.
3. Customer Experience
3.1 International-FX Payment
3.1.1 Rules & Guidelines
# | Step | Rules & Guidelines |
|---|---|---|
IP-1 | Single IP details collection | TPPs MUST: 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 | Single IP Consent | Basic Consent Parameters TPPs MUST: 2.1 Enable Users to review the parameters related to the IP they need to consent to. These parameters include:
|
International-FX & International Payments Only
| ||
Additional Consent Parameters TPPs MUST: 2.2 Set/clear the ‘Is Single Authorization’ flag as appropriate (as per Common Rules and Guidelines | 7. Is Single Authorization flag). 2.3 Set the Authorization Expiration DateTime (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1rc2/pages/134843363/Common+Rules+and+Guidelines#8.-Authorization-Expiration-DateTime) 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/standardsv1rc2/pages/134843363/Common+Rules+and+Guidelines#18.-Multi-User-Authorization-Flow). 2.4 Set/clear the “Is Pay By Account” flag as appropriate in the case the initiated payment is a payments at POS or e-commerce payment. 2.5 Set the Risk Information Block (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1rc2/pages/134843363/Common+Rules+and+Guidelines#9.-Risk-Information-Block) | ||
TPPs MUST: 2.6 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-3 | Consent Staging | |
IP-4 | Hand-off to LFI | Example wording to use: ‘We will securely transfer to YOUR LFI to authorize and make the payment“. |
IP-5 | Authentication | LFI Authentication Only LFIs MUST: 5.1 Enable Users to perform authentication with their LFIs, as per the following sections: 5.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 5.3 As per Centralized Authentication and Authorization | ||
IP-6 | Authorization | LFIs MUST: 6.1 Enable Users to authenticate using Multi-Factor Authentication (MFA) in order to review and authorize the single IP Consent. 6.2 Retrieve from the OFP the single IP Consent details staged by the TPP and present relevant details to Users. 6.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/standardsv1rc2/pages/134843363/Common+Rules+and+Guidelines#12.-Payment-Account-Selection-at-LFI
6.4 Verify that the authorization status of the chosen payment account aligns with the TPPs' Is Single Authorization flag as per Common Rules and Guidelines | 7. Is Single Authorization flag. |
International-FX Only 6.5 Use the reference information provided in the IP Consent to identify the User's preferred forward FX rate agreement (e.g. future contract) related to User's account profile with the LFI, if this was included in the IP Conent. 6.6 Provide to the User the details of any forward FX rate agreement (e.g. future contract) they have in place in relation to the selected payment account and use this for the currency conversion required for the transaction. 6.7 Display to the User the details related to the Forward FX rate agreement, if applicable
6.8 Provide the same actual (deal) FX rate and charges as it would be offered to the User via the LFIs' other channels such as mobile or online banking, if the User has no FX agreement with the LFI. | ||
6.9 Display to Users the TPP Trading Name of the TPP that initiated the single IP Consent.
6.10 Present to Users the following minimum required information for authorizing the single IP payment Consent:
6.11 Refresh the Actual FX Rate if the remaining time has expired (if applicable) 6.12 Request Users to authorize the single IP payment Consent, so that a single IP payment can be initiated. 6.13 Provide Users the ability to cancel 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. 6.14 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. 6.15 Update the single IP payment Consent details stored in the OFP. | ||
OFP MUST: 6.16 Check the Authorization Time Window is valid as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1rc2/pages/134843363/Common+Rules+and+Guidelines#19.-Check-Authorization-Time-Window. 6.17 Confirm back to the LFIs that the single IP payment Consent details have been updated successfully. | ||
Multi-Authorization Journey Only | ||
IP-7 | Hand-off back to the TPP | |
IP-8 | Payment Initiation | TPPs MUST: 8.1 Submit to OFP the IP payment initiation requests with the same parameters as per the IP Payment Consents authorized by Users. 8.2 Submit to OFP the IP payment initiation request immediately after they receive the IP Payment Consent authorization confirmation. This is required in the case that there is FX conversion related to the International Payment AND the FX rate included in the IP Payment Consent was the actual rate (i.e. deal rate) and not indicative rate or a fixed rate related to a future contract agreement. The IP payment initiation request MUST be received by the LFI within the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1rc2/pages/134843434/Limits+and+Constants#Actual-FX-Rate-SLA. |
OFP MUST: 8.3 Allow the TPPs to submit the individual payment initiation requests under the Payment Consents authorized by Users, without any additional MFA or authorization from Users. 8.4 Check that the received payment initiation request relates to a valid IP Payment Consent authorized by the User. The Consent MUST be in the Authorized state. The OFP MUST reject an IP payment initiation message related to an IP Payment Consent in a different state and respond back to the TPP with the appropriate error message/code. 8.5 Check the payment initiation request parameters against the authorized IP Payment Consent. All parameters MUST match exactly.
8.5 Send the IP payment initiation request to the LFI for initiating a single International Payment using the payment parameters included in the payment initiation request including:
8.6 Submit to the LFI the IP payment initiation request immediately after they receive the IP Payment request from the TPP. This is required in the case that there is FX conversion related to the International Payment AND the FX rate included in the IP Payment Consent was the actual rate (i.e. deal rate) and not indicative rate or a fixed rate related to a future contract agreement. The IP payment initiation request MUST be received by the LFI within the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1rc2/pages/134843434/Limits+and+Constants#Actual-FX-Rate-SLA. Note: In cases where the IP Payment request has not been received within the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1rc2/pages/134843434/Limits+and+Constants#Actual-FX-Rate-SLA and the FX in the authorized IP Consent was not related to a future contract rate, the LFI is expected to use a different FX rate for the transaction. This rate will be provided back to the TPP in the IP Payment response message. This scenario can also occur in the exceptional circumstances of the IP Consent authorization being provided to the LFI just at the point of the FX deal cut-off time. This is more prominent to occur in cases where the LFI is not using the CLS system. Similalry, the same scenario can occur in situations where the IP Consent was authorized at the cut-off time of the underlying payment system causing the payment to be executed in the next available window on the following date with a different value date. | ||
LFIs MUST: 8.7 Trigger the payment initiation process for the payment Consent immediately after receiving the payment initiation request from the OFP. 8.8 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.9 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.10 Subject to successful BAU checking, validation and payment processing, proceed with the execution of the payment by submitting the payment to the underlying payment rails. 8.11 Provide the OFP with all the available information in relation to the initiated payment instruction including the payment’s unique identifier Payment Transaction ID. | ||
OFP MUST: 8.12 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.13 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.14 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.1.2 Journey Variations
3.1.2.1 International Payment
3.1.2.2 Contract selection at LFI
.png?version=1&modificationDate=1728575416017&cacheVersion=1&api=v2&width=1604&height=961)
3.1.2.3 Multi-Auth International FX Payment
3.1.2.2 Contract selection at TPP
3.2 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/standardsv1rc2/pages/134842067/Multi-Payments#6.2.1-Periodic-Payment-Schedule
Initiated from a User’s payment account held by the LFI in local or foreign currency
To a specific Creditor (Beneficiary) owning a payment account located abroad (cross-border)
3.2.1 User Journey
%20AlexD%20v2.png?version=1&modificationDate=1728575414252&cacheVersion=1&api=v2&width=1419&height=521)
3.2.2 Customer Experience
3.2.2.1 Fixed Recurring International-FX Payments
3.2.3 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 | Fixed Recurring IP Payment Consent | Basic Consent Parameters TPPs MUST: 2.1 Enable Users to review the parameters related to the IP they need to consent to. These parameters include:
|
International-FX & International Payments Only
| ||
Additional Consent Parameters 2.2 Set/clear the ‘Is Single Authorization’ flag as appropriate (as per Common Rules and Guidelines | 7. Is Single Authorization flag). 2.3 Set the Authorization Expiration DateTime (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1rc2/pages/134843363/Common+Rules+and+Guidelines#8.-Authorization-Expiration-DateTime) 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.
2.4 Set/clear the “Is Pay By Account” flag as appropriate in the case the initiated payment Consent relates to payments at POS or e-commerce payments. 2.5 Set the Risk Information Block (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1rc2/pages/134843363/Common+Rules+and+Guidelines#9.-Risk-Information-Block) | ||
2.6 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-3 | Consent Staging | |
FRIP-4 | Hand-off to LFI | Example wording to use: ‘We will securely transfer to YOUR LFI to authenticate and authorize your payments setup“. |
FRIP-5 | Authentication | LFI Authentication Only LFIs MUST: 5.1 Enable Users to perform authentication with their LFIs, as per the following sections: 5.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 5.3 As per Centralized Authentication and Authorization | ||
FRIP-6 | Authorization | LFIs MUST: 6.1 Enable Users to authenticate using Multi-Factor Authentication (MFA) in order to review and authorize the long-lived Fixed Recurring IP Consent. 6.2 Retrieve from the OFP the payment Consent details staged by the TPP using the unique Consent Identifier. 6.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/standardsv1rc2/pages/134843363/Common+Rules+and+Guidelines#12.-Payment-Account-Selection-at-LFI
6.4 NOT earmark (i.e. block) any funds related to the payment Consent in the Users' payment account at the point of Consent authorization. 6.5 Verify that the authorization status of the chosen payment account aligns with the TPPs' “Is Single Authorization” flag as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1rc2/pages/134843363/Common+Rules+and+Guidelines#13.-Check-Is-Single-Authorization-flag. |
International-FX Only 6.6 Use the reference information provided in the IP Consent to identify the User's preferred forward FX rate agreement (e.g. future contract) related to User's account profile with the LFI, if this was included in the IP Conent. 6.7 Provide to the User the details of any forward FX rate agreement (e.g. future contract) they have in place in relation to the selected payment account and use this for the currency conversion required for the transaction. 6.8 Display to the User the details related to the Forward FX rate agreement, if applicable
6.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 User has no FX agreement with the LFI. | ||
6.10 Display to Users the TPP Trading Name of the TPP that initiated the long-lived payment Consent.
6.11 Present to Users the following minimum required information for authorizing the long-lived Fixed Recurring IP payment Consent:
6.12 Request Users to authorize the long-lived IP payment Consent, so that TPPs can initiate payments from the payment account. 6.13 Provide Users the ability to cancel 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 long-lived IP payment Consent, 6.14 Change the state of the IP payment Consent from Awaiting Authorization to Authorized when all Authorizers (one or more) have authorized the payment Consent. 6.15 Update the payment Consent details stored in the OFP with the relevant information. 6.16 Update the Fixed Recurring IP payment Consent details stored in the OFP with the relevant information as authorized by the User. | ||
OFP MUST: 6.17 Check the Authorization Time window is valid as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1rc2/pages/134843363/Common+Rules+and+Guidelines#19.-Check-Authorization-Time-Window 6.18 Confirm back to the LFIs that the payment Consent details have been updated successfully. | ||
Multi-Authorization Journey Only | ||
FRIP-7 | Hand-off back to the TPP | |
FRIP-8 | Confirmation to User |
3.2.4 Journey Variations
3.2.4.1 Fixed Recurring International Payments
3.2.4.2 Fixed Recurring International FX Payments with Contract selection at LFI
3.2.5 Payment Initiation
# | Step | Rules & Guidelines |
|---|---|---|
FRIPPI-1 | Payment Initiation | TPPs MUST: 1.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. 1.2 Schedule the execution time of the payments related to the Periodic Payment Schedule to occur during time periods of low payment volume. 1.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. 1.4 Include in each one of the payment initiation requests the same Debtor Reference as specified in the authorized long-lived Payment Consent, as the default value, if previously provided. However, this may be overwritten by a new Debtor Reference provided by the User or the TPP, if relevant, for each payment initiation request. 1.5 Include in each of the payment initiation requests a Creditor Reference. This MUST be populated as follows:
|
FRIPPI-2 | Processing of Payment Initiation Requests | OFP MUST: 2.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. 2.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. 2.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:
2.4 Check the Fixed Recurring Payment initiation request parameters against the Fixed Recurring Payment Consent. More specifically, the OFP MUST:
2.5 Increment the cumulative total number of payments after the payment has been successfully executed and received payment status confirmation from the Creditor Bank. The initial value of this parameter should be zero for each authorized Fixed Recurring IP Payment Consent. 2.6 Set the Fixed Recurring IP 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 IP Payment Consent. 2.7 Allow the description of the Creditor Reference in the submitted payment initiation request to be different than the one defined in the Consent Reference of the long-lived IP Payment Consent. 2.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. 2.9 Send the IP payment initiation request to the LFI for initiating a single International Payment using the payment parameters included in the payment initiation request including:
|
LFIs MUST: 2.10. Allow the OFP to submit the payment initiation request without any additional MFA or authorization from the User. 2.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. 2.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. 2.13 Subject to successful BAU checking, validation and payment processing, proceed with the execution of the payment by submitting the payment to the underlying payment rails. 2.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. | ||
OFP MUST: 2.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. 2.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. 2.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-3 | Payment Status Update | |
FRIPPI-4 | Payment Notifications |
3.2.6 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/standardsv1rc2/pages/134843363/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/standardsv1rc2/pages/134843434/Limits+and+Constants#Max-Inter-bank-IP%2FFXP-Payment-Amountfor any payments to Creditor 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 Creditor 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 Creditor 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/standardsv1rc2/pages/134843434/Limits+and+Constants#Max-Inter-bank-IP%2FFXP-Payment-Amount value for all Inter-bank payments.
4.3 Creditor Identification for International Payments
TPPs MUST:
4.3.1 Either allow Users to manually enter/select their Creditor Identification details or pre-populate them for the Users, depending on the use case. These parameters include:
4.3.1.1 Destination Country: This is the country where the LFI holding the beneficiary account resides. TPPs SHOULD check with the LFIs participating in the UAE Open Finance ecosystem which destination countries they support for payment orders in order to provide better customer experience.
4.3.1.2 Creditor Account Identification: This is the account number of the beneficiary in the LFI holding the beneficiary account. The Creditor Account Number can be in one of the following formats:
IBAN: Consists of up to 34 alphanumeric characters. The length varies by country. TPPs MUST validate the format of the IBAN depending on the selected destination country for the payment.
Other local account format defined in the destination country
4.3.1.3 Creditor Account Holding Entity/Routing Identification: This is the identification information of the LFI holding the beneficiary account including information for the local routing of the payment in the destination country. It can be in one of the following formats:
Bank Identification Code (BIC/SWIFT Code): This is the identification information of the LFI holding the beneficiary account. Consists of 8 to 11 characters.
National Clearing Code (NCC): National routing/account numbering system (including ABA Routing Transit Number used in the US).
4.3.1.4 Creditor Account Holding Entity Name and Address: This is the name and address of the LFI holding the beneficiary account.
4.3.1.5 Creditor Account Name: This is the name of the beneficiary account as defined in the LFI holding the beneficiary account. This maybe different from the beneficiary name owning the payment account.
4.3.1.6 Creditor Account Address: This is the address of the beneficiary account as defined in the LFI holding the beneficiary account.
4.3.2 Ensure that the format and other validation rules of the Creditor Identification details are correct in case Users manually enter the Creditor Identification details. If incorrect, TPPs MUST request Users to review and re-enter the information.
4.4 Payment Order Priority for International Payments
TPPs MUST:
4.4.1 Either allow Users to select the priority of the international payment order. This can be one of the following:
Normal
Urgent
4.5 Payment Charge Model for International Payments
TPPs MUST:
4.5.1 Either allow Users to select the charge model for the international payment order. This can be one of the following:
“SHARE”: The sender User of the payment will pay fees to the sending LFI for the outgoing transfer charges. The receiving beneficiary will receive the amount transferred, minus the correspondent (intermediary) LFI charges
“OUR”: All fees will be charged to the sender User of the payment – i.e. the receiving beneficiary gets the full amount sent by the sender of the payment. Any charges applied by the receiving LFI will be billed to the sender of the payment (usually sometime after sending the payment).
“BEN”: BEN (beneficiary) means that the sender User of the payments does not pay any charges. The receiver beneficiary of the payment receives the payment minus all transfer charges, including the sending LFI charges if any.
4.6 Multi-User Authorization for IP Payments
All rules for Multi-User Authorization apply as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1rc2/pages/134843363/Common+Rules+and+Guidelines#18.-Multi-User-Authorization-Flow.
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 IP-FX Payment will be the spot rate at the date and time of the final authrozer in the authorization matrix, if not future contract agreement exists between the LFI and the User.
4.6.2 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 Payment or each of their Fixed Recurring IP payments will be the spot rate on the date of each of the payment initiation, if not future contract agreement exists between the LFI and the User.
4.6.3 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 the 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.
4.7 External Purpose Code
TPPs MUST:
4.7.1 Support all category purpose codes including their descriptions as defined in the international https://r.search.yahoo.com/_ylt=AwrLNjFo0atmz_IgKTYM34lQ;_ylu=Y29sbwNpcjIEcG9zAzEEdnRpZAMEc2VjA3Ny/RV=2/RE=1722565097/RO=10/RU=https%3a%2f%2fwww.iso20022.org%2fcatalogue-messages%2fadditional-content-messages%2fexternal-code-sets/RK=2/RS=Sq2vjuHl2b_GD5wd4.lmwJUnvOk- in order to be able to support the requirements for International Payments.
4.7.2 Either allow Users to select the available purpose of payment from a list or pre-populate it for Users.
4.7.3 Ensure and validate that the format of the payment purpose is according to the international https://r.search.yahoo.com/_ylt=AwrLNjFo0atmz_IgKTYM34lQ;_ylu=Y29sbwNpcjIEcG9zAzEEdnRpZAMEc2VjA3Ny/RV=2/RE=1722565097/RO=10/RU=https%3a%2f%2fwww.iso20022.org%2fcatalogue-messages%2fadditional-content-messages%2fexternal-code-sets/RK=2/RS=Sq2vjuHl2b_GD5wd4.lmwJUnvOk-format.