Open banking is creating new opportunities across financial services, but questions remain over how widely institutions can participate as frameworks mature and delivery demands grow.

Here, Irfan Ahmed, regional business solutions director at global payments solution provider BPC, explores why the next challenge may lie less in regulation itself and more in the capacity institutions have to build, support and scale API connectivity.

Open banking is becoming bigger, broader and more operationally demanding. That change is playing out in different forms across markets.

In the UK, open banking now supports more than 17 million active user connections, with £8.3 billion in cumulative value already delivered across payments, savings, lending and accounting.

In Australia, the Consumer Data Right now covers almost every consumer account, and attention has shifted to whether institutions have the tools to make use of it. In the UAE, open finance is being built around mandatory participation, service initiation and shared infrastructure rather than narrow data access alone.

Much of the discussion so far has centred on regulation, standards and rollout timetables. The harder part starts inside the institution once those frameworks have to be turned into working services.

Some banks can support the ongoing task of building, maintaining and monitoring API integrations. Others struggle to keep pace once the workload becomes continuous. That gap usually shows up in the day‑to‑day work of onboarding partners, supporting new versions and meeting regulatory updates.

Where the real pressure sits

The strain becomes clearer once API delivery stops being a project and starts becoming part of normal operations. It turns into a steady flow of updates, onboarding, monitoring and support running alongside core system change, digital channels and regulatory deadlines. It touches multiple product teams and quickly becomes part of everyday operations.

Even institutions with established digital teams feel it once they move beyond a small number of connections. For mid‑tier banks and fast‑growing players, it tends to surface earlier.

Most teams are not short of ideas or intent. What they lack is the time and capacity to turn those ideas into live, reliable services while keeping everything else running. That constraint plays a big part in determining how widely institutions can participate.

Why capacity shapes participation

The banks with the capacity to support ongoing API work tend to move faster. They can take on new connections, respond to regulatory updates and bring new services to market without forcing trade‑offs elsewhere. For everyone else, progress depends on what can be fitted around core system work, digital channels and mandatory change.

That difference shows up in delivery timelines. Some institutions can move from idea to live service in months; others take far longer, not because the ideas are weaker but because the teams behind them are already stretched. The gap between what banks want to offer and what they can realistically deliver starts to widen.

Capacity affects more than timing. It changes what gets built in the first place. Banks with more room can try a broader range of use cases and respond faster when customer or partner demand shifts. Banks under tighter delivery pressure tend to cut the list much earlier. The safer projects move first. The more speculative ones wait.

That is how participation starts to narrow. Institutions with more delivery capacity move first, and the gap widens as the workload grows.

How participation broadens

If open banking is going to reach more institutions, the delivery work needs to be easier to take on. Low‑code and no‑code tools help by turning API delivery into something product teams can configure and manage without relying on large engineering groups. They reduce the amount of bespoke build work and make it possible to support more connections with the same resources.

API banking-as-a-service takes that a step further. Instead of every bank maintaining its own integrations, versioning and monitoring, much of that operational work sits in a managed layer. Institutions can focus on the services they want to offer rather than the mechanics of keeping each connection running.

Most teams can manage the first few use cases. The pressure builds once the work becomes continuous: new partners to onboard, new versions to support, new requirements to meet. At that point, progress depends less on appetite and more on how much capacity can be freed from other programmes.

Australia’s own ecosystem reporting points in the same direction: once coverage is in place, the harder task becomes turning that framework into something simpler to use and easier to build on.

Participation widens when the delivery work becomes manageable for more than the largest players. Regulation can set direction, but easier deployment and lower operational overhead are what allow more institutions to take part.

In our work with banks and fintechs, the institutions that make faster progress are usually the ones that reduce the amount of bespoke integration work from the start. They give teams a workable way to test early, avoid turning every new connection into a separate engineering project, and make ongoing API support easier to manage across the business.

BPC delivery models

That is also the logic behind the delivery models BPC has invested in through SmartVista. The platform has been shaped by a long-standing focus on technological excellence, but also by a practical understanding that large upfront investments in hardware, databases and proprietary platforms can limit participation.

For many institutions, especially smaller and mid-tier players, the challenge is not only whether they want to take part in open banking, but whether they can do so without adding another layer of costly infrastructure and operational complexity.

And to address that, BPC has steadily moved SmartVista towards a cloud-friendly, modular architecture built around microservices and containerisation and with wide set of APIs. With cluster-based deployment through Kubernetes and OpenShift, institutions gain a delivery model that makes systems easier to deploy, update and scale, while also improving fault tolerance, resilience and disaster recovery.

The same thinking shapes BPC’s open API layer. SmartVista has been strengthened through a unified Open API framework, aligned with internal technical requirements and industry standards. Combined with sandbox environments, low-code/no-code integration tools and supporting SDKs, that gives banks, fintechs and third-party providers a faster path to integration and a more manageable way to support API connectivity over time.

It also supports an API banking-as-a-service model for business teams, backed by an integration engine with API management, configurable workflows, third-party onboarding and integration with strong customer authentication solutions. The platform provides the infrastructure needed for PSD2 and UK open banking, while enabling secure extension into fintech, e-commerce, e-government and other domains.

The result is a lighter delivery model, with faster testing, fewer operational bottlenecks and more room to add services and connections without forcing the same level of engineering effort for every new use case.

What open finance needs next

If open banking and open finance are going to spread beyond the institutions with the deepest technology benches, the delivery model has to widen too. Regulation can open the door, but participation depends on whether institutions can step through it without building every layer from scratch.

That is what will decide whether open finance becomes a genuinely broad market or remains concentrated among the banks and fintechs with the biggest engineering teams. The next phase depends on making participation easier to deliver, easier to support and easier to scale.

Low‑code tools, no‑code workflows and managed service models are part of what makes that broader participation possible.