Prerequisites 4 min read
Before your API Hub can be provisioned, you MUST complete the prerequisites questionnaire via a Service Desk ticket. This page describes the information you will need to provide and why it is required.
Ensure your organisation is registered in the Trust Framework before starting the prerequisites process. See Trust Framework Onboarding for details.
Legal name, IBAN, and contacts
| Field | Description |
|---|---|
| LFI Legal Name | Your legal name as it appears on your Trust Framework organisation page. |
| IBAN Bank Code | The IBAN bank code for the brand associated with this onboarding. Not applicable for insurers. |
| Primary Technical Contact (PTC) | Email address of the main technical contact for integration queries. |
| Primary Business Contact (PBC) | Email address of the main business contact. |
Short identifier used in hostnames and headers
Your LFI Code is the short identifier that represents your institution across the API Hub. It is used in two places:
- Hostnames. It forms part of the URL for both the TPP-facing and LFI-facing domain names — including your API Hub's well-known discovery document URI. See Environment Specific Configuration for the full list of
auth1.{lfiCode}.*,rs1.{lfiCode}.*,hh.{lfiCode}.*,cm.{lfiCode}.*, andadmin.{lfiCode}.*hostnames. - The
o3-provider-idrequest header. Every request the API Hub forwards to your Ozone Connect endpoints carrieso3-provider-idset to your LFI Code, so Ozone Connect can identify which Hub the call originated from. This matters most for multi-segment LFIs.
Choosing a value
Pick a code that is:
- Short — typically 3–8 characters. It will appear in every TPP integration and every URL.
- Lowercase alphanumeric — no spaces, hyphens, underscores, or special characters (it must be DNS-safe).
- Recognisable as your brand — usually an abbreviation of your legal or trading name.
- Stable — once you go live, the LFI Code is effectively immutable. Changing it later means re-issuing every URL TPPs depend on, and is highly disruptive.
Multi-brand institutions
If your institution operates multiple brands (e.g. retail and business), each brand will have its own API Hub and its own LFI Code, and each brand is onboarded separately. The common convention is to take your single-brand short code and append the segment as a single lowercase token — for example, FAB uses fabretail for its retail Hub and fabbusiness for its business Hub. See Multi-Segment LFIs for the full deployment model.
Hosting environment and digital channels
Hosting Environment
Indicate where your Ozone Connect endpoints will be hosted:
- Azure
- AWS
- OCI (Oracle Cloud Infrastructure)
- GCP (Google Cloud Platform)
- On-premises
Digital Channels
Indicate which digital channels you currently support for end user authentication and consent journeys:
- Web
- Mobile
- Both
Will you adopt CAAP?
Indicate whether you intend to adopt CAAP — the Nebras-operated Central Authentication and Authorization Platform — for the end user's authentication and consent authorisation experience.
- Yes — CAAP. When a TPP creates a consent, the end user is redirected to CAAP for authentication and consent approval, and CAAP delivers the Consent Management Interface. You do not provide an Authorization Endpoint URL, and you do not implement the LFI-side Consent Management Interface or build directly against Headless Heimdall. You MUST implement the CAAP Operations endpoints on Ozone Connect — see CAAP.
- No — LFI-operated. The end user is redirected to your Authorization Endpoint; you implement the authentication and consent authorisation UX and the Consent Management Interface yourself.
Adopting CAAP does not change the LFI's responsibility to deliver the Ozone Connect endpoints for Bank Data Sharing, Bank Service Initiation, Insurance Data Sharing, and the other Open Finance services exposed to TPPs.
One Hub per business brand
Indicate how many business brands you will be implementing. Each brand represents a separate API Hub instance — for example, a bank may have separate brands for retail and corporate, each requiring its own onboarding.
Which API families you plan to support
Indicate which API families you plan to support. The available families are:
- Bank Data Sharing — account information, balances, transactions, and related data
- Bank & FX Service Initiation — payment initiation, including domestic transfers
- Consent Events & Actions — consent lifecycle event notifications
Insurance API families (e.g. Health, Motor, Travel) will be covered in a future update to this documentation.
Three mandatory endpoints
The following health check endpoints are mandatory for all LFI implementations:
| Endpoint | Description |
|---|---|
GET/hello | Basic connectivity check. |
GET/hello-mtls | Verifies mutual TLS is correctly configured. |
GET/echo-cert | Returns the client certificate details received by your server, used to verify certificate propagation. |
These endpoints MUST be implemented and reachable before your integration can proceed to testing. See Ozone Connect — Health Check for full API reference and usage.
Pre-validation, event notifications, augmentation
During onboarding you will be asked which optional features you plan to implement. These are configured per API family.
Consent Pre-Validation
Allows your Ozone Connect implementation to validate a consent before it is created. When enabled, the API Hub calls your validation endpoint during consent creation.
Consent Pre-Validation is strongly recommended for all LFI implementations. Implementing this feature allows you to catch invalid consent parameters early — before the end user begins the authorization journey — resulting in a significantly better customer experience. This feature may become a mandatory requirement in a future version of the specification if adoption is insufficient.
See Consent Events & Actions for details.
Consent Event Notification
Enables asynchronous notification of consent lifecycle events to your Ozone Connect implementation. When enabled, the API Hub sends event notifications when consents are created, authorized, revoked, or otherwise modified.
See Consent Events & Actions for details.
Consent Augmentation
Enables the POST/consent/action/augment endpoint on your Ozone Connect implementation, which the API Hub calls to request an augmented consent payload during consent creation.
LFIs SHOULD NOT enable Consent Augmentation. Select No on the onboarding form unless Nebras has specifically advised you to enable it. The feature may be revisited in a future version of the specification.