API Hub Release Notes — 2026

The API Hub now enforces mandatory validation of the x-fapi-customer-ip-address header on the Product API endpoints.

Requests to GET /products and POST /leads that omit this header now receive an HTTP 400 response, bringing the Hub into line with the v2.1 specification.

Corrected the Sandbox Model Bank transaction response payloads for GET /accounts/{AccountId}/transactions to align with the v2.1 API specification.

Invalid null-valued CreditorAccount fields have been removed. CreditorAccount is now returned only when valid values are available.

Resolved a 500 internal server error affecting corporate Confirmation of Payee requests where organisationClaims.name lacked a corresponding fullName value.

Corporate Confirmation of Payee flows now return the expected HTTP 200 status.

Implemented 60-second authorisation code expiry enforcement for FAPI 2.0 profiles.

Authorisation codes that are not exchanged within 60 seconds now return an invalid_grant error, bringing the Hub into compliance with FAPI 2.0 security requirements.

Added Meta object support to Statements API responses.

Responses now include TotalPages and, where available, FirstAvailableDateTime and LastAvailableDateTime, aligning with the v2.1 specification.

Resolved consent processing failures that affected consent expiry status updates.

Duplicate key errors raised during consent processing no longer prevent expired consents from being updated to the correct status.

Improved API Hub Sandbox data consistency across the Account Information APIs.

Resolved intermittent 500 errors, empty response objects, missing AccountSubType values, and null DebtorAccount or CreditorAccount objects, supporting more reliable integration and UAT testing.

Removed idToken handling from the Admin Portal and Hub Portal flows.

The implementation has been aligned with Raidiam for FAPI 2.0 compliant behaviour.

Resolved a 500 error in the Confirmation of Payee endpoint caused by name masking logic failing on single-character name parts, such as initials.

Valid responses are now returned with an HTTP 200 status.

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 end user. 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.