Cloud Banking in 2026: The Complete Guide
A 2026 deep dive into cloud banking: SaaS core banking, public vs private vs hybrid cloud, DORA, FFIEC, migration patterns, and the vendors running real banks in the cloud.
What is cloud banking?
Cloud banking is the model where a bank or licensed financial institution runs its core banking system, ledger, payments engine, analytics and customer channels on public, private or hybrid cloud infrastructure rather than on self-hosted servers in its own data centre. In 2026 this is no longer an edge case. It is the default for every new license in Europe, North America and APAC, and it is the endpoint of almost every modernisation program at incumbent banks.
The shift is driven by three forces at once: hyperscalers building dedicated banking offerings (AWS Financial Services, Microsoft Cloud for Financial Services, Google Cloud for Financial Services), a new generation of cloud-native core banking vendors (Mambu, Thought Machine, Finxact, Tuum, 10x, Pismo), and regulators who finally moved from "cloud is risky" to "cloud is fine if you manage the risk". The Digital Operational Resilience Act (DORA) took full effect in the EU on 17 January 2025 and codifies exactly how banks must govern their cloud providers.
SaaS core banking
Ledger, accounts, loans and payments delivered as a managed service, upgraded by the vendor, consumed via APIs.
Cloud-native architecture
Microservices, containers, event streaming, infrastructure as code. Horizontal scale instead of overnight batch.
Supervised resilience
DORA in the EU, FFIEC guidance in the US, BAIT and VAIT in Germany. Cloud is regulated as a critical dependency.
The end state is the same everywhere: a bank that can ship a new product in a sprint, open new markets without a data-centre build, survive a regional outage without customer impact, and prove all of that to its regulator with a paper trail that generates itself.
Let's discuss your project and see how we can launch your digital banking product together
Request demoPublic, private and hybrid cloud, single vs multi-tenant
Not all "cloud" means the same thing. A CIO choosing a model is really choosing two axes: where the infrastructure lives, and how the software is partitioned across customers. Both decisions have direct regulatory consequences.
| Model | What it is | Typical use | Trade-off |
|---|---|---|---|
| Public cloud | Shared hyperscaler infrastructure (AWS, Azure, Google Cloud, Oracle, IBM) consumed on demand. | Greenfield neobanks, fintechs, most new core banking deployments. | Best economics and scale. Concentration risk and exit strategy must be documented under DORA. |
| Private cloud | Dedicated infrastructure, on the bank's premises or in a colocation, operated like a cloud. | Tier-1 incumbents with data residency or legacy constraints. | Full control, higher unit cost, slower time to new capability. |
| Hybrid cloud | A mix: sensitive workloads on private, elastic workloads on public, with a common control plane. | Mid-size and Tier-1 banks during multi-year migration programs. | Operationally realistic, architecturally heavier. Good compromise for a 3-5 year journey. |
| Multi-tenant SaaS | Many banks share the same logical platform, isolated at data and policy level. | Mambu, Tuum, Pismo and similar cloud-native cores. | Fastest rollout, lowest cost, less per-bank customisation. |
| Single-tenant | One dedicated instance per bank, usually on the bank's own cloud account. | Thought Machine Vault, 10x, large transformations. | More control, more regulatory comfort, higher price tag. |
A practical rule in 2026: greenfield builds go public-cloud, multi-tenant. Large incumbents go hybrid with single-tenant cores. Everything in between is negotiated case by case with the regulator, not with the vendor.
Why cloud, and why now
The business case used to be about cost. In 2026 cost is the least interesting part of the conversation. The five drivers below, in order, are what actually move a board to approve a cloud migration.
Speed
Launch a product in weeks, not release windows. Environments spin up in minutes.
Scalability
Absorb payday peaks, Black Friday and flash growth without over-provisioning.
Resilience
Multi-AZ, multi-region, automated failover. DORA-grade recovery objectives by default.
Innovation
Direct access to AI, data and analytics services. No separate procurement for each.
Cost
Opex instead of capex. Unit economics that flex with the business, not with the rack.
On the regulator side, the mood changed somewhere between 2022 and 2025. The ECB, the Bank of England and the OCC now run supervisory expectations that explicitly assume cloud adoption. Not using cloud is no longer the safe option; it is one that increasingly needs its own justification in an audit.
The cloud banking vendor landscape
The stack splits cleanly into two layers: hyperscalers that provide the infrastructure and industry services, and core banking vendors that provide the product of record. A real deployment usually mixes one of each.
Cloud infrastructure for banks
- AWS Financial Services - largest footprint in global banking, deep partner network.
- Microsoft Cloud for Financial Services - strong in Europe and at incumbents running Dynamics and M365.
- Google Cloud for Financial Services - data, AI and analytics-led deals, Vertex AI for fraud.
- Oracle Financial Services - Flexcube and OFSAA on Oracle Cloud Infrastructure.
- IBM Cloud for Financial Services - policy framework built with Bank of America, strong in hybrid.
Cloud-native core banking
- Mambu - multi-tenant SaaS, retail, SME, lending, used by N26 and ABN AMRO (New10).
- Thought Machine Vault - single-tenant, powers Lloyds, Standard Chartered Mox, Intesa Isybank.
- Finxact - US-focused, acquired by Fiserv, deposit-led core.
- Tuum - European next-gen core, composable, strong in Nordics and DACH.
- 10x Banking - metacore platform behind Chase UK and Westpac in AU.
- Pismo - cards and core in LATAM and APAC, acquired by Visa in 2024.
The choice between vendors is rarely about features on a spreadsheet. It is about the three questions regulators will ask: who is accountable, how do we exit, and what happens during a cloud outage. A good vendor walks into the first meeting with the answers already written.
Regulation: DORA, FFIEC and the 2026 compliance map
Two frameworks dominate the conversation in 2026. In the EU, DORA (Regulation EU 2022/2554) has been in force since 17 January 2025 and covers ICT risk, incident reporting, resilience testing and oversight of critical third-party providers including hyperscalers. In the US, FFIEC guidance on cloud computing (last updated 2020) is reinforced by the OCC Third-Party Risk Management Guidance (2023) and the Interagency Guidance on outsourcing.
- Register every cloud contract. Under DORA article 28, regulated entities maintain a register of information on all ICT third-party arrangements and submit it annually to the national competent authority.
- Document an exit strategy. Before signing with any cloud provider supporting a critical or important function, the bank must prove it can migrate out within a defined timeframe. "We trust AWS" is not an exit plan.
- Test operational resilience. Threat-led penetration testing (TLPT) on critical functions is mandatory under DORA for significant institutions. FFIEC and OCC expect equivalent scenario testing in the US.
- Manage concentration risk. DORA explicitly recognises that too much banking on one hyperscaler is a systemic issue. Diversification, multi-region and portable architectures are now a board-level topic.
- Protect data sovereignty. GDPR, the EU Data Act and national rules in Germany, France and Spain constrain cross-border transfer. Cloud region choice is a regulatory decision as much as an engineering one.
Add the horizontals: SOC 2, ISO 27001, PCI DSS 4.0, NIS2, the EU AI Act for model risk, and sector-specific guidance from the EBA on outsourcing. None of this is optional. The good news is that mature cloud-native vendors pre-package the controls, and hyperscalers publish the shared-responsibility matrix line by line.
Benefits for incumbents vs new entrants
The business case looks different depending on where you start. A Tier-1 bank migrating from a mainframe has nothing in common with a fintech launching on day one. Both win, but not in the same way.
Incumbents (migration)
- Retire expensive COBOL and mainframe estates
- Cut data-centre footprint and fixed infrastructure capex
- Accelerate product delivery from quarters to sprints
- Enable real-time analytics and AI on customer data
- Meet DORA and BAIT resilience objectives by design
New entrants (greenfield)
- No legacy, no technical debt, no data-centre build
- Go live with a SaaS core in 6 to 12 months
- Enter new countries without new infrastructure
- Low fixed cost, opex scales with revenue
- Hiring pool of cloud-native engineers, not mainframe retirees
The common thread: both camps stop competing on infrastructure and start competing on product. Once the cloud layer is solved, the differentiator is what you build on top of it.
Security, uptime and compliance posture
The old objection was "cloud is less secure than my data centre". The data no longer supports that. Hyperscalers invest more in security annually than any single bank, and the certifications show it. What a 2026 cloud banking stack looks like on paper:
Shared responsibility is the only concept that matters. The hyperscaler secures the cloud; the bank secures what it puts in the cloud. Identity, network segmentation, secrets management, key ownership (BYOK or HYOK), logging into a SIEM, and well-rehearsed incident response are the bank's job. Get those right and you pass audit; get them wrong and no certificate on the vendor's wall will help.
Migration paths: strangler, parallel run, big-bang
There are three honest migration strategies. None of them is painless, and the right answer depends on your starting point, your appetite for risk, and your regulator.
| Pattern | How it works | Time | Risk profile |
|---|---|---|---|
| Strangler | Wrap the legacy core with APIs, route new capabilities to a cloud-native platform, retire the legacy piece by piece. | 2-4 years | Lowest risk. Preferred by Tier-1 incumbents. Continuous value delivery. |
| Parallel run | Run legacy and cloud core in parallel, migrate customer segments in waves with full reconciliation. | 12-24 months | Medium risk. Best for banks with distinct portfolios or geographies. |
| Big-bang | Cut over the whole book on a single weekend after long rehearsals. | 9-18 months | Highest risk, fastest payoff. Viable mainly for small or mid-size banks with simple product sets. |
Whichever you choose, two things are non-negotiable: a reversible rollout plan and a reconciliation strategy that proves, cent by cent, that no customer balance moved in the wrong direction. Regulators will ask to see both.
Launch cloud banking with Crassula
Crassula is a cloud-native banking platform that runs on the hyperscaler of your choice and behaves like a SaaS product when you want it to. The core, the ledger, IBAN provisioning, card issuing, KYC orchestration, payments routing and the admin back office are already built. You pick the deployment model (multi-tenant SaaS, single-tenant on your cloud account, or hybrid), we handle the rest.
Launch in weeks
A branded cloud banking product live in 6 to 12 weeks, on AWS, Azure or Google Cloud.
DORA-ready
Exit strategy, incident reporting, ICT register and resilience testing built into the platform.
Modular
Swap any module, bring your own core, plug into partner BaaS rails. No vendor lock-in by design.
If you are planning a migration, a new digital bank or a vertical fintech, Crassula gives you a cloud banking stack that is already compliant, already resilient, and already integrated with the payment networks you need.
FAQ
Cloud banking is when a bank runs its core systems, ledger, payments and customer channels on public, private or hybrid cloud infrastructure instead of in its own data centre. Usually that means using a SaaS core banking vendor on top of a hyperscaler like AWS, Azure or Google Cloud.
Yes. In the EU, DORA has been in force since 17 January 2025 and regulates exactly how banks must use cloud. In the US, FFIEC cloud guidance and OCC third-party risk rules do the same. Cloud is supervised as a critical dependency, but it is explicitly permitted and widely expected.
Public cloud uses a shared hyperscaler like AWS or Azure. Private cloud is dedicated infrastructure operated cloud-style, usually for data residency or legacy reasons. Hybrid mixes both, with a common control plane. Most new banks go public and multi-tenant; most large incumbents run hybrid during migration.
Mambu, Thought Machine Vault, Finxact, Tuum, 10x Banking and Pismo lead the cloud-native category. They run on hyperscalers and power banks like Lloyds, Standard Chartered Mox, Chase UK, N26 and Intesa Isybank. See our core banking systems guide for a full comparison.
DORA requires a register of every ICT third-party contract, a documented exit strategy for critical providers, threat-led penetration testing, incident reporting inside 24 hours for major incidents, and explicit management of concentration risk when a bank depends on a single hyperscaler.
A greenfield launch on a SaaS core can go live in 6 to 12 months. A full migration of an incumbent bank typically runs 2 to 4 years using the strangler pattern. Parallel runs land at 12 to 24 months, and a big-bang cutover is rare outside mid-size banks with simple product sets.
Hyperscalers hold SOC 2, ISO 27001 and PCI DSS 4.0 certifications and invest more in security than any single bank. The model is shared responsibility: the provider secures the cloud, the bank secures identity, data, keys and configuration. With that done right, cloud banking meets or exceeds on-premise security.
Crassula provides a cloud-native banking platform with ledger, IBAN, card issuing, KYC, payments and admin back office already built. It runs on AWS, Azure or Google Cloud, deploys as multi-tenant SaaS or single-tenant, and ships with DORA-ready controls. You launch a branded banking product in weeks without rebuilding the plumbing.
