Cloud Core Banking Platform: When Banks and MFIs Should Move Beyond Legacy Systems

Legacy systems reach limits

The decision to replace a core with a cloud core banking platform rarely starts with strategy. It starts with a release calendar that keeps slipping and a maintenance bill nobody can justify anymore. Banks allocate between 15% and 20% of total IT budgets to core system maintenance, and among mid-to-large institutions with high transaction volumes, internal studies put that figure above 70%.

So the warning signs are operational before they're architectural. Batch windows that no longer fit inside the night. A product change that takes six months because the ledger logic sits in code nobody has touched since 2004. Fragmented customer data spread across systems that each hold a partial truth. Then there's the integration estate. Mid-market banks carry 50 to 150 active third-party connections, many of them partially or entirely undocumented, which means every new channel adds another brittle link to a chain nobody has mapped. Add the skills problem, because the people who understand COBOL-era account structures are retiring faster than they're being replaced.

Real-time payments expose the limit. Around 62% of US banks planned to offer real-time payments in 2026, up from 49% in 2024, and batch-processing cores can't support FedNow or the Real-Time Payments network (RTP) natively. That's an architectural wall.

Cloud core banking platform models

Cloud is not one operating model, and treating it as one is where business cases go wrong. A cloud core banking platform can mean a subscription you configure through a browser, or it can mean a dedicated instance your own engineers patch on a schedule you set. Which model you pick determines ownership and the depth of customization you're allowed.

Compare that against on-premise deployment, where you own the hardware and every upgrade decision. Control is total. So is the obligation. The real question in any cloud banking deployment is which obligations you want to keep and which you're willing to hand over in exchange for speed.

SaaS core platforms

In a multi-tenant or managed Software-as-a-Service (SaaS) model, the vendor runs the platform and everyone on it receives the same version. Pricing moves to subscription, $2 to $8 per active account per month based on functionality scope, which CFOs find easier to model than MIPS-based mainframe licensing. Upgrades arrive on the vendor's calendar.

That standardization is the trade. You get cloud banking deployment in weeks instead of years, and you stop being responsible for infrastructure entirely. Marginalen Bank in Sweden moved off its legacy core to a cloud core banking platform in just 13 months, with Avenga handling the decommissioning. Bo Andersson, the bank's Chief Information Officer, described the outcome as letting them "modernize our consumer and business deposit offering."

But vendor dependence is real and it's structural. If the platform doesn't support a product construct your market requires, you wait for the roadmap.

Hosted cloud platforms

A dedicated vendor-hosted or institution-managed instance gives you your own environment and far more room to configure. Doocat, for example, is Kubernetes-native and runs on AWS, GCP, Azure as well as on-premise infrastructure, which means the same platform supports several ownership arrangements.

The cost of that control is operational weight. Somebody has to plan upgrades and manage the capacity envelope. Your run costs stay higher than a shared-tenancy subscription because you're not sharing anything.

This cloud core banking platform model fits institutions with genuine product complexity that standardized platforms can't absorb. BancoEstado's CuentaRUT product has over a hundred different subtypes, each with distinct business and fee rules. That kind of variation needs configuration depth.

Hybrid deployment

Sometimes the constraint is law. India's Reserve Bank required through its April 2018 circular that all payment system data be stored only in systems located in India, with a six-month compliance deadline. Residency rules like that decide where workloads sit before architecture does.

Hybrid also answers latency and integration realities. Field officers in rural areas work with intermittent connectivity, and CGAP's assessment of rural connectivity for microfinance institutions noted that branch integration with head office systems must work both in real time and offline with periodic synchronization. About 64% of financial institutions run hybrid architectures for exactly these reasons. Keeping selected workloads on-premise while modernizing the rest is a deliberate design. It works when identity management is synchronized and data governance defines which workload runs where.

Where cloud adds value

What matters is which institutional constraint the move actually removes, measured in something you can put in front of a board.

Elastic capacity

Hardware provisioning cycles force you to buy for peak and idle through the rest of the year. Cloud removes that arithmetic. Nubank processes 1.2 billion daily API calls on AWS and triples capacity during Black Friday without carrying idle hardware costs the other 364 days.

Geographic expansion changes shape too. Instead of standing up infrastructure per market, you extend an existing footprint into a new region. Resilience improves for the same reason, because redundancy and failover are configuration decisions. The flip side exists. Elastic capacity is also elastic spend, and Harness estimated that 21% of enterprise cloud infrastructure spend in 2025, roughly $44.5 billion, went to underutilized resources.

Faster product releases

Automated environments and deployment pipelines shorten release cycles, but only when the governance around them changes with the tooling. BancoEstado can now launch and iterate on products rapidly compared with the six-month standard it faced on the legacy platform, and its technology transaction costs are a fraction of mainframe equivalents. The bottleneck migrates. If your change approval board still meets monthly and your testing is manual, a pipeline that can deploy daily will simply queue.

What has to change alongside the cloud core banking platform:

• Test automation coverage sufficient to release without a full regression cycle by hand

