API Hub Release Notes — 2026

Added refresh token support to the Single Instant Payment flow when used under Multi-Authorization.

Previously, the access token issued at initial authorization expired after 10 minutes. In a multi-authorization journey the final authorizer can act much later than this, so by the time the consent reached Status=Authorized the TPP no longer held a valid access token to call POST /payments. This effectively blocked Single Instant Payments from being used with multi-authorization consents.

TPPs can now use the refresh token issued at initial authorization to obtain a fresh access token and submit the payment once all authorizers have completed their step.

Corrected the response mapping for GET /accounts/{AccountId}/beneficiaries to align with the TPP-facing specification.

Previously, fields such as CreditorAccount and AccountHolderName were dropped from the response sent to the TPP, even though the LFI returned them on its Ozone Connect endpoint. The mapping between Ozone Connect responses and TPP-facing responses has been corrected so the full AEBeneficiary payload is preserved.

Corrected the response mapping for GET /accounts/{AccountId}/standing-orders to align with the TPP-facing specification.

Previously, fields such as CreditorAccount and AccountHolderName were dropped from the response sent to the TPP, even though the LFI returned them on its Ozone Connect endpoint. The mapping between Ozone Connect responses and TPP-facing responses has been corrected so the full standing order payload is preserved.

Corrected Sandbox Model Bank behaviour when the TPP supplies a valid Initiation.DebtorAccount in the PAR request for a Single Instant Payment or Multi Payment consent.

Previously, the Sandbox Model Bank incorrectly rejected the consent during the authorisation journey even when the supplied DebtorAccount was a valid IBAN held by the test PSU. This deviated from the Debtor Account validation rules — a valid pre-populated account should be accepted and used as the source account for the payment.

The Sandbox Model Bank now accepts a valid pre-populated DebtorAccount and proceeds with the consent journey as specified.

Tightened response validation for Account Access Consent endpoints to bring the API Hub in line with the v2.1 specification.

Previously, the API Hub permitted an additional array nested inside the Permissions field on consent responses. This was never valid per the spec, but the loose validation allowed it through. Validation has now been tightened to remove the extra array and enforce the strict Permissions structure defined in the spec.

Every Banking endpoint defined in v2.1 of the UAE Open Finance standard is now live in the API Hub and available for TPPs and LFIs to integrate and test against. This covers:

- Data Sharing — accounts, balances, transactions, beneficiaries, standing orders, scheduled payments, direct debits, statements, customer, and product endpoints. - Service Initiation — Single Instant Payment, all Multi Payment variants (variable/fixed × on-demand/periodic/defined schedules), refunds, multi-authorization, and PII handling. - Confirmation of Payee — POST /customers/action/cop-query. - Products & Leads — GET /products, POST /leads. - ATMs — GET /atm.

The release spans all three layers required for an end-to-end v2.1 journey:

- TPP-facing standards exposed by the API Hub at the rs1.* resource server. - Ozone Connect endpoints that LFIs implement to serve data and execute payments. - API Hub Consent Manager updates needed to support the v2.1 consent and payment lifecycle.

The full request/response mapping between Ozone Connect and the TPP-facing standards is in place for every endpoint in the families above.