/
Common Rules and Guidelines

This space is deprecated and no longer supported. Please use the latest available version here.

Common Rules and Guidelines

Owned by Chris Michael
Last updated: 12 Jul 2024 by Alexandros Dimitrakoudis
20 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.

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.

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

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

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.

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

4. Payee Identification

5. Payer(Debtor) Reference

6. Creditor Reference

7. Is Single Authorization flag

8. Authorization Time Window

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, as follows:

9.1.1 Payments to Merchants onboarded by TPPs (Pay by Account)

9.1.2 P2P/B2P Payments

9.1.3 Payments-to-self

9.1.4 Payments to Businesses non-onboarded by TPPs

9.1.5 Summary Table

[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 (Payer) Indicators

  1. User Name

C (if onboarded)

C (if onboarded)

C (if onboarded)

C (if onboarded)

  1. Geo Location

C (if customer present)

C (if customer present)

C (if customer present)

C (if customer present)

  1. Device Operating System & Version

O

O

O

O

  1. Date/time onboarded by the TPP

C (if onboarded)

C (if onboarded)

C (if onboarded)

C (if onboarded)

B. Transaction Indicators

  1. Customer Present flag (Y/N)

M

M

M

M

  1. Payee Contract with TPP Present flag (Y/N)

M

M (Y)

M (Y)

M (Y)

  1. Initiating Channel (Web/Mobile)

M

M

M

M

C. Destination Delivery Address

  1. Recipient Type (Individual/Corporate)

M (Online), C (Instore)

C (upon availability)

N

M (Online), C (Instore)

  1. Recipient Name

M (Online), C (Instore)

C (upon availability)

N

M (Online), C (Instore)

  1. Full Delivery Address with region and country

M (Online), C (Instore)

C (upon availability)

N

M (Online), C (Instore)

D. Beneficiary Indicators

  1. Beneficiary Account Type (Retail/Corporate)

M

M (Retail)

M

M

  1. Beneficiary Prepopulated by TPP flag (Y/N)

M

M

M

M

  1. Merchant Trading Name

M

N

N

N

  1. Beneficiary Verified by TPP flag (Y/N)

C (if verified by KYC or COP)

N

N

C (if verified by KYC or COP)

  1. Verified by COP (Y/N)

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)

  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. Merchant Details such as

  • Name

  • SIC code

  • Merchant Identification

  • MCC code

M

N

N

O

9.2 LFI Obligations

9.3 Additional TPP Obligations

9.3.1 Details Verification for Merchants onboarded by TPPs

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.12 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.

Copy of SAMA Generic Payment Process BRs - Algorithm flowchart example (1).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 (ISO 200022 ACSC)

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

Payment instructions included in the credit transfer is accepted without being posted to the creditor customer’s account.

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

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

16. Confirmation to User

17. Payment Notifications

CRG-17.4 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

20. Check Authorization Time Window

21. Purpose of Payment

22. Shari’ah compliance of TPP

Shari'ah compliance of TPP journey.png

 

 

 

© CBUAE 2024
Open License and Contribution Agreement | Attribution Notice