Open banking in the UK is moving into a more defined phase.
The initial years focused on access. Standards were established, APIs were deployed and connectivity improved across the ecosystem. Adoption followed, with growing volumes and broader use cases. But the emphasis is now shifting.
Policy and regulatory work is moving toward a longer-term structure that defines how open banking operates at scale. The National Payments Vision places account-to-account payments at the centre of a more competitive system, and further consultation is expected on how that model should be implemented and governed over time¹².
For teams building on top of these capabilities, this changes the nature of the work. The challenge is no longer simply integration. It is designing systems that remain stable as the model around them evolves.
From connectivity to operating model
Early implementations were judged on whether they worked.
Could a payment be initiated? Did the journey complete? Was performance acceptable?
Although those questions still matter, they are no longer enough. Because, as open banking becomes more formalised, systems need to support a defined operating model. That includes how consent is handled, how transactions are tracked, how exceptions are managed and how behaviour can be explained after the event. These requirements sit alongside performance rather than replacing it.
Designing for change rather than reacting to it
Regulatory change rarely arrives in a single step. It tends to develop through consultation, iteration and gradual alignment across participants. Systems that are tightly coupled to current assumptions tend to require repeated adjustment.
A more durable approach is to design for change from the outset.
That includes:
- treating consent as a persistent record rather than a one-time event
- maintaining consistent identifiers across the full transaction lifecycle
- structuring logs and telemetry for retrospective analysis
- separating orchestration logic from bank-specific integrations
This creates a foundation that can absorb change without significant rework.
John Blackmore, Head of Technology, describes the difference in practical terms:
“If you assume the rules will stay the same, you end up rebuilding. If you assume they will evolve, you build systems that adapt. That usually comes down to how well you can trace what happened and why.”
Observability becomes essential
As expectations increase, so does the need for clear visibility.
Understanding what happens across a payment journey requires more than a success or failure signal. Each transition point needs to be measurable and attributable.
That includes:
- initiation and request context
- consent and authentication events
- authorisation outcomes
- return states across app and web contexts
- completion confirmation and reconciliation
With that level of detail, teams can separate bank-side behaviour from application issues and prioritise changes based on actual failure patterns. And without it, performance improvement becomes guesswork.
Orchestration as a control layer
At scale, outcomes are shaped by how the full flow is managed.
Routing, fallback behaviour, consent state and session continuity all influence how a payment performs in practice. These elements also determine how predictable and explainable the system is.
Treating orchestration as a control layer brings consistency across different banks, reduces variability in user journeys and provides a clear structure for handling exceptions. It also creates a more stable foundation for governance.
Aligning product decisions with governance
As the regulatory model becomes clearer, product decisions carry more weight.
Choices about user flows, retry handling, consent management 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, Head of Operations, highlights where this becomes visible:
“When systems are ambiguous, the pressure lands in operations. Clear ownership and clear behaviour reduce support load and make outcomes easier to explain.”
Designing with that in mind produces more consistent outcomes across both customer journeys and internal processes.
Preparing for scheme-level evolution
Open banking is moving toward more structured, scheme-like characteristics. This brings additional considerations around pricing transparency, liability, dispute handling and consistency of experience.
Systems that already support traceability, clear ownership and consistent state management are better positioned for that transition. Those that do not tend to rely on implicit behaviour that becomes harder to sustain.
A practical shift
The next phase of open banking is not defined by new interfaces. It is defined by how existing capabilities are operated and governed.
For teams building and maintaining these systems, the priority is clarity. Clarity of state, clarity of ownership and clarity of behaviour across 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 minimise ambiguity, expose clear control points and support consistent outcomes across participants. The regulatory model will continue to develop. Systems designed with that assumption will require fewer changes and deliver more predictable performance over time.
- HM Treasury, National Payments Vision. Link
- Financial Conduct Authority, Payments regulatory priorities. Link
- Open Banking Limited, ecosystem updates. Link
