Major Version Deprecation Policy
Defines the dual-running and deprecation requirements LFIs must follow when a new major version of the Open Finance standard is introduced — protecting TPPs and their customers from disruption while the ecosystem moves forward.
What this policy covers
Applies to all LFIs operating within the UAE Open Finance ecosystem, covering major version transitions of the LFI API Hub implementation, the dual-running period, and the formal deprecation process.
When dual-running does not apply
Where an LFI implements the API for the first time, only a single version is required initially. There is no expectation to support dual-running before a prior version exists.
There is also no expectation for LFIs to implement dual-running or formal deprecation processes for:
- Minor (non-breaking) API version updates
- Errata or corrective changes
- UI components or presentation-layer changes
- Downstream system or internal implementation changes
These changes are expected to be backward compatible and managed without requiring concurrent version support.
Operating two versions in parallel
When an LFI is ready to go live with a new major version (e.g. Vx.y → Vz.0), it must operate both the prior and new version concurrently for the duration of the deprecation window.
How dual-running works
- Deploy two active versions of their API Hub implementation simultaneously (e.g. V1.x and V2.0)
- Route incoming API requests to the correct implementation based on the version the TPP requested — currently via the
o3-api-uriheader - Ensure each implementation is independently maintained and supported, with no cross-version dependencies that could cause instability
Both implementations must remain fully functional and compliant with their respective standards throughout the dual-running period.
An LFI running V1.2 and V2.1 simultaneously would route a request to https://api.bank.ae/open-finance/v1.2/accounts to the V1.2 implementation, and a request to https://api.bank.ae/open-finance/v2.1/accounts to the V2.1 implementation.
The five-phase deprecation pipeline
The deprecation of a prior version follows a structured timeline to protect TPPs and their customers from unplanned disruption.
Launch and communication
Stand up the new version — The LFI deploys and validates the new major version of their API Hub implementation in production.
Validate readiness — The LFI confirms the new version is functioning correctly, including end-to-end consent flows, data sharing, and service initiation (as applicable).
Formal communication via Nebras — Nebras issues a formal ecosystem-wide communication informing all TPPs that the new version is available, that they are expected to begin migrating, and that the prior version will be deprecated in accordance with this policy.
Migration monitoring (Months 1–3)
From the date of the formal communication, LFIs must actively monitor the creation of new consents across both versions.
At the 3-month mark, LFIs must report to Nebras on the status of TPP migration, specifically identifying any TPPs that are still raising new consents on the prior version. Nebras will use this information to engage directly with non-migrated TPPs.
Final migration window (Months 4–5)
A further 2-month window is provided for remaining TPPs to complete migration.
At the 5-month mark, LFIs must again report to Nebras identifying any TPPs still raising new consents on the prior version. If no new consents are being raised on the prior version at this point, the LFI may request Nebras approval to proceed to Phase 4.
Restricting new consents on prior version
With Nebras approval, the LFI may restrict the creation of new consents on the prior version. This means:
- Existing consents on the prior version remain valid and must continue to be honoured
- No new consent journeys can be initiated against the prior version
- TPPs with active consents on the prior version may continue to exercise those consents until they expire
Sunset of prior version
From the point at which new consent creation is restricted, the prior version must remain operational for a further 12 months, providing sufficient time for all existing consents on the prior version to expire naturally.
After this 12-month period, and once Nebras confirms that no active consents remain on the prior version, the LFI may decommission the prior version entirely.
Milestone summary
Where TPPs do not migrate by the six-month mark
Where TPPs have not completed migration to the new version by the 6-month mark from the date of formal communication, Nebras will take an active role in managing the deprecation.
- Directly engaging with non-migrated TPPs to understand technical or operational blockers
- Setting individual migration deadlines for non-migrated TPPs, with formal written notice
- Escalating persistent non-compliance to the relevant regulatory authority where appropriate
- Coordinating with the LFI to ensure migration support is available to affected TPPs
- Retaining oversight of the LFI's deprecation timeline and adjusting it where necessary to protect TPPs and their customers
LFIs must provide Nebras with any data or reporting required to support this process.
Sustaining both versions during the transition
LFIs are expected to maintain appropriate operational support for both versions throughout the dual-running period.
- Incident management — Both API versions must be covered by the LFI's standard incident management and response procedures, with equivalent SLAs applied to both
- Monitoring and alerting — LFIs must maintain active monitoring across both API versions, including availability, error rates, and latency
- Change management — Any changes to either version during the dual-running period must be assessed for impact on the other version and communicated to Nebras in accordance with standard change management procedures
- TPP support — LFIs must be able to provide technical support to TPPs migrating between versions, including guidance on breaking changes and access to sandbox environments running both versions
- Consent data integrity — LFIs must ensure that consent records associated with the prior version are preserved and remain accessible for the full duration of those consents' validity, regardless of the deprecation status of the API version
Adherence and Nebras discretion
LFIs are required to adhere to this policy for all major version transitions within the UAE Open Finance ecosystem. Failure to comply, including failure to dual-run versions during the transition period or failure to report migration status to Nebras, may result in regulatory escalation.
Nebras reserves the right to adjust deprecation timelines in exceptional circumstances, including where ecosystem-wide migration issues are identified or where the interests of TPPs or their customers require additional protection.