v2.1-errata1 v2.1
# 1. Account Information — Permissions array flattening
What changed
The Permissions field on consent responses was previously typed as an array of arrays of strings — an array containing a nested array of permission codes. It is now a flat array of strings, matching the normative text and how clients have always populated it on the request side.
Why the change was required
The nested-array form was a defect in the published OpenAPI. The v2.1 normative text and every consumer of the response treat Permissions as a flat array of permission codes, and the API Hub already enforces the flat structure. The schema is being corrected to match.
Effective date
To be confirmed on merge to main.
# 2. Account Information — TrustFrameworkCode enum corrected to FI
What changed
The TrustFrameworkCode enum used by VerifiedClaimVerification.TrustFramework on GET /parties and GET /accounts/{AccountId}/parties previously declared a single value Undefined — a value no conforming LFI could produce on the wire. The enum has been replaced with FI, matching what Ozone Connect emits on CbuaeVerifiedClaim.verification.trustFramework and what every real response reaching a TPP has always contained.
Why the change was required
The v2.1 enum was internally inconsistent with the Ozone Connect spec the Hub proxies from: every real response carried FI while the standards enum declared only Undefined. Formally this is an enum-value removal, but in practice no consumer could have relied on Undefined because no conforming implementation could have produced it. Richer values (UAE Pass digital identity, Emirates ID physical verification) are deferred to v3.0.
Effective date
To be confirmed on merge to main.
# 3. Authorization Endpoints — POST /token restructured as oneOf; client_credentials grant added; client_id optional
What changed
Three aligned corrections on POST /token:
1. The response body is now defined as a oneOf across three grant-type-specific schemas — AEAuthorizationCodeGrantTokenResponseProperties, AERefreshTokenGrantTokenResponseProperties, and AEClientCredentialsGrantTokenResponseProperties. Previously a single combined schema described the response, which marked fields like id_token and refresh_token as required for every grant even though they are only valid for some.
2. The client_credentials grant is now explicitly documented as a supported grant type on POST /token. v2.1 declared only authorization_code and refresh_token, yet the API Hub has always accepted client_credentials — the spec has been brought into line.
3. The client_id request parameter is now optional. Under FAPI 2.0 with mTLS client authentication the client is identified by its certificate, so client_id is not required on the wire.
Why the change was required
All three corrections align the spec with how the API Hub has behaved in production since v2.1 was published. The single-schema response form misrepresented the contract (each grant type returns a different shape); omitting client_credentials hid a supported grant; and requiring client_id contradicted the FAPI 2.0 mTLS profile the Hub has always operated under. This is a documentation-level correction — no behavioural change is being made.
Effective date
To be confirmed on merge to main.
# 4. Confirmation of Payee — 204 response description corrected
What changed
The description of the 204 No Content response on POST /confirmation has been corrected to "IBAN is not recognised". Previously it read "Account holder has opted-out of Confirmation of Payee and no data is returned", which confused the semantics of the status code — 204 is returned when the supplied IBAN is not recognised by the LFI, not when an account holder has opted out.
Why the change was required
The opt-out wording misled integrators about when to expect a 204. No opt-out mechanism is defined on this surface; the 204 is the unrecognised-IBAN response and the prose has been aligned with actual behaviour.
Effective date
To be confirmed on merge to main.
# 5. Confirmation of Payee — aud claim tightened from array to single string
What changed
The aud (audience) claim on every *BodySigned schema used by POST /confirmation and POST /discovery — AEError400ResponseBodySigned, AEError403ResponseBodySigned, AEError500ResponseBodySigned, DiscoverConfirmationSourceRequestBodySigned, DiscoverConfirmationSourceResponseBodySigned, NameConfirmationRequestBodySigned, and NameConfirmationResponseBodySigned — was previously typed as an array of strings. It is now a single string, matching what every JWT observed on this API actually carries.
Why the change was required
Every signed message on this surface has exactly one recipient — a specific authorisation server on requests, and a specific TPP client identifier on responses — so the array-of-strings form was over-modelled. RFC 7519 §4.1.3 permits aud to be a single StringOrURI when the JWT has a single audience. The array-only modelling did not reflect real wire traffic; any consumer strict-validating against it could not have decoded Model Bank responses. The correction brings the spec into line with production behaviour.
Effective date
To be confirmed on merge to main.
# 6. Monetary Amount pattern — double-escaped regex corrected across five specs
What changed
The monetary Amount schema carried a doubled-backslash pattern (a YAML-escape artefact) that no JSON-Schema validator would have interpreted as the intended numeric regex. The pattern is corrected to ^\d{1,13}$|^\d{1,13}\.\d{1,5}$ — matching the canonical regex used by every conforming implementation.
The correction spans five specs that each carried the same defect: uae-fx-service-initiation-openapi, uae-api-hub-consent-manager-openapi, uae-ozone-connect-bank-service-initiation-openapi, uae-ozone-connect-consent-events-actions-openapi, and uae-ozone-connect-user-operations-openapi.
Why the change was required
The published regex was non-functional: strict validators either rejected every amount or accepted any string depending on how they handled the literal backslash sequences. Production systems rely on the canonical single-backslash form; the correction brings every Amount definition on these five specs into line with that canonical form, tracked as OF-6288.
Effective date
To be confirmed on merge to main.
# 7. Webhook Template — Permissions array flattening
What changed
The Permissions field on consent webhook payloads was previously typed as an array of arrays of strings and is now a flat array of strings. This matches the equivalent correction on the Account Information consent responses (see §1) so the webhook payload and the consent resource share the same Permissions shape.
Why the change was required
Webhook payloads must mirror the structure of the underlying consent resource. The nested-array form in the webhook spec was the same defect corrected in §1 and would have caused subscribers parsing strictly against the published schema to fail.
Effective date
To be confirmed on merge to main.
# 8. API Hub Consent Manager — unused AERiskExternalAccountIdentificationCode schema removed
What changed
The namespaced AEBankServiceInitiationRichAuthorizationRequests.AERiskExternalAccountIdentificationCode schema has been deleted. It duplicated the canonical AERiskExternalAccountIdentificationCode and was never referenced from any other schema.
Why the change was required
The duplicated schema was dead weight in the OpenAPI and invited accidental divergence from the canonical definition. Removing it leaves a single source of truth for the type without changing any wire contract.
Effective date
To be confirmed on merge to main.
# 9. API Hub Consent Manager — AEExternalAccountTypeCode collapsed into AEAccountTypeCode; SME added
What changed
Two overlapping AccountType enums have been consolidated. AEAccountTypeCode (previously [Retail, Corporate], referenced by the stored consentBody) and AEExternalAccountTypeCode (previously [Retail, SME, Corporate], referenced by the RAR request body) are now a single AEAccountTypeCode declaring [Retail, SME, Corporate]. The RAR request body has been repointed to AEAccountTypeCode.
Why the change was required
The split caused internal inconsistency — a RAR request carrying AccountType: SME validated against the request schema but failed against the consentBody schema in the same payload. Collapsing the two and adopting SME on the canonical enum lets a single AccountType value flow through the whole consent lifecycle cleanly.
Effective date
To be confirmed on merge to main.
# 10. API Hub Consent Manager — duplicate OnBehalfOf collapsed into AEOnBehalfOf
What changed
Two structurally equivalent OnBehalfOf schemas have been consolidated. The unprefixed OnBehalfOf (used only by the Insurance RAR) has been deleted, and the Insurance RAR repointed to the canonical AEOnBehalfOf already used by Bank Data Sharing and the consent body paths. Both carried the same TradingName / LegalName / IdentifierType / Identifier shape and the same IdentifierType: [Other] constraint.
Why the change was required
Two definitions of the same shape invited silent drift between the Bank and Insurance RAR contracts. The collapse eliminates that risk without changing any wire contract.
Effective date
To be confirmed on merge to main.
# 11. Consent Manager & Consent Events Actions — duplicate EventNotification and Amount schemas collapsed
What changed
Two pairs of structurally identical schemas have been consolidated across the Consent Manager and the Ozone Connect Consent Events Actions spec:
- EventNotification (the Webhook subscription shape — Webhook.Url + Webhook.IsActive) has been folded into AEEventNotification. The Data Sharing, Insurance, and Service Initiation AuthorizationDetails schemas have been repointed.
- Amount (monetary-amount string pattern) has been folded into AEActiveOrHistoricAmount. The Service Initiation RemittanceAmount has been repointed.
Why the change was required
Carrying two definitions of the same shape in each spec invited silent drift between the families that referenced each side. The collapse leaves a single canonical AE-prefixed definition per concept across both specs.
Effective date
To be confirmed on merge to main.
# 12. Ozone Connect User Operations — duplicate AEAddressItem and Amount schemas collapsed
What changed
Two pairs of structurally identical schemas under the OzoneConnectConsentEventActionAPIs namespace have been consolidated:
- AEAddressItem (array-of-postal-address) has been folded into AEAddress. Debtor.PostalAddress and Creditor.PostalAddress have been repointed.
- Amount (monetary-amount string pattern) has been folded into AEActiveOrHistoricAmount.
Why the change was required
Two definitions of the same shape in the same spec invited silent drift. The collapse leaves a single canonical definition per concept.
Effective date
To be confirmed on merge to main.