We have collectively lost our minds.
Across boardrooms in Frankfurt, Singapore, and New York, banking executives are signing off on cloud migration budgets in the hundreds of millions. The pitch is compelling: elastic compute, managed services, pay-as-you-go pricing. The promise is that all of this will solve deep, structural problems in how banks build and run technology.
It won’t. Not because the cloud is bad; it isn’t, but because the problems were never about infrastructure in the first place. They’re about architecture, organization, and the way we think about constraints. And until we face that reality, we’ll keep building beautifully scalable systems that amplify our dysfunction rather than fix it.
Here’s the uncomfortable truth your cloud vendor will never volunteer: the bottleneck didn’t disappear. It moved. And if you don’t know where it moved to, you’re now flying blind.
The Myth of Infinite Scalability
The cloud sales pitch goes something like this: Peak trading volumes? Auto-scale. Quarterly reporting surge? Burst capacity. Stress testing? Spin up a thousand nodes. Technically, all of that is true at the infrastructure layer. But treating “we can scale compute” as the same thing as “we can scale our banking platform” is a dangerous leap of logic.
Take real-time gross settlement systems, the plumbing that moves money between banks. When a major institution migrates these to the cloud, they get real wins: faster provisioning, better disaster recovery metrics, cleaner cost tracking. What they often miss is that the thing slowing them down has shifted. It’s no longer a hardware problem. Now it’s an integration problem, a data consistency problem, and increasingly, a people problem, because the teams operating these systems are drowning in complexity they didn’t sign up for.
Eli Goldratt nailed this decades ago in The Goal: “An hour lost at a bottleneck is an hour lost for the entire system.” The danger with cloud-native banking is that the bottlenecks have become invisible. They no longer look like maxed-out servers. They look like API rate limits cascading through service meshes, consistency conflicts in distributed data stores, and authentication latency that compounds every time a request crosses a microservice boundary. You can’t auto-scale your way out of these.
When Computer Science Theory Meets Banking Regulation
There’s a foundational idea in distributed systems called the CAP theorem. In plain terms, it says that any distributed system can only reliably deliver two out of three things at the same time: consistency (everyone sees the same data), availability (the system is always responsive), and partition tolerance (it keeps working when parts of the network fail). You have to pick two. You can’t have all three. This isn’t an engineering limitation; it’s a mathematical reality.
Now apply that to banking. Under Basel III, banks have to hold enough high-quality liquid assets to survive 30 days of financial stress. This is called the Liquidity Coverage Ratio, and regulators are dead serious about it. Miss your number and you’re looking at restrictions on dividends, bonuses, and potentially your license to operate. The systems that calculate this ratio need all three properties that the CAP theorem says you can’t have simultaneously.
Consistency isn’t optional. When a regulator, the OCC, the PRA, whomever, asks for your liquidity position, “the data is still syncing” isn’t an answer. Two nodes returning different numbers for your liquid assets isn’t a technical glitch; it’s a control failure that ends up in enforcement actions.
Availability isn’t optional either. Treasury operations don’t pause because a database went down. Intraday liquidity management, tracking cash flows, managing payment queues, making collateral decisions, runs constantly. If your system goes dark during peak settlement windows, you’re looking at missed payments, failed settlements, and a chain reaction across counterparties.
And partition tolerance isn’t optional because networks break. This is the one engineers sometimes dismiss as theoretical, right up until an availability zone goes dark, a cloud region loses connectivity, or an undersea cable gets damaged. If your liquidity engine spans multiple data centers (and it almost certainly has to for resilience), you will face partitions. When you do, the CAP tradeoff hits whether you planned for it or not.
So what do banks actually do in practice? They make different tradeoffs in different contexts. Regulatory reporting pipelines typically favor consistency, better to delay a report than submit a wrong one. Real-time treasury dashboards favor availability, showing the best-known position while flagging how fresh the data is. Payment execution leans toward consistency for individual transactions but builds availability into the broader orchestration through queuing and retries.
The point isn’t that this is impossible. The point is that these are design decisions that need to be made explicitly, by architects, upfront; not discovered in production when something breaks.
Cloud Migration Is Platform Transformation, Whether You Admit It or Not
Sangeet Paul Choudary’s Platform Scale makes a useful argument: platforms create value by enabling exchanges between producers and consumers, and they capture value by curating those interactions. Applied to banking, this means your cloud strategy should be judged not by how much you saved on compute, but by how well it enables new kinds of collaboration, between business units, between development teams, with fintech partners, with regulators, and with customers.
The banks that will win in the next decade are the ones that treat cloud as the foundation for a platform operating model. That requires brutal honesty about where things actually stand. Most banks have moved workloads to the cloud while preserving the organizational silos, approval chains, and architectural boundaries of the mainframe era. They’ve achieved lift-and-shift. They have not achieved transformation.
The real constraint in these organizations isn’t technical. It’s the architecture review board that meets once a month. It’s the change management process designed for quarterly releases being applied to continuous deployment. It’s the procurement team treating cloud spend as a capital expense when it behaves like an operating expense. The bottleneck moved from the data center to the org chart, and nobody updated the roadmap.
Governance Has to Change Too
Peter Block, writing about stewardship and organizational design, argues that real accountability can’t be imposed from the top down. It has to come from structures that push ownership to the people closest to the work. That insight matters enormously for cloud governance in banking.
The traditional model treats enterprise architecture as a gatekeeping function: teams propose, architects approve or reject. That model made sense when infrastructure changes were expensive, slow, and hard to reverse. In a cloud-native world where a misconfigured identity policy can be deployed in seconds and expose millions of customer records, the gatekeeping model isn’t just slow. It’s dangerous. The constraint has shifted from deployment to detection, from prevention to observability.
The fix isn’t to remove governance. It’s to redesign it as enablement. Establish guardrails through policy-as-code. Build automated compliance checks into deployment pipelines. Shift accountability from centralized approval to distributed ownership with centralized visibility. This isn’t architectural anarchy. It’s putting control where the risk actually lives.
You’re Probably Making Your Technical Debt Worse
Here’s a pattern I see constantly: legacy applications get containerized without refactoring, data gets replicated to the cloud without rethinking data flows, APIs get bolted on top of batch processes. This isn’t modernization. It’s adding a new layer of complexity on top of every existing problem.
The financial metaphor of technical debt is especially apt in banking: debt compounds. A sloppy cloud integration today becomes a bottleneck for every future initiative that touches it. The interest payments show up as longer project timelines, more production incidents, and the gradual slowdown that executives chalk up to “complexity” without understanding where it actually comes from.
Simon Sinek’s idea of the “infinite game” is useful here. In an infinite game, the goal isn’t to win; it’s to keep playing. Banks that treat cloud migration as a finite project with a completion date are optimizing for the wrong thing. The goal isn’t to “finish” cloud migration. It’s to build the architectural patterns and organizational muscle that let you continuously adapt to new regulations, new market conditions, and new technologies, without starting from scratch every time.
Start with the Constraint
I’m not proposing a framework or a methodology. I’m proposing a habit of mind.
Before approving a migration, before signing a cloud contract, before deploying a new managed service, ask three questions: Where is the bottleneck in this system right now? How does this change move, eliminate, or create new bottlenecks? And what will tell us when the constraint has shifted again?
Your cloud vendors won’t encourage this thinking; they make money when you consume more. Your consultants won’t emphasize it; they’re incentivized to propose big transformation programs, not incremental constraint resolution. The responsibility falls to us, the architects, the engineers, the leaders who will live with these systems long after the implementation partners have moved on.
So here’s the question every banking CTO needs to sit with: In your cloud architecture, where is the constraint today, and where will it be tomorrow?
If you can’t answer with precision, maybe it’s time to stop scaling and start understanding.
