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.

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.

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 https://openfinanceuae.atlassian.net/wiki/spaces/StandardsDraft01standardsv1draft2/pages/3876454652528887/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 https://openfinanceuae.atlassian.net/wiki/spaces/StandardsDraft01standardsv1draft2/pages/3876454652528887/Limits+and+Constants#Max-Inter-bank-Payment-Amount value for all Inter-bank payments.

TPPs MUST:

CRG-4.1 Either allow Users to manually enter/select their Payee 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 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 Payee Identification details.

CRG-4.2 The TPP MUST allow the Payee Identification using one of the following options:

• CRG-4.2.1 Payee identified by IBAN: In this case the information required for the payee is:

  • IBAN of the Payee

  • Name of the Payee

  • The Payee account holding entity. TPPs MUST identify the holding entity by decoding the IBAN and MUST NOT ask Users to provide it or select from a list.

• CRG-4.2.2 Payee identified by Account number: In this case the information required for the payee is:

  • Account number of the Payee. This is the 12 or 14 digits domestic account number of the payee with their bank.

  • Name of the Payee.

  • The Payee account holding entity. TPPs MUST enable Users to identify the holding entity using its trading name which is familiar to Users. The trading name MUST correspond to a valid IBAN Bank Code.

• CRG-4.2.3 Payee identified by Alias: In this case the information required for the payee is:

  • Alias of the Payee. The acceptable Aliases for the payee are the following:

    • Mobile phone number

    • Email

    • Any other proxy available in UAE

  • The Payee account holding entity. TPPs MUST enable Users to identify the holding entity using their trading name which is familiar to Users.

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

TPPs MUST:

CRG-5.1 Allow Users to manually enter a Payer Note. 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 Payer Note is according to the UAE Open Finance Standard specifications. The Payer Note length is limited to https://openfinanceuae.atlassian.net/wiki/spaces/StandardsDraft01standardsv1draft2/pages/3876454652528887/Limits+and+Constants#Max-Payer-Note-Length.

CRG-5.3 Include the Payer Note in each Payment Initiation Request as the default value. This information will not be transferred via the payment rails.

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. payer) using information requested by the beneficiary (i.e. payee) 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. The Payment Reference length is limited to https://openfinanceuae.atlassian.net/wiki/spaces/StandardsDraft01standardsv1draft2/pages/3876454652528887/Limits+and+Constants#Max-Payment-Reference-Length.

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

TPPs MUST:

CRG-7.1 Set the appropriate parameter in the Consent specifying the type of payment authorization that is acceptable by the TPP for their supported use case. The available options are as follows:

• Single Authorization: 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.

• Multi Authorization: The Consent MUST incur a multi-User authorization. This is used when there is clear requirement by the TPP that the Consent on the account to be used needs to be authorized by multiple authorizer Users.

• Both: The Consent can be subject to either a single User authorization or multi-User authorization. This is used when the TPPs are indifferent of either single or multi-authorization.

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 Time Window that can be specified by a TPP is limited to https://openfinanceuae.atlassian.net/wiki/spaces/StandardsDraft01standardsv1draft2/pages/3876454652528887/Limits+and+Constants#Max-Authorization-Time-Window after the Consent has been submitted (i.e. staged) by the TPP for User authorization.

TPPs MUST:

CRG-9.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:

• User (Payer) Indicators: Information related to the User including User Name, Geo Location, Device ID, Date/time of last password change, Date/time onboarded by the TPP

• Destination Delivery Address: Information for all related e-commerce payments, including recipient name and type, full delivery address, with region, and country

• Transaction Indicators: Information in relation to the transaction itself including Customer Present flag, Contract Present flag and initiating Channel

• Beneficiary Indicators: Information in relation to the Beneficiary of the initiated payment including Beneficiary Account Type (Retail or Corporate), Beneficiary Prepopulated by TPP flag, Merchant Details (with Name and SIC code), Merchant Trading Name, Beneficiary Verified by TPP flag and additional Beneficiary Account holder Identifiers (such as a national ID or Passport Number for Retail accounts or business registration number for Business and Corporate accounts).

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 MUST 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 from the point of the Consent resource creation by providing TPPs with a unique Consent Identifier.

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 reject the payment Consent and provide the appropriate error code to the OFP.

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 https://openfinanceuae.atlassian.net/wiki/spaces/StandardsDraft01standardsv1draft2/pages/3915893652527741/Authentication+and+Authorization#5.-Effective-Use-of-Redirection-Screens.

CRG-11.2 Trigger the Authentication & Authorization process with the LFI by using the appropriate API Auth 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.

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 available balance of each payment account in the list, if the purpose is Service Initiation.

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

LFIs MUST:

CRG-13.1 Check the Accepted Authorization Type parameter of the payment Consent against the authorization matrix of the account selected for the payment initiation. If the Consent parameter is set to Single Authorization while the authorization matrix of the selected account requires multiple authorizers then LFIs MUST decline the payment consent and abort the payment journey and redirect the User back to the TPP with an appropriate response.

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

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 (aka “polling” method).

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 on the event of changes in the status of a payment (aka “webhook” method).

• CRG-15.2.1 Setup the asynchronous event notifications (i.e. webhooks) with the OFP during payment Consent Staging step as defined inhttps://openfinanceuae.atlassian.net/wiki/spaces/StandardsDraft01standardsv1draft2/pages/3916098852528830/Common+Rules+and+Guidelines#10.-Consent-Staging in case they want to use this method for status updates.

OFP MUST:

