Versions Compared

Version Old Version 3 New Version 4
Changes made by

Alexandros Dimitrakoudis

Alexandros Dimitrakoudis

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

#

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:

  • User Payment Account or User LFI & Currency

  • Payment Amount & Currency

  • Destination Country (for International Payments)

  • Payment Order Priority (for International Payments)

  • Payment Charges model (for International Payments)

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:

  • User Payment Account or User LFI & Currency

  • Payment Amount & Currency

  • Destination Country (for International Payments)

  • Payment Order Priority (for International Payments)

  • Payment Charges model (for International Payments)

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.5.1 Provide the same actual FX rate and charges as it would be offered to the User via the LFIs other channels such as mobile or online banking.

  • 2.5.2 Provide an indicative FX rate and charges if the information provided by the OFP does not include the User’s Payment Account Identification details. The FX Rate MUST be clearly indicated to be Indicative and subject to change.

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:

  • Destination Country (for International Payments)

  • Payment Order Priority (for International Payments)

  • Payment Charges model (for International Payments)

2.8 Provide the OFP with all the FX Rate and charges information in relation to the FX Rate Request.

  • 2.8.1 Generate a unique FX Rate Reference number for identifying the FX Rate details and include this in the response to the OFP

OFP MUST:

2.9 Return back to the TPP the FX Rate Response, as follows:

  • FX rate for the transaction

  • Indicative or Actual FX rate flag

  • Time remaining for the FX rate to be valid (this maybe adjusted by the OFP as appropriate if required)

  • Charges to the User payment account for the payment execution based on priority and payment charges model

  • FX Rate Reference number

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.

  • 2.12.1 Provide a message to the User that the FX Rate has expired and a new FX Rate Request will be provided.

IP-3

Single IP Consent

Basic Consent Parameters

TPPs MUST:

3.1 Enable Users to review the parameters related to the IP /FXP they need to consent to. These parameters include:

  • User Payment Account & Currency or User LFI

  • Payment Amount & Currency

  • Payee Identification details

  • Payer Note (Optional)

  • Payment Reference

International-FX & International Payments Only

  • Payment Order Priority

  • Payment Charges model

  • Any other supplementary information required which the LFI has published as required and is specific to that LFI

International-FX Payments Only

FX Quote Rate

  • FX rate for the transaction & FX Quote Rate Reference

  • Indicative or Actual FX rate flag

  • Time remaining for the FX rate to be valid, if FX rate is Actual

  • Charges to the User payment account for the payment execution

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.3.1 Set the Consent Expiry Date accordingly if the Authorization Time Window is set to more than 1 day. This is to avoid the consent expiring before all necessary authorizations are completed. Otherwise, the default value of the Consent Expiry Date MUST be set to the same day (i..e current day). The Consent Expiry Time MUST always be set to 23:59:59 of the Consent Expiry Date.

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

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#10.-Consent-Staging

IP-5

Hand-off to LFI

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/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

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.

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.3.1 NOT allow Users to select a payment account from their list of available payment accounts that has insufficient funds for the single IP /FXP initiation. This only applies in case Users do not select their payment account when providing their Consent to TPPs.

  • 7.3.2 Reject the single IP initiation, if the payment account identification was part of the single IP payment Consent provided to the TPPs and the payment account has insufficient funds to cover the payment amount and any related charges, if applicable. The OFP MUST be notified about this rejection with an appropriate error message.

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 /FXP payment Consent:

  • User Payment Account & Currency

  • Payment Amount & Currency

  • Payment Amount in User’s Payment Account Currency (for International-FX Payments)

  • FX rate for the transaction & FX Quote Reference (for International-FX Payments)

  • Time remaining for the FX rate to be valid (for International-FX Payments)

  • Payee Identification details including:

    • Destination Country (for International Payments)

    • Payee Account Identification (IBAN, alias if specified, other local account format)

    • Payee Account Holding Entity/Routing Identification (BIC/SWIFT Code, NCC, ABA Routing etc) (for International Payments)

    • Payee Account Name

    • Payee Account Address (for International Payments)

    • Payee Account Holding LFI Name

    • Payee Account Holding LFI Address (for International Payments)

  • Payer Note (Optional)

  • Payment Reference

  • Payment Order Priority (for International-FX & International Payments)

  • Payment Charges model (for International-FX & International Payments)

  • Fees & VAT (if applicable): These are the charges that may be applied to the User account for making the payment in relation to the single IP/FXP payment Consent. If applicable, both bank charges and VAT MUST be presented and stated separately, prior to the User Consent authorization.

