UAE Compliance Guide

CBUAE Open Finance integration guide

A field guide for building Open Finance integrations against UAE Licensed Financial Institutions (LFIs) under the Central Bank of the UAE's Open Finance Regulation (Circular No. 03/2025), commonly known as Al Tareq. Four KhaleejiAPI endpoints turn the regulation into a set of testable, programmable checks.

KhaleejiAPI does not proxy customer data to or from LFIs. We provide the directory, consent compliance, and payment compliance tooling so your AISP/PISP can build correctly the first time. The actual account and payment APIs are exposed by each LFI under the CBUAE API Hub.

What is CBUAE Open Finance / Al Tareq?

The CBUAE's Open Finance Regulation (effective 15 April 2025) mandates that UAE banks, insurance companies, payment service providers, exchange houses, finance companies, and stored value facilities expose customer-permissioned data and payment-initiation APIs through a single regulated API Hub. Al Tareq (الطريق) is the implementation programme; the standards version in force at launch is v1.2-final with a rollout in three phases through 2027.

Authoritative source: CBUAE Rulebook — Open Finance Regulation.

The four KhaleejiAPI endpoints

Endpoint	Method	Required scope	Purpose
/v1/openfinance/participants	GET	openfinance:participants	Directory of 18 onboarded LFIs
/v1/openfinance/consent/validate	POST	openfinance:consent	Article 22 consent compliance
/v1/openfinance/payment/validate	POST	openfinance:payment	ISO 20022 payment compliance
/v1/openfinance/standards	GET	openfinance:standards	Standards, roadmap, SCA & ISO 20022 catalog

Each scope is granted automatically on Professional plans and above. Free and Starter keys can call /standards only. See Rate Limits.

Participant Directory

Returns the 18 UAE LFIs currently onboarded under Circular No. 03/2025, with SWIFT/BIC, license number, onboarding date, supported services, certified endpoint count, and product list. Filterable by type, country, status, phase, swift, id, or free-text search.

bash

# List all 18 UAE LFIs in the CBUAE Open Finance directory
curl "https://khaleejiapi.dev/api/v1/openfinance/participants" \
  -H "x-api-key: $KHALEEJI_API_KEY"
 
# Filter to active Phase 1 banks
curl "https://khaleejiapi.dev/api/v1/openfinance/participants?type=bank&phase=1&status=active" \
  -H "x-api-key: $KHALEEJI_API_KEY"
 
# SWIFT lookup (single participant)
curl "https://khaleejiapi.dev/api/v1/openfinance/participants?swift=EABORUAEAAA" \
  -H "x-api-key: $KHALEEJI_API_KEY"
 
# Lookup by id
curl "https://khaleejiapi.dev/api/v1/openfinance/participants?id=lfi-001" \
  -H "x-api-key: $KHALEEJI_API_KEY"

Response shape (truncated):

json

{
  "data": {
    "participants": [
      {
        "id": "lfi-001",
        "name": "First Abu Dhabi Bank",
        "nameAr": "بنك أبوظبي الأول",
        "type": "bank",
        "swift": "NBADAEAA",
        "licenseNumber": "CBUAE-B-001",
        "regulator": "Central Bank of the UAE (CBUAE)",
        "openFinance": {
          "status": "active",
          "phase": 1,
          "services": ["both"],
          "onboardingDate": "2025-09-01",
          "complianceDeadline": "2025-09-30",
          "certifiedEndpoints": 12
        },
        "products": ["deposits", "payment_accounts", "savings", "credit_cards", "loans", "mortgages"]
      }
    ],
    "summary": { "total": 18, "totalCertifiedEndpoints": 196, "byType": {...}, "byPhase": {...} },
    "regulation": {
      "framework": "CBUAE Open Finance Regulation",
      "circular": "No. 03/2025",
      "effectiveDate": "2025-04-15"
    }
  }
}

The directory is the source of truth for whether an LFI is active, still onboarding, or planned. Always check openFinance.status before kicking off a consent flow — calling an unready LFI's API Hub will return 503s.

Consent Validator (Article 22)

Article 22 of the regulation prescribes the shape of a valid customer consent: explicit opt-in, purpose limitation, time-bounded validity, named permissions, and a withdrawal channel. This endpoint runs your draft consent object through every check and returns a structured pass/fail with article citations, so your audit trail can prove compliance per request.

bash

curl -X POST "https://khaleejiapi.dev/api/v1/openfinance/consent/validate" \
  -H "x-api-key: $KHALEEJI_API_KEY" \
  -H "content-type: application/json" \
  -d '{
    "consent": {
      "userId": "user-123",
      "providerId": "lfi-001",
      "purpose": "account_data_sharing",
      "permissions": ["ReadAccountsBasic", "ReadBalances", "ReadTransactionsBasic"],
      "expirationDate": "2027-01-15",
      "transactionFromDate": "2024-01-01",
      "transactionToDate": "2025-01-01",
      "recurring": false,
      "sensitiveData": false,
      "consentMethod": "explicit_opt_in",
      "withdrawalMethod": "app_toggle",
      "dataStorageLocation": "AE",
      "thirdPartySharing": false
    }
  }'

Response shape:

json

{
  "data": {
    "compliant": true,
    "summary": {
      "total_issues": 0,
      "errors": 0,
      "warnings": 0,
      "verdict": "FULLY_COMPLIANT"
    },
    "issues": [],
    "regulation": {
      "framework": "CBUAE Open Finance Regulation",
      "circular": "No. 03/2025",
      "keyArticle": "Article 22 — Data Privacy and Consent",
      "standardsVersion": "v1.2-final"
    },
    "validPermissions": ["ReadAccountsBasic", "ReadBalances", ...],
    "validPurposes": ["account_data_sharing", ...],
    "validConsentMethods": ["explicit_opt_in", ...]
  }
}

