Many UK banks already have an API programme. They have gateways, REST endpoints, microservices and integration platforms. Yet a familiar problem remains: adding the next channel, fintech partner or product still takes too long and still requires too much custom engineering.
That should raise an uncomfortable architecture question. If the bank has invested in APIs, why does every new integration still behave like a project?
The answer is often that the interface has changed while the integration model has not. An API gateway can expose legacy capability more cleanly. It cannot, by itself, eliminate the bespoke logic underneath it. When every new consumer still requires a custom route into core data and processes, the bank has modernized access without removing coupling.
An API Gateway Manages Traffic. It Does Not Eliminate Integration Debt
The common pattern is easy to recognize. A gateway is placed in front of the core. REST endpoints are exposed for digital channels. Integration between those endpoints and the core is then implemented case by case as new requirements arrive.
The architecture looks cleaner from the outside, but the delivery model remains fundamentally point-to-point. Each connection carries its own transformation logic, dependencies and maintenance burden. The gateway has introduced a layer of indirection, not a reusable domain model.
This is why API modernization can disappoint when success is measured by the number of APIs published rather than by the amount of bespoke integration removed.
Channel APIs Can Recreate the Same Problem in a New Form
A digital channel API can solve an immediate delivery requirement. The problem appears when that API is designed for one consumer rather than around a reusable banking capability.
The mobile channel gets one interface. The next partner needs similar functionality but with different data. Another integration is built. A third consumer arrives and another variant follows. The bank now has modern APIs, but each new demand still creates new connection logic.
The same risk applies when legacy functionality is simply exposed through REST adapters. HTTP access does not change the underlying data model, transaction model or service coupling. Downstream teams may no longer call COBOL directly, but they can remain tightly exposed to the complexity of the core.
Microservices Do Not Automatically Create Decomposition
Microservices are equally vulnerable to architectural theatre. Building new services for new features can create a hybrid estate in which the microservices still depend on the monolith for any data or process that remains inside the legacy system.
The result is not independent architecture. It is a collection of new islands connected back to the same central dependency.
Integration platforms can suffer from the same problem. Tools such as MuleSoft, Azure Integration Services or IBM App Connect can manage connections effectively, but the platform does not remove custom connection logic unless the bank also introduces a coherent domain-driven API design strategy. Otherwise, the integration platform itself becomes another layer to maintain.
Design APIs Around Banking Domains, Not Consumers
The alternative described in Maveric’s technical briefing is domain-driven decomposition. Instead of designing interfaces around individual channels, the bank identifies bounded banking capabilities that can become reusable services with their own data models, APIs and deployment pipelines.
Customer identity and profile is a clear example. It is consumed across mobile, web, branch, partner and regulatory environments. Extracting customer profile, consent state and identity verification logic into a dedicated service changes the integration question for every future consumer. The requirement becomes “call the identity API,” not “integrate with the core.”
The same logic applies to payment initiation and status, product and account origination, notifications and communications, and regulatory reporting and compliance data. These are high-consumption or high-change domains with boundaries that can be separated from core transaction processing.
The Test of an API Strategy Is Reuse
For architecture leaders, the most useful measure of API maturity is not API count. It is whether the next business requirement can reuse an existing governed capability without recreating integration logic.
That requires stable contracts, versioning, security policy enforcement, consent management, observability and deliberate governance. It also requires domain knowledge. A payment API in UK banking cannot be designed in isolation from Faster Payments, SEPA, CHAPS, Open Banking, PSD2 consent or the bank’s own core data model.
This is why the technical pattern alone is insufficient. The delivery economics change when the domain knowledge and reusable banking libraries do not need to be rebuilt from scratch for every programme.
APIs Should Reduce the Cost of the Next Connection
A bank can have a sophisticated API gateway and still carry the same integration debt it had before. The decisive question is whether the architecture has converted bespoke connections into reusable domain services.
If every new channel still requires custom work against the core, API layering has not resolved the root problem. If a new consumer can connect to a stable, governed domain API and remain insulated from the legacy transaction model, the architecture has begun to change the economics of delivery.
That is the difference between exposing a monolith and progressively decomposing it.
Go Deeper: The Hidden Cost of Monolithic Banking
Maveric’s technical briefing explains why API gateways, channel APIs, REST adapters, microservices and middleware platforms can leave integration debt intact when they are not paired with domain-driven decomposition.
It then shows how the Strangler-Fig pattern can be applied in a live banking environment, including the five bounded contexts that can provide the strongest starting points for Tier 2 and regional banks.
Download The Hidden Cost of Monolithic Banking
FAQ
1. Why does an API gateway not solve banking integration debt by itself?
A gateway manages and exposes traffic, but bespoke point-to-point logic can remain underneath it. Without domain-driven API design, every new connection can still require custom integration.
2. What is a domain API in banking?
A domain API exposes a reusable banking capability, such as customer identity or payment initiation, rather than being designed around one channel or consumer.
3. Do microservices automatically modernize a banking monolith?
No. New microservices can remain dependent on the monolith for data and processes, creating islands rather than independently deployable bounded contexts.
