Banks Don't Have a Technology Problem. They Have a Thirty-Year Coupling Problem.

The usual story about banking technology is that the systems are old. That is true and it is not the interesting part, because plenty of old systems run beautifully. Age is not the defect.

The defect is coupling.

For thirty years, each new channel a bank added — the branch terminal, the call centre application, the ATM network, the website, then the mobile app — was built directly against the core banking system, in whatever way was most expedient at the time. Each integration had its own assumptions about data formats, its own direct database reads, its own special-cased behaviour.

The result is not a bank with an old core. It is a bank where the core has forty different consumers, each of which knows too much about it, and none of which can be changed independently.

That is why a change that should take a week takes eight months. Not because the technology is old. Because nothing can move without everything moving.

What API-Driven Actually Means Here

An API layer between the core and everything else is not a technology upgrade. It is a contract, and the contract is the point.

Once channels talk to a defined interface rather than to the core directly, several things become possible that were not before. You can replace the mobile app without touching the core. You can modernise a core component without renegotiating with forty consumers. You can launch a new channel in weeks, because the integration work has already been done once. And you can expose a capability to a partner without giving them access to your database.

That last one has become non-optional. Open banking regulation in the UK and EU, and equivalent moves elsewhere, made third-party access a legal requirement rather than a strategic choice. Banks that had already decoupled complied by exposing an existing interface. Banks that had not spent enormous sums building one under a deadline.

The strategic version of the same point: the interface is the product boundary. A bank whose capabilities are only reachable through its own applications competes on those applications. A bank whose capabilities are reachable through a defined interface can be embedded in someone else's product, which is a fundamentally different business.

The Design Decisions That Age Badly

Three choices tend to determine whether an API layer helps for a decade or becomes the new legacy in three years.

Versioning, decided up front. Financial APIs have consumers you cannot force to upgrade — partners, corporate clients with their own release cycles, internal systems nobody owns any more. If you have not decided how versions coexist before the first external consumer integrates, you will either break people or freeze the interface permanently. Both are expensive, and the second is the more common failure.

Modelling the domain rather than the database. The strong temptation is to expose what the core already has, because it is fast. That reproduces the coupling problem one layer up: consumers now depend on the shape of your internal storage through a thin wrapper. The interface should describe accounts, payments, and customers as the business understands them, so the storage underneath can be replaced without every consumer noticing.

Idempotency, everywhere it matters. In finance this is not a nicety. Network calls fail ambiguously — the client does not know whether the transfer went through. Without idempotency keys, the retry is a second transfer. This has to be designed into the interface from the beginning, because retrofitting it means renegotiating with every consumer.

Security Is Not a Layer You Add

The security model for an API-driven bank differs from the perimeter model that preceded it in a way that is easy to underestimate.

The old model assumed a boundary: inside the network was trusted, outside was not. That assumption is void the moment third parties hold credentials to your interfaces, and it is void whether or not anyone updated the architecture documents.

What replaces it is per-request authorisation with scoped, delegated access. The standards are well established — OAuth 2.0 and OpenID Connect underpin most open banking implementations — but the standards are the easy part. The hard parts are the ones specific to your institution: what a consent actually grants, how it expires, how a customer revokes it and what happens to in-flight operations, and how you detect a partner's credentials being used in a pattern that does not match their business.

And the auditing requirement is stricter than most teams initially plan for. In a regulated environment you need to reconstruct, per request, who acted, on whose authority, under what consent, at what time. That is a design constraint on the interface itself, not something a logging library provides.

Why This Is Genuinely Hard

It is worth being fair about why banks did not simply do this earlier.

A bank cannot stop. There is no maintenance window in which to re-platform, and the failure mode of getting it wrong is not a bad quarter but a regulatory event. Every migration has to run alongside the existing system, prove equivalence against it, and shift traffic gradually — which is more expensive and slower than a rewrite, and is also the only responsible approach.

The regulatory surface is enormous, and it varies by jurisdiction, which means an interface serving multiple markets encodes several sets of rules simultaneously.

And the institutional knowledge problem is acute. The behaviour of a core banking system after thirty years of amendments is documented mainly in the memories of people approaching retirement, and a decoupling project depends entirely on knowing what the current behaviour actually is — including the parts that are technically wrong and that downstream systems now depend on.

None of that makes the work optional. It makes the sequencing matter: define the contract, put it in front of the core as it exists, migrate consumers onto it one at a time, and only then start changing what sits behind it.

The banks that did this before they were required to spent less and got a business capability. The ones that waited got a compliance project.

API Driven Banking: Designing Flexible Financial Platforms covers the architecture end to end — API design for financial services, versioning and lifecycle, OAuth 2.0 and OpenID Connect, threat modelling, compliance, and building flexible front-ends on top.