API management beyond Open Banking: what production scale actually looks like

API management beyond Open Banking: what production scale actually looks like

Most financial services API programmes start with Open Banking compliance and stop thinking much further than that. The regulatory deadline gets met, a gateway gets stood up, the required APIs get published, and the programme is declared a success. What tends not to get addressed is what happens next: how the platform scales, how new APIs get onboarded without the gateway becoming a bottleneck, how deprecation is managed when downstream consumers are slow to migrate, and who owns the developer experience when the initial build team has moved on.

We ran a national API management platform for five years, processing over 1.6 billion transactions and supporting a developer community spanning hundreds of organisations. The problems we solved in years two, three and four were not the ones we anticipated at the start. This is what we learned.

The gateway is the easy part

Selecting and deploying an API gateway is a well-understood engineering problem. There are good products available, the implementation patterns are documented, and most organisations can stand up a functioning gateway within a reasonable timeframe. The difficulty is not the gateway. It is everything that sits around it.

At the point when you have fifteen active API producer teams, each on different delivery cycles, each with different standards of documentation and testing, and each with their own view of what a breaking change looks like, the gateway configuration becomes a governance problem rather than a technical one. The organisations that manage this well have invested in the processes and tooling that sit around the gateway, not just the gateway itself.

The difficulty is not the gateway. It is everything that sits around it.

‍

Developer experience is a product, not a document

One of the most common failure modes in financial services API programmes is treating the developer portal as a documentation exercise. A portal gets built, API reference documentation gets published, and the team moves on. The result is a portal that is technically present but practically unusable: out-of-date documentation, no sandbox environment, no clear onboarding path, and no mechanism for consumer teams to raise issues or track the roadmap.

The developer experience is the product. If consuming your APIs is slow and frustrating, adoption will be slow and frustrated. On the platform we operated, we tracked time-to-first-call as a primary metric: how long does it take a new consumer team to make a successful API call against the sandbox? When that number was high, it was almost never because the API was poorly designed. It was because the onboarding process had friction that nobody had bothered to remove.

Reducing that friction requires the same kind of iterative, user-centred work that goes into any good product. It requires someone who owns the developer experience, has the authority to prioritise improvements, and treats the feedback from consumer teams as a legitimate source of product requirements.

Deprecation is where platforms go wrong

Every API eventually needs to change in ways that are not backwards-compatible. How that change is managed determines whether your platform is trusted or feared by the teams that depend on it.

The standard advice is to version your APIs and give consumers reasonable notice before deprecating old versions. In practice, this is harder than it sounds. Consumer teams have their own delivery priorities. A migration that looks straightforward from the producer side often turns out to involve significant changes on the consumer side. Notice periods that seemed generous turn out not to be. And the producer team, having shipped the new version and moved on, has limited appetite for maintaining the old one indefinitely.

The organisations that handle this well treat deprecation as a managed programme rather than a deadline. That means identifying which consumer teams are affected, understanding their migration constraints, providing migration tooling where the effort is significant, and maintaining visibility of migration progress at a platform level. It means having a deprecation policy that is public, consistently applied, and backed by someone with the authority to enforce it.

Operating at Platinum SLA changes everything

An API gateway that goes down takes every consumer service that depends on it down with it. In financial services, that consequence is immediate and visible. The operational disciplines required to run a platform at this level of criticality are different in kind from what is needed to run a development or test environment.

This means 24/7 on-call capability with clear escalation paths. It means runbooks that are actually up to date. It means disaster recovery procedures that have been tested, not just documented. It means monitoring that surfaces problems before consumers notice them, and incident management processes that communicate clearly to affected teams without waiting for a full post-mortem.

On the platform we operated, we ran Splunk, Grafana, and Prometheus in combination, with alerting configured to distinguish between noise and genuine service degradation. Getting that configuration right took months of iteration. The alert that fires at 2am needs to mean something. A team that is conditioned by false positives stops responding quickly, and response speed is what determines whether an incident becomes an outage.

What financial services API programmes should be thinking about

Open Banking compliance is a floor, not a ceiling. The organisations that will get the most value from their API platforms over the next five years are the ones that are already thinking about the governance, the developer experience, the deprecation management, and the operational disciplines that determine whether a platform is genuinely useful at scale.

The investment required to build those capabilities is not trivial. But the cost of not building them, in slow adoption, in integration failures, in the engineering time consumed by poorly-managed deprecations, is considerably higher. We have seen both sides of that equation. The organisations that treat API management as a platform capability rather than a compliance exercise are the ones that end up ahead.

Aire Logic designed and operated a national API management platform processing over 1.6 billion transactions across hundreds of organisations. If you want to talk about what production-grade API management actually requires, get in touch.