This space is deprecated and no longer supported. Please use the latest available version here.
Trust Framework User Documentation
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
The Production Trust Framework can be accessed at the following link:
Web Application : https://web.directory.openfinance.ae/
OIDC Discovery API :https://auth.directory.openfinance.ae/.well-known/openid-configuration
The Sandbox and the Production environments are functionally the same, with the Sandbox environment serving as a testing ground for institutions to use before they start consuming/publishing APIs on the Production Environment.
2. Role of the Trust Framework
The Trust Framework enables secure data sharing between LFIs and TPPs by providing API discovery, client onboarding and client authentication functionalities. Key roles executed by the Trust Framework in the ecosystem include:
Trust Anchors:
Provide a registry of authorized participants and their scope of access within the ecosystem.
API Portal:
Provide a registry of all the servers, clients, and APIs in the ecosystem.
Keystore:
Provide a registry of all active keys for each participant, allowing them to recover those keys and use them to validate each other's identity, enabling trust—a key requirement for data sharing.
PKI:
A public key infrastructure that enables the issuance and management of TLS, signature, and encryption certificates.
Provides mechanisms to verify the certificates generated on the platform PKI.
It is important to note that no consumer data passes through the Trust Framework, with the platform serving as a facilitator for secure data exchange.
For more details, visit the https://docs.connect.raidiam.io/trust-framework-types#MonDi and the https://docs.connect.raidiam.io/centralized-directory on the Raidiam Connect Documentation.
3. LFIs Responsibilities
LFIs, or users acting on behalf of LFIs, need to execute the following actions on the Trust Framework:
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.
Points 1 and 2 are covered in this guide as they require active directory usage. Points 3 and 4 are programmatically done and are detailed in the Ecosystem API Security Documentation.
4. LFIs Quick Access Guide
This guide assumes that the LFI has submitted all required documentation and passed all necessary KYBs and KYC requirements for entry into the ecosystem(Onboarding Process | 2.1 KYC/KYB Prerequisites ).
4.1 Creating an Account
Upon being granted access to the Trust Framework (as an Organisation Administrator or Organisation User), you will receive an email with a link to the platform. Follow these steps to create your account using the same email address provided for access:
Click the link in the email to navigate to the Trust Framework registration page.
Enter your email address and follow the prompts to set up your account credentials.
The image below illustrates the registration steps for first-time users or when logging in to the platform:
Important: The Sandbox and Production environments of the Trust Framework use separate Identity Providers (IDPs). Therefore, you must complete two separate registrations: one for the Sandbox environment and another for the Production environment.
4.2 Signing the Terms & Conditions Document
As part of the Ecosystem Registration process, the First Primary Business Contact (PBC) of the Institution, upon receiving access to the Sandbox Trust Framework, must issue the Ecosystem Terms & Conditions Document. This document requires signatures from the legal representatives of the Institution.
Access to the Production Environment will be granted once this document is signed by the legal representatives and validated by the AlTareq team responsible for the onboarding process.
Issuing the Document - PBC :
The image below outlines the steps the PBC should follow when issuing the Ecosystem Participation Document:
Important: The Legal Representatives appointed on the process above are required to have enough powers to represent the Institutions as defined on the Institution’s Statutory Documents.
Signing the Document - Legal Representatives :
The appointed legal representatives will receive an email prompting them to sign the document via DocuSign.
The process to sign the document should be straightforward, with each representative being required to click on the “Review Document” button on the Docusign E-mail and follow the steps on the screen.
Validation and Receiving Production TF Access:
Once the document is signed by all legal representatives, the AlTareq team will validate it.
Upon confirmation of the signatures, the appointed PBC will also be granted access to the Production Environment, where they can now onboard additional users.
For more information on the Terms and Conditions and how the Directory handles them, please refer to the documentation available at Terms & Conditions - Raidiam Connect Documentation .
4.3 Onboarding Additional Users
Organisation Administrators can onboard new Organisation Administrators as well as technical Users - Raidiam Connect Documentation .
The Initial List of Users Supported on the Trust Framework can be seen in the table below :
User Type | Access Scope |
---|---|
Organisation Admin | Can Manage all the resources on the Organisation, Technical and Non-Technical |
Primary Business Contact (PBC) | Can Manage Contacts in the Organisation Cannot Manage Technical Resources |
Primary Technical Contact (PTC) | Can Manage all Technical Resources of an Organisation - Data Providers, Applications and Certificates |
Secondary Technical Contact (STC) | Can Manage Data Providers, adding and removing API Endpoints and Certifications. Cannot Manage Applications and Certificates |
User management, including adding or removing users in the Trust Framework, can be done using the platform UI. Detailed instructions can be found at Add Users - Raidiam Connect Documentation
Additional User types can be configured on the platform to grant access to other platforms of the Ecosystem, like, for example, a “Primary Service Desk Contact", which would have access to the AlTareq Service Desk, but not necessarily anything on the Trust Framework or the Api Hub.
4.4 Registering Servers and APIs
LFIs are responsible for maintaining an up-to-date registry of their Authorisation Servers - Raidiam Connect Documentation and API Resources - Raidiam Connect Documentation that they support the Open Finance Schema. Only valid and accessible resources should be included in the Trust Framework to ensure an interoperable data access journey for TPPs.
The Data Provider Resource allows Organisations to register details of their OAuth 2.0 Authorization Servers (Open ID Providers), which manage client access to participant-protected APIs.
The interaction rules between clients and Authorization Server endpoints are outlined in the CBUAE FAPI 2.0 Standards.
4.4.1 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-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 Manage APIs for Discovery and Integration - Raidiam Connect Documentation
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 Publish Authorisation Server Certification - Raidiam Connect Documentation
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 | < To be Confirmed Once Service Desk is Live> |
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 Manage Certificates for Organisation - Raidiam Connect Documentation
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(Onboarding Process | 2.1 KYC/KYB 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/TFDocsv3/pages/edit-v2/183468054#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/TFDocsv3/pages/edit-v2/183468054#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/TFDocsv3/pages/edit-v2/183468054#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/spaces/standardsv1final/pages/151846988 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 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 | Allowed API Scopes | Allowed Authorization Details Types | Allowed Grant Types |
---|---|---|---|
BSIP - Bank Service Initiation Provider |
|
|
|
BDSP - Bank Data Sharing Provider |
|
|
|
ISP - Insurance Service Provider |
|
|
|
LFI - Licensed Financial Institution |
|
|
|
5.4.2 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.
Those three fields should be filled out with relevant information that describes the services and the application to ensure optimal discovery by 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.3 Shari’ah compliance flag
When registering/editing an Application a Field called “Flags” is available to be edited by the User.
This field will include the parameter “Shariah Compliant” with two options “True” and “False”. When registering an Application it’s required that the Shari’ah compliance information is added by the Participant on the Trust Framework (OFTF). This compliance information ensures that financial services and applications align with Shari’ah principles for users who require it.
Once registered, this information will be recovered via the Trust Framework APIs by the Data Providers on the Ecosystem, informing this on the Consent Authorization Flow.
Details about how the Shari'ah compliance will be informed to the end users can be seen on : https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850813/Common+Rules+and+Guidelines#21.-Shari%E2%80%99ah-compliance-of-TPP
5.4.3 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.
Instructions on obtaining the Certifications can be seen on the Certification Framework documentation. All Obtained Certifications must be registered on the Clients before they start executing connections to LFIs/Data Providers in production.
Instructions on how to register a Certification can be found on https://docs.connect.raidiam.io/manage-application-certifications . For the “Certification Payload” field, the Participant is expected to provide the URI that points to the .zip file provided on the OIDF Certification Table, for the FAPI 2 RP - UAE Profile
Use the following table as a reference of what must be provided when a new Certification is registered:
Field Name | Guidance | Example |
---|---|---|
Certification Type | Select one of the three potential certification types for TPPs - Functional, Security or Customer Experience | TPP FAPI Certification |
Certification Type Variant | Select the Variant Type of this Certification, that is, which track was executed when running the Certification Process - Note that for most certifications only one value is set | FAPI 2.0 UAE RP |
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 | For Nebras Issued Certifications : 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 For OIDF Issued Certifications : The URI of the Certification Package as presented on https://openid.net/certification/ | |
Start Date of Certification | Data of when the Certification was Granted by either Nebras or the OIDF - For the OIDF this value must match the one presented on their Certification Page | 22/08/2025 |
5.5 Creating Client Certificates
There are three types of client certificates, each with specific use cases. Detailed information about client certificates can be found in the Certificate Standard
Instructions on creating server certificates are available at Manage Certificates for Organisation - Raidiam Connect Documentation
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.
5.6 Connecting with Data Providers
Once client certificates are created, TPPs can start accessing customer data/services by connecting to the registered Authorization Servers and Resource Servers using the provided credentials.
5.6.1 Data Providers Discovery
The first step is to discover all the resources registered by the LFIs in the Directory, which can be done using the Participants Public API - https://docs.connect.raidiam.io/receive-data#l9cWY / https://docs.connect.raidiam.io/find-data-providers-via-public-api
The Participant's Public APIs provide a single response in JSON format that contains information about all the Data Providers registered on the Ecosystem, including all their metadata and API Information, allowing a single call to provide all the information about who offers what product and the endpoint to access it on the AlTareq Platform.
The Technical Requirements around API and Server discovery are outlined on the security standards, on the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151847050
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 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151846988 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.
6 Additional Information
This section provides insights into aspects of the Trust Framework that go beyond the data exchange processes between LFIs and TPPs, offering a broader view of the platform’s capabilities.
6.1 Organisation Flags
Once a participant is onboarded into the Trust Framework, the Nebras team configures a set of metadata flags known as "Organisation Flags." These flags indicate whether an institution supports certain services or products that fall outside the current scope of Open Finance but may be relevant for future integrations. For example, an institution might support "House Insurance Policies" but may not have an active API family for these products yet. The development of APIs for such services could still be in progress.
In essence, Organisation Flags outline the expected products or services that an LFI should share, while https://openfinanceuae.atlassian.net/wiki/spaces/TFDocsv3/pages/edit-v2/183468054#4.4.2-Registering-API-Resources reflect what they are currently sharing.
Flags included on the Trust Framework Participants can be reviewed under the "Flags" object via the https://docs.connect.raidiam.io/participants-api
6.2 Accessing Data from the Trust Framework
Any registered application on the Trust Framework can access non-PII (Personally Identifiable Information) data, regardless of the roles assigned to the client. Here's how to retrieve this data:
6.2.1 Public APIs
Public APIs are endpoints that don't require authentication, allowing any application to interact with them without using a TLS certificate or undergoing OAuth 2.0 authentication. Below are the available public APIs in the Trust Framework:
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 https://docs.connect.raidiam.io/participants-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
The mTLS Protected APIs can only be accessed by Applications that have been registered with the Trust Framework and hold valid TLS/Transport certificates issued by authorized Certificate Authorities (CAs) within the Trust Framework.
Instructions on how to generate an Application are described on https://openfinanceuae.atlassian.net/wiki/spaces/TFDocsv3/pages/edit-v2/183468054#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
Token Endpoints:
Sandbox: https://matls-auth.sandbox.directory.openfinance.ae/token
Production: https://matls-auth.directory.openfinance.ae/token
After obtaining the access token, it can be used to access GET
operations for all Trust Framework APIs that do not return personal data.
The Swagger documentation for the TF API is available here: https://api.connect.raidiam.io/source.yaml
The API Host URls are:
An example request against the Trust Framework Protected APIs can be found https://docs.connect.raidiam.io/find-all-applications
© CBUAE 2025
Please try out our Advanced Search function.