API Performance & Customer Impact

Availability, latency, data freshness and usable journeys

Measure what the customer needs

API performance is the ability to serve the promised business capability accurately and within a useful time. A reachable gateway can coexist with failed authentication, stale balances or uncertain payments. Different products need different definitions of success.

Measure permission setup, account-information access, payment initiation and later status enquiries separately. Distinguish interactive requests from background refresh. A 200 response containing unavailable data is not the same outcome as a correct account response.

Latency, freshness and completion

Latency is elapsed response time at a defined boundary. State whether measurement includes network, authentication or downstream processing. Percentiles describe distribution; an average can hide a slow tail. Segment by product, partner, region and workload where useful, without excluding failures merely to improve the chart.

Freshness is the age of the information relative to its source or update point. Low response latency does not make yesterday's cache current. Payload timestamps and known limitations should remain visible to consumers. A partner should not describe a stale balance as live merely because the response was fast.

Business completion depends on the product: permission granted, data supplied, instruction accepted or a later payment outcome. Keep these states distinct. A payment-status uncertainty can be serious even when every HTTP request completed successfully.

Capacity and retry behaviour

Forecast normal traffic, campaign peaks, scheduled refresh and reconnect storms after disruption. Rate limits and quotas should be documented and implemented consistently with the applicable access framework. Do not apply a commercial preference that undermines mandated access duties.

Use bounded retries where they are safe, with backoff and appropriate randomness to avoid synchronised load. Distinguish transient technical failure from invalid scope or authority; repeatedly retrying a refused request rarely helps. Payment retries need instruction identity and idempotency across effects.

Timeout values should match the whole request path and service promise. An upstream timeout shorter than the downstream processing time can create unknown outcomes rather than definite failure. Provide enquiry and pending-state handling instead of encouraging a new payment.

Worked example: green availability, stale information

In this fictional service, the API returns cached account data during a source-system disruption. Gateway availability is high, but the cache age grows. A budgeting app keeps displaying the values as current.

The bank exposes freshness and a suitable degraded state, alerts on age and coordinates consumer handling. The partner displays the limitation. Operations joins related customer contacts to the incident and investigates any harm. Replacing a stale value with zero would introduce another misleading result.

Incidents and service commitments

Set service-level objectives against usable outcomes and keep contractual promises distinct from regulatory requirements. No one universal response time applies to every open-banking product. Identify any applicable interface-performance or reporting duty from the actual framework.

Status communication should identify affected capabilities, known limitations and the next update. Avoid presenting a partial outage as full recovery. After restoration, inspect outstanding instructions, data gaps and retry-driven duplicates before closing the business incident.

Review measures and sources

The EBA PSD2 rulebook and UK Open Banking standards provide market-specific context. Contract and operating objectives must be consistent with the applicable requirements.

Takeaway

Performance should describe the customer's usable outcome, data truth and safe failure behaviour. A green gateway graph alone cannot establish that the banking service works.

Continue to Open Banking Risk.