• Change governance that reviews risk classes

• Environment provisioning that developers trigger themselves instead of requesting through a ticket

API-ready core infrastructure

An API-ready core infrastructure on a cloud core banking platform replaces point-to-point integrations with a documented interface layer that mobile banking and payment rails consume the same way. The Berlin Group's NextGenPSD2 access-to-account interface is now used by 3,600 banks, over 75% of European banks, which tells you standardization won this argument some time ago.

The practical gain is arithmetic. Every new channel added to a point-to-point estate multiplies connections, while every channel added to an API-ready core infrastructure consumes existing ones. Doocat exposes REST APIs and webhooks for cards and payment rails, which is the pattern to look for. Analytics and lending systems benefit most, since both need consistent access to ledger events. That's where an API-ready core infrastructure stops being an integration convenience and starts changing what products you can price.

When cloud is premature

Now the counterargument, and it deserves weight. Core banking transformation programs fail 70% of the time, with average overruns of 189% on timeline and 148% on budget across McKinsey's 2025 analysis of 147 bank modernization efforts. National Bank of Greece's €450M program collapsed in 2023 after attempting to migrate all products simultaneously inside 24 months. Data quality is the reason to wait on a cloud banking deployment. Migration failures stem overwhelmingly from incomplete or poorly governed data, which is why banks now treat data migration as its own workstream with dedicated cleansing and reconciliation.

Hold off if any of these describe your position:

• Connectivity at branches or in the field can't support the availability the new cloud core banking platform assumes

• Ownership of the program sits in IT with no executive sponsor who can arbitrate between business units

• Deep process customization exists because the business genuinely requires it

Karl im Brahm of Objectway, who works on core migrations, puts the governance failure plainly: "Often, clear responsibilities and coordination between business units and IT are lacking the project is not strategically anchored." Phased modernization is the safer path when that anchor is missing.

Security and governance

Outsourcing infrastructure never outsources accountability, and regulators have made that explicit. Under the shared responsibility model, the provider secures the infrastructure while you remain responsible for data and configuration. Gartner has long projected that at least 95% of cloud security failures through 2025 trace back to customer error.

The European Union's Digital Operational Resilience Act (DORA) sharpened the obligations further. Regulation (EU) 2022/2554 applied from 17 January 2025 across 20 categories of financial entity, and Articles 28 through 44 govern how you select and exit ICT third-party relationships. On 18 November 2025 the European Supervisory Authorities designated 19 critical ICT providers for direct oversight, among them the hyperscale cloud platforms.

Exit planning is where most institutions are weakest. DORA Article 30 requires contractual mandatory transition periods during which the provider keeps delivering service while you switch to another provider or move back in-house. The European Banking Authority's outsourcing guidelines go further and expect exit strategies to be tested. Concentration risk deserves board attention as well, since the European Systemic Risk Board has flagged that the top three cloud providers support over 70% of cloud-based financial services infrastructure in the EU. Engage your supervisor early. A regulator who learns about your migration from your notification register is a regulator who will slow you down.

Build the business case

Savings claims are the weakest part of most cloud proposals, because the honest comparison covers more lines than infrastructure and licenses. Implementation investment for cloud-native migration to a cloud core banking platform runs $15 million to $80 million for mid-size institutions, with professional services accounting for 60% to 70% of total project cost.

Count the dual-running period, which is the largest hidden item. BancoEstado ran both platforms in parallel while shifting 14 million customers over several years, and that means paying twice for the duration. Add migration tooling and the cost of exit if the arrangement ends. Then weigh what the numbers can't hold on their own. Cost per transaction matters, but so does the ability to launch a product in weeks. FinOps discipline is not optional here, because 84% of financial institutions without formal FinOps practices see cost overruns exceeding 30% of initial estimates.

Plan migration and rollout

Map the dependency graph and every digital channel before you choose an approach, because the sequence is determined by what depends on what. Only 20% of core banking migrations succeed, and data quality determines the outcome.

Four approaches exist, and each carries a different risk profile. Rehosting moves the workload with minimal change. Phased replacement retires functions one at a time. Parallel operation runs old and new together with reconciliation between them, which is how League Data migrated credit unions in under 48 hours each while integrating more than 20 ecosystem partners. Full cutover is fastest and least forgiving. Whichever you choose, the operational disciplines are the same. Reconcile balances daily against the legacy ledger. Performance-test at projected peak volume. Write a rollback plan with a decision deadline and the authority to invoke it named in advance.

Staff readiness gets underestimated consistently. In the National Bank of Greece post-mortem, 73% of critical issues had been identified by front-line staff and suppressed by middle management who feared blame. Your tellers and field officers see problems first, so build a path for what they report to reach the people who can act.

Assess cloud readiness

Before you commit to a target model, get an honest read on data quality and the connectivity your channels actually have. Doocat builds a cloud core banking platform for banks and microfinance institutions, with migration tooling and playbooks for moving off Flexcube and other legacy cores, and greenfield deployments go live in 12 to 20 weeks. Book a call with the Doocat team to assess your architecture and costs.