/
Common Rules and Guidelines

Common Rules and Guidelines

Owned by Chris Michael
12 Nov 2024

This section contains Rules & Guidelines which are common for all Bank Data Sharing and Bank Service Initiation capabilities described in the UAE Open Finance Standards.

IMPORTANT NOTE:

  • LFIs & TPPs MUST comply with the rules and guidelines listed in this section.

  • LFIs MUST connect all mandatory APIs to the Open Finance Platform and may provide direct access to TPPs.

    • Note: The Standard does not support the direct access of LFIs to TPPs.

Basic terminology

In the context of the Open Finance Standard, the following terms have been used:

  • Debtor: Term used to describe the originating payer of an Open Finance bank service initiation. In most of the cases, the Debtor is the User of the Open Finance services offered by TPPs.

  • Creditor: Term used to describe the beneficiary payee of an Open Finance bank service initiation.

1. Supported Accounts & Payment Rails

LFIs MUST:

CRG-1.1 Provide Open Finance APIs for as many of the following account types as they allow their Users to access in their existing Digital channels:

  • Retail Accounts: Accounts used for the execution of payment transactions provided by LFIs to individuals

    • Current accounts, Savings accounts

  • SME Accounts: Accounts used for the execution of payment transactions provided by LFIs to SMEs

    • Current accounts, Savings accounts

  • Corporate Accounts: Accounts used for the execution of payment transactions provided by LFIs to Corporates

    • Current accounts, Savings accounts

CRG-1.2 Provide Open Finance APIs for the aforementioned account types in all currencies. The scope of currencies is as follows:

  • CRG-1.2.1 For Bank Data Sharing, the aforementioned accounts as per CRG-1.1 MUST be supported in ALL available currencies.

  • CRG-1.2.2 For Bank Service Initiation, the following scope rules apply:

    • For domestic payments (i.e. payment accounts within the UAE jurisdiction) both debtor (initiating) payment account and creditor (beneficiary) payment account MUST be in AED.

    • Domestic payments (i.e. payment accounts within the UAE jurisdiction) 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.

    • For international payments (i.e. payments to accounts outside the UAE jurisdiction), ALL available currencies supported by LFIs MUST be supported for Open Finance payment initiation. For more information, please refer to International Payments | 1. Description.

CRG-1.3 Allow Users to authorize consents only for eligible accounts.

CRG-1.4 Provide Open Finance APIs with domestic Payment Initiation capabilities from the aforementioned account types using ONLY the Instant Payment Platform (IPP).

  • CRG-1.4.1 In the scenario that the Creditor account is with an LFI that has not been onboarded with the IPP platform, the LFIs MUST perform their BAU check and reject any payments to Creditor accounts not supported by the IPP platform.

  • CRG-1.4.2 In the scenario that IPP is unavailable, for example, it is going through maintenance and planned downtime, the LFIs MUST reject the payment and set the status of the payment to the Rejected terminal state.

  • CRG-1.4.3 In the scenario that IPP does not have the user's date/city of birth registered, the LFIs MUST NOT route the Open Finance payments via other payment systems. Instead, LFIs MUST reject the Open Finance payment, informing the User what is required to be done in order to resolve this issue. It is expected that the LFIs MUST obtain this information through the KYC or another process, to ensure that this mandated information is registered with the IPP platform.

  • CRG-1.5 Provide Open Finance APIs for International (i.e. cross-border) Payment Initiation capabilities from the aforementioned account types using ALL available payment rails in use by LFIs to support International payment initiation for their existing online channels.

  • CRG-1.6 NOT impose any additional constraints to the Open Finance initiated payments on top of the LFI limits (minimum and maximum) stated in the Open Finance Standard. More specifically, subject to meeting the minimum values stated in Limits and Constants | C. LFI Channel Limits LFIs MUST set the maximum transaction limits to the same value or higher as the transaction limits imposed on the following existing digital channels and use cases: 

    • Applicable Channels & Use Cases

      • Debit and Credit Card Transactions: Transactions made via point-of-sale (POS) and online purchases, encompassing payments to merchants onboarded by Third-Party Providers (Pay by account).

      • Proprietary online banking & Mobile banking applications: Transactions executed via the LFIs’ web portal or mobile app, including transfers, bill payments, and peer-to-peer (P2P) payments, enabling the following use cases

        • P2P/B2P Payments: Peer-to-peer payments between individuals and business-to-person payments.

        • Payments-to-self: Transfers made by customers to their accounts, whether within the same LFI or to accounts at other financial institutions.

        • Payments to Businesses non-onboarded by TPPs: Payments made to businesses not onboarded by TPPs.

  • CRG-1.7 NOT impose any timing constraints on the Open Finance initiated payments. For example, cooling-off periods for new beneficiaries with reduced transactional limits or other constraints related to the number or value of payment transactions MUST NOT be applied to Open Finance initiated payments.

    CRG-1.8 Follow the principle that transaction limits and other constraints applied to the Open Finance services are not more restrictive than those applied across other commonly used banking digital channels. This establishes parity, ensuring that customer experience is consistent regardless of the digital channel used.

