API Response Time Policy
Defines the response time the ecosystem is expected to deliver on every TPP request that reaches an LFI — what customers actually feel when they check a balance, confirm a payee, or authorise a payment.
Where this policy applies
Applies to every TPP-facing Open Finance API request in production that results in a corresponding request to the LFI's Ozone Connect, across every API family an LFI has enabled.
The subject of this policy is the request as the TPP experiences it — not any single hop within it. A request that is fast on one leg and slow on another is a slow request, and is measured as such.
A request is in scope where the API Hub calls Ozone Connect to serve it. Requests the API Hub answers entirely on its own are out of scope, because there is no LFI segment for the end-to-end figure to say anything about.
Out of scope
- Requests the API Hub serves without calling Ozone Connect — consent reads, authorisation, and token endpoints among them. The Hub's performance on these is managed by Nebras outside this policy.
- Sandbox or non-production environments
- The public internet between the TPP and the API Hub, and anything happening inside the TPP's own systems
- 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
Nothing else is excluded. In particular, there is no exclusion for time spent calling an external service — whether that call is made by the API Hub or by the LFI, and whether the service is the Trust Framework, a core banking platform, or any other dependency. Dependency latency is response time.
500 ms p95 per endpoint, per calendar day
Every endpoint is expected to return to the TPP within a p95 response time of 500 ms or better. 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 API families
This target aligns with the 500 ms average response time published in the Availability, Performance and Usage Benchmarks standard. Holding each 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.
TPP → API Hub → Ozone Connect → API Hub → TPP
Response time is measured as Time to Last Byte (TTLB) at the API Hub resource server: the clock starts when the API Hub receives the first byte of the TPP's request, and stops when the last byte of the response is written back to the TPP. Everything in between is inside the window.
TPP → API Hub — clock starts
The request arrives at the API Hub resource server (rs1.{lfiCode}.apihub.openfinance.ae). Measurement begins here, which is why the public internet between the TPP and the Hub falls outside the window.
API Hub processing — inbound
mTLS and DPoP verification, access token validation, consent validation, OpenAPI schema enforcement, and request enrichment with the customer, account, and TPP information the LFI needs. Any call the Hub makes to an external service while handling the request — including the Trust Framework — is inside the window.
API Hub → Ozone Connect → API Hub
Both network legs, plus everything Ozone Connect does in between. The LFI's own onward calls are inside the window too — to its core banking platform, to internal authorisation or decisioning services, and to any external service it depends on. No portion of the elapsed time is deducted for a slow dependency.
API Hub → TPP — clock stops
Response normalisation and error mapping, until the last byte is written to the TPP.
The measurement is taken as observed. There is no mechanism for either Nebras or an LFI to exclude a downstream system from its figures. Where a dependency is the cause of a missed target, the owning party is expected to address it — by caching, by moving the call off the request path, or by working with the provider — rather than to treat it as an exclusion.
One target, two owners
The 500 ms p95 is a single number measured on a single request, and both Nebras and the LFI are accountable for meeting it. Because the API Hub records the timing of each segment, a breach can be attributed to the party whose segment caused it.
Nebras owns the API Hub segment
- Hub processing on the way in and on the way out (stages 02 and 04 above)
- Every call the Hub makes to an external service while handling the request, including the Trust Framework
- The Hub's network legs to and from Ozone Connect
The LFI owns the Ozone Connect segment
- Everything from the request arriving at Ozone Connect to the last byte of its response leaving (stage 03 above)
- Every onward call Ozone Connect makes while handling the request, to internal or external systems alike
Attribution is settled by the API Hub's per-segment timing record. LFIs see their own segment in the Admin Portal through the LFI Performance report, which reports response times with API Hub processing removed; the Performance report alongside it reports the end-to-end figure this policy targets. Neither party may attribute a breach to the other in place of that record. Where a breach spans both segments, remediation is planned jointly.
What 500 ms covers for POST /payments
For POST /payments, the 500 ms target applies to the API response returned to the TPP — the point at which 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, which the API Hub maps and returns to the TPP. 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.
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 target must be demonstrably met across all in-scope endpoints over the proving period, measured on the full TPP-facing request
- 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. Where the API Hub segment is the cause, Nebras remediates it and the proving period is not counted against the LFI. This requirement applies equally to initial go-live and to any subsequent major version go-live.
Continuous, central observation
Nebras actively monitors response times in real time, using the API Hub's own logs of every TPP request. Response times are tracked continuously, per endpoint, against the 500 ms p95 target, with the API Hub and Ozone Connect segments recorded separately.
LFIs are expected to review their own response times, including the segment timings the API Hub reports back to them.
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. Where the attributed cause sits in the API Hub segment, the same expectations fall on Nebras.
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 is assessed on the TPP-facing figure; the obligations below fall on the party that owns the attributed segment.
Severity definitions
Obligations during a P1 or P2 degradation
Acknowledge promptly
For P1, within 15 minutes of the owning party becoming aware. For P2, within 1 hour.
Notify the other party
Through the agreed incident channel. Where the LFI owns the cause, it notifies Nebras; where the API Hub segment is the cause, Nebras notifies the affected LFIs.
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, whichever segment the degradation sits in. 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 party that owns the attributed cause is expected to provide a post-incident review within five business days of resolution. Where the cause spans both segments, the review is produced jointly. 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 that will be taken to prevent recurrence, with owners and dates
A minimum, not an aspiration
Customer experience improves continuously as response times fall. Nebras and LFIs alike are expected to:
- Track response times against target across every endpoint, not just in aggregate, and at segment level as well as end to end
- 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
- Keep dependency calls off the request path wherever the data allows it to be cached or pre-fetched
- Participate in ecosystem-wide reviews convened by Nebras to share practices for keeping Open Finance services fast