Govern · Operate · Evolve

Version Management Policy

Applies toNebrasRead5 minUpdated21 Apr 2026Effective fromV2.1

Defines how API specifications, UI components, and related standards are versioned for the UAE Open Finance ecosystem — major and minor cadence, errata constraints, and the stability guarantees that apply once a capability is declared Live.

18moMin. major-version cadence

6moMin. minor-version cadence

01 Scope

What this policy governs

This policy applies to all Open Finance standards published within the UAE Open Finance ecosystem.

API specifications
UI components
Downstream systems
Consent objects
Supporting documentation

02 Effective scope

When this policy takes effect

This policy takes effect from V2.1 of the UAE Open Finance Standard. Standards, specifications, and documentation published prior to V2.1 — including V2.0 and any earlier errata — are not governed by this policy. Breaking changes introduced before V2.1 do not constitute non-compliance.

The stability guarantees set out in this policy — in particular, the restriction of breaking changes to major version releases and the scope constraints on errata — apply only to Live capabilities. A capability is Live when Nebras has formally declared it in production use within the UAE Open Finance ecosystem.

Capabilities not yet declared Live

Breaking changes MAY be introduced in minor versions or errata without requiring a major version increment
The release cadence defined below continues to apply
Once a capability is declared Live, all subsequent changes MUST comply with this policy in full

Nebras is responsible for maintaining and publishing the register of Live capabilities.

03 Versioning

Major and minor versions

The UAE Open Finance standard uses a two-part version identifier of the form Vx.y, where x is the major version and y is the minor version.

Major versionsV1.1 → V2.0

18 monthsMinimum interval

MAY include breaking changes that are not backward compatible
MUST NOT be released more frequently than every 18 months from the last major release
MUST include a comprehensive record of all breaking changes, with migration guidance and a clear deprecation timeline for the prior major version

Minor versionsV1.0 → V1.1

6 monthsMinimum interval

MUST NOT include breaking changes
MUST NOT be released more frequently than every 6 months from the previous release
MAY include non-breaking enhancements such as additional optional fields, additional GET response fields, additional endpoints, or non-breaking changes to field types

Version documentation

Every major and minor version MUST be accompanied by:

A complete change log covering all modifications since the previous version
Implementer guidance describing how to adopt the new version
For major versions, migration guidance for each breaking change

04 System & UI

Version-independent UI support

UI elements MUST NOT rely on API versioning for core functionality
Where UI behaviour depends on new data in a consent object, LFIs and TPPs MUST implement logic based on the presence of the data itself, not on the consent version

Example

If a new consent permission ReadStatements is added in V2.1, the UI SHOULD check whether ReadStatements is present on the consent rather than checking whether the consent version equals V2.1.

UI adoption

LFIs MAY adopt visual or branding changes from a future version before upgrading their API version. Example: new UI requirements published in V2.0 may be implemented while still serving API V1.2
Adoption of new UI elements requires successful Customer Experience (CX) certification
When an LFI upgrades its API to a given version, the UI MUST also align with that version. UI enhancements MAY precede API version upgrades but MUST NOT lag behind them

05 Release management

Publication, candidates, and post-publication change

Standards publication

A standards version MAY only be declared published once it is fully available to TPPs via the API Hub.

Release candidate

A release candidate (e.g. V1.2-rc) MAY be issued ahead of official publication. Once a version is agreed but not yet delivered into the API Hub, it carries a -rc-final suffix to indicate fixed-but-not-yet-published state.

Changes to published versions

Post-publication changes are limited to guidance clarifications or bug fixes, and MUST follow the Changes to Published Documentation Policy
No functional changes affecting LFI or TPP implementations may be introduced after publication; such changes require a new minor or major version
Errata MUST NOT introduce breaking changes
Errata MUST NOT introduce new functionality — additive enhancements MUST be delivered through a new minor version

06 Compliance & review

Governance and policy lifecycle

Compliance

Nebras, LFIs, and TPPs are required to adhere to this policy. Nebras is responsible for maintaining the versioning scheme, publishing version artefacts, and coordinating with ecosystem participants on upcoming releases.

Review and updates

This policy will be reviewed periodically by Nebras to ensure alignment with industry best practice and the evolving UAE Open Finance ecosystem. Material changes will be communicated to LFIs and TPPs in advance of taking effect.