A Consent is an authorisation object that represents a user's explicit permission for a TPP to access their data or initiate services at an LFI. Every protected resource request in UAE Open Finance is bound to a consent — there is no access without one.
There are two types of consent, corresponding to the two service families.
| Type | Used for | Created via |
|---|---|---|
| Bank Data Sharing | Reading account data, balances, transactions, and related resources | authorization_details with type: urn:openfinanceuae:account-access-consent:v2.1 |
| Bank Service Initiation | Initiating payments | authorization_details with type: urn:openfinanceuae:payment-consent:v2.1 |
Before any UserOAuth2Security protected resource can be accessed, a consent must go through a two-phase flow: staging and authorization.
The API Hub maintains all Open Finance consents and acts as the authoritative system of record for consents across the ecosystem. All consent creation, modification, and revocation events are recorded within the API Hub to ensure a single, consistent source of truth.
Whenever a TPP initiates a request to access customer data or initiate a payment, the request is validated against the consent record stored in the API Hub.
To maintain ecosystem-wide consistency, consent updates such as status changes must be synchronised with the API Hub.
Once a consent is staged, the only field under Data that may change is Status. All other Data values are fixed for the lifetime of that consent. Subscription and Meta may be patched, but they sit outside the Data object. See the request/response models in the OpenAPI (e.g. /account-access-consents) for the canonical structure.
If a user needs to change any Data value (for example, to adjust ExpirationDateTime or add or remove a permission), the TPP must create a new consent, revoke the previous one, and link the two via BaseConsentId.
Resources secured with UserOAuth2Security require user involvement — the user must authenticate with the LFI and explicitly authorise the consent before the TPP can access any resource on their behalf.
Two independent conditions must both be satisfied before the API Hub will serve a UserOAuth2Security resource:
Requests must carry a Bearer access token in the Authorization header:
Authorization: Bearer <access_token>Access tokens are short-lived (10-minute lifetime) and are bound to the consent they were issued for. See Tokens & Assertions for the full token lifecycle.
The consent referenced in the access token's authorization_details must be in the Authorized state. The authorization_details object defines the exact scope of access — which permissions are granted, to which endpoints, for which accounts, and for how long.
The API Hub must reject all requests to UserOAuth2Security resources where the associated consent is not in the Authorized state — including consents that are AwaitingAuthorization, Suspended, Expired, Revoked, Rejected, or Consumed.
A consent moves through a defined set of states during its lifecycle. Your application must track these states and respond appropriately — particularly to terminal states, which require a new consent flow.
The initial state for all consents. The TPP has submitted a Rich Authorization Request (RAR) via /par and is waiting for the user to authenticate with the LFI and authorise the consent.
If the LFI requires multiple authorizers (e.g. joint account), the consent remains in AwaitingAuthorization until all required parties have authorized.
The consent has been fully authorized and is active. The TPP may make resource requests referencing this consent.
ConsumedExpirationDateTime reached → ExpiredRevokedSuspendedThe consent leaves Authorized when one of the following occurs:
The consent moves from AwaitingAuthorization to Rejected when:
Terminal state. The TPP must submit a new /par request with a fresh ConsentId to restart the flow.
The LFI moves the consent from Authorized to Suspended when it temporarily blocks access — for example, if the user's Emirates ID has expired and must be renewed before access can be restored.
Once the block is cleared, the LFI must return the consent to Authorized. Not a terminal state.
The consent moves from Authorized to Consumed when the action it covers has been fully used.
Terminal state. Applies only to Service Initiation consents — a Data Sharing consent can never move to Consumed under any circumstances.
The consent moves from Authorized or Suspended to Expired when it reaches its ExpirationDateTime.
Terminal state. The TPP must prompt the user to re-consent and begin a new authorization flow with a new ConsentId.
The consent moves from Authorized or Suspended to Revoked when the user explicitly revokes it — either through the TPP's consent management interface or directly at the LFI.
Terminal state.