1.1 Accounts for Minors

This section includes key guidelines and parental controls for access to accounts of minors in the context of Open Finance in the UAE.

1.1.1 Consent and Authorization

  • Parental Control: For children under 16, parents or guardians act as the legal representative and must provide consent on behalf of the child. The child cannot independently grant access to TPPs for Open Finance services. Parents maintain control over which third-party apps or services can access their child’s account data, ensuring that only trusted services are connected.

1.1.2 Data and Security

  • Parents control whether data from their child’s bank account is shared via Open Finance APIs. They can revoke access at any time to protect their child’s privacy. Given that children may not fully understand the implications of sharing their financial data, parents play a critical role in vetting third-party providers and ensuring that their child’s data is secure and used responsibly.

1.1.3 Age-Appropriate Services

  • Parents can choose which services are connected to their child’s account, ensuring they align with age-appropriate spending and financial management. For example, parents may opt to connect budgeting apps, but not payment initiation services. This control ensures that children under 16 are not exposed to inappropriate financial services, like loans or investments, which could misuse their personal data or negatively impact their financial education.

1.1.4 Access Restrictions

  • Parents can restrict third-party access to only certain types of data (e.g., viewing balances without allowing payments). They can also monitor the data shared and revoke access if they suspect misuse. This layered control protects children from unauthorized access to their accounts or malicious third-party services, ensuring they can benefit from Open Finance features like financial insights without compromising security.

1.1.5 Payment Initiation

  • For children under 16, parents are responsible for authorizing any payment initiation through Open Finance connected services. Most children’s accounts do not allow for overdrafts or credit facilities, and this restriction is crucial to Open Finance services that may otherwise allow payments or transfers. Payment services through Open Finance need to ensure that any transactions on a child’s account are fully authorized by the parent. Parents can deny access to TPPs that offer payment services, limiting a child’s ability to spend money through third-party apps.

2. User Payment Account Selection

TPPs MUST:

