Ozone Connect Response Time Policy
Defines the response times LFIs are expected to meet for their Ozone Connect endpoints — what customers actually feel when they check a balance, confirm a payee, or authorise a payment.
Where this policy applies
Applies to all Ozone Connect endpoints operated by an LFI in production, across every API family the LFI has enabled.
Out of scope
- Endpoints operated by the API Hub itself (such as consent reads, authorisation, and token endpoints)
- Sandbox or non-production environments
- Latency attributable to the API Hub, the TPP, or the broader internet
- Time taken by the LFI to complete fraud, sanctions, and compliance screening of a payment after the API response has been returned
- Time taken by the underlying payment rail to process and settle a payment (for example Aani), governed by the applicable scheme rules
- Time a customer spends completing authentication at the LFI — measured separately under the Consent Journey requirements
500 ms p95 per endpoint, per calendar day
Each LFI is expected to meet a p95 response time of 500 ms or better for its Ozone Connect endpoints. A single target keeps the policy simple to reason about, and reflects the reality that customers expect comparable responsiveness whether they are checking a balance, retrieving transactions, confirming a payee, or initiating a payment consent.
Endpoints in scope (examples)
- Bank Data Sharing —
GET /accounts,GET /accounts/{accountId}/balances,GET /accounts/{accountId}/transactions,GET /accounts/{accountId}/standing-orders,GET /accounts/{accountId}/beneficiaries, and other account-scoped reads - Service Initiation —
POST /payments,POST /payment-consents,POST /payment-consents/{consentId}/file,POST /payment-consents/{consentId}/refund,GET /payments/{paymentId} - Confirmation of Payee —
POST /customers/action/cop-query - Products and Leads —
GET /products,POST /leads - Insurance, FX, Account Opening, ATM, User Operations, and Consent Events — all endpoints under the corresponding Ozone Connect API families
This target aligns with the 500 ms average response time published in the Availability, Performance and Usage Benchmarks standard. Holding each Ozone Connect endpoint to this p95 figure — rather than only an average — ensures the customer experience remains consistent across the long tail of requests, not just on average.
What 500 ms covers for POST /payments
For POST /payments, the 500 ms target applies to the Ozone Connect API response — the point at which the LFI acknowledges the payment request has been received and accepted for onward processing. It does not require the LFI to have completed screening or settlement within 500 ms.
Payment processing spans three distinct phases, each with its own expectation:
API response — 500 ms p95 (this policy)
The LFI acknowledges the payment request and returns an initial payment status. This is the point at which the TPP knows the request is in the LFI's hands and can show the customer an appropriate in-progress state.
Fraud, sanctions, and compliance screening — up to 3 seconds
Screening runs after the API response has been returned. Once screening is complete, the LFI updates the payment status accordingly — either progressing the payment to the rail or rejecting it with the appropriate reason.
Rail execution — payment scheme rules
For domestic instant payments this is subject to the Aani scheme rules (3 seconds per payment end-to-end, as set out in the Availability, Performance and Usage Benchmarks standard). The LFI's obligations toward the scheme operator are defined by the scheme and sit outside this policy.
The same structure — fast API acknowledgement followed by asynchronous processing — applies to other service initiation endpoints such as POST /payment-consents/{consentId}/file and the refund and FX endpoints. In every case, the 500 ms target in this policy refers only to the API response time.
How response time is measured
Response time is measured as Time to Last Byte (TTLB): the elapsed time from the moment the API Hub issues the request to Ozone Connect until the final byte of the response is received by the Hub. This isolates the LFI's contribution from anything happening on the TPP side or the public internet.
Proving the target before go-live
Before an LFI is signed off as compliant with this policy and approved to go live on the ecosystem, the LFI must complete a live proving period with one or more TPPs.
- During the proving period, the LFI operates its Ozone Connect endpoints against real TPP traffic in production
- The 500 ms p95 response time target must be demonstrably met across all in-scope Ozone Connect endpoints over the proving period
- Nebras reviews the results and confirms, or withholds, sign-off before the LFI is approved for general availability
An LFI that does not meet the target during proving remains in proving until it does, with Nebras support where required. This requirement applies equally to initial go-live and to any subsequent major version go-live.
Continuous, central observation
Nebras actively monitors every LFI's Ozone Connect response times in real time, using the API Hub's own logs of every request made to the LFI. Response times are tracked continuously, per endpoint, against the 500 ms p95 target.
LFIs are expected to review their own Ozone Connect response times.
When the target is persistently missed
"Persistently" is assessed in the round, but typically means any of:
- Missing the 500 ms p95 target for the same endpoint in three consecutive calendar months
- Three or more P1 or P2 degradations in a rolling 90-day window
- Failure to deliver remediation actions agreed in a previous review
Engagement may include a formal review meeting, a written remediation plan with owners and dates, enhanced (typically weekly) reporting, and escalation to the relevant regulatory authority where non-compliance is persistent or where the interests of customers or TPPs require it.
A sustained breach is functionally an incident
Even if the service is technically still responding, a sustained breach of the response time target is treated as an incident.
Severity definitions
LFI obligations during a P1 or P2 degradation
Acknowledge promptly
For P1, within 15 minutes of the LFI becoming aware. For P2, within 1 hour.
Notify Nebras
Through the agreed incident channel.
Provide regular status updates
For P1, at least every 30 minutes until performance is restored. For P2, at least every 2 hours.
Declare resolved
Only once performance has been stable within target for a reasonable observation period (typically 30 minutes).
Nebras takes responsibility for cascading status information to affected TPPs through its own communication channels. LFIs are not expected to communicate directly with TPPs during degradation incidents.
Post-incident review
For every P1 degradation — and for any P2 that recurs within 30 days — the LFI is expected to provide a post-incident review to Nebras within five business days of resolution. The review should cover:
- A factual timeline of the degradation
- The root cause, including any capacity, data-growth, or dependency factors
- The customer and TPP impact
- The remediation already applied
- Any further actions the LFI will take to prevent recurrence, with owners and dates
A minimum, not an aspiration
Customer experience improves continuously as response times fall. LFIs are expected to:
- Track response times against target across every endpoint, not just in aggregate
- Pay attention to trends at p99 even where p95 remains within target — p99 is an early warning of capacity or data-growth issues
- Review monthly response time reports with their engineering and operations leadership
- Invest in the capacity, caching, and downstream tuning required to keep pace with volume growth
- Participate in ecosystem-wide reviews convened by Nebras to share practices for keeping Open Finance services fast