A non-compliant consent returns compliant: false with verdict: "NON_COMPLIANT" and an issues[] array. Each issue carries field, severity, article, and a human-readable message in English and Arabic — wire those straight into your developer or end-user error UI.

Payment Validator (ISO 20022)

PISP-initiated payments under Al Tareq must conform to ISO 20022 messaging and CBUAE-specific constraints (charge bearer, currency, scheme routing). This endpoint classifies the payment (IPP / UAEFTS / SWIFT gpi), checks every required field, and returns the same compliant/issues structure as the consent validator.

bash

curl -X POST "https://khaleejiapi.dev/api/v1/openfinance/payment/validate" \
  -H "x-api-key: $KHALEEJI_API_KEY" \
  -H "content-type: application/json" \
  -d '{
    "payment": {
      "payerIBAN": "AE070331234567890123456",
      "payeeIBAN": "AE460261234567891234567",
      "amount": 1500.00,
      "currency": "AED",
      "purpose": "domestic_payment",
      "paymentType": "instant",
      "executionDate": "2025-07-15",
      "endToEndId": "E2E-2025-001",
      "remittanceInfo": "Invoice #INV-2025-001",
      "beneficiaryName": "Dubai Trading LLC",
      "consentId": "consent-abc-123",
      "chargeBearer": "SLEV"
    }
  }'

Response shape:

json

{
  "data": {
    "compliant": true,
    "summary": { "verdict": "FULLY_COMPLIANT", "errors": 0, "warnings": 0 },
    "classification": {
      "payerCountry": "AE",
      "payeeCountry": "AE",
      "domestic": true,
      "paymentScheme": "IPP (Aani)",
      "messagingStandard": "ISO 20022"
    },
    "issues": [],
    "regulation": {
      "circular": "No. 03/2025",
      "messagingStandard": "ISO 20022",
      "paymentSchemes": {
        "instant": "IPP — Instant Payment Platform (Aani)",
        "domestic": "UAEFTS — UAE Funds Transfer System",
        "international": "SWIFT gpi"
      }
    }
  }
}

Standards Reference

A read-only mirror of the CBUAE standards artefacts your engineers reach for again and again: current and upcoming versions, the ISO 20022 message catalog, Strong Customer Authentication rules (Article 18), the rollout roadmap by phase and release, and the article-by-article product map.

bash

# Full standards reference (current version, roadmap, ISO 20022 message catalog, SCA rules)
curl "https://khaleejiapi.dev/api/v1/openfinance/standards" \
  -H "x-api-key: $KHALEEJI_API_KEY"
 
# Just the rollout roadmap, filtered by phase
curl "https://khaleejiapi.dev/api/v1/openfinance/standards?section=roadmap&phase=2" \
  -H "x-api-key: $KHALEEJI_API_KEY"

Use ?section=roadmap when building a customer-facing “readiness” dashboard, and ?section=articles when building internal compliance tooling.

End-to-end: AISP onboarding flow

A typical Account Information Service Provider on-ramp uses three of the four endpoints in sequence: directory lookup, consent validation, then handing off to the LFI's API Hub.

javascript

// Real-world flow: AISP/PISP onboarding a UAE customer
// 1. Look up the customer's bank in the participant directory
const dirRes = await fetch(
  "https://khaleejiapi.dev/api/v1/openfinance/participants?swift=EABORUAEAAA",
  { headers: { "x-api-key": process.env.KHALEEJI_API_KEY } },
)
const { data: { participant } } = await dirRes.json()
if (participant.openFinance.status !== "active") {
  throw new Error(`${participant.name} not yet onboarded for Open Finance`)
}
 
// 2. Build the consent object and validate it BEFORE storing it
const consent = {
  userId: customer.id,
  providerId: participant.id,
  purpose: "account_data_sharing",
  permissions: ["ReadAccountsBasic", "ReadBalances", "ReadTransactionsBasic"],
  expirationDate: addMonths(new Date(), 12).toISOString().slice(0, 10),
  transactionFromDate: "2024-01-01",
  transactionToDate: new Date().toISOString().slice(0, 10),
  recurring: false,
  sensitiveData: false,
  consentMethod: "explicit_opt_in",
  withdrawalMethod: "app_toggle",
  dataStorageLocation: "AE",
  thirdPartySharing: false,
}
 
const consentRes = await fetch(
  "https://khaleejiapi.dev/api/v1/openfinance/consent/validate",
  {
    method: "POST",
    headers: {
      "x-api-key": process.env.KHALEEJI_API_KEY,
      "content-type": "application/json",
    },
    body: JSON.stringify({ consent }),
  },
)
const { data: validation } = await consentRes.json()
if (!validation.compliant) {
  // validation.issues is an array of {field, severity, article, message}
  throw new ConsentRejectedError(validation.issues)
}
 
// 3. Now safe to persist consent and proceed with the LFI's API

Compliance pitfalls we see most often

Implicit consent. Article 22 requires consentMethod: "explicit_opt_in". Pre-ticked checkboxes and bundled consents fail.
Open-ended expiry. Consents must be time-bounded — expirationDate is mandatory and capped at 12 months for most purposes.
Permission inflation. Asking for every permission in VALID_PERMISSIONS is a red flag. Validator emits warnings when scope exceeds purpose.
Cross-border data storage. dataStorageLocation outside AE needs documented adequacy or returns errors.
Wrong charge-bearer. Domestic AED payments under IPP require SLEV. SHAR or DEBT trip validation.

The standards version, mandated entity list, and rollout dates returned by these endpoints are sourced directly from CBUAE Circular No. 03/2025 and the CBUAE Annual Report 2025. We update them whenever the rulebook does — call /v1/openfinance/standards in your CI to detect drift.