Versions Compared

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 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 Rate

  • FX rate for the transaction & FX 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

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.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 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 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 Rate Request process again if the FX Rate was Indicative or the remaining time for an Actual FX Rate has expired.

  • 7.8.1 Provide a message to the User than the FX Rate was indicative or has expired and a new FX 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/58621958/International+Payments#4.6-Multi-User-Authorization-for-IP-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

...