/
Common Rules and Guidelines

Common Rules and Guidelines

Owned by Chris Michael
Last updated: 21 Dec 2024 by Warren Handley
26 min read

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.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 (Aani Core).

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

  • CRG-1.4.2 In the scenario that Aani Core 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 Aani Core 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 Aani Core 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

3. Payment Amount & Currency

4. Creditor Identification

5. Debtor Reference

6. Creditor Reference

7. Is Single Authorization flag

8. Authorization Expiration Date Time

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.

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

  1. Is Contract Present (true/false)

M

M

M

M

  1. Channel Type

M

M

M

M

  1. Sub Channel Type

O

O

O

O

L. (Transaction) Payment Process

  1. Total Duration

M

M

M

M

  1. Current Session Attempts

M

M

M

M

  1. Current Session Failed Attempts

M

M

M

M

  1. Last 24 Hour Attempts

M

M

M

M

  1. Last 24 Failed Attempts

M

M

M

M

M. (Transaction) Merchant Risk

  1. Delivery Timeframe

M

C

C

C

  1. Reorder Items Indicator

M

C

C

C

  1. Pre Order Purchase Indicator

M

C

C

C

  1. Is Gift Card Purchase (true/false)

M

C

C

C

  1. Is Delivery Address Matches Billing (true/false)

M

C

C

C

  1. Address Match Level

M

C

C

C

N. (Transaction) Supplementary Data

  1. Supplementary Data

O

O

O

O

O. Creditor Indicators

  1. Beneficiary Account Type (Retail/Corporate)

M

M (Retail)

M

M

  1. Beneficiary Prepopulated by TPP (true/false)

M

M

M

M

  1. Merchant Trading Name

M

N

N

N

  1. Is Verified By TPP (true/false)

C (if verified by KYC or COP)

N

N

C (if verified by KYC or COP)

  1. Additional Beneficiary Account holder Identifiers such as:

  • Emirates ID or Passport Number for Retail accounts or Trade License number number for Business/Corporate accounts

  • Account Holder Name

M (Trade License number)

M (Account Holder Name)

O (Emirates ID)

C (D4) (Account Holder Name)

O (Emirates ID)

C (D4) (Account Holder Name)

O (Trade License number)

C (D4) (Account Holder Name)

  1. Verified by COP (true/false)

C (if verified by KYC or COP)

M

M

C (if verified by KYC or COP)

  1. COP signed response contents

C (if verified by KYC or COP)

M

M

C (if verified by KYC or COP)

P. (Creditor) Merchant Details

  1. Merchant ID

C

C

C

C

  1. Merchant Name

C

C

C

C

  1. Merchant SIC Code

C

C

C

C

  1. Merchant Category Code

C

C

C

C

Q. (Creditor) Supplementary Data

  1. Supplementary Data

O

O

O

O

Additional details and descriptions for each factor can be found in the below spreadsheet:

9.2 LFI Obligations

9.3 Additional TPP Obligations

9.3.1 Details Verification for Merchants onboarded by TPPs

9.3.2 Capturing of Emirates ID

10. Consent Staging

11. Hand-off to LFI

12. Payment Account Selection at LFI

13. Check Is Single Authorization flag

14. Hand-off back to the TPP

15. Payment Status Update

GRC-15.10 Payment Status Model

This figure illustrates the payment status model that can be used to cover the payment status throughout the payment's lifecycle. The model is applicable to all payment types including Single Immediate, Future Dated, Fixed Recurring, Variable Recurring, Fixed On-demand, Variable On-demand, and Variable-defined.

Payment Status New3.png

Payment Status

Description

Payment Status

Description

Pending (ISO 200022 PDNG)

Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status updates will be performed.

Rejected (ISO 200022 RJCT)

The payment initiation has been rejected

Accepted Settlement Completed Debtor Account (ISO 200022 ACSC)

The payment has successfully passed technical validation, customer profile checking, and funds checking. The payment instruction has been accepted for execution and the settlement is now in process.

The amount of the payment has been reserved in the User Account and the payment has been sent through the payment rails for execution. The User Account will be debited in response to successful credit accepted by the recipient LFI. Alternatively, in response to rejected credit from the recipient LFI (or not response), the User Account will be released from the reserved payment amount as per the BAU payment initiation processes of the LFI.

Accepted Credit Settlement Completed (ISO 200022 ACCC)

OR

Accepted Without Posting (ISO 200022 ACWP)

The receiving account holding entity has successfully accepted the credit transfer initiated by the TPP payment instruction and the credit has been posted to the creditor customer’s account.

OR

The receiving account holding entity has successfully accepted the credit transfer initiated by the TPP payment instruction, but the credit has not been posted to the creditor customer’s account yet.

Accepted with change (ISO 200022 ACWC)

The sending LFI has accepted the payment order with changes to the initial order.

16. Confirmation to User

17. Payment Notifications

CRG-17.5 Multi-User Authorization Flow Notifications

In scenarios of multi-user accounts such as shared accounts or corporate accounts where multiple users have delegated authority to approve the payments.

18. Multi-User Authorization Flow

19. Check Authorization Time Window

20. Purpose of Payment

21. Shari’ah compliance of TPP

image-20241220-143145.png

 

22. Supplementary Information

23. TPP Obligations towards Customer Verification

 

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