The context: performance now matters
According to the latest report from Open Banking Limited, October 2025 data shows the UK’s open banking Account Service Provider APIs (ASPSP APIs) reached 99.22% average availability (unweighted) and 331 milliseconds average response time¹.
These are real performance benchmarks.
As open banking moves from “innovation sandbox” to “production at scale”, these numbers are differentiators.
Why this infrastructure shift hurts many providers
1. Latency kills conversion faster than cost
Merchants and fintechs using open banking for payments or data take delight in the lower transaction cost compared to cards. But if an API call takes 500+ ms or fails entirely, a card fallback is likely and trust drops.
OBL’s data shows a failure rate of 0.61% failed API calls in October 2025¹. Every failure is friction, and every millisecond counts.
2. Observability, not just availability
Availability alone isn’t enough. Without end-to-end telemetry - consent capture, authorisation latency, API endpoint success/failure, refund paths - you cannot demonstrate operational quality to banks, regulators or enterprise clients. OBL’s Data-Collection Framework emphasises that TPPs must collect and report detailed metrics².
3. Scale is real and unforgiving
Earlier open banking flows were small: single account, one off. As services grow - aggregated accounts, VRPs, recurring flows - the platform must support thousands of concurrent sessions, multiple ASPSPs, failover routing and identity linkage. Legacy API designs tuned for “one user, one request” often buckle under production load.
What this means for infrastructure providers like Asima
At Asima we see three imperatives:
- Design for <200 ms calls and ≥99.9% uptime. Internal SLAs shouldn’t aim for “good enough” - they must be significantly better than the market average to win enterprise trust.
- Embed comprehensive observability. Consent logs, authorisation metrics, endpoint health, fallbacks, session failures - all must feed dashboards that alert before the client notices.
- Ensure multi-ASPSP diversity and resilience. Platform design must anticipate ASPSP endpoint failure: route around it; notify the client; maintain service. Redundancy becomes a KPI, not an afterthought.
“Infrastructure isn’t just the pipes - it’s the performance promise.” ~ Kieron James, CEO, Wonderful Payments (Asima)
Practical steps for clients this quarter
- Map your API volume vs latency budget: Recognise your user-peak profile and simulate real-world volumes across all integrated ASPSPs.
- Build telemetry early: Instrument consent flows, authorisation, API errors, fallback usage. Use the data to root-cause performance gaps.
- Define SLA tiers with partners: If your backend uses third-party ASPSP connections, make latency and availability part of your commercial terms—not just “connect and hope”.
- Plan for identity flows and VRP: Recurring flows amplify performance risk because re-authorisation, consent refresh and multi-account orchestration multiply complexity.
When open banking applications are small, occasional delays are tolerable. At scale, they aren’t. API performance becomes a trust currency. Users expect seamless flows; merchants expect 99.9% reliability. The numbers from October 2025 show the infrastructure side is stabilising - but they also raise: “What differentiates the winner?”
For firms building infrastructure, the answer is clear: obsess over performance, observability and resilience. That is how you turn rails into advantage.
The market is no longer asking if open banking works - it expects how well it performs. Asima is built for the latter, not just the former.
¹ Open Banking Limited. October 2025 API performance – unweighted average availability 99.22%, average response time 331 ms. Link
² Open Banking Limited. Data collection framework for API availability and performance (JROC/OBL), v1.4. Link
