Multi-Segment LFIs — How to Structure API Hubs Across Customer Segments
Many LFIs serve more than one customer segment — for example retail, SME, private banking, or corporate. When those segments authenticate their customers in different places, the LFI needs one API Hub per authentication context, but can share a single Ozone Connect — minimising LFI-maintained certificates.
Authentication context dictates topology
The API Hub is more than a proxy — it acts as the OIDC Authorization Server for the LFI within the Open Finance ecosystem. When a TPP drives an end user through an authorization flow, the API Hub is the entity that:
- Exposes the single OIDC
/authorizeendpoint the TPP redirects the end user to - Issues the access tokens the TPP uses to call APIs
- Holds the authoritative record of consents
Because the API Hub must behave as a conformant OIDC Authorization Server, it has one authorization endpoint that redirects the end user into the LFI's own authentication experience (see the Consent Journey API Guide and the Authorization Endpoint configuration).
If retail and SME customers authenticate in different places — for example, retail customers in the retail mobile app and SME customers in a separate business banking portal — a single authorization endpoint cannot send an end user to both. Since the Hub mimics a standard Authorization Server, it can only be configured to redirect to one authentication flow.
In that situation the LFI needs one API Hub per distinct authentication context:
- Retail end users → Retail API Hub → Retail authentication endpoint
- SME end users → SME API Hub → SME authentication endpoint
The same logic applies to any additional segment (private banking, corporate) that has its own authentication experience.
If all segments authenticate through the same endpoint — for example, a single unified banking app that handles both retail and SME sign-in — a single API Hub is sufficient. The need for multiple Hubs is driven by distinct authentication flows, not by the existence of multiple products.
One Trust Framework org, one client, one Ozone Connect
- One Trust Framework organisation — the LFI is a single legal entity in the UAE Open Finance ecosystem and is registered as one organisation regardless of how many segments it serves.
- One API Hub deployment per authentication context — e.g. one for retail, one for SME. Each Hub has its own authorization endpoint, its own environment-specific onboarding, and its own base URLs.
- One shared
C3-hh-cm-clientapplication — both Hubs use the same client registration. This means the LFI's client-side identity and signing material is created once and reused. - One shared Ozone Connect deployment — the LFI exposes a single set of Ozone Connect APIs, and routes incoming Hub requests to the correct downstream core using the
o3-provider-idheader.
The LFI's burden does not grow with extra Hubs
LFI-held certificates — maintained once, shared across Hubs
LFI-held certificates live on the LFI's Trust Framework organisation and are held by the LFI. Because both Hubs sit under the same organisation and share the same C3-hh-cm-client application, the LFI maintains one set of these certificates:
| Certificate | Purpose | Reused across Hubs |
|---|---|---|
| C3 | LFI client cert used when calling Consent Manager & Headless Heimdall | ✅ |
| S4 | LFI server cert identifying Ozone Connect to the API Hub | ✅ |
| Sig4 | LFI JWT Auth signing key (only if JWT Auth is selected) | ✅ |
| Enc1 | LFI encryption key used to decrypt PII | ✅ |
See API Hub Connectivity & Certificates for the full certificate model and the existing "Certificate reuse across brands" note.
Ozone-held certificates — additional material added per Hub
Each additional API Hub requires its own server-side certificates — most visibly S1, the server transport certificate that identifies the Hub instance to TPPs. These are added to the LFI's Trust Framework organisation so TPPs can validate the Hub's identity, but the private keys are held and maintained by Ozone.
From the LFI's perspective, these certificates appear under the organisation but require no operational involvement — the LFI does not generate, store, or rotate the private key material.
| Certificate | Purpose | Added per Hub | Private key held by |
|---|---|---|---|
| S1 | Identifies the Hub instance to TPPs | ✅ | Ozone |
| S3 | Identifies CM & HH servers to the LFI | ✅ | Ozone |
| Sig2 | Signs API Hub responses / id_token to TPPs | ✅ | Ozone |
| C4 | Hub client cert when calling Ozone Connect (held in Ozone's org) | ✅ | Ozone |
| Sig3 | Signs Hub-side JWT Auth headers (held in Ozone's org, only when JWT Auth is used) | ✅ | Ozone |
Net effect: the LFI's own certificate maintenance burden does not grow as additional Hubs are added. The one-time set of C3, S4, Sig4, and Enc1 covers every Hub sitting under the organisation.
o3-provider-id selects the segment
Because the LFI uses a single shared Ozone Connect deployment, incoming requests from the multiple Hubs arrive at the same set of endpoints. The Ozone Connect layer must identify which Hub the request came from and route internally to the appropriate downstream core (retail core vs SME core, for example).
The API Hub tells the LFI which Hub the request originated from via the o3-provider-id request header. The value sent on every request is the LFI Code for the Hub that originated it — the same code that forms part of that Hub's TPP-facing and LFI-facing hostnames (see Prerequisites — LFI Code). Because each segment Hub is onboarded with its own LFI Code, Ozone Connect can use o3-provider-id directly to identify the segment.
For example, FAB operates separate retail and business Hubs in production with LFI Codes fabretail and fabbusiness respectively — Ozone Connect receives those exact values in the o3-provider-id header on each request.
| Request | o3-provider-id value (FAB example) | LFI action |
|---|---|---|
| Retail Hub → Ozone Connect | fabretail | Route to retail core banking system |
| Business Hub → Ozone Connect | fabbusiness | Route to SME / business core banking system |
Implementation guidance
- The
o3-provider-idvalue is fixed at onboarding when each Hub's LFI Code is agreed with Nebras. There is no separate configuration step. - Treat
o3-provider-idas the first branching decision inside Ozone Connect. All downstream logic (account lookup, customer lookup, payment execution, consent validation) should resolve through the segment's own core. - Validate the header on every request — reject calls with a missing or unknown
o3-provider-id. - Keep segment boundaries clean: a consent created via the retail Hub MUST be served by the retail core; a consent created via the business Hub MUST be served by the business core. Do not allow cross-segment resolution.
o3-provider-idis the supported identifier.o3-aspsp-idis a deprecated alias retained for backward compatibility only — see the request header tables in each API guide (e.g. Bank Data Sharing API Guide).
At a glance
| Concern | Recommendation |
|---|---|
| Trust Framework organisations | One |
| API Hub deployments | One per distinct authentication context (e.g. retail, SME) |
C3-hh-cm-client application | One, shared |
| LFI-held certificates (C3, S4, Sig4, Enc1) | One set, shared across Hubs |
| Ozone-held certificates (S1 etc.) | Added per Hub; maintained by Ozone |
| Ozone Connect | One deployment, routing on o3-provider-id |
| Downstream cores | One per segment, selected by o3-provider-id |
This pattern keeps the LFI's operational and certificate footprint independent of the number of segments served, while still meeting the Open Finance authentication and authorization model for each segment independently.