Release Notes & Erratas

API Hub Release Notes — 2026 ​

This page tracks API Hub releases to production during 2026. Entries are listed newest first.

2026.13.1 ​

20th April 2026

Refresh token support for multi-authorization on Single Instant Payments ​

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.

Impact: TPPs intending to use Single Instant Payments under multi-authorization consents must implement refresh token handling. TPPs that only use single-authorizer SIP are unaffected.

Corrected response mapping for GET /beneficiaries ​

Corrected the response mapping for the GET /accounts/{AccountId}/beneficiaries endpoint 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.

Impact: TPPs now receive the complete AEBeneficiary record — including CreditorAccount, AccountHolderName, AccountHolderShortName, Reference, CreditorAgent, and SupplementaryData — as defined in the spec. No TPP changes are required to consume the additional fields.

Corrected response mapping for GET /standing-orders ​

Corrected the response mapping for the GET /accounts/{AccountId}/standing-orders endpoint 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.

Impact: TPPs now receive CreditorAccount, AccountHolderName, and the other standing order fields as defined in the spec. No TPP changes are required to consume the additional fields.

Corrected Sandbox Model Bank behaviour for pre-populated Debtor Account ​

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.

Impact: TPPs testing pre-populated DebtorAccount flows in the Sandbox can now exercise both Single Instant Payment and Multi Payment journeys end-to-end. Production behaviour is unchanged.

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.

Affected endpoints:

Impact: No real-world impact — this is a validation tightening on a malformed structure that was technically possible to send before. Functional behaviour and the documented schema are unchanged.

2026.07.0 ​

11th March 2026

V2.1 Banking API families enabled end-to-end ​

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.

Impact: TPPs can begin integrating against any v2.1 Banking endpoint through the API Hub. LFIs can implement, deploy, and certify their Ozone Connect endpoints against the live Hub.