← Observatory

Methodology

How we calculate Observatory metrics and derive ecosystem status

Data Sources

All data displayed in the Observatory is derived from the public UAE Open Finance Trust Framework Directory , operated by Raidiam on behalf of Nebras Open Finance LLC (a CBUAE subsidiary).

Dual Environment Collection

We collect data from both environments of the UAE Open Finance Trust Framework:

Production

The production directory publishes registrations, role claims and authorization-server metadata. Registration does not establish use of a service.

data.directory.openfinance.ae
Sandbox

The sandbox directory publishes testing-environment registrations and metadata. Registration alone does not show testing activity or certification.

data.sandbox.directory.openfinance.ae

Observation Limits

The collector schema changed to version 2.1 on 8 October 2026 to preserve insurance, ATM and unknown API families. Older snapshots retain their original coverage; newly observed families can reflect this collection correction rather than a new deployment. Capability flags are source declarations, and an unmarked flag has not been tested. The Watch uses separate traffic logs with explicit reporting periods.

Update Frequency

Data is collected automatically once per day at 06:00 UTC via a GitHub Actions workflow. Each collection creates timestamped snapshots for both production and sandbox environments.

Historical snapshots are preserved, enabling trend analysis and visualization of ecosystem growth over time. Milestones (such as new participant registrations) are automatically tracked.

Metric Definitions

Core Metrics

Registrations

Count of distinct OrganisationId values after excluded test/support and unresolved unnamed records are filtered out. One legal entity may have multiple registrations. Cross-environment totals deduplicate IDs, not legal entities.

Authorization Server Published

Registrations with at least one active authorization server and a nonempty issuer field. We do not validate issuer reachability, certification, successful integration, or traffic. The JSON fields isLive and liveInProduction retain this meaning for compatibility.

In the UAE, the API Hub is the OIDC/FAPI authorization server and token issuer. Metadata published under an LFI registration can describe that Hub endpoint; it does not establish that the institution issues TPP access tokens.

Directory Shariah Flag

Registrations whose source shariah_compliant flag includes True. This source declaration is not a classification of every Islamic finance institution, and editorial profiles are not used to overwrite it.

Multi-Role Participants

Registrations with two or more active role claims. This does not measure integration depth, usage, or licence category.

Participant Roles

Directory roles and permissions use the Trust Framework role documentation (terminology reviewed 2026-10-08). A role claim is separate from a licence or editorial company-type classification.

LFI — Licensed Financial Institution

Regulated financial institutions, including banks and insurers, providing data or services through the central API Hub.

BDSP — Bank Data Sharing Provider

Entities that provide data sharing services, enabling secure access to customer financial data.

BSIP — Bank Service Initiation Provider

The directory role for bank service initiation. Consult the operator for the permissions attached to this claim.

ISP — Insurance Service Provider

The directory role for insurance service provision.

TPP — Third Party Provider

Fintech companies and other third parties that access Open Finance APIs to provide innovative financial services.

A registration may hold multiple roles. TPP population is unavailable from these claims; the legacy tppCount field only counts explicit TPP claims.

API Families

Insurance and ATM families are preserved alongside banking families. Unknown family identifiers are retained verbatim, and every declared version and completeness flag is available in the dataset and participant detail. Absence from a snapshot is not proof that a service is unavailable.

Derived from the API resources registered under each participant's authorization servers:

Account Information

APIs for accessing account balances, transactions, and account holder information.

Payments

Payment Initiation APIs enabling authorized third parties to initiate payments on behalf of customers.

Confirmation of Payee (CoP)

APIs for verifying payee details before payment execution, reducing fraud and misdirected payments.

Products

Product Information APIs providing details about financial products offered by institutions.

Declared Authorization Capabilities

Flags declared on active authorization servers. Unmarked capabilities are not declared true; their availability has not been tested.

CIBA — Client Initiated Backchannel Authentication

Decoupled authentication flow where the authorization is initiated from a consumption device but authentication happens on a different device (e.g., mobile phone). Enhances security for headless and IoT scenarios.

DCR — Dynamic Client Registration

Capability allowing Third Party Providers to register their applications dynamically via API, streamlining the onboarding process for TPPs.

Redirect Flow

The TPP initiates authorization through the API Hub. In the LFI redirect journey, the customer authenticates with the institution. The Hub owns the consent state and issues the access token. A declared redirect flag does not verify this journey.

Cross-Environment Analysis

When viewing "Both" environments, additional metrics are available:

In Both Environments

Registration IDs observed in both production and sandbox. Presence in both does not establish certification or successful integration.

Sandbox Only

Registration IDs observed in sandbox and absent from the production snapshot. This does not establish a testing phase, certification status or planned launch.

Production Only

Registration IDs observed in production and absent from the sandbox snapshot. This does not establish a graduation event or previous sandbox participation.

Historical Trends

The Observatory tracks ecosystem growth over time by preserving daily snapshots. The Ecosystem Growth chart displays:

  • Total participant count over time
  • Net change in participants (growth/decline)
  • Milestones marking when new participants joined

Historical data is automatically aggregated from daily snapshots to provide trend visualization without requiring manual data entry.

Known Limitations

  • We only display publicly available metadata; we cannot verify actual API functionality or performance
  • Participant counts may differ from official CBUAE statistics due to registration timing differences
  • TPP population cannot be inferred from role claims. The legacy explicit-claim count does not indicate how many licensed TPPs exist.
  • Historical data before the launch of this Observatory is not available
  • Sandbox data availability depends on the public API being accessible (may require authentication in future)
  • Authorization capability flags (CIBA, DCR, Redirect) reflect declared support, not verified functionality

Data Freshness

The "Last updated" timestamp shown on the Observatory indicates when the data was last collected. If collection fails (e.g., API unavailable), the previous snapshot is retained and the timestamp reflects the last successful collection.

Each environment (production and sandbox) is collected independently. If one environment fails, the other may still be updated successfully.

Open Source

The collector script and all data transformations are open source. You can review the code at:

github.com/openfinance-os

Key files:

  • scripts/collect-observatory.ts — Data collection and transformation
  • scripts/utils/directory-client.ts — API client for both environments
  • scripts/types/participant.ts — TypeScript type definitions
  • data/observatory/ — Snapshots and historical data

If you find an error or have suggestions, please open an issue .