...
This guide assumes that the LFI has submitted all required documentation and passed all necessary KYBs and KYC requirements for entry into the ecosystem(https://openfinanceuae.atlassian.net/wiki/spaces/OF/pages/50790460/Onboarding+Process#2.1-KYC%2FKYB-Prerequisites ).
To Facilitate the Onboarding flow for the LFIs the Onboarding Quick Access Video, which includes the steps presented in Sections 4.1 and 4.2 can be seen here facilitate the onboarding process, three videos have been created to provide a live demonstration of the steps LFIs need to follow for full onboarding into the Sandbox:
Session
URI
5.1 / 5.2
https://www.youtube.com/watch?v=NVQ6WJJQX_E&ab_channel=Raidiam-TrustedEcosystems%2CDelivered
5.3
https://www.youtube.com/watch?v=EGFdPQWrOP4&ab_channel=Raidiam-TrustedEcosystems%2CDelivered
5.4
5.4.6
5.5
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.
T&Cs Documents :
The Documents that need to be signed by either the LFIs or the TPPs representatives, depending on the institution type, can be seen below :
| View file | ||
|---|---|---|
|
| View file | ||
|---|---|---|
|
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.
Verifying Document Status
If the user wants to verify the status of a document to know if it has been signed, declined or re-issued, the following options can be executed :
Option 1: Through the Al Tareq Trust Framework
In the Trust Framework, select your organization, then go to Documents > History to verify the status of the Term & Conditions that have been issued - If the document was updated recently we recommend clicking on the three dots and selecting “Pool” to get the latest document status
...
Option 2: Through the Docusign sub account
It is also possible to verify the status of the documents directly on Docusign. Through the following URL https://apps.docusign.com/send/documents/details/<Envelope_ID> the user is able to review the current status of the document assuming he also participated on the signature process.
The envelope ID can be found on Documents > History and just needs to be inputed at the end of the URL:
...
For more information on the Terms and Conditions and how the Directory handles them, please refer to the documentation available at https://docs.connect.raidiam.io/terms-and-conditions .
4.3 Onboarding Additional Users
Organisation Administrators can onboard new Organisation Administrators as well as technical https://docs.connect.raidiam.io/users .
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 https://docs.connect.raidiam.io/add-users
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 https://docs.connect.raidiam.io/authorisation-servers and https://docs.connect.raidiam.io/api-resources 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 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) 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.
...
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 gg'
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.
T&Cs Documents :
The Documents that need to be signed by either the LFIs or the TPPs representatives, depending on the institution type, can be seen below :
| View file | ||
|---|---|---|
|
| View file | ||
|---|---|---|
|
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.
Verifying Document Status
If the user wants to verify the status of a document to know if it has been signed, declined or re-issued, the following options can be executed :
Option 1: Through the Al Tareq Trust Framework
In the Trust Framework, select your organization, then go to Documents > History to verify the status of the Term & Conditions that have been issued - If the document was updated recently we recommend clicking on the three dots and selecting “Pool” to get the latest document status
...
Option 2: Through the Docusign sub account
It is also possible to verify the status of the documents directly on Docusign. Through the following URL https://apps.docusign.com/send/documents/details/<Envelope_ID> the user is able to review the current status of the document assuming he also participated on the signature process.
The envelope ID can be found on Documents > History and just needs to be inputed at the end of the URL:
...
For more information on the Terms and Conditions and how the Directory handles them, please refer to the documentation available at https://docs.connect.raidiam.io/terms-and-conditions .
4.3 Onboarding Additional Users
Organisation Administrators can onboard new Organisation Administrators as well as technical https://docs.connect.raidiam.io/users .
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 https://docs.connect.raidiam.io/add-users
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 https://docs.connect.raidiam.io/authorisation-servers and https://docs.connect.raidiam.io/api-resources 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 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) 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/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 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 https://openfinanceuae.atlassian.net/wiki/x/1ICQD .
Instructions on creating server certificates are available at 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 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.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.
To facilitate the onboarding process, three videos have been created to provide a live demonstration of the steps TPPs need to follow for full onboarding into the Sandbox:
5.1 Creating an Account
Refer to the https://openfinanceuae.atlassian.net/wiki/spaces/TFDocsv5/pages/edit-v2/235077660#4.1-Creating-an-Account section.
...