Open banking’s next phase: from framework to operating model

Open banking in the UK is entering a different phase.

The initial focus was on access. Standards were defined, APIs were implemented and connectivity improved across the ecosystem. Adoption followed, with increasing volumes and broader use cases across payments and data sharing.

The direction is now changing. Policy attention is shifting toward long-term structure, governance and sustainability. The National Payments Vision places account-to-account payments at the centre of a more competitive payments landscape, while the Financial Conduct Authority continues to signal further work on how open banking should operate over time¹².

For product and engineering teams, this introduces a more practical question. How do you build systems that remain stable as the regulatory model evolves?

From implementation to accountability

Early open banking implementations prioritised connectivity. Success was measured by whether a payment could be initiated, whether a journey completed, and whether performance met baseline expectations.

Those measures remain important, but they are no longer sufficient on their own. As open banking moves into a more formal operating environment, accountability becomes a design requirement. Systems need to demonstrate:

• how consent is obtained and preserved;
• how transactions can be traced across participants;
• how exceptions are handled and owned;
• how decisions can be explained after the event.

All of which moves the emphasis from integration to operating model.

Designing for regulatory continuity

Regulatory change rarely arrives as a single event.

It tends to emerge incrementally, through consultation, clarification and gradual alignment across participants. Systems designed only for current requirements often require repeated rework as those expectations evolve.

A more robust approach is to design for continuity. That includes:

• treating consent artefacts as durable records rather than transient events;
• maintaining consistent identifiers across the full lifecycle of a transaction;
• structuring logs and telemetry so they can support retrospective analysis;
• separating orchestration logic from bank-specific implementations.

This creates a system that can absorb regulatory refinement without structural disruption.

John Blackmore, Head of Technology at Asima, puts it directly:

“The systems that scale are the ones that assume the rules will tighten. If you design for auditability and traceability from the start, you don’t need to retrofit control later.”

The role of observability in a governed environment

As governance expectations increase, so does the importance of observability.

Operational clarity depends on understanding what happens at each stage of a payment journey. This goes beyond simple success or failure metrics. Teams need to capture:

• initiation and request context;
• consent and authentication events;
• authorisation outcomes;
• return states across app and web contexts;
• completion confirmation and reconciliation.

With this level of instrumentation, it becomes possible to distinguish between bank-side behaviour, application defects and user-driven outcomes.

Without it, performance issues are harder to diagnose and governance requirements become difficult to evidence.

Orchestration as a control surface

At enterprise scale, open banking performance is shaped less by individual API calls and more by how the overall flow is orchestrated.

Routing, fallback handling, consent state and session continuity all contribute to outcomes. In a more formalised ecosystem, orchestration also becomes a control surface. It determines:

• how consistently journeys behave across banks;
• how exceptions are handled and recovered;
• how predictable outcomes are for customers and support teams;
• how easily behaviour can be audited and explained.

Treating orchestration as a first-class system concern leads to more stable and measurable performance.

Aligning product decisions with governance expectations

As regulatory structures become more defined, product decisions carry governance implications. Choices about user flows, retry behaviour, consent handling and error states affect not only conversion but also compliance, liability and operational clarity. This requires closer alignment between product, engineering and operations.

Carmen James, Asima's Head of Operations, highlights the operational impact:

“When governance is unclear, the pressure shows up in operations. Support teams carry the uncertainty. Clear design and clear ownership remove that burden.”

Designing with governance in mind reduces ambiguity and creates a more consistent experience across both customer journeys and internal processes.

Preparing for scheme-level evolution

Open banking is moving toward more formalised scheme structures. This introduces additional considerations around:

• commercial models and pricing transparency;
• liability frameworks across participants;
• dispute handling approaches;
• consistency of experience across banks.

Systems that already support traceability, consistent state management and clear ownership will adapt more easily to these developments. Those that do not will require structural change.

A practical shift

The next phase of open banking is not defined by new interfaces. It is defined by how existing capabilities are operated, governed and scaled. For teams building and maintaining these systems, the priority is clarity:

• clarity of state;
• clarity of ownership;
• clarity of behaviour under both success and failure conditions.

That clarity supports both performance and compliance.

Structured progression

Open banking has moved beyond initial enablement. The focus is now on durability.

Systems that perform well in this environment are designed with precision. They minimise ambiguity, expose clear control points and support consistent outcomes across participants.

The regulatory model will continue to evolve. Systems that are built with that assumption will require fewer adjustments and deliver more reliable performance over time.

Footnotes

1. HM Treasury, National Payments Vision. Link
2. Financial Conduct Authority, Payments regulatory priorities and open banking direction. Link
3. Open Banking Limited, ecosystem updates and adoption data. Link