Private cloud and on-premises infrastructure are different. I know this. I used the terms interchangeably anyway because I was trying to compress a pattern into one sentence.
That was sloppy, but the underlying pattern still matters.
Banks run Kubernetes differently from most other organizations. Not because every bank makes the same choices, but because similar constraints can produce a similar pattern. Each institution assembles its own collection of reasonable security controls, infrastructure decisions, and historical exceptions. Eventually, that collection becomes a private platform the bank must maintain indefinitely.
- Deployment location is not the real tax. Locally owned divergence is.
- No single security control creates a snowflake, but restrictions compound across the platform.
- Banks and their vendors gain an advantage by treating necessary exceptions as funded product decisions.
The building is not the point
On-premises infrastructure means the bank runs hardware in facilities it controls. A private cloud adds cloud-style APIs, resource pooling, and self-service on infrastructure dedicated to one organization. On-premises is like building your own workout program from scratch. Private cloud often starts from decisions made by platform vendors while preserving data sovereignty and room to customize.
Still, both approaches can create similar long-term problems. The bank owns more of the lifecycle: installation, upgrades, compatibility, capacity, integration, and incident response. The issue gets worse when security policy prevents the platform from following the standard path used by the broader ecosystem.
This does not mean banks have rejected public cloud. LSEG’s 2025 survey of 453 financial-services executives found that 82% operated a hybrid or multi-cloud strategy. It also found that 84% had adjusted their cloud strategy in response to regulations including DORA and GDPR.
The architecture is mixed because the risks are mixed. Data sovereignty, operational resilience, provider concentration, privacy, and existing systems all affect where a workload can run. That is rational. Each choice can also add to the platform’s long-term carrying cost.
Reasonable decisions add up
There is no universal banking version of Kubernetes.
One institution may prohibit mutating admission webhooks. Another may allow them after a lengthy review. One may permit a narrow set of Custom Resource Definitions. Another may standardize on OpenShift. A third may build an internal distribution around its own network, identity, and audit systems.
Any one of those decisions can make sense within a particular threat model. The maintenance problem appears when the decisions combine and create operational and technical drag.
All of these local decisions mean the platform team now has a unique compatibility target. Every upgrade must be tested against its controls. Every vendor must adapt to its APIs and approval process. Every development team inherits the same constraints, even when the original risk does not apply to its workload.
From the platform team’s perspective, limiting automation and flexibility can look like the safest option. It is the shared resource, and it carries the burden of preventing a breach or loss of data sovereignty. The downside is asymmetric: approve the wrong exception and the platform team gets blamed. Reject it and a development team merely moves slower.
Exceptions are taxes. They also charge interest.
flowchart LR
A[Risk requirement] --> B[Local control]
B --> C[Platform exception]
C --> D[Custom integration]
D --> E[Upgrade burden]
E --> F[Platform tax]
Automation dies by inches
Kubernetes was designed to be extended. Operators use Custom Resources and controllers to turn operational knowledge into software. Admission webhooks validate or modify objects as they enter the cluster. A large part of the cloud-native ecosystem assumes those mechanisms are available.
Restricting them is not irrational. The Kubernetes project’s own webhook guidance warns about latency, availability, loops, side effects, and overly broad mutation. A webhook can sit in the path of every API request. Security teams are right to care.
But removing an extension point does not remove the work. Someone still rotates certificates, provisions databases, enforces policy, coordinates upgrades, and handles failure. The work moves into tickets, scripts, internal middleware, or human review.
The platform may look safer in a diagram while depending on people for routine correctness. That is human labor by design.
Take a Kubernetes operator. The operator pattern encodes operational knowledge and reduces repetitive labor. One large customer I work with does not allow operators in its Kubernetes clusters. As a result, an external service must perform the same work by calling the Kubernetes API through an authenticated service account.
That technically works, but the bank now owns another service, authentication path, deployment model, and review process. The operator existed for a reason. Eliminating it did not eliminate the work. It moved the work into a more complex and fragile architecture.
Every platform becomes a product
Buying OpenShift can defer difficult decisions to engineers who spend all day solving Kubernetes lifecycle and security problems. That is valuable. Standardization efforts like OpenShift do not create the snowflake on their own.
The snowflake emerges from everything layered around it: approved versions, disabled capabilities, custom identity integration, private registries, network controls, internal deployment APIs, and exceptions for legacy systems. Eventually, a vendor upgrade is not an upgrade. It is a port. In my experience, that is one reason financial-services rollouts often require substantial professional services work.
Building an internal Kubernetes distribution makes the ownership even clearer. The bank is now funding a platform roadmap alongside AWS, Google, Microsoft, Red Hat, and the open-source community. Those organizations spread the work across thousands of customers. A bank spreads it across itself.
The internal platform may satisfy requirements no external product can meet. But that does not change the economics. Custom middleware that saved time five years ago can become the component blocking the next industry standard.
AI adds another layer
The same cycle is starting with AI infrastructure.
Training, inference, accelerator scheduling, model routing, and AI gateways are still converging. The Kubernetes community introduced the Gateway API Inference Extension to standardize model-aware routing. Its design adds two Custom Resources: InferencePool and InferenceModel.
That creates an immediate conflict for a bank that restricts CRDs. It can reject the emerging standard, create an approved internal equivalent, or change its control model. The familiar response is to roll another custom solution that must be documented, maintained, and approved. The gift keeps giving. Nobody likes the present.
The Bank of England warned in 2025 that financial institutions increasingly rely on outside providers for advanced models, cloud infrastructure, and data. That concentration risk is real. So is the risk of responding by building a private AI stack that cannot absorb improvements from the wider industry.
AI will not eliminate the platform tax. It can compound it.
Constraint fluency is the moat for vendors
FinTech companies often begin with less legacy infrastructure and fewer inherited exceptions. That gives them an adoption advantage. It does not exempt them from regulation, security, or trust.
Banks can narrow the gap by treating every exception as a product decision. What risk does it mitigate? Which workloads need it? Who owns its compatibility burden? When will the bank review it again?
Vendors face the same choice. Supporting financial institutions requires more integration labor, longer timelines, and deeper security work. Pricing that engagement like a normal software sale creates frustration on both sides. Building for it seriously may also turn the financial-services edition into a distinct product.
That specialization can be a moat. A vendor that solves the same hard constraints repeatedly has something a general-purpose competitor lacks. A bank that removes unnecessary divergence can move faster than another bank operating under the same regulations.
The expensive part is not any single security decision. It is waking up ten years later and discovering that thousands of defensible decisions have quietly become a private technology industry. AI training and inference will add another layer before many banks have paid down the last one.