This space is deprecated and no longer supported. Please use the latest available version here.
Common Rules and Guidelines
- Chris Michael
- Alexandros Dimitrakoudis
- Manish Haldankar (Deactivated)
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 Note
6.Payment Reference
7. Accepted Authorization Type
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 |
|---|---|---|---|---|
A. User (Payer) Indicators | ||||
| C (if onboarded) | C (if onboarded) | C (if onboarded) | C (if onboarded) |
| C (if customer present) | C (if customer present) | C (if customer present) | C (if customer present) |
| O | O | O | O |
| C (if onboarded) | C (if onboarded) | C (if onboarded) | C (if onboarded) |
B. Transaction Indicators | ||||
| M | M | M | M |
| M | M (Y) | M (Y) | M (Y) |
| M | M | M | M |
C. Destination Delivery Address | ||||
| M (Online), C (Instore) | C (upon availability) | N | M (Online), C (Instore) |
| M (Online), C (Instore) | C (upon availability) | N | M (Online), C (Instore) |
| M (Online), C (Instore) | C (upon availability) | N | M (Online), C (Instore) |
D. Beneficiary Indicators | ||||
| M | M (Retail) | M | M |
| M | M | M | M |
| M | N | N | N |
| C (if verfied by KYC or COP) | N | N | C (if verfied by KYC or COP) |
| C (if verfied by KYC or COP) | M | M | C (if verfied by KYC or COP) |
| 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) |
| 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 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 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. |
|
|
GRC-15.13 Payment Status Model for Bulk and Batch Payments
The status model for the file-payments for Bulk and Batch describes the initiation status and the subsequent execution of the file-payments.
Payment order state model key:
Colour (Style) | Description |
|---|---|
Green (Bold) | Mandatory |
Orange (Italic) | Optional, but recommended |
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
21. Purpose of Payment
22. Shari’ah compliance of TPP
© CBUAE 2024
Open License and Contribution Agreement | Attribution Notice
Please try out our Advanced Search function.