| Expand | ||||
|---|---|---|---|---|
| ||||
|
1. Introduction
This document aims to explain the role of the Trust Framework in the Open Finance UAE Program and how technical users from LFIs and TPPs are expected to interact with it. Its content is derived from the https://docs.connect.raidiam.io/ Documentation, which is referenced multiple times within this document.
The Sandbox Trust Framework can be accessed at the following link:
Web Application : https://web.sandbox.directory.openfinance.ae/
OIDC Discovery API : https://auth.sandbox.directory.openfinance.ae/.well-known/openid-configuration
...
Sign Participation Documents
To fully onboard on the Ecosystem all participants - LFIs, TPPs and VASPs, are expected to issue and sign the Ecosystem participation Document on Docusign.
Ensure Server Certificates are Valid:
Generate transport, signing and encryption certificates on the Trust Framework; rotating them at least once every 12 months (certificate expiration is set at 13 months).
Ensure Published APIs are Valid and Certified:
Publish the API endpoints and ensure the correct version is available before any defined ecosystem go-live date.
Ensure server metadata is always up to date, including server logo, server description and customer-facing name.
Integrate with Directory for Onboarding:
Integrate with the Trust Framework registration endpoints, ensuring all clients registered are onboarded and validated following the ecosystem Registration Framework
Integrate Authentication:
Integrate with the Trust Framework JWKS endpoints, recovering client public keys when validating message signatures and executing message encryption.
Integrate with the Directory OCSP/CRL services, verifying that used certificates are valid and up-to-date.
...
The interaction rules between clients and Authorization Server endpoints are outlined in the CBUAE FAPI 2.0 Standards.
4.4.1 What is a Server
...
The Server Resource within the Trust Framework allows organizations to register their OAuth 2.0 Authorization Servers (OpenID Providers), which are responsible for managing client access to participant-protected APIs.
Large LFIs (Licensed Financial Institutions or LFIs) and TPPs will use the following fields to provide information about the server to existing users. These fields should be filled out with relevant information that accurately describes the services and the application to ensure optimal discovery by the end users.
...
Field Name
...
Field Description
...
Example
...
Customer Friendly Name
...
The name of the financial institution branch/segment/service as it will appear to end users.
...
Global Finance - Private Banking
...
Description
...
A detailed description of the financial institution, highlighting its key features, services, and benefits. This should give users a comprehensive understanding of what the financial institution offers and how it can support service providers.
...
Global Financial Services is a leading financial institution offering a wide range of services including savings and checking accounts, loans, mortgages, and investment services. The institution is dedicated to providing secure and efficient financial solutions for individuals and businesses.
...
Portal URI
...
The URL pointing to the financial institution’s portal, directing users to a webpage where they can find more information about the services provided by the institution.
...
https://globalfinancialservices.com
...
Logo URI
...
The URL pointing to the financial institution’s logo in PNG or JPEG format. This logo will be displayed alongside the financial institution name and description on the platform, providing a visual identifier for users.
...
https://www.centralbank.ae/media/ouxfisxh/banner-text-en-july28-1.png
Once registered in the Trust Framework, the Authorization Server can be recovered via the Trust Framework APIs, notably the Participants Public API.
Instructions on how to register an Authorization Server can be found at https://docs.connect.raidiam.io/add-data-provider
4.4.2 Registering API Resources
Participants can register https://docs.connect.raidiam.io/xwL5-api-resources for the products and services they offer on the schema. Only approved API endpoints and versions for go-live should be added to the Trust Framework.
Instructions on how to add and maintain API resources are available at https://docs.connect.raidiam.io/manage-apis-for-discovery-and-integration
Details about the API resources can be obtained through the same Participants Public API accessible under - https://data.directory.openfinance.ae/participants
4.4.3 Registering Certifications
LFIs are required to register their acquired certifications under the “Server Certifications” for every Data Provider/Server registered under the Trust Framework
The Certification Framework defines that LFIs must obtain their LFI Customer Experience Certification following the steps outlined on the Certification Framework.
Once this certification is obtained the LFI is required to register it on the Trust Framework following the steps outlined on https://docs.connect.raidiam.io/publish-authorisation-server-certification
Use the following table as a reference of what must be provided when a new Certification is registered:
...
Field Name
...
Guidance
...
Example
...
Certification Type
...
LFI Customer Experience - Only Existing Value
...
LFI Customer Experience
...
Certification Type Variant
...
Select the type of segment for this Data Provider, in line with the validation flow that was executed on the Certification Process
...
Retail
...
Profile Version
...
Provide “1” if that’s the first certification of this Variant for this Server and add +1 for each new Certification Requested/Updated
...
1
...
Certification Payload
...
The URI of the Service Desk ticket used to obtain the Certification Request - Make sure that the Ticket Number is included on the URI Provided
...
https:/altareq.atlassian.net/servicedesk/CERT-12
...
Start Date of Certification
...
Data of when the Certification was Granted to the LFI
...
22/08/2025
4.5 Creating Server Certificates
There are three types of server certificates, each serving different purposes. Detailed information about server certificates can be found in the Certificate Standard .
Instructions on creating server certificates are available at https://docs.connect.raidiam.io/manage-certificates-for-organisation
Servers must use valid TLS certificates to protect registered resources in the Trust Framework, with a policy to update these certificates at least once every 12 months.
5. TPPs Quick Access Guide
This guide assumes that the TPP has completed the onboarding process, including submitting all required documentation and passing all necessary KYBs and KYC requirements(https://openfinanceuae.atlassian.net/wiki/spaces/OF/pages/50790460/Onboarding+Process#2.1-KYC%2FKYB-Prerequisites ).
There is no logical difference between Organisation Entries used by TPPs or LFIs. Therefore, the procedures for creating accounts, signing documents, and onboarding for TPPs are the same as for LFIs.
5.1 Creating an Account
Refer to the https://openfinanceuae.atlassian.net/wiki/spaces/TFDocv3/pages/edit-v2/168263702#4.1-Creating-an-Account section.
5.2 Signing the Terms & Conditions Document
The process for a TPP to sign the Terms & Conditions Document is similar to the process for LFIs, with the primary difference being the document type: "TPP - Terms & Conditions."
Access to the Production Environment will be granted once the document is signed and reviewed by the AlTareq team.
Refer to the https://openfinanceuae.atlassian.net/wiki/spaces/TFDocv3/pages/edit-v2/168263702#4.2-Signing-the-Terms-%26-Conditions-Document section for more details.
5.3 Onboarding Additional Users
Refer to the https://openfinanceuae.atlassian.net/wiki/spaces/TFDocv3/pages/edit-v2/168263702#4.3-Onboarding-Additional-Users section.
5.4 Registering Applications
The Applications Resource allows Organisations to register details of their OpenID Relying Parties (Clients), which interact with OAuth 2.0 Authorization Servers to access protected APIs. The interaction rules are outlined in the Security Profile - FAPI document.
When creating an Application in the Trust Framework, participants can select the regulatory roles for the client, which define the types of APIs the client can access. The instructions on how to create new Applications Can be found on ) often operate with multiple brands, security infrastructures, and IT environments tailored to different customer segments. This means the Open Finance ecosystem must be flexible enough to support a variety of LFI infrastructure deployments while ensuring that all necessary services are discoverable by third-party providers and customers.
An LFI may register one or multiple servers, provided they meet the following conditions:
Customer Recognition: The server must be recognizable by customers as a place they would typically associate with their banking services.
Token Issuance: The Server must be able to issue tokens for the resources and services that a customer or TPP seeks to access.
Example of Server Registration for an LFI:
Customer Friendly Name | Well-Known Endpoint | Resource |
Amazing Business Banking | https://auth.business.amazingbank.org.br/.well-known/openid-configuration | Accounts, payments |
Amazing Credit-Cards | https://auth.credit-cards.amazingbank.org.br/.well-known/openid-configuration | Accounts, payments |
Amazing Retail Banking | https://auth.retail.amazingbank.org.br/.well-known/openid-configuration | Accounts, payments |
Amazing Insurance | https://auth.insurance.amazingbank.org.br/.well-known/openid-configuration | Insurance |
In this example, the organization "Amazing LFI" has chosen to publish four servers on the Trust Framework. These servers are recognizable by customers as distinct brands. During the consent authorization flow, customers can select the brand they normally associate with their banking activities. Additionally, each brand advertises a unique set of API resources, enabling TPPs to identify the services offered by each LFI.
4.4.2 Server Technical Metadata
When registering a server, technical metadata must be provided to ensure that TPPs can discover the appropriate authorization and connection endpoints offered by the server. These endpoints typically include:
Token Endpoint: Used to issue access tokens.
Pushed Authorization Request (PAR) Endpoint: Used to initiate the user authorization flow.
Token Introspection Endpoint: Used to verify the status and information of access tokens.
All the endpoints mentioned above are detailed in the Authorization Server Well-Known Endpoint, which is outlined in the Server Discovery section of the Registration Framework documentation.
It is important to note that all the required technical metadata for the server should be provided by the API Hub. If the LFI is using the API Hub services, their focus should be on registering the necessary Server Discovery Metadata, as explained in the following sections
4.4.3 Server Discovery Metadata
When creating a new server, Data Providers (Licensed Financial Institutions or LFIs) and TPPs will use the following fields to provide information about the server to existing users. These fields should be filled out with relevant information that accurately describes the services and the application to ensure optimal discovery by the end users.
Field Name | Field Description | Example |
|---|---|---|
Customer Friendly Name | The name of the financial institution branch/segment/service as it will appear to end users. | Global Finance - Private Banking |
Description | A detailed description of the financial institution, highlighting its key features, services, and benefits. This should give users a comprehensive understanding of what the financial institution offers and how it can support service providers. | Global Financial Services is a leading financial institution offering a wide range of services including savings and checking accounts, loans, mortgages, and investment services. The institution is dedicated to providing secure and efficient financial solutions for individuals and businesses. |
Portal URI | The URL pointing to the financial institution’s portal, directing users to a webpage where they can find more information about the services provided by the institution. | |
Logo URI | The URL pointing to the financial institution’s logo in PNG or JPEG format. This logo will be displayed alongside the financial institution name and description on the platform, providing a visual identifier for users. | https://www.centralbank.ae/media/ouxfisxh/banner-text-en-july28-1.png |
Once registered in the Trust Framework, the Authorization Server can be recovered via the Trust Framework APIs, notably the Participants Public API.
Instructions on how to register an Authorization Server can be found at https://docs.connect.raidiam.io/add-server#Zb72c
4.4.4 Registering API Resources
Participants can register https://docs.connect.raidiam.io/api-resources for the products and services they offer on the schema. Only approved API endpoints and versions for go-live should be added to the Trust Framework.
Instructions on how to add and maintain API resources are available at https://docs.connect.raidiam.io/manage-apis-for-discovery-and-integration
Details about the API resources can be obtained through the same Participants Public API accessible under - https://data.directory.openfinance.ae/participants
4.4.5 Registering Certifications
LFIs are required to register their acquired certifications under the “Server Certifications” for every Data Provider/Server registered under the Trust Framework
The Certification Framework defines that LFIs must obtain their LFI Customer Experience Certification following the steps outlined on the Certification Framework.
Once this certification is obtained the LFI is required to register it on the Trust Framework following the steps outlined on https://docs.connect.raidiam.io/addpublish-andauthorisation-manageserver-applications
5.4.1 Roles
https://docs.connect.raidiam.io/roles dictate the rights and permissions that each Application can have on the Open Finance Schema.
Roles will be initially granted to Organisations once they are onboarded on the Ecosystem and they will reflect the Technical Access Scopes that the Applications of this Organisation can have on the Schema.
When creating an Application it’s important to include all the Roles that this Application should have in the Ecosystem to ensure it will be able to properly register with all the Data Providers in the Ecosystem
A Table Containing all the Roles and the Technical Access Scopes that they can grant on the Ecosystem can be found below :
...
Role
...
Granted to
...
Allowed API Scopes
...
Allowed Authorization Details Types
...
Allowed Grant Types
...
BSIP - Bank Service Initiation Provider
...
Participants that act as TPP for Payments and other Account-Related Services
...
openid
payments
...
urn:openfinanceuae:service-initiation-consent:*
...
client_credentials
authorization_code
refresh_token
...
BDSP - Bank Data Sharing Provider
...
Participants that act as TPP for Receiving Account Data Information
...
openid
accounts
...
urn:openfinanceuae:account-access-consent:*
...
client_credentials
authorization_code
refresh_token
...
ISP - Insurance Service Provider
...
Participants that act as TPP for Receiving Insurance Data Information or Insurance Services
...
openid
insurance
...
urn:openfinanceuae:insurance-consent:*
...
client_credentials
authorization_code
refresh_token
...
LFI - Licensed Financial Institution
...
Authorized LFIs
...
N/A
...
N/A
...
N/A
...
TSP - Technical Services Provider
...
Organisations that are providing services to the Open Finance Platform and aren’t directly acting as participants
...
N/A
...
N/A
...
N/A
...
Use the following table as a reference of what must be provided when a new Certification is registered:
Field Name | Guidance | Example |
|---|---|---|
Certification Type | LFI Customer Experience - Only Existing Value | LFI Customer Experience |
Certification Type Variant | Select the type of segment for this Data Provider, in line with the validation flow that was executed on the Certification Process | Retail |
Profile Version | Provide “1” if that’s the first certification of this Variant for this Server and add +1 for each new Certification Requested/Updated | 1 |
Certification Payload | The URI of the Service Desk ticket used to obtain the Certification Request - Make sure that the Ticket Number is included on the URI Provided | https:/altareq.atlassian.net/servicedesk/CERT-12 |
Start Date of Certification | Data of when the Certification was Granted to the LFI | 22/08/2025 |
4.5 Creating Server Certificates
There are three types of server certificates, each serving different purposes. Detailed information about server certificates can be found in the https://openfinanceuae.atlassian.net/wiki/x/1ICQD .
Instructions on creating server certificates are available at https://docs.connect.raidiam.io/manage-certificates-for-organisation
Servers must use valid TLS certificates to protect registered resources in the Trust Framework, with a policy to update these certificates at least once every 12 months.
...
5. TPPs Quick Access Guide
This guide assumes that the TPP has completed the onboarding process, including submitting all required documentation and passing all necessary KYBs and KYC requirements(https://openfinanceuae.atlassian.net/wiki/spaces/OF/pages/50790460/Onboarding+Process#2.1-KYC%2FKYB-Prerequisites ).
There is no logical difference between Organisation Entries used by TPPs or LFIs. Therefore, the procedures for creating accounts, signing documents, and onboarding for TPPs are the same as for LFIs.
5.1 Creating an Account
Refer to the https://openfinanceuae.atlassian.net/wiki/spaces/TFDocsv4/pages/edit-v2/183468280#4.1-Creating-an-Account section.
5.2 Signing the Terms & Conditions Document
The process for a TPP to sign the Terms & Conditions Document is similar to the process for LFIs, with the primary difference being the document type: "TPP - Terms & Conditions."
Access to the Production Environment will be granted once the document is signed and reviewed by the AlTareq team.
Refer to the https://openfinanceuae.atlassian.net/wiki/spaces/TFDocsv4/pages/edit-v2/183468280#4.2-Signing-the-Terms-%26-Conditions-Document section for more details.
5.3 Onboarding Additional Users
Refer to the https://openfinanceuae.atlassian.net/wiki/spaces/TFDocsv4/pages/edit-v2/183468280#4.3-Onboarding-Additional-Users section.
5.4 Registering Applications
The Applications Resource allows Organisations to register details of their OpenID Relying Parties (Clients), which interact with OAuth 2.0 Authorization Servers to access protected APIs. The interaction rules are outlined in the https://openfinanceuae.atlassian.net/wiki/x/TYCQD document.
When creating an Application in the Trust Framework, participants can select the regulatory roles for the client, which define the types of APIs the client can access. The instructions on how to create new Applications Can be found on https://docs.connect.raidiam.io/add-and-manage-applications
5.4.1 What is an Application
An Application (or "App") in the context of the Open Finance UAE ecosystem can be likened to an entry in an Open Finance UAE App Store. This App record holds all the information required for a Licensed Financial Institution (LFI) to identify and interact with the application. It also contains essential details that help consumers verify the legitimacy of the application.
When a new application or software statement is registered, the following process is followed:
Log in to the Directory.
Navigate to the Applications section.
Click Create New and complete the provided form.
It’s important to note that the majority of the information entered in the application form will be displayed to customers by the banks as part of the redirection or authorization process. Therefore, it is crucial to ensure that all URIs (such as redirect URIs) and descriptions are accurate and relevant to the customer audience, as these will directly impact the customer’s experience and trust in the application.
5.4.2 Roles
https://docs.connect.raidiam.io/roles dictate the rights and permissions that each Application can have on the Open Finance Schema.
Roles will be initially granted to Organisations once they are onboarded on the Ecosystem and they will reflect the Technical Access Scopes that the Applications of this Organisation can have on the Schema.
When creating an Application it’s important to include all the Roles that this Application should have in the Ecosystem to ensure it will be able to properly register with all the Data Providers in the Ecosystem
A Table Containing all the Roles and the Technical Access Scopes that they can grant on the Ecosystem can be found below :
Role | Granted to | Allowed API Scopes | Allowed Authorization Details Types | Allowed Grant Types |
|---|---|---|---|---|
BSIP - Bank Service Initiation Provider | Participants that act as TPP for Payments and other Account-Related Services |
|
|
|
BDSP - Bank Data Sharing Provider | Participants that act as TPP for Receiving Account Data Information |
|
|
|
ISP - Insurance Service Provider | Participants that act as TPP for Receiving Insurance Data Information or Insurance Services |
|
|
|
LFI - Licensed Financial Institution | Authorized LFIs |
|
|
|
TSP - Technical Services Provider | Organisations that are providing services to the Open Finance Platform and aren’t directly acting as participants |
|
|
|
5.4.3 Application Technical Metadata
When creating a new application, two primary technical configurations must be included to ensure the application functions as expected:
Federation Configuration: This section determines whether the application participates in the Open Finance UAE Federation. The following options must be selected:
Federation Enabled: Choose whether the application is enabled to participate in the federation.
Federation Managed: If federation is enabled, specify whether the application is managed as part of the federation.
Applications that provide services to end users must always be configured as Federation Enabled and Federation Managed. This ensures they operate within the Open Finance UAE Federation, allowing for secure and standardized interactions.
If the application is only intended to interact with the Trust Framework—such as executing a Single Sign-On (SSO) flow or retrieving information from other participants—it does not need to be federation-enabled. In such cases, the application should not be marked as "Federation Enabled" because federation is not required for these interactions.
Redirect_URI Field: The Redirect URI (also known as the Callback URL) is a list of endpoints specified in the client metadata. These are the URLs where the Authorization Server will redirect users after they have authenticated and authorized access to the application.
Providing the Redirect URI list ensures that the authorization code, which results from the authorization flow, is only sent to endpoints controlled by the TPP (Third-Party Provider).
5.4.4 Application Discovery Metadata
When creating a new Application, three fields will be used by the AlTareq Platforms to display the available Open Finance applications and use cases for the end users.
...
Field Name | Field Description | Example |
|---|---|---|
Client Name | The name of the application as it will appear to end users | Finance Tracker Pro |
Description | A detailed description of the application, highlighting its key features, functionalities, and benefit | Finance Tracker Pro helps users manage their personal finances by tracking income, expenses, and savings goals. Features include budget planning, expense categorization, and financial reporting |
Client Info URI | The URL pointing to the application’s webpage. This should direct users to a webpage where they can find more detailed information about the application, including its features, pricing, and support. | |
Logo URI | The URL pointing to the application’s logo in PNG or JPEG format. This logo will be displayed alongside the application name and description on the platform, providing a visual identifier for users. |
5.4.
...
5 Shari’ah compliance flag
When registering/editing an Application a Field called “Flags” is available to be edited by the User.
...
Details about how the Shari'ah compliance will be informed to the end users can be seen on : https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1finalstandardsv1dot1final/pages/151850813210800446/Common+Rules+and+Guidelines#21.-Shari%E2%80%99ah-compliance-of-TPP
5.4.
...
6 Registering Certifications
Clients are only authorized to Operate on the Ecosystem once they have passed their full set of certifications defined on the Certification Framework, including their FAPI 2.0 UAE Relying Party Certification.
...
There are three types of client certificates, each with specific use cases. Detailed information about client certificates can be found in the Certificate Standard https://openfinanceuae.atlassian.net/wiki/x/1ICQD
Instructions on creating server certificates are available at https://docs.connect.raidiam.io/manage-certificates-for-organisationapplication
Servers must validate the certificates and signatures used by clients on each new connection and authentication request. If a client uses a revoked or expired certificate, the server will deny the request.
...
The Technical Requirements around API and Server discovery are outlined on the security standards, on the Registration Framework https://openfinanceuae.atlassian.net/wiki/x/i4CQD
5.6.2 Establishing Connection with Servers
After retrieving all the resources, clients can call the Authorization Server token and PAR endpoints, as outlined in the Security Profile - FAPI https://openfinanceuae.atlassian.net/wiki/x/TYCQD document.
Note: Clients are not required to undergo an active registration step in the Registration Framework; servers will accept all incoming valid requests from clients.
...
In essence, Organisation Flags outline the expected products or services that an LFI should share, while https://openfinanceuae.atlassian.net/wiki/spaces/TFDocv3TFDocsv4/pages/edit-v2/168263702#4183468280#4.4.24-Registering-API-Resources reflect what they are currently sharing.
...
API Name | Endpoint | Usage | Instructions / Swagger |
|---|---|---|---|
Participants | Sandbox : https://data.sandbox.directory.openfinance.ae/participants Production : https://data.directory.openfinance.ae/participants | Provides details about all the Servers that have been registered on the Trust Framework, including :
| https://docs.connect.raidiam.io/find-data-providers-via-public-api |
Keystores | Sandbox : https://keystore.sandbox.directory.openfinance.ae/<org_id>/<app_id>/application.jwks Production : https://keystore.directory.openfinance.ae/<org_id>/<app_id>/application.jwks | Provides details about the certificates generated by the Trust Framework PKI. To verify details about client certificates, replace the <org_id> with the value of the Organisation UUID of the participant on the TF and the <app_id> with the value of the Client UUID To verify details about server certificates, remove the <app_id> from the URI path and provide only the the <org_id> with the value of the Organisation UUID of the participant | https://docs.connect.raidiam.io/public-and-private-keys#bz_0v |
PKI Chain | Provides the issuer and root certificates in | https://docs.connect.raidiam.io/public-key-infrastructure#lwJo2 | |
API Resources | Sandbox : https://web.sandbox.directory.openfinance.ae/config/apiresources Production : https://web.directory.openfinance.ae/config/apiresources | Provides the list of API Families that can be published on the TF. This API returns a JSON file which includes:
|
6.2.2 mTLS Protected APIs
...
Instructions on how to generate an Application are described on https://openfinanceuae.atlassian.net/wiki/spaces/TFDocv3TFDocsv4/pages/edit-v2/168263702#5183468280#5.4-Registering-Applications
To access these protected APIs, the participant must first generate an access token with the directory: software scope by calling the token endpoint using the client_credentials grant type. Instructions for obtaining the token can be found on https://docs.connect.raidiam.io/client-credentials-flow-obtain-access-token#YzDfh
...