Operational resilience for open banking: a UK enterprise playbook

July’s OBL dashboard logged 11,052,438 failed API calls (0.54%). At national scale, tiny percentages matter. Here’s a UK-focused playbook to assess providers, test severe-but-plausible scenarios, and embed operational resilience in your open banking stack. [^1]

Open banking also now carries meaningful payment volume. In March 2025, the UK logged 31 million open banking payments, about 1 in 13 (7.9%) of all Faster Payments. With material customer impact at stake, firms must evidence resilience, not just promise it. ^[2]

What does operational resilience actually require?

Under the FCA’s PS21/3 framework, firms must identify important business services, set impact tolerances (the maximum acceptable disruption), and remain within those tolerances during severe but plausible scenarios. The transition period ended 31 March 2025. ^[3]

How does this apply to open banking payments and data?

If open banking powers your recurring collections, account verification/onboarding, or real-time data feeds for lending and risk, these are prime candidates for “important business services”. Your plan must show how you stay within tolerance if, for example, a major ASPSP’s API degrades, Faster Payments slows or queues, or your third-party provider suffers a cloud incident. UK authorities have also urged payments firms to step up disruption-mitigation and testing ahead of 2025. ^[4]

Which metrics matter for resilience decisions?

Three outside-in signals help calibrate risk and design tests:

Ecosystem failure rates, not just your provider’s stats. OBL’s July dashboard quantifies failures (business and technical) across brands. ^[1:1]
Payment share and growth, to gauge customer impact if your service fails. March 2025’s 31m payments, 7.9% of Faster Payments, signals material dependency. ^[2:1]
Forthcoming governance, with the FCA’s Future Entity expected to formalise standards, certification and performance oversight. ^[5]

What questions should we ask an open banking provider?

Uptime and latency: What is your published SLA and historic performance?
Peak handling: How do you scale for promotions, billing cycles or sudden demand, and can you evidence sustained high request rates?
Idempotency and replay protection: How do you prevent duplicate collections during retries/failovers?
Dependency management: Which banks, cloud regions and third-party services are in the path, and how are they monitored?
Incident management: Do you provide a transparent status page, proactive alerts, post-mortems and clear escalation paths?
Resilience testing: Do you run severe-but-plausible exercises (e.g. extended ASPSP errors, FPS frictions, consent-dashboard incidents), and can we review results? ^[6]
Data residency and compliance: Where is data processed and stored, and how does that align with UK expectations?

How should we test ‘severe but plausible’ scenarios?

Start with ecosystem realities, then tune to your business:

ASPSP degradation: Simulate a top-3 bank returning elevated 4xx/5xx for six hours. Measure delayed/failed collections, customer comms, and reconciliation impact. Use OBL’s monthly failure metrics to calibrate volumes and timelines. ^[1:2]
Faster Payments frictions: Model slower or queued FPS settlement and observe cash flow, ledger and customer-experience impacts.
Third-party or region outage: Disable your provider’s primary cloud region in a controlled test, confirm RTO/RPO vs tolerance, and verify idempotent recovery (no double charges).
Consent/dashboard incident: Ensure customers can still cancel, pause or review mandates, or that you have fallbacks and clear messaging.

Document results against impact tolerances, update run-books, and repeat. Regulators expect evidence, not assertions. ^[3:1]

How will the Future Entity and UK Payments Initiative change resilience?

The FCA’s FS25/4 outlines expectations for a Future Entity to maintain standards, certify implementations and monitor performance. In parallel, 31 organisations have funded the creation of a new industry-owned operator (expected to trade as UK Payments Initiative Ltd) to deliver commercial VRP (“Smart Debits”). Together, these moves should lift the baseline on interoperability, observability and recurring-payments resilience. ^[5:1]^[7]

What does ‘good’ look like in practice?

A credible open banking partner should offer:

Transparent SLAs and status history, with incident RCAs.
Idempotent APIs for payment initiation and mandate operations, so retries never double-charge.
Real-time hooks for consent changes and failures, with run-booked operational responses.
Scalable cloud foundations with multi-region failover and tested recovery objectives.
UK alignment on data protection and operational-resilience expectations. ^[6:1]

How Asima approaches resilience

Asima is engineered for enterprise use in the UK market:

Clear SLAs and incident communications, with status transparency.
Serverless scaling on Google Cloud (e.g. Cloud Run) for predictable performance at peak.
Idempotency and replay protection across payment and consent workflows.
Real-time webhooks for events that affect billing or customer experience.
UK-aligned operations and a roadmap tuned to the Future Entity and the roll-out of Smart Debits. These capabilities and our Google Cloud architecture are described in our launch article. ^[8]

A quick resilience checklist you can use today

Have we named our open-banking-related important business services?
Are impact tolerances defined in time and customer-harm terms?
Do we have evidence of testing against ASPSP, FPS and provider-level incidents?
Can we show board oversight and a funded remediation plan?
Do our providers offer status transparency, RCA access, and idempotent APIs?

Final thought

Open banking now moves real money at national scale, and ecosystem data shows that tiny percentages still mean millions of problematic calls in a single month. The FCA expects firms to be within tolerance now, not later. Build for failure, choose partners who can prove resilience, and treat transparency as a customer feature. ^[1:3]^[3:2]