/
Common Rules and Guidelines

Common Rules and Guidelines

Owned by Chris Michael
12 Nov 2024
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.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 jurisdiction) both debtor (initiating) payment account and creditor (beneficiary) payment account MUST be in AED.

    • Domestic payments (i.e. payment accounts within the UAE jurisdiction) 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 jurisdiction), ALL available currencies supported by LFIs MUST be supported for Open Finance payment initiation. For more information, 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 with 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 perform 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 reject the payment and set the status of the payment to the Rejected terminal state.

  • CRG-1.4.3 In the scenario that IPP 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 IPP 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

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.

    • CRG-2.1.1 TPPs MUST use logos and the brand names of the LFIs as they are defined in the Trust Framework Directory.

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 Creditor 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 Creditor 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. Creditor Identification

TPPs MUST:

CRG-4.1 Either allow Users to manually enter/select their Creditor Identification details or pre-populate them for the Users.

Note: It is in the competitive space of TPPs to enable additional services for Users that may provide a 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 Users' list of Authorized Beneficiaries with a specific LFI, making it easier for Users to select the Creditor Identification details.

CRG-4.2 Allow the Creditor Identification using the following information:

  • IBAN of the Creditor payment account

  • Name of the Creditor

Note: Depending on the use case, the Creditor details may not be displayed to Users in full. However, these still need to be part of the payment Consent request sent by the TPP.

CRG-4.3 Display to Users the full IBAN details of the Credit payment account, if these details have been manually entered/provided by the User.

CRG-4.4 Display to Users the masked IBAN (only last 4 digits) of the Credit payment account, if these details have been populated/provided by the TPP (e.g. in case of merchant onboarded by TPPs).

CRG-4.5 Ensure that the format and other validation rules of the Creditor Identification details are correct in case Users manually enter the Creditor Identification details. If incorrect, TPPs MUST request Users to review and re-enter the information.

CRG-4.6 TPPs MUST send the Merchant Category Code where the Creditor is a Merchant onboarded by them.

5. Debtor Reference

TPPs MUST:

CRG-5.1 Allow Users to manually enter a Debtor Reference. This note is for the Users' reference and may be available to Users as additional information in relation to a payment by their LFIs. This information is optional for Users and may not be provided at all.

CRG-5.2 Validate that the format of the Debtor Reference is according to the UAE Open Finance Standard specifications.

CRG-5.3 Append to the Debtor Reference the TPP ID, Merchant ID, BIC for the Creditor Account for payments to Merchants.
CRG-5.4 Append to the Debtor Reference the TPP ID, BIC for the Creditor Account for all other Payments.

CRG-5.5 Include the Debtor Reference in each Payment Initiation Request as the default value. This information will not be transferred via the payment rails. For details on the format of Debtor Reference please refer to Bank Service Initiation OpenAPI

6. Creditor Reference

TPPs MUST:

CRG-6.1 Allow Users to manually enter a Payment Reference or pre-populate it for the Users, depending on the use case. Payment Reference is optional for Users. Payment Reference may be populated by the User (i.e. Debtor) using information requested by the beneficiary (i.e. Creditor) or any other information the User wants to provide to the beneficiary to assist in identifying and reconciling the payment. This information will be transferred via the payment rails to the beneficiary’s LFI, if different than the User’s LFI.

Note: TPPs may make the Payment Reference mandatory based on their specific use cases or business requirements (for example credit card payment, invoice payments, etc)

CRG-6.2 Validate that the format of the Payment Reference is according to the UAE Open Finance Standard specifications.

CRG-6.3 Include the Payment Reference in the Payment Initiation Request as the default value. The Payment Reference will be used by the LFI to populate the Remittance Information of the payment.

For details on the format of Creditor Reference please refer to Bank Service Initiation OpenAPI

7. Is Single Authorization flag

TPPs MUST:

CRG-7.1 Set Is Single Authorization flag in the Consent to specify that the Consent MUST be subject to single User authorization only. This is used when there is a clear requirement that the Consent on the account to be used cannot be subject to multiple User authorizations.

8. Authorization Expiration Date Time

TPPs MUST:

CRG-8.1 Have the option to set the appropriate parameter in the Consent specifying the time window during which the Consent MUST be authorized by all required authorizers (one or multiple). The Authorization Expiration Date Time that can be specified by a TPP is limited to Limits and Constants | Max Authorization Time Window after the Consent has been submitted (i.e. staged) by the TPP for User authorization.

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.

TPPs MUST:

CRG-9.1.1 Set ALL the available data in the Risk Information Block in order to provide additional information in relation to the Payment Consent and allow LFI to assess their risk. This includes the following information as shown in the table below, based on the type of payment/use case. The information MUST be provided as per the following requirements:

  • 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 (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 fAdditional details and descriptions for each risk factor can be found found in the below spreadsheet:

9.2 LFI Obligations

LFIs MUST:

CRG-9.2.1 Use all the available information of the Risk Information Block provided by the TPP for their risk profile analysis of the Payment Consent or a Payment Initiation in a non-discriminatory way of Open Finance initiated payments compared to payments initiated by other LFI channels such as online or mobile banking.

9.3 Additional TPP Obligations

9.3.1 Details Verification for Merchants onboarded by TPPs

TPPs MUST:

CRG-9.3.1.1 Ensure that all Merchants onboarded follow KYC/KYB compliant processes. In addition to all other information the following Merchant details MUST be verified:

  • Merchant’s Trading Name

  • Merchant’s Bank Account details

  • All other Merchant details are included in the Risk Information Block as defined in Common Rules and Guidelines | 9.1 TPP Obligations for the Payments to Merchants onboarded by TPPs (Pay by Account) type of payments.

Note: TPPs will be populating some of this information in the Risk Information Block when submitting Payment Initiation requests.

9.3.2 Capturing of Emirates ID

TPPs MUST:

CRG-9.3.2.1 Capture a user's Emirates ID for all payments where a long-lived consent is required.

CRG-9.3.2.2 Capture a user's Emirates ID for all data sharing use cases where transaction data is shared, regardless of the consent type.

CRG-9.3.2.3 Capture the user’s Emirates ID prior to initiating the prescribed user journey for the relevant use case.

  • When a user is known to the TPP, the Emirates ID can be captured during onboarding.

  • When a user is unknown to the TPP, the Emirates ID can be captured prior to the consent customer journey.

Note: TPPs are not required to verify the Emirates ID.

10. Consent Staging

TPPs MUST:

CRG-10.1 Provide all the payment Consent parameters to OFP before redirecting Users to LFIs for authentication and proceed with payment Consent confirmation/authorization.

CRG-10.2 Setup the asynchronous event notifications (i.e. webhooks) with the OFP during this stage, in case TPPs want to use this method for any Consent or payment status updates.

OFP MUST:

CRG-10.3 Check the payment Consent parameters and validate their format and compliance to business rules.

CRG-10.4 Connect to the LFI and request the LFI to perform additional Consent parameter validations.

CRG-10.5 Reject the payment Consent and provide the appropriate error message to TPPs, if any of these validations performed fail.

CRG-10.6 Allow TPPs to retrieve information about the status of the Consent at any point in time.

LFIs MUST:

CRG-10.7 Check the payment Consent parameters requested by the OFP and validate them. If these are not validated, then LFIs MUST provide the appropriate error code to the OFP.

11. Hand-off to LFI

TPPs MUST:

CRG-11.1 Provide messaging to inform Users that they will be redirected to their LFIs to complete the payment Consent authorization.

Note: For guidelines on generic TPP to LFI redirection screens and messages, please refer to section Authentication and Authorization | 5. Effective Use of Redirection Screens.

CRG-11.2 Trigger the Authentication & Authorization process with the LFI by using the LFI's authorization endpoint.

LFIs MUST:

CRG-11.3 NOT present any additional inbound redirection screens.

CRG-11.4 Request the details included in the staged Consent from the OFP

OFP MUST:

CRG-11.5 Provide the Consent details to the LFIs based on the unique Consent identifier.

LFIs MUST:

CRG-11.6 Initiate the User Authentication process.

12. Payment Account Selection at LFI

LFIs MUST:

CRG-12.1 Enable Users, after authentication, to select the payment account for the payment Consent from a list of their available payment accounts, if the payment Consent parameters do not contain this information. The payment accounts displayed to the User MUST be eligible for account information or initiating payments via online and mobile banking channels and have no AML or other related restrictions.

CRG-12.2 Display to Users the interim available balance including all credit lines and arranged overdrafts of each payment account in the list, if the purpose is Service Initiation.

CRG-12.3 Provide Users with the ability to cancel the payment journey, if Users decide to terminate the request. The LFI MUST hand-off the Users back to the TPP, providing the necessary error message to the TPP.

13. Check Is Single Authorization flag

LFIs MUST:

CRG-13.1 Check if Is Single Authorization flag of the payment Consent is set against the authorization matrix of the account selected for the payment initiation. If the flag is set while the authorization matrix of the selected account requires multiple authorizers then LFIs MUST only display accounts that require single Authorization. If none exists, LFIs MUST decline the payment consent and cancel the payment journey and redirect the User back to the TPP with an appropriate response.

14. Hand-off back to the TPP

LFIs MUST:

CRG-14.1 Confirm to the OFP that the interaction session is now completed.

OFP MUST:

CRG-14.2 Initiate the User Redirection process by providing all necessary information to the LFI (including the required Authorization code)

LFIs MUST:

CRG-14.3 Provide messaging to inform Users that they will be taken back to their TPP.

CRG-14.4 Redirect Users to the TPP immediately after receiving the required information from the OFP.

15. Payment Status Update

TPPs MUST:

CRG-15.1 Check with the OFP for the status of a payment at various points in time throughout the payment lifecycle. The frequency of these queries to the OFP MUST be subject to fair usage policies. This is applicable in cases where TPPs are using the method of querying the payment status from the OFP.

CRG-15.2 Have the option to be notified by the OFP of the payment request status change when it occurs without requiring to query the OFP. This is only applicable in cases where TPPs selected to use the method of requesting the OFP to notify them asynchronously in the event of changes in the status of a payment.

OFP MUST:

CRG-15.3 Request the LFIs to notify it asynchronously on the event of changes in the status of a payment. The setup the asynchronous event notifications with the LFI will take place during the payment Consent staging.

CRG-15.4 Update the status of each payment initiated by the TPP throughout the payment lifecycle with the appropriate status value based on its progress through payment initiation processing and execution as provided by the LFI.

  • 15.4.1 Check if the status of the payment has been set to ‘Rejected. In this case:

    • For all payments related to a VRP Consent, the OFP MUST decrement:

      • the cumulative Total Number of payments by 1 and,

      • the cumulative Total Value of payments by the value of the payment

    • For all payments related to a VRP Consent where a Control Period is set, the OFP MUST decrement:

      • the cumulative Total Number of payments per Control Period and,

      • the cumulative Total Value of payments per Control Period.

CRG-15.5 Respond to payment status query requests from a TPP with the appropriate status codes as listed below in section Common Rules and Guidelines | GRC 15.10 Payment Status Model based on the status information provided by the LFI.

CRG-15.6 Return to the TPP, in addition to the payment status, other payment system-specific status codes and payment rejection reasons codes as specified in the UAE Open Finance Standard specifications.

LFIs MUST:

CRG-15.7 Update the status of each payment initiated by the OFP throughout the payment lifecycle with the appropriate status value based on its progress through payment initiation processing and execution.

CRG-15.8 Be able to notify the OFP asynchronously about any changes in the status of the payment request. More specifically, LFIs MUST provide asynchronous notification to the OFP by sending the appropriate status codes as listed below in section Common Rules and Guidelines | GRC 15.10 Payment Status Model,

CRG-15.9 Return to the OFP in addition to the payment status, other payment system-specific status codes and payment rejection reasons codes as specified in the UAE Open Finance Standard specifications.

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.

Note: In relation to Payment execution, once the Debtor's LFI has performed all process steps and checks, the payment can be placed in the infrastructure of the chosen payment rails, processed and passed on to the Creditor's LFI. Receiving a payment status message from the Creditor's LFI is dependent upon the payment rails used whether the Creditor's LFI can send a confirmation status that the payment has been received, accepted or rejected and if the Creditor's account has been credited.

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

TPPs MUST:

CRG-16.1 Confirm to Users the outcome of their Consent Authorization with the LFI, in case of Long-lived Consents.

CRG-16.2 Inform Users if further authorizations are required for the Consent and provide additional information about the Authorizers supplied by the OFP as described in Common Rules and Guidelines | 18. Multi User Authorization Flow.

CRG-16.3 Confirm to Users the outcome of the Service Initiation based on the payment status received by the OFP.

CRG-16.4 Confirm the payment outcome to Users using confirmation screens in line with the customer journey, for every Service Initiation that Users are present.

17. Payment Notifications

TPPs MUST:

CRG-17.1 Send a notification on the outcome of each Service Initiation to the beneficiary, if the beneficiary is onboarded by the TPP.

  • 17.1.1 Notify the debtor about any upcoming scheduled payments, including fixed future payments, future variable payments, and recurring payments one day before the payment date. The notification must include details of the payment amount, date, and beneficiary and should be delivered through the same channels used for payment-related notifications (e.g., SMS, email, app notifications).

LFIs MUST:

CRG-17.2 Send a notification to Users on the success or failure of a Service Initiation in the following scenarios:

  • A Single Use Consent payment is initiated by Users and is either successfully received by the Creditor or there is an error in processing the payment. This may include Single Instant Payments or Future Dated Payments.

  • A Long-lived Consent is set up by Users, including information of the TPP or beneficiary party on behalf of the TPP which acquired the User Consent

  • A Service Initiation request as part of a Long-lived Consent submitted by the TPP is either successfully received by the Creditor or there is an error in processing the payment

CRG-17.3 Use SMS as a minimum channel to notify Users and optionally any other allowable channels (e.g. email, app notifications) currently used for account access or payment-related notifications to their customers depending on UAE rules and regulations, for all Open Finance related notifications to Users.

CRG-17.4 Identify in the notifications the TPP initiating the payment, the beneficiary of the payment and additionally include the information provided in the on-behalf field.

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.

LFIs MUST:

CRG-17.5.1 Inform all Users about the submission of a payment Consent for authorization.

CRG-17.5.2 Notify the other authorizers about any Single Use or Long-lived Consent that is pending their authorization, using all of the existing channels (e.g. SMS, email, app notifications) currently used for payment-related authorizations.

TPPs MUST:

CRG-17.5.3 Notify the Users of the updated status of the multi-user authorization received from the OFP, displaying the authorizers who have accepted, rejected or still have to authorize the payment.

18. Multi-User Authorization Flow

The rules in this section are additional rules intended to cover authorization cases for multi-user payment initiation from payment accounts.

LFIs MUST:

CRG-18.1 Respond to the payment Consent request staged by the TPP with the OFP by providing an appropriate message to inform the User that the payment Consent to initiate one or more payments via the TPP is received by the LFI but is subject to further authorization. It is in the domain of the LFIs to determine how to do this in alignment with their own businesses' journeys.

CRG-18.2 Allow Users to use the payment initiation services if it is permitted within their user authority for the account, as defined by the LFI. In cases of shared personal accounts, a User will be able to initiate a payment Consent using a TPP, subject to having credentials with the LFI and the authority to initiate payments via the LFI’s channels under their profile permissions.

CRG-18.3 Allow a User acting with delegated user authority on behalf of a business, to only use the Service Initiation, if this is permitted within the parameters of the delegated user authority and appropriate profile permissions. Payment Consent requests MUST be resolved by the LFI in line with the entitlements (i.e. access privileges) held by each specific business\corporate user. These entitlements may be set via approvals from authorized signatories of the business\corporate entities, and LFIs are assumed to have these processes already.

CRG-18.4 Inform the OFP about the requirement for multiple authorizations of the staged payment consent. LFIs MUST make available to the OFP via the payment Consent further information in relation to multi-authorization process. This information includes:

  • The total number of Authorizers required for the payment Consent to be fully authorized

  • For each Authorizer:

    • the Type of Authorizer (for example, Financial, Manager, Director, Accountant etc.)

    • the date and time of when the Authorizer actioned the payment Consent

    • the status reflecting the Authorizer's final decision regarding the payment Consent (i.e. Pending, Approved or Rejected)

CRG-18.5 Be able to notify the OFP about the event of each authorizer in the chain authorizing or rejecting the payment Consent pending further authorization.

CRG-18.6 Change the state of the payment Consent with the OFP from Awaiting Authorization to Authorized when all Authorizers (one or more) have authorized the payment Consent.

OFP MUST:

CRG-18.7 Inform the TPP about the requirement for multiple authorizations of the staged payment consent. The OFP MUST make available to the TPPs via the payment Consent further information in relation to multi-authorization process. This information includes:

  • All the information received from the LFI

  • For each Authorizer:

    • the Type of Authorizer (for example, Financial, Manager, Director, Accountant etc.)

    • the date and time of when the Authorizer actioned the payment Consent

    • the status reflecting the Authorizer's final decision regarding the payment Consent (i.e. Pending, Approved or Rejected)

CRG-18.8 Notify the TPPs about the event of each authorizer in the chain authorizing or rejecting the payment Consent pending further authorization.

19. Check Authorization Time Window

OFP MUST:

CRG-19.1 Reject a Consent Awaiting Authorization and move it to the terminal state in the following cases:

20. Purpose of Payment

TPPs MUST:

CRG-20.1 Support all category purpose codes including their descriptions as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft1/pages/244224050/Limits+and+Constants#Payment-Purpose-Codes of the UAE Open Finance Standard.

CRG-20.2 Either allow Users to select the available purpose of payment from a list or pre-populate it for Users.

CRG-20.3 Ensure and validate that the format of the payment purpose is according to the UAE Open Finance Standard.

21. Shari’ah compliance of TPP

Shari'ah compliance of TPP journey.png

TPPs MUST:

CRG-21.1 Provide information about their Shari’ah compliance when they are onboarded on the Open Finance Trust Framework OFTF.

OFP MUST:

CRG-21.2 Retrieve the information on the Shari’ah compliance of the TPP on receiving a Data Sharing or Service Initiation consent request from the TPP and pass this information to the LFI along with the consent request.

LFIs MUST:

CRG 21.3 Check for any information available on the Shari’ah compliance of the TPP in the consent request. If this information is present in the consent request then the LFI must present this information on the consent authorization screen.

CRG 21.4 Display the Shari’ah compliance information about the TPP, if available, on the consent dashboard against each consent

22. Supplementary Information

LFIs MUST:

22.1 Determine the situations where Supplementary Information is required to be shown to Users, keeping consideration of the https://openfinanceuae.atlassian.net/wiki/x/-YCQD that LFIs MUST maintain on the Open Finance journeys. Supplementary Information may be required in the following cases:

  • Where fees, charges or Forex apply (e.g. international payments)

  • Where interest rates apply

  • To display a warning to Users that the relevant payment account will become overdrawn / exceed an overdraft limit as a result of the intended payment

  • To show value-add information based on functionality implemented by LFIs in competitive space which provides positive customer outcome (e.g. cashflow prediction engine) 

  • Where the payments may be duplicated by the User in a short period (e.g. LFI may display a warning that payment appears to be duplicated)

  • To display fraud alerts to Users in relation to a specific Creditor or other general fraud alert occurrences which will also appear in the LFI’s direct online channels.

Note: The above list in only indicative and not exhaustive as there many other scenarios where LFIs may be presenting Supplementary Information to Users.

23. TPP Obligations towards Customer Verification

TPPs MUST:

CRG-23.1 ensure that proper KYC is carried out when Users are onboarded for any customer facing product that leverages Open Finance and has a regulatory requirement for KYC ( wallet, remittance app etc.)

CRG-23.2 ensure that some basic verification is carried out when Users are onboarded for any product that leverages Open Finance ( email, mobile number verification)

CRG-23.3 have the capability, within customer-facing product that supports multiple users within the same account, to create profiles with different sets of permissions. Certain profiles should be able to use specific OF features like authorizing a new Service/Data Request consent or using a Long-Lived consent setup by some other user with that account.

 

Related content

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