Technical guides and explainers for building on UAE Open Finance.
Account Permissions in a Payment Consent
How to use ReadAccountsBasic, ReadAccountsDetail, and ReadBalances on a payment consent, which endpoints they unlock, and why they're useful during a payment flow.
Read article →Base Consent ID (consentGroupId) – How to Link Consents
How to use a Base Consent ID to link related consents within a TPP's service, and when it applies.
Read article →Choosing a Payment Type
Guide to the seven UAE Open Finance payment types — Single Instant Payment and the six Multi-Payment variants — with a decision framework for selecting the right one and notes on the Delegated SCA overlay.
Read article →Consent Identifiers — Why PSU and Account IDs Must Be Opaque
Why any identifier patched onto a consent (psuIdentifiers, accountIds) must be an opaque, non-sensitive, stable LFI-defined value.
Read article →FAPI Request Headers — Traceability, Context, and Safe Retries
What the FAPI and Open Finance request headers are for, why x-fapi-interaction-id is the most important one to get right, and a one-line guide to each of the others.
Read article →Identity Assurance Claims — OIDC IDA as the response format for customer data
Why GET /customer, GET /accounts/{AccountId}/customer, and the CoP query response all share a verifiedClaims envelope derived from OpenID Connect for Identity Assurance 1.0.
Read article →JWT Claim Rules — Request Object and Client Assertion
Per-claim reference for both JWTs sent to /par and /token: aud, jti, lifetime windows, sub rules, and the most common rejection causes.
Read article →mtls_endpoint_aliases — what it is and when it matters
FYI explainer for the mtls_endpoint_aliases object returned by .well-known/openid-configuration. Today the aliases match the top-level endpoints, but the FAPI 2.0 spec allows them to diverge — preferring the alias keeps your client future-proof.
Read article →Multi-Segment LFIs — How to Structure API Hubs Across Customer Segments
When an LFI serves multiple customer segments (e.g. retail and SME) with different authentication endpoints, they need one API Hub per segment but can share a single Ozone Connect — minimising LFI-maintained certificates.
Read article →O3 Sandbox Utilities — Signing and Encryption Helpers
What the O3 Util endpoints are, why they exist, and how to use them in Postman to test message signing, PII encryption, and client assertions without writing your own cryptographic code.
Read article →OnBehalfOf — When to Use It and When Not To
When to populate OnBehalfOf in PAR requests, which consent types support it, and how payment (service initiation) consents handle merchant identity via creditor fields instead.
Read article →Pagination — LFI `meta` to TPP `Links`
How page-based pagination flows from the LFI's Ozone Connect response through the API Hub, converted into the Links envelope consumed by the TPP.
Read article →Payment PII Encryption — Why It Exists and What It Means for You
Why personal identifiable information in payment consents is encrypted end-to-end, what that means for LFI validation responsibility, TPP onboarding care, and how creditor rules differ by payment type.
Read article →The tpp and decodedSsa Context Blocks on Ozone Connect Calls
Every call the API Hub makes to your Ozone Connect endpoints carries a tpp object identifying the calling TPP, plus its decoded Software Statement Assertion. This article explains what each field is, why it's there, and the operational reasons an LFI might want to use it — even though none are required for payment execution.
Read article →