Key Takeaways
- Cloud-native core banking is a live option for banks of different sizes, and the choice of migration pattern matters as much as the choice of vendor (interpretation).
- In our reading, the progressive migration (strangler fig) pattern is the most pragmatic approach for existing banks, balancing risk reduction with architectural modernization (interpretation).
- Vendor selection should prioritize true cloud-native architecture, API-first design, and proven scalability over breadth of legacy functionality.
- Data migration, regulatory compliance and organizational change management are the risk areas we see as easiest to underestimate (interpretation).
- For US banks, third-party risk management for a cloud core follows the June 2023 interagency guidance, which rescinded and replaced OCC Bulletin 2013-29 and SR 13-19; a September 2026 proposal to replace it is not final.
Moving a core banking system to the cloud is among the most consequential technology decisions a bank CIO can make, because the core shapes how quickly the institution can change its products and channels for years afterward (interpretation).
The Case for Cloud-Native Core Banking
Traditional core banking systems, many built on mainframes and monolithic architectures in the 1980s and 1990s, are in our reading a major constraint on digital change in banking (interpretation). Platforms of that generation, some running COBOL on IBM System z mainframes, can be expensive to maintain, difficult to integrate with modern digital channels, and hard to adapt to the real-time, API-driven experiences customers now expect.
The arguments for a cloud-based core come down to four (interpretation):
- Cost Reduction: Mainframe operating costs (MLC licensing, specialized staff, energy) are largely fixed. Cloud platforms offer a variable cost model that can reduce total cost of ownership over a multi-year horizon, depending on how the migration and the cloud contract are run (interpretation).
- Speed to Market: Modern cloud-native cores support continuous deployment, which can shorten the time it takes to configure and launch a new product (interpretation).
- Scalability: Cloud infrastructure can scale to handle peak transaction volumes (month-end, tax season) without over-provisioning.
- Ecosystem Integration: API-first architectures enable smooth integration with fintechs, payment networks, and banking-as-a-service (BaaS) partners.
Cloud Core Banking Architecture Patterns
Full Replacement (Big Bang)
Replacing the entire legacy core with a cloud-native platform. This approach offers the cleanest architecture but carries, in our reading, the highest execution risk (interpretation). Suitable for smaller banks or greenfield digital bank launches.
Progressive Migration (Strangler Fig)
Gradually migrating products, customer segments, or functions from the legacy core to the cloud platform. New accounts are opened on the cloud core while existing accounts are migrated in waves. In our reading it suits mid-sized and large banks with a large existing book to move (interpretation).
Hollowed-Out Core
Retaining the legacy system as a book-of-record while building a modern cloud-based engagement and processing layer around it. APIs abstract the legacy core, and new functionality is built exclusively on cloud services. In our reading, this approach minimizes migration risk but limits long-term architectural benefits (interpretation).
Parallel Run / Digital Bank Spin-Off
Launching a separate digital bank on a cloud-native core while maintaining the legacy core for existing operations. Over time, capabilities may converge.
Leading Cloud Core Banking Vendors
| Vendor | Architecture (our characterization) | Bank clients named in a vendor or bank release | Focus (interpretation) |
|---|---|---|---|
| Thought Machine (Vault) | Cloud-native, microservices | Standard Chartered (Mox), Lloyds Banking Group, JPMorgan Chase | Smart contracts engine |
| Temenos Transact | Cloud-enabled, modular | Nordea (selected in 2015) | Modular product coverage |
| Mambu | SaaS-only, composable | N26, ABN AMRO (New10, BUUT) | SaaS delivery, lending |
| 10x Banking | Cloud-native | Chase UK, Westpac | Cloud-native core |
| Finxact (Fiserv) | Cloud-native | Not verified | Deposit focus, Fiserv ecosystem |
| Oracle Banking | Cloud-enabled | Not verified | Broad product suite, analytics |
| FIS Modern Banking Platform | Cloud-native | Not verified | Core + payments integration |
| Infosys Finacle | Cloud-enabled | DBS; ICICI Bank (trade finance, not core banking) | Core banking suite |
Clients are listed only where a vendor or bank has announced the relationship: Thought Machine on Standard Chartered (March 2020), Lloyds Banking Group (November 2019) and JPMorgan Chase (October 2022); Accenture on Nordea's selection of Temenos (September 2015); Mambu's customer pages on N26 and on ABN AMRO; 10x Banking on Chase (September 2021); Westpac's 2022 media release; Finacle's customer stories on DBS and ICICI Bank. "Not verified" means we found no such announcement, not that the vendor has no bank clients. Cloud deployment options are not listed because we could not verify each vendor's; check them with the vendor.
Regulatory and Risk Considerations
Supervisors have addressed outsourcing to cloud providers in instruments of different force. In the UK, the PRA's SS2/21, Outsourcing and third party risk management sets out supervisory expectations, and one of its stated aims is to "facilitate greater resilience and adoption of the cloud and other new technologies". In the EU, DORA is binding law, and the ECB's Guide on outsourcing cloud services to cloud service providers (July 2025) says it "does not lay down legally binding requirements, practices, or rules". In the US, the banking agencies' third-party guidance, below, applies. Key considerations include:
- Data Residency: Some jurisdictions restrict where customer financial data may be stored or processed, and the rules differ by market. Map the rules for each market before choosing regions, and architect multi-region deployments to match (interpretation).
- Operational Resilience: Supervisors will expect a bank to show that a cloud-hosted core meets its availability, disaster recovery and business continuity needs (interpretation). In the EU this is law: the Digital Operational Resilience Act (Regulation (EU) 2022/2554, adopted by the European Parliament and the Council, not by the ECB) has applied since 17 January 2025 to the financial entities it lists, credit institutions among them.
- Concentration Risk: Dependence on a small number of cloud providers is a supervisory concern (interpretation). DORA Article 29 requires financial entities to consider ICT concentration risk, including contracting a provider that is "not easily substitutable", before contracting for ICT services that support critical or important functions, and Article 28(8) states: "For ICT services supporting critical or important functions, financial entities shall put in place exit strategies." None of the instruments cited here requires a multi-cloud deployment.
- Third-Party Risk Management: For US banks the governing document is the Interagency Guidance on Third-Party Relationships: Risk Management (88 FR 37920, June 9, 2023), issued by the Federal Reserve, FDIC and OCC, which rescinded and replaced OCC Bulletin 2013-29, the Federal Reserve's SR 13-19 and the FDIC's FIL-44-2008. It is supervisory guidance, which "does not have the force and effect of law", and it covers the life cycle of a relationship: planning, due diligence and third-party selection, contract negotiation, ongoing monitoring, and termination. On contracts it notes that "a contract often establishes the banking organization's right to audit and provides for remediation when issues are identified." On September 11, 2026 the agencies and the NCUA announced proposed replacement guidance, published in the Federal Register on September 15, 2026 (91 FR 58536; comments due November 16, 2026). It is a proposal, so the 2023 guidance remains current until a final version is issued.
- Data Security & Encryption: Plan to encrypt customer data at rest and in transit and to decide who controls the keys; bank-controlled key management, hardware security modules (HSMs) and confidential computing are options to weigh for cryptographic operations (interpretation).
Implementation Roadmap
A core banking cloud migration can be planned as a multi-year roadmap like this one (interpretation):
- Phase 0 — Strategy & Vendor Selection: Define target architecture, evaluate vendors, conduct proof-of-concept with 2–3 shortlisted platforms, and build the business case. 2. Phase 1 — Foundation: Establish cloud landing zone, implement security controls, build CI/CD pipelines, configure the core platform, and begin data migration planning. 3. Phase 2 — Pilot Product: Launch a single product (e.g., savings accounts) on the new core for a subset of customers. Validate data migration, integrations, and operational procedures. 4. Phase 3 — Scale Migration: Migrate additional products and customer segments in waves. Each wave follows a standardized playbook covering data migration, integration testing, and cutover procedures. 5. Phase 4 — Legacy Decommission: After all products and customers are migrated, decommission the legacy core. This phase often extends as long-tail edge cases and regulatory reporting dependencies are resolved.
Cost-Benefit Analysis
The comparison below is directional and ours (interpretation); actual costs depend on the bank, the platform and the contract.
| Cost Category | Legacy Mainframe (Annual) | Cloud Core Banking (Annual) |
|---|---|---|
| Infrastructure & Licensing | significantly higher | materially lower |
| Application Maintenance | higher (on-premise) | meaningfully lower (cloud) |
| Specialized Staff (COBOL, etc.) | high | reduced |
| Change Delivery | Slow | Fast (weekly/daily releases) |
| Scalability | Fixed capacity | Elastic, pay-per-use |
Lessons for a Cloud Core Migration
- Data migration is often the hardest part (interpretation). It is easy to underestimate the complexity of migrating decades of transaction history, customer data, and regulatory records. Invest heavily in data quality, mapping, and reconciliation.
- Organizational change management matters as much as technology. Cloud-native cores require different skills (DevOps, API management, SRE) and operating models. Plan for extensive reskilling.
- Start with less complex products. Savings accounts and personal loans are easier to migrate than complex commercial lending or trade finance. Build confidence and capability before tackling the hardest products.
- Regulatory engagement must begin early. Proactively engage regulators on cloud migration plans. Surprises create delays.
Key Takeaways
FAQ Section
Q: Is it safe to run core banking systems in the public cloud? A: It can be, with proper controls (interpretation). Banks need encryption, access controls, network segmentation, and continuous monitoring. In the US, the June 2023 interagency third-party guidance addresses any business arrangement "between a banking organization and another entity, by contract or otherwise", which includes a cloud provider, and expects risk management scaled to the relationship's risk. In the EU, DORA's rules on ICT third-party risk apply.
Q: What is the typical cost of a core banking cloud migration? A: Total program costs vary widely by bank size and scope.
Q: Should we choose a SaaS core banking platform or a self-managed cloud deployment? A: SaaS platforms (like Mambu) minimize operational burden but offer less customization. Self-managed cloud deployments (like Thought Machine on AWS) provide more control but require stronger internal DevOps capabilities. The right choice depends on the bank's technical maturity and customization requirements.
Q: How do we manage the risk of vendor lock-in with cloud core banking? A: Negotiate contractual exit provisions, maintain data portability standards, use open APIs, and consider multi-cloud deployment options. One option is to require the vendor to support more than one major cloud provider, which also bears on concentration risk (interpretation).
- Explore the Core Banking Transformation Toolkit — a detailed transformation toolkits framework for financial services teams.
Frequently Asked Questions
Is it safe to run core banking systems in the public cloud?
It can be, with proper controls (interpretation). Banks need encryption, access controls, network segmentation, and continuous monitoring. In the US, the June 2023 interagency third-party guidance applies to a cloud provider as to any other third party; in the EU, DORA's rules on ICT third-party risk apply.
Should we choose a SaaS core banking platform or a self-managed cloud deployment?
SaaS platforms minimize operational burden but offer less customization. Self-managed cloud deployments provide more control but require stronger internal DevOps capabilities. The right choice depends on the bank's technical maturity and customization requirements.
How do we manage the risk of vendor lock-in with cloud core banking?
Negotiate contractual exit provisions, maintain data portability standards, use open APIs, and consider multi-cloud deployment options. One option is to require the vendor to support more than one major cloud provider, which also bears on concentration risk (interpretation).