Payments with Delegated Authentication
- Chris Michael
1. Overview
Payments using Delegated Authentication is the capability enabled by Open Finance wherein the TPP can request the user for a one-time setup of a long-lived payment consent by authenticating and authorizing it with their LFI. Unlike the Multi Payments setup, this is an open-ended consent. The controls on the allowable beneficiaries, and limits on transaction frequency are not pre-defined as part of the initial setup with the LFI. These are defined and managed by the TPP. Given the nature of the consent, the TPP will bear liability for a range of disputes that arise as a result of the transactions initiated using this capability. The liability details will be covered under the Liability framework.
The Payments scope is targeted to domestic creditor accounts (i.e. creditor accounts offered by LFIs located in UAE) and payments in local currency as used by the local payment systems infrastructure for domestic payments. Common Rules and Guidelines | 1. Supported Accounts & Payment Rails
1.1. Long-Lived Payment Consent
The Long-lived consent type is further categorized based on the consent payment parameters as shown in the following table:
Consent Type | Beneficiaries | Payment Amount | Payment Schedule | Payment limits | Typical Usage Examples |
|---|---|---|---|---|---|
Long-lived | Variable
| Variable | Variable | None (except LFI BAU limits) | Contactless merchant payments, Payments using automated number plate recognition |
1.2 Debtor and Creditor Segments
The scope of the Multi-Payments bank service initiation related to the segments of debtors and Creditors is shown below:
Debtor | Creditor | ||||
|---|---|---|---|---|---|
Consumer | SME | Corporate | Consumer | SME | Corporate |
1.3 User Story
User Story
As a User (Consumer or Business),
I want to provide my consent to a TPP to set up Open Finance as a frictionless payment method by authorizing with my LFI,
so that I can arrange to make ad-hoc payments to different beneficiaries with variable amounts without having to explicitly set these up with my LFI.
1.4 Prerequisites for Payments with Delegated Authentication
With the Delegated Secure Customer Authentication (SCA) model, the TPP is responsible for securely authenticating the user using a SCA process for each payment initiation, leveraging a long-lived consent agreement established with the user, that also triggers the liability shift (see Limitation of Liability Model)for the SCA activities from the LFI. Authentication factors are categorized based on:
Knowledge: Something only the user knows
Possession: Something only the user possesses
Inherence: Something unique to the user’s physical characteristics
1.4.1 The authentication methods are limited to the following:
User biometrics on a mobile device: such as fingerprint or facial recognition executed on the customer’s device, where a TPP app is also bound
Dynamic tokens on a mobile device: generated by authenticator apps (e.g., Authy, Google Authenticator, Microsoft Authenticator) on the customer’s device, where a TPP app is also bound
NFC-based trigger on a mobile device: used as a possession factor through Near Field Communication for secure, contactless verification, on the customer’s device, where a TPP app is bound and logged in
NFC based trigger on another IoT device: The device holds credentials that can be used to verify the User identity, provisioned in conjunction with a TPP service. The device MUST have a biometric capability, a means to securely store a private key that is uniquely linked to the User, and can only be activated on presentment of a supported biometric gesture linked to the device.
The TPP application can support biometric authentication and a secondary authentication method, such as a PIN. If biometric authentication fails or is unavailable for the user, the secondary authentication method can be provided as an alternative.
In this model, TPPs can choose from the following approaches to authenticate the user:
Implement their own SCA solution, managing user onboarding and authentication.
Leverage SCA solution provided by a recognized Identity Service Provider (ISP), such as UAEPass or biometrics on mobile devices, to authenticate and verify the user for each transaction.
The factors used by TPPs MUST be in alignment with the list of required evidence that will be listed in the liability model. For more details on SCA please refer to Strong Customer Authentication Guidelines
1.5 Balance Check Permission
The long-lived Consent can be extended to include optional permission for Balance Check which allows the TPP to check the balance of the User’s Payment account before initiating a payment as part of this consent.
This capability allows the TPP
check the balance in advance of payment to be initiated as part of this consent and ask the user to take remedial action if the funds are insufficient.
display the balance to the user at the point of initiating a payment.
2. User Journey
3. Customer Experience
3.1. Consent Setup
# | Step | Rules & Guidelines |
|---|---|---|
MPCS-1 | Consent setup | Basic Consent Parameters TPPs MUST: 1.1 Enable Users to provide and review the parameters related to the initiation of a series of Multi-Payments they need to consent to. These parameters include:
|
| Additional Consent Parameters 1.2 Set the Accepted Authorization Type (as per Common Rules and Guidelines | 7. Is Single Authorization flag ). 1.3 Set the Authorization Time Window (as per Common Rules and Guidelines | 8. Authorization Time Window) if there are specific timing requirements that must be met for the consent authorization. This is also relevant to cases where multiple authorizers are required to authorize the payment consent. 1.4 Set the Risk Information Block (as per Common Rules and Guidelines | 9. Risk Information Block) | |
| 1.5 Enable Users to provide explicit consent for the initiation of future Payments from their online payment account held at their LFI as specified in the consent. | |
| Balance Check Permission 1.6 Request permission to check the balance of the payment account before initiating a payment. Payments with Delegated Authentication | 4. Balance Check | |
MPCS-2 | Consent Staging | |
MPCS-3 | Hand-off to LFI | As per Common Rules and Guidelines | 11. Hand off to LFI Example wording to use: ‘We will securely transfer to YOUR LFI to authenticate and authorize your payments setup“. |
MPCS-4 | Authentication | LFI Authentication Only As per the following sections: |
Centralized Authentication and Authorization (Federated) Only | ||
MPCS-5 | Authorization | LFIs MUST: 5.1 Enable Users to authenticate using Multi-Factor Authentication (MFA) in order to review and authorize the long-lived payment Consent. 5.2 Retrieve from the OFP the payment Consent details staged by the TPP using the unique Consent Identifier. 5.3 Allow Users to select a payment account for the initiation of the payments, if this was not provided in the retrieved staged Payment Consent details as per Common Rules and Guidelines | 12. Payment Account Selection at LFI
5.4 Only present additional screens, if necessary to allow the validation and confirmation of the payment Consent. 5.5 NOT earmark (i.e. block) any funds related to the payment Consent in the Users' payment account at the point of Consent authorization. 5.6 Check the authorization status of the selected payment account is in accordance with the TPPs' Accepted Authorization Type as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft1/pages/244223957/Common+Rules+and+Guidelines#13.-Check-Accepted-Authorization-Type. 5.7 Display to Users the TPP Trading Name of the TPP that initiated the long-lived payment Consent.
5.8 Present to Users the following minimum required information for authorizing the long-lived payments Consent:
5.9 Request for Balance Check Permission: If the TPP has requested permission to check the balance of the User’s payment account. 5.10 Change the state of the payment Consent from Awaiting Authorization to Authorized when all Authorizers (one or more) have authorized the payment Consent. 5.11 Update the payment Consent details stored in the OFP with all the information included in the payment Consent authorized by the User. |
| OFP MUST: 5.12 Check the Authorization Time window is valid as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft1/pages/244223957/Common+Rules+and+Guidelines#19.-Check-Authorization-Time-Window. 5.13 Confirm back to the LFIs that the payment Consent details have been updated successfully. 5.14 Start tracking the Consent Control Parameters for the Control Period at the Control Period Start Date, if provided, or the Consent creation Date otherwise. The Control Period starts from 00:00:00 of the day and ends at 23:59:59 of the Control Period end day, calculated based on the Control Period type as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft1/pages/244222022/Multi-Payments#6.3.2-VRP-Consent-Control-Period-%26-Start-Date. | |
| Multi-Authorization Journey Only | |
MPCS-6 | Hand-off back to the TPP | |
MPCS-7 | Confirmation to User |
4. Balance Check
# | Step | Rules & Guidelines |
|---|---|---|
DELBAL-1 | Balance Check | TPPs MUST: 1.1 be able to request the balance information using the authorized long-lived consent before initiating the payment. 1.2 Use this capability only in relation to the payment initiation step. 1.3 not use this capability as an alternative for Account Information Service, for example, to satisfy use cases like Personal finance manager where the account balance is being refreshed periodically. |
DELBAL-2 |
| LFIs MUST: 2.1 Provide the OFP with the the information related to the balance of the User's account which was used for authorizing the Long-lived Payment consent. This information must be the same information as defined under the Balances in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft1/pages/244223677/Customer+Data#6.3-Data-Cluster-Structure-%26-Language |
DELBAL-3 |
| OFP MUST: 3.1 Provide the TPP with all the available information in relation to the balance check request. 3.2 Send an appropriate error response to the TPPs in case the balance check request is not successful. |
5. Payment Control at TPP
# | Step | Rules & Guidelines |
|---|---|---|
DELPC-1 | Control Parameters | TPPs MUST: 1.1 provide the capability within the TPP app for the user to setup and manage the control parameters associated with the payments initiated with Long-Lived consent. These are not included during the consent requested for the authorization with the LFI. These cannot be validated by the LFI/OFP. These MUST be available for the User within the TPP application
1.2 display to the user
1.3 provide the ability to revoke the consent 1.4 Implement any of the Action-Based Controls to govern the execution of VRPs. These controls must ensure that only specific, predefined actions can trigger a transaction without additional customer authorization.
Any unusual or unexpected actions, such as transactions with significantly higher amounts or non-typical service charges, must require explicit customer approval before payment is processed. Clearly explain to customers the implications of these Action-Based Controls at the time of onboarding or during any update to the payment consent. This explanation should include:
The TPP must ensure that customers fully understand how these controls affect the payment process and their role in managing their consent for different types of transactions. |
6. Payment Initiation
# | Step | Rules & Guidelines |
|---|---|---|
DELPI-1 | Payment Initiation | TPPs MUST: 1.1 Present to Users for each payment initiation the following minimum required information:
1.2 Ensure that the Creditor details are verified as specified in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft1/pages/244222867/Confirmation+of+Payee#3.3.1-Rules-%26-Guidelines 1.3 Ensure that all required authorization conditions as agreed with the User during the Consent setup are met. 1.4 Generate a unique identifier for the transaction that links the User’s authorization factors with the payment details (i.e. amount and creditor identification). TPPs MUST generate an audit trail of the User’s payment initiation actions during the session. TPPs MUST have all required records as evidence required as listed in the liability model. 1.5 Provide Users the ability to abort the payment journey, if Users decide to terminate the request. |
| TPPs MUST: 1.6 Enable Users to authenticate using Multi-Factor Authentication (MFA) to review and authorize the payment. 1.7 Submit to OFP payment initiation requests with the same fixed parameters as per the long-lived Payment Consent authorized by the User. 1.8 Submit to OFP payment initiation requests with variable parameters within the allowable limits of the Consent Controls as per the long-lived Payment Consent authorized by the User. 1.9 Include in each of the payment initiation requests a Payment Reference for every payment initiated under the long-lived Payment Consent based on the requirements of the TPPs or their servicing customers. 1.10 Include all the details specified in the Risk Information Block https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft1/pages/244223957/Common+Rules+and+Guidelines#9.1-TPP-Obligations | |
| TPPs MUST: 1.11 NOT submit any payment initiation requests which are outside the limits which are configured by the User as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft1/pages/edit-v2/244223133#5.-Payment-Control-at-TPP | |
DELPI-2 | Processing of Payment Initiation Requests | OFP MUST: 2.1 Allow the TPPs to submit individual payment initiation requests under the long-lived Payment Consent authorized by the User, without any additional MFA or authorization from the User. 2.2 Check that the received payment initiation requests relate to a valid long-lived Payment Consent authorized by the User. The Consent MUST be in the Authorized state. The OFP MUST reject any payment initiation messages related to a Payment Consent in a different state (e.g. expired) and respond back to the TPP with the appropriate error message/code. 2.3 Check the payment initiation request parameters against the authorized long-lived Payment Consent. More specifically, the OFP MUST check the following:
|
| OFP MUST: 2.4 Allow the description of the Payment Reference in the submitted payment initiation request to be different than the one defined in the Payment Reference of the long-lived Payment Consent. 2.5 Reject the payment initiation and provide the necessary error message to the TPP if any other checks of the payment initiation request parameters fails against Consent parameters of the authorized long-lived Payment Consent. 2.6 Send a payment initiation request to the LFI for initiating an instant payment using the payment parameters included in the payment initiation request including:
| |
| LFIs MUST: 2.7 Allow the OFP to submit the payment initiation request without any additional MFA or authorization from the User.https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft1/pages/244223133/Payments+with+Delegated+Authentication#1.5.3.2-Multifactor-Authentication 2.8 Additionally apply all existing BAU payment account controls and limits such as single transaction value limit, total transaction value limit, AML checking (if applicable) and others, as if the payment request has been initiated by the existing channels of the LFI. LFIs MUST send an appropriate error response to the OFP in case the payment is rejected due to violating any of these limits or checks. 2.9 Trigger the payment initiation process immediately after receiving the payment initiation request from the OFP.”
2.10 Reject the payment initiation if the payment account selected for the payment has insufficient funds. The OFP MUST be notified about this rejection with an appropriate error message. 2.11 Subject to successful BAU checking, validation and payment processing, proceed with the execution of the payment by either submitting the payment to the underlying payment rails or executing internally as Intra-bank payment. 2.12 Provide the OFP with all the available information in relation to the initiated payment instruction including the payment’s unique identifier Payment Transaction ID. | |
OFP MUST: 2.13 Send an appropriate error response to the TPPs in case the payment is rejected due to violating any of the LFIs BAU payment accounts checks or limits. 2.14 Send to the TPP the appropriate error message in case the payment payment initiation was rejected by the LFI due to insufficient funds in the selected payment account. 2.15 Provide the TPP with all the available information in relation to the initiated payment instruction including the payment’s unique identifier Payment Transaction ID. | ||
DELPI-3 | Payment Status Update | |
DELPI-4 | Payment Notifications |
7. Consent Updates with LFI
# | Step | Rules |
|---|---|---|
DELCU-1 | Consent Update | TPPs MUST: 1.1 Enable Users to use the Consent Dashboard to amend the following parameters of a long-lived Payment consent:
1.2 Require the Users to authenticate with their LFI and authorize the Consent update. |
8. Wallet Use Case
The diagram illustrates the setup of consent for Payments with Delegated Authentication for a payment wallet use case.
The wallet enables users to make contactless payments to merchants. Users can add their Credit/Debit cards or link a Bank Account as a payment option.
When the user selects the bank account option they will be taken through the Open Finance setup journey as explained in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft1/pages/244223133/Payments+with+Delegated+Authentication#3.1.-Consent-Setup. Once the user authorizes the consent they can start making contactless payments where the payments will be initiated using Open Finance from their connected account.
© CBUAE 2024-2025
Open License and Contribution Agreement | Attribution Notice
Please try out our Advanced Search function.