CRG-15.3 Request the LFIs to notify them asynchronously on the event of changes in the status of a payment (aka “webhook” method). The setup the asynchronous event notifications (i.e. webhooks) 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.

CRG-15.5 Respond to payment status query requests from a TPP with any of the following status messages: “Rejected”, “Pending” or “Accepted Settlement Completed" at any point in time during the payment initiation, processing and execution stages of the payment lifecycle for all payment types initiated via a TPP, based on the status information provided by the LFI.

CRG-15.6 Be able to notify the TPPs, asynchronously, about any changes in the status of the payment request. This is applicable when TPPs setup asynchronous event notifications (i.e. webhooks) with the OFP.

CRG-15.7 Respond to payment status query requests from a TPP or provide asynchronous notification, by sending a status of:

• “Accepted Credit Settlement Completed" (ISO code ACCC) when the Recipient LFI confirms that the Payee account has been credited with the funds of the payment initiated via the TPP or

• “Accepted Without Posting” (ISO 200022 ACWP) when the Recipient LFI confirms that it has accepted the payment but has not applied the credit to the Payee account yet.

CRG-15.8 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 .

LFIs MUST:

CRG-15.9 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.10 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 a status of:

• “Rejected”, “Pending” or “Accepted Settlement Completed" at any point in time during the payment initiation, processing and execution stages of the payment lifecycle for all payment types

• “Accepted Credit Settlement Completed" (ISO code ACCC) when the Recipient LFI confirms that the Payee account has been credited with the funds of the payment or

• “Accepted Without Posting” (ISO 200022 ACWP) when the Recipient LFI confirms that it has accepted the payment but has not applied the credit to the Payee account yet.

CRG-15.11 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.

TPPs MUST:

CRG-16.1 Confirm to Users the outcome of their Consent Authorization with the LFI, in case of Long-lived Consents. TPPs MUST include the Consent ID provided by the OFP in their confirmation for reference. The Consent ID presented to the User MUST be user-friendly.

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 https://openfinanceuae.atlassian.net/wiki/spaces/StandardsDraft01standardsv1draft2/pages/3916098852528830/Common+Rules+and+Guidelines#18.-Multi-User-Authorization-Flow.

CRG-16.3 Confirm to Users the outcome of the Service Initiation related to a Single Use Consent based on the payment status received by the OFP.

CRG-16.4 Provide Users with the payment unique identifier Transaction ID and any other additional information in relation to the initiated payment.

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

TPPs MUST:

CRG-17.1 Confirm to Users using notifications the payment outcome of each Service Initiation, if Users are not present during the payment initiation (for example for Long-lived Consent scheduled payments such as FDPs, FRPs, Variable-defined payments). The notifications MUST also include the payment unique identifier Transaction ID and any other additional information in relation to the initiated payment.

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 payee or there is an error in processing the payment

• 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 payee 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.

LFIs MUST:

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

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

TPPs MUST:

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

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 Search for all Service Initiation or Data Sharing Consents provided by business\corporate Users who had their payment account access revoked by the business\corporate. The LFIs MUST inform the OFP to reject any Service Initiation or Data Sharing request in relation to these Consents until the business\corporate User is granted payment account access again or the Consent is revoked by the TPP

CRG-18.5 Keep track of the Authorizers required for the payment Consent and update all related records.

CRG-18.6 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 Authorizer identification

  • the Authorizer's Name

  • 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.7 Be able to notify the OFP about the event of each authorizer in the chain authorizing or rejecting the payment Consent pending further authorization. This is applicable when TPPs setup asynchronous event notifications (i.e. webhooks) with the LFI.

CRG-18.8 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.9 NOT allow any further Service Initiation or Data Sharing requests from a TPP in relation to a payment Consent provided by a business\corporate User who had their payment account access revoked by the business\corporate. This information will be provided to the OFP by the LFIs.

CRG-18.10 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:

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

• For each Authorizer:

  • the Authorizer identification

  • the Authorizer's Name

  • 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.11 Notify the TPPs about the event of each authorizer in the chain authorizing or rejecting the payment Consent pending further authorization. This is applicable when TPPs setup asynchronous event notifications (i.e. webhooks) with the OFP.

TPPs MUST:

CRG-18.12 Request that the Consent to be revoked and terminated by the OFP, if the business\corporate User who provided the Consent had their payment account access revoked by the business\corporate.

TPPs COULD:

CRG-19.1 In cases where TPPs have long-term contractual relationships with the Users, and subject to acquiring Users' consent, TPPs COULD store the below payment details, if the LFIs' response indicated that they are correct. Users, can easily access this stored information for future payment setups.

• Payer Account Provider Name (LFI Name).

• Payer Account Identification.

• Beneficiary LFI Name.

• Beneficiary Name.

• Beneficiary Account Identification details (e.g., account number, full IBAN, any proxies supported by the LFI selected).

LFIs MUST:

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

• CRG-20.1.1 The Authorization Time Window as per https://openfinanceuae.atlassian.net/wiki/spaces/StandardsDraft01standardsv1draft2/pages/3916098852528830/Common+Rules+and+Guidelines#8.-Authorization-Time-Window, if set by the TPP, has expired and the Consent has not been fully authorized.

• CRG-20.1.2 The https://openfinanceuae.atlassian.net/wiki/spaces/StandardsDraft01standardsv1draft2/pages/3876454652528887/Limits+and+Constants#Max-Submitter-Authorization-Time-Window has elapsed and the Consent had not been authorized by any the required authorizer.