Digital on the outside, and legacy on the inside: what’s the risk? Very simply, it’s that you’ll be found out.
Being digital on the outside has typically meant having very snazzy front ends, having what you would call a moderately good user experience, and having a very user-friendly interface. Sadly, that’s no longer enough.
What customers are really looking for today is immediacy. They want immediate gratification and immediate accuracy of information. It’s something we take for granted in every major app we use daily, whether it’s a ride-sharing app or a delivery app or our banking app.
A ride-sharing app tells you in real time where your cab is, and that makes you feel better than an app that just says, “Ride will be here in eight minutes,” without you knowing if it’s true. When a delivery app processes your refund and tells you, “This refund has been processed,” you stop checking your balance because you trust it will arrive.
It’s a matter of trust. And these capabilities require an extremely deep knowledge of computer science and engineering. Beyond a certain point it becomes very hard to fake that. If you’re only digital on the surface, you’ll hit that wall quickly and once that trust is lost, it’s almost impossible to win it back.
What defines a modern core system
If I were a CTO, I would ask for proof on three different points.
First: can you process transactions at the same throughput as your old legacy mainframe? Those mainframes were very good at what they did. There’s a reason they still run 90–95% of reliable, high-throughput code. Can you process 15,000 or 20,000 transactions per second without affecting latency or customer experience, without going down, still keeping four- or five-nines availability?
Second: with that kind of performance, how much of the heavy lifting still has to be done? In the legacy world, banks spent huge amounts keeping infrastructure up to scratch and maintaining cybersecurity. Modern cloud providers should take care of much of that under the hood. How much of that pain goes away?
Third: if you’re really a cloud-native core banking system, you’ve built your architecture using microservices. Each microservice does one thing, but it does that one thing extremely well. That’s the principle of single responsibility. One service might open an account, another might close an account, another might process a transaction. The third test a CTO should do is take a simple product and see how easy it is to construct it from existing, documented APIs.
From brain transplants to tonsillectomies
Transformation used to feel like a heart transplant and a brain transplant with two knee transplants thrown in for good measure.
For many years, large studies by top consulting firms showed that many transformations failed either outright or by slowly dying after failing to achieve their objectives. A large part of that was because they tried to map old products from the old platform onto the new without changing the old way of working. If you had 40 deposit products, the right thing to do would have been to pare them down to the top four before mapping them. Or not to try to take a modern platform and make it adapt to an old, document-based process.
Migrations used to be laborious. You had to map every field from the old system to the new, write scripts to ensure millions of accounts moved correctly, and then run both systems side by side for months.
Modern platforms are changing this. They make it easier to orchestrate what needs to be built. They make product creation simpler. You can use large language models to automate mapping in minutes instead of weeks.
Banks can now run two systems side by side: one expensive legacy core, and one new system where you pay only for what you use. That lets you control cost, run experiments, and scale when ready.
Because of this, the risk has gone down dramatically. We’re already seeing “migration factories,” where modern platforms—Pismo included—migrate two or three million accounts every week.
It’s simply not the old world anymore. What used to be a brain transplant is fast becoming a tonsillectomy.
Gaining control in the cloud
I would take a very data-driven look at the question of control.
A large cloud provider can spend millions on resilience, cybersecurity, and geopolitically secure data-center placement. Their sites are heavily guarded, often anonymous so you wouldn’t know where they are.
So yes, banks may worry about losing control, but let’s use a real-world analogy. Think of a hospital. Hospitals rely on machines that are literally life-critical: ECG monitors, automated drug dispensers etc. If one goes down, a patient could die. Yet hospitals don’t generate their own power; they trust the power grid and just keep small backup generators.
Banks can think the same way: Rely on the public cloud for scale, security, and uptime, and maintain backups or multi-cloud strategies for contingency.
As data volumes grow, running everything yourself becomes impossible. Your space, energy, and infrastructure costs would climb until they’re unsustainable. Cloud providers already operate at a scale no single bank can match.
Regulators are recognising this too. They’re pushing financial institutions to think about cloud use in a risk-based, multi-provider way by balancing control and resilience.
How Pismo fits into the future
We’ve worked with Tier 1 banks from day one. They pushed us to the highest standards of scale, security, and resilience and that pressure shaped our platform. We were among the first to invest seriously in high-speed, high-throughput migrations taking a million accounts from one system to another in hours, not days.
We were also among the first to build multi-region resilience. If a region goes down, we can recover in another that’s hundreds or thousands of miles away, with minimal delay. We’re working toward multi-region active-active capabilities designed to minimise delay.
We’re enabling clients to integrate their own CI/CD pipelines with ours, allowing them to test and innovate more freely while still benefiting from a single-code-base SaaS model.
And for global institutions running operations across multiple continents, we now manage seven or eight regions, each serving as a backup for another. That’s an entirely new level of resilience.
Because of how big our customers are, and because they constantly push us to our limits, we’re becoming better every day. They help us push the boundaries, and we help them do the same.
One piece of advice for every bank
A building is only as strong as its foundation.
If you take a building with a weak foundation and try to build a 50-storey, modern, green structure on it, sooner or later that building will collapse. If not immediately, then certainly a few years later.
Whether we like it or not, that foundation today is your core technology. It’s the basis on which your bank exists. It’s the foundation of your balance sheet, your customer experience, and your future competitiveness.
It would be to any financial institution’s detriment to ignore that foundation while pursuing new digital initiatives. You can’t keep expanding a building without first ensuring the base can bear the load.
If I were the CEO of a bank this would be one of my top five priorities, right alongside interest-rate management, market movement, fee income, and customer growth.
You have to take a critical look. Just as you wouldn’t want your treasury to give you an overly rosy picture of market volatility, you shouldn’t want your senior technology leaders to give you a rosy picture of what your platform can handle.
That’s the single most important piece of advice I can give.
You can’t fake real-time performance. You can’t fake trust. And you can’t build the future on a foundation that was never designed for it.
Because the future of banking starts, quite literally, at the core.
