This space is deprecated and no longer supported. Please use the latest available version here.
Common Rules and Guidelines
- Chris Michael
This section contains Rules & Guidelines which are common for all Bank Data Sharing and Bank Service Initiation capabilities describe in the UAE Open Finance Standards.
1. Supported Accounts
LFIs MUST:
CRG-1.1 Provide Open Finance APIs to TPPs 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
Examples include: Current, Pre-paid, Electronic Money, Charge Card accounts
Corporate Accounts: Accounts used for the execution of payment transactions provided by LFIs to SMEs & Corporates
Examples include: Current, Pre-paid, Electronic Money, Charge Card accounts
CRG-1.2 Allow Users to authorize consents only for eligible accounts.
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 and provide an Alias. The acceptable Aliases for Users are the following:
Mobile phone number
Email
Any other proxy available in UAE
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
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 payee 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 payee 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. Payee Identification
5. Payer Note
6.Payment Reference
7. Accepted Authorization Type
8. Authorization Time Window
9. Risk Information Block
10. Consent Staging
11. Hand-off to LFI
12. Payment Account Selection at LFI
13. Check Accepted Authorization Type
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.
Payment Status | Description |
|---|---|
Pending (ISO 200022 PDNG) | Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status update 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 on response of successful credit accepted by recipient LFI. Alternatively, on response of 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 instruction 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. |
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
19. Payment Details Saving
20. Check Authorization Time Window
© CBUAE 2024
Open License and Contribution Agreement | Attribution Notice
Please try out our Advanced Search function.