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 juristinction) both debtor (initiating) payment account and creditor (beneficiary) payment account MUST be in AED.

  • Domestic payments (i.e. payment accounts within the UAE juristinction) 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 juristinction), ALL available currencies supported by LFIs MUST be supported for Open Finance payment initiation. For more informaiton, 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 for 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 perfrom 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 NOT route the Open Finance payments via other payment systems. Instead, LFIs MUST keep the status of the payment to pending and process the payment as normal when IPP is available again.

  • Note: This does not exclude edge cases where the payment value may be applied on a different date than the payment authorization. CBUAE will be monitoring the ecoysystem for these cases to assess whether remediations may be required in the future.

• CRG-1.4.3 In the scenario that IPP does not have the user's date/city of bith registered, the LFIs MUST NOT route the Open Finance payments via other payment systems. Instead, LFIs MUST reject the Open Financen 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.

• keep the status of the payment to pending and process the payment as normal when IPP is available again.

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.