7.7 Initiate the FX Quotation Rate Request process again if the FX Quote Rate was Indicative or the remaining time for an Actual FX Quote Rate has expired.

  • 7.8.1 Provide a message to the User than the FX Quotation Rate was indicative or has expired and a new FX Quote Rate Request will be provided.

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

7.14 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/5269094558621958/International+FX+Payments#5Payments#4.6-Multi-User-Authorization-for-IP%2FFXPIP-Payments

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

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#15.-Payment-Status-Update

IP-10

Hand-off back to the TPP

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#14.-Hand-off-back-to-the-TPP

IP-11

Confirmation to User

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#16.-Confirmation-to-User

IP-12

Payment Notifications

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#17.-Payment-Notifications

...

#

Step

Rules & Guidelines

FRIP-1

Fixed Recurring IP

/FXP

Payment details collection

TPPs MUST:

1.1 Enable Users to provide the parameters related to the Fixed Recurring IP /FXP payment order they want to initiate. These parameters include:

International-FX & International Payments Only

Fixed Recurring IPFX IP Payment (IPFXIP-FRPs) Consent

FRIP-2

FX

Quotation

Rate Request

International-FX & FX Payments Only

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/5269094558621958/International+FX+Payments#FX-Rate-QuotationRequest in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/5269094558621958/International+FX+Payments#2.4-Rules-%26-Guidelines subject to the following:

LFIs MUST:

2.1 Set the FX Quote Rate Flag to Forward if they have the capability to lock the FX rate for all the IP /FXP recurring payments during the Recurring Payment Schedule. In this case, LFIs MUST not return any timer value with the FX QuoteRate. Instead, LFIs MUST return the date that the Forward FX rate is valid.

  • Provide all charges in relation to the Forward FX rates in the FX QuoteRate.

2.2 Provide an indicative FX rate in the FX Quote Rate Response if they cannot forward lock the FX rate for the full duration of the Payment Schedule.

FRIP-3

Fixed Recurring IP

/FXP

Payment Consent

Basic Consent Parameters

TPPs MUST:

3.1 Enable Users to review the parameters related to the IP /FXP they need to consent to. These parameters include:

  • User Payment Account & Currency or User LFI

  • Payment Amount & Currency

  • Payee Identification details

  • Payer Note (Optional)

  • Consent Reference

International-FX & International Payments Only

  • Payment Order Priority

  • Payment Charges model

  • Any other supplementary information required which the LFI has published as required and is specific to that LFI

International-FX & FX Payments Only

FX Quote Rate

  • FX rate for the transaction & FX Quote Rate Reference

  • Indicative or Forward FX rate flag

  • Date for the FX rate to be valid, if the FX rate is Forward

  • Charges to the User payment account for the payment execution

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 Quote 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 /FXP payments will be the spot rate on the date of each of the payment initiation, if the FX Quote Rate is Indicative.

  • 3.3.1 Allow the User to select one of the following option for Indicate FX QuotesRates:

    • Either receive an FX Quote Rate on each day of the payment initiation and authorize each payment with the TPP

    • Or, allow the TPP to initiate all IP /FXP payments in the Recurring Payments Schedule for which the FX Quote Rate on the initiation day is within a User configurable range. The threshold for this will be configured by the User as part of their TPP account profile.

Additional Consent Parameters

3.4 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.5 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.

  • 3.5.1 The Authorization Time Window MUST be less than the time of the first payment in the Periodic Payment Schedule.

3.6 Set the Risk Information Block (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/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 /FXP 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

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#10.-Consent-Staging

FRIP-5

Hand-off to LFI

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/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.3.1 Allow Users to select a payment account for the initiation of the multi-payments even if it has insufficient funds at the time of the payment Consent authorization. This allows Users to fund the payment accounts appropriately before the dates of the payment initiation. However, the LFIs MUST inform the User, if the selected payment account has insufficient funds.

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.7.1 Return back to the OFP (and the TPP) in the payment Consent response the IBAN of the Payee identification returned by the Proxy resolution.

5.8 Present to Users the following minimum required information for authorizing the long-lived payments Consent:

  • User Payment Account

  • Payee Identification details

  • Payer Note (Optional)

  • Consent Reference

  • Payment Amount & Currency (if relevant, depending on the type of the long-lived payment Consent)

  • Consent Controls Parameters (if relevant, depending on the type of the long-lived payment Consent)

  • Consent Control Period & Start Date (if relevant, depending on the type of the long-lived payment Consent)

  • The Payment Schedule (Periodic or Variable-defined) (if relevant, depending on the type of the long-lived payment Consent)

  • Consent Expiration Date & Time

  • Fees & VAT (if applicable): These are potential charges that will be applied to the User account for making a payment in relation to the long-lived payment 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 payment initiation and not at the point of payment Consent authorization.

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 /FXP Consent.

7.2 Retrieve from the OFP the Fixed Recurring IP /FXP 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 /FXP 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.3.1 Allow Users to select a payment account for the initiation of the Fixed Recurring IP /FXP even if it has insufficient funds at the time of the payment Consent authorization. This allows Users to fund the payment accounts appropriately before the dates of the payment initiation. However, the LFIs MUST inform the User, if the selected payment account has insufficient funds.

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

FX Payments Only

7.7 Add to the Fixed Recurring FXP Consent the IBAN of the Payee returned by the Proxy resolution process, if the Fixed Recurring FXP 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.

  • 7.7.1 Include in the payment Consent response to the OFP the IBAN of the Payee identification returned by the Proxy resolution.

International-FX & FX-Payments Only

FX Quote 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 Quote Rate was Forward type.

  • 7.8.1 Display to the User the date that the Forward FX rate is valid.

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 /FXP payments will be the spot rate on the date of each of the payment initiation, if the FX Quote Rate was Indicative type.

7.10 Present to Users the following minimum required information for authorizing the long-lived Fixed Recurring IP /FXP payment Consent:

  • User Payment Account & Currency

  • Payment Amount & Currency

  • Payment Amount in User’s Payment Account Currency (for International-FX & Domestic-FX Payments)

  • FX rate for the transaction & FX Quote details (for International-FX & Domestic-FX Payments)

  • Date remaining for the FX rate to be valid, if FX rate was not Indicative type (for International-FX & Domestic-FX Payments)

  • Payee Identification details including:

    • Destination Country (for International Payments)

    • Payee Account Identification (IBAN, alias if specified, other local account format)

    • Payee Account Holding Entity/Routing Identification (BIC/SWIFT Code, NCC, ABA Routing etc) (for International Payments)

    • Payee Account Name

    • Payee Account Address (for International Payments)

    • Payee Account Holding LFI Name

    • Payee Account Holding LFI Address (for International Payments)

  • Payer Note (Optional)

  • Consent Reference

  • Payment Order Priority (for International-FX & International Payments)

  • Payment Charges model (for International-FX & International Payments)

  • The Periodic Payment Schedule

  • Consent Expiration Date & Time

  • Fees & VAT (if applicable): These are the charges that may be applied to the User account for making the payment in relation to the single IP /FXP payment Consent. If applicable, both bank charges and VAT MUST be presented and stated separately, prior to the User Consent authorization.

7.11 Initiate the FX Quotation Rate Request process again if the FX Quote Rate was Indicative or the remaining time for an Actual FX Quote Rate has expired.

  • 7.11.1 Provide a message to the User than that the FX Quotation Rate was indicative or has expired and a new FX Quote Rate Response will be provided.

7.12 Request Users to authorize the single IP /FXP payment Consent, so that a single IP /FXP 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 /FXP 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 /FXP 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 /FXP payment Consent details stored in the OFP with all the information included in the Fixed Recurring IP /FXP 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

7.18 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/5269094558621958/International+FX+Payments#5Payments#4.6-Multi-User-Authorization-for-IP%2FFXPIP-Payments

FRIP-8

Hand-off back to the TPP

8.1 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#14.-Hand-off-back-to-the-TPP

FRIP-9

Confirmation to User

9.1 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#16.-Confirmation-to-User

9.2 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#19.-Payment-Details-Saving

...

#

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 /FXP Payment Consent included an Indicative FX rate.

1.2 Initiate a FX Quote Rate Request to the OFP, if FX conversion is required for the payment order. TPPs MUST provide the following details to the OFP:

  • Fixed Recurring IP /FXP Payment Consent Identifier

OFP MUST:

1.3 Check the FX Quote Rate Request parameters and validate their format and compliance to the UAE Standard. OFP MUST reject the FX Quote 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:

  • Fixed Recurring IP /FXP Payment Consent Identifier

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.5.1 Provide the same actual FX rate and charges quote as it would be offered to the User via the LFIs other channels such as mobile or online banking.

  • 1.5.2 Provide an indicative FX rate and charges quote if the information provided by the OFP does not include the User’s Payment Account Identification details. The FX Quote Rate MUST be clearly indicated to be Indicative and subject to change.

1.6 Set the Indicative flag for the FX QuoteRate, 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 Quote 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 QuoteRate.

1.7 Determine the charges for the International-FX Payment based on the information provided by the OFP, as follows:

  • Destination Country (for International Payments)

  • Payment Order Priority (for International Payments)

  • Payment Charges model (for International Payments)

1.8 Provide the OFP with all the FX Quote Rate and charges information in relation to the FX Quote Rate Request.

  • 1.8.1 Generate a unique FX Quote Rate Reference number for identifying the FX Quote Rate details and include this in the response to the OFP

OFP MUST:

1.9 Return back to the TPP the FX Quote Rate Request response, as follows:

  • FX rate for the transaction

  • Indicative or Actual FX rate flag

  • Time remaining for the FX rate to be valid (this maybe adjusted by the OFP as appropriate if required)

  • Charges to the User payment account for the payment execution based on priority and payment charges model

  • FX Quote Rate Reference number

TPPs MUST:

1.10 Check if the User selected to authorize every payments with the TPP based on the FX QuoteRate.

1.11 Send notification to the User presenting all the information of the FX QuoteRate.

1.12 Provide the appropriate message to the User, if the FX Quote Rate was based on an indicative FX rate. TPP MUST Request User to authorize the IP /FXP payment with the TPP.

1.13 Check if the the FX Quote Rate variance is within a User configurable range, in the case the user selected the automated initiation of the IP /FXP payments. If the FX Quote Rate is above the acceptable threshold, the TPP MUST notify the User and request authorization of the IP /FXP payment. Otherwise, TPPs MUST initiate the IP /FXP payment.

1.14 Initiate the FX Quotation Rate Request process again for all FX Quotes Rates with actual FX rate that their validation time has expired and the User has not provided a single IP /FXP payment Consent.

  • 1.14.1 Provide a message to the User that the FX Quotation Rate has expired and a new FX Quote Rate will be provided.

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 /FXP 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 /FXP 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:

  • 2.5.1 If the Payment Reference in the authorized long-lived Fixed Recurring IP /FXP Payment Consent was provided by the User, TPPs MUST use the same Payment Reference for every payment initiated under the long-lived Fixed Recurring IP /FXP Payment Consent.

  • 2.5.2 If the Payment Reference in the authorized long-lived Fixed Recurring IP /FXP Payment Consent was pre-populated by the TPP, TPPs can:

    • EITHER use the same Payment Reference for every payment initiated under the long-lived Fixed Recurring IP /FXP Payment Consent

    • OR pre-populate the Payment Reference with different information for every payment initiated under the long-lived Fixed Recurring IP /FXP Payment Consent based on the requirements of the TPPs or their servicing customers.

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 /FXP 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 /FXP 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 /FXP Payment Consent. More specifically, the OFP MUST check the following:

  • The Payee Identification details in the submitted payment initiation request matches exactly the Payee Identification in the authorized Payment Consent.

  • The date of the submitted payment initiation request is within:

    • the validity period of the long-lived Fixed Recurring IP /FXP Payment Consent (i.e. Consent Expiration Date & Time)

    • the period defined in the Periodic Payment Schedule. In this case, the dates of each payment initiation request MUST match exactly the dates in the Payment Schedule.

  • The amount in the submitted payment initiation request matches exactly the consented payment amount for the Fixed Recurring IP /FXP Consent.

3.4 Check the Fixed Recurring Payment initiation request parameters against the Fixed Recurring Payment Consent. More specifically, the OFP MUST:

  • Check the cumulative Total Number of payment initiations including the submitted payment initiation request is less than the Total Number of Payments as defined in the authorized long-lived Fixed Recurring Payment Consent.

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 /FXP 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:

  • User Payment Account (or account identifier)

  • Payment Amount & Currency

  • Payee Identification details

  • Payer Note (If provided)

  • Payment Reference

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 /FXP payment instruction including the payment’s unique identifier Payment Transaction ID.

FRIPPI-4

Payment Status Update

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#15.-Payment-Status-Update

FRIPPI-5

Payment Notifications

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#17.-Payment-Notifications

3.4 Consent Updates

#

Step

Rules

FRIPCU-1

Consent Update

TPPs MUST:

1.1 Enable Users to use the Consent Dashboard to amend the following parameters of a long-lived Fixed Recurring IP

/FXP

Payment Consent:

1.2 Require the Users to authenticate with their LFI and authorize the Consent update.

4. International Payments Common Rules & Guidelines

...

Panel
panelIconId5b2e39a5-8ce4-448d-936b-b645409e332b
panelIcon:bank:
panelIconText:bank:
bgColor#FFFAE6

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 /FXP payments will be the spot rate on the date of each of the payment initiation, if the FX Quote 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 Quote was Forward type. LFIx LFIs MUST also display to the User the date that the Forward FX rate is valid.