CRG-2.1 Provide Users at least one of the following options for selecting their payment account to be used for the Consent:

  • Manually enter their Payment Account Identification details (e.g. IBAN, account number & LFI, and any other formats supported by the LFI holding the Users' payment account)

  • Select their Payment Account Identification details. This assumes that these have been saved previously and the User has a long-term profile with the TPP, having completed a User onboarding step.

  • Select their LFI only (so that they can select their Payment Account later on in the journey after authenticating with the LFI). The LFI MUST be identified using the trading name which is familiar to Users.

    • CRG-2.1.1 TPPs MUST use logos and the brand names of the LFIs as they are defined in the Trust Framework Directory.

Note: It is in the competitive space of TPPs to enable additional services for Users that may provide better customer experience. For example, a TPP with a long-term relationship with a User may have dual Data Sharing and Service Initiation roles and have access to the User list of accounts with a specific LFI, making it easier for the User to select the payment account they want to use for the payment initiation.

3. Payment Amount & Currency

TPPs MUST:

CRG-3.1 Either allow Users to manually enter the payment amount or pre-populate it for the Users. This is dependent on the use case.

CRG-3.2 For domestic payments, ensure that Users clearly understand that the payment amount is in local currency (i.e. United Arab Emirates Dirham - AED) as used by the local payment systems infrastructure for domestic payments.

CRG-3.3 Ensure and validate that the lowest allowable amount is 0.01 AED. The amount of the payment MUST be specified with max 2 decimal digits.

CRG-3.4 Ensure that the maximum allowable amount is equal to Limits and Constants | Max Inter bank Payment Amount for any payments to Creditor accounts managed by a different account holding entity than the User’s LFI.

  • CRG-3.4.1 NOT apply any maximum amount limit for payments to Creditor accounts managed by the same LFI as the User’s LFI (i.e. Intra-bank payments).

CRG-3.5 Display a message to Users informing them that the payment amount cannot exceed the Limits and Constants | Max Inter bank Payment Amount value for all Inter-bank payments.

4. Creditor Identification

TPPs MUST:

CRG-4.1 Either allow Users to manually enter/select their Creditor Identification details or pre-populate them for the Users.

Note: It is in the competitive space of TPPs to enable additional services for Users that may provide a better customer experience. For example, a TPP with a long-term relationship with a User may have dual Data Sharing and Service Initiation roles and have access to Users' list of Authorized Beneficiaries with a specific LFI, making it easier for Users to select the Creditor Identification details.

CRG-4.2 Allow the Creditor Identification using the following information:

  • IBAN of the Creditor payment account

  • Name of the Creditor

Note: Depending on the use case, the Creditor details may not be displayed to Users in full. However, these still need to be part of the payment Consent request sent by the TPP.

CRG-4.3 Display to Users the full IBAN details of the Credit payment account, if these details have been manually entered/provided by the User.

CRG-4.4 Display to Users the masked IBAN (only last 4 digits) of the Credit payment account, if these details have been populated/provided by the TPP (e.g. in case of merchant onboarded by TPPs).

CRG-4.5 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.

CRG-4.6 TPPs MUST send the Merchant Category Code where the Creditor is a Merchant onboarded by them.

5. Debtor Reference

TPPs MUST:

CRG-5.1 Allow Users to manually enter a Debtor Reference. This note is for the Users' reference and may be available to Users as additional information in relation to a payment by their LFIs. This information is optional for Users and may not be provided at all.

CRG-5.2 Validate that the format of the Debtor Reference is according to the UAE Open Finance Standard specifications.

CRG-5.3 Append to the Debtor Reference the TPP ID, Merchant ID, BIC for the Creditor Account for payments to Merchants.
CRG-5.4 Append to the Debtor Reference the TPP ID, BIC for the Creditor Account for all other Payments.

CRG-5.5 Include the Debtor Reference in each Payment Initiation Request as the default value. This information will not be transferred via the payment rails. For details on the format of Debtor Reference please refer to Bank Service Initiation OpenAPI

6. Creditor Reference

TPPs MUST:

CRG-6.1 Allow Users to manually enter a Payment Reference or pre-populate it for the Users, depending on the use case. Payment Reference is optional for Users. Payment Reference may be populated by the User (i.e. Debtor) using information requested by the beneficiary (i.e. Creditor) or any other information the User wants to provide to the beneficiary to assist in identifying and reconciling the payment. This information will be transferred via the payment rails to the beneficiary’s LFI, if different than the User’s LFI.

Note: TPPs may make the Payment Reference mandatory based on their specific use cases or business requirements (for example credit card payment, invoice payments, etc)

CRG-6.2 Validate that the format of the Payment Reference is according to the UAE Open Finance Standard specifications.

CRG-6.3 Include the Payment Reference in the Payment Initiation Request as the default value. The Payment Reference will be used by the LFI to populate the Remittance Information of the payment.

For details on the format of Creditor Reference please refer to Bank Service Initiation OpenAPI

7. Is Single Authorization flag

TPPs MUST:

CRG-7.1 Set Is Single Authorization flag in the Consent to specify that the Consent MUST be subject to single User authorization only. This is used when there is a clear requirement that the Consent on the account to be used cannot be subject to multiple User authorizations.

8. Authorization Expiration Date Time

TPPs MUST:

CRG-8.1 Have the option to set the appropriate parameter in the Consent specifying the time window during which the Consent MUST be authorized by all required authorizers (one or multiple). The Authorization Expiration Date Time that can be specified by a TPP is limited to Limits and Constants | Max Authorization Time Window after the Consent has been submitted (i.e. staged) by the TPP for User authorization.

9. Risk Information Block

9.1 TPP Obligations

Based on the type of payment/use case, TPPs have different obligations with populating the various parts of the Risk Information Block.

TPPs MUST:

CRG-9.1.1 Set ALL the available data in the Risk Information Block in order to provide additional information in relation to the Payment Consent and allow LFI to assess their risk. This includes the following information as shown in the table below, based on the type of payment/use case. The information MUST be provided as per the following requirements:

  • M- Mandatory

  • N - Not Required

  • C- Conditional

  • O - Optional (if available/applicable)]

Risk Information Block Element

 

Payments to Merchants onboarded by TPPs (Pay by Account)

P2P/B2P Payments

Payments-to-self

Payments to Businesses non-onboarded by TPPs

Risk Information Block Element

 

Payments to Merchants onboarded by TPPs (Pay by Account)

P2P/B2P Payments

Payments-to-self

Payments to Businesses non-onboarded by TPPs

A. User (Debtor) Indicators

Information related to the User.

  1. User Name

C (if onboarded)

C (if onboarded)

C (if onboarded)

C (if onboarded)

B. Authentication (Debtor) Indicators

Information in relation to the authentication initiated by the User.

  1. Authentication Channel

M

M

M

M

  1. Possession Factor Used (true/false)

M

M

M

M

  1. Possession Factor Type

C

C

C

C

  1. Knowledge Factor Used (true/false)

M

M

M

M

  1. Knowledge Factor Type

C

C

C

C

  1. Inherence Factor Used (true/false)

M

M

M

M

  1. Inherence Factor Type

M

M

M

M

  1. Challenge Outcome

C (if User prompted for MFA or other challenge)

C (if User prompted for MFA or other challenge)

C (if User prompted for MFA or other challenge)

C (if User prompted for MFA or other challenge)

  1. Authentication Flow

C (if Challenge Outcome is Pass or Fail)

C (if Challenge Outcome is Pass or Fail)

C (if Challenge Outcome is Pass or Fail)

C (if Challenge Outcome is Pass or Fail)

  1. Authentication Value

C (if Challenge Outcome is Pass and value supported)

C (if Challenge Outcome is Pass and value supported)

C (if Challenge Outcome is Pass and value supported)

C (if Challenge Outcome is Pass and value supported)

  1. Challenge Date Time

C (if User prompted for MFA or other challenge)

C (if User prompted for MFA or other challenge)

C (if User prompted for MFA or other challenge)

C (if User prompted for MFA or other challenge)

C. (Debtor) GeoLocation

  1. Latitude

C (if User consents to sharing location data)

C (if User consents to sharing location data)

C (if User consents to sharing location data)

C (if User consents to sharing location data)

  1. Longitude

C (if User consents to sharing location data)

C (if User consents to sharing location data)

C (if User consents to sharing location data)

C (if User consents to sharing location data)

D. (Debtor) Device Information

  1. Device ID

M

M

M

M

  1. Alternative Device ID

O

O

O

O

  1. Device Operating System

M

M

M

M

  1. Device Operating System Version

M

M

M

M

  1. Device Binding ID

C

C

C

C

  1. Last Binding Date Time

C

C

C

C

  1. Binding Duration

C

C

C

C

  1. Binding Status

C

C

C

C

  1. Device Type

M

M

M

M

  1. Device Manufacturer Model

C

C

C

C

  1. Device Manufacturer Manufacturer

C

C

C

C

  1. Device Language

M

M

M

M

  1. Device Local Date Time

M

M

M

M

  1. Connection Type

C (with permissions)

C (with permissions)

C (with permissions)

C (with permissions)

  1. Screen Information: Pixel Density

C

C

C

C

  1. Screen Information: Orientation

C

C

C

C

  1. BatteryStatus: Level

C

C

C

C

  1. BatteryStatus: Is Charging (true/false)

C

C

C

C

  1. Touch Support: Supported

C

C

C

C

  1. Touch Support: Max Touch Points

C

C

C

C

  1. Motion Sensors: Status

C

C

C

C

  1. Motion Sensors: Accelerometer

C

C

C

C

  1. Motion Sensors: Gyroscope

C

C

C

C

  1. Device Environment Context

C

C

C

C

E. (Debtor) Biometric Capabilities

  1. Supports Biometric

M

M

M

M

  1. Biometric Types

C

C

C

C

F. (Debtor) App Information

  1. App Version

C

C

C

C

  1. Package Name

C

C

C

C

  1. Build Number

C

C

C

C

G. (Debtor) Browser Information

  1. User Agent

C

C

C

C

  1. Cookies Enabled (true/false)

C

C

C

C

  1. Available Fonts

O

O

O

O

  1. Plugins

O

O

O

O

  1. Pixel Ratio

C

C

C

C

H. (Debtor) User Behavior

  1. Scroll Behavior: Direction

C

C

C

C

  1. Scroll Behavior: Speed

C

C

C

C

  1. Scroll Behavior: Frequency

C

C

C

C

I. (Debtor) Account Risk Indicators

  1. User Onboarding Date Time

C (if onboarded)

C (if onboarded)

C (if onboarded)

C (if onboarded)

  1. Last Account Change Date

C (if onboarded)

C (if onboarded)

C (if onboarded)

C (if onboarded)

  1. Last Password Change Date Suspicious Activity

C (if onboarded)

C (if onboarded)

C (if onboarded)

C (if onboarded)

  1. Transaction History: LastDay

C (if onboarded)

C (if onboarded)

C (if onboarded)

C (if onboarded)

  1. Transaction History: LastYear

C (if onboarded)

C (if onboarded)

C (if onboarded)

C (if onboarded)

J. (Debtor) Supplementary Data

  1. Supplementary Data

O

O

O

O

K. Transaction Indicators

  1. Is Customer Present (true/false)

M

M

M

M

© CBUAE 2024-2025
Open License and Contribution Agreement | Attribution Notice