How Cloud Banking Platforms Work: Architecture to Vendor Choice

Most platform evaluations stall at the same point: the demos look identical, the feature lists are almost interchangeable, and the sales decks all claim cloud-native architecture. The difference is in what happens when a SEPA transfer hits the ledger at 11 PM, a compliance check fails mid-flow, or you need to swap a KYC provider without rebuilding your integration layer.

For CTOs, heads of product, and digital transformation leads at banks, EMIs, and fintechs, that difference translates directly into your go-live timeline, your audit exposure, and your exit options if the vendor relationship sours.

This guide walks you through how a cloud banking platform actually works layer by layer, where lock-in risk sits in the contract and the architecture, and how to match the right deployment model to your institution’s constraints, drawing on DashDevs’ experience delivering 100+ financial products across regulated markets.

How a Cloud Banking Platform Works

A cloud banking platform is a managed technology stack that hosts core financial operations, product configuration, and customer-facing channels on cloud infrastructure, making them accessible through APIs instead of proprietary terminal connections — built for banks, EMIs, and fintechs replacing or extending on-premises systems. If you need a primer on what core banking actually does before evaluating platforms, start there.

Cloud computing in banking has moved from experimental to standard infrastructure. According to the European Central Bank’s analysis of outsourcing trends across supervised banks, nearly all ECB-supervised banks now hold contracts for cloud-based critical functions, and spending on cloud outsourcing across those institutions grew by 13.5% in 2024 compared to 2023.

The shift reflects both commercial pressure and a maturing regulatory stance on cloud banking software and cloud-based banking software from supervisors in the EU, UK, and US.

The word “platform” is part of the problem. Vendors apply it to products with very different underlying architectures. Some are genuinely cloud-native from the ground up. Others are legacy systems running on rented servers. The difference determines how much you can actually change without a full migration.

The Five-Layer Architecture

Every production-grade cloud-based banking platform, regardless of vendor, has the same five functional layers. Understanding what each layer does and who controls it is the fastest way to evaluate any vendor.

Layer 1: Cloud infrastructure. The physical and virtual compute resources: servers, storage, networking, and security controls. This layer is typically provided by a hyperscaler such as AWS, Google Cloud, or Microsoft Azure, either directly or through the platform vendor’s managed environment. You rarely touch it directly, but you need to know where your data lives and which regions are covered.

Layer 2: Core ledger and product engine. The accounting and product logic layer. This is where account balances are maintained, interest is calculated, fees are applied, and product rules are enforced. It is the most consequential layer to evaluate. For a deeper look at how it works across different product types, see our guide to ledger architecture for multi-product banks. Migrating it later is the most expensive operation in financial infrastructure.

Layer 3: Orchestration and integration layer. The middleware that connects your core ledger to external services: payment networks, card processors, KYC providers, fraud engines, AML systems, and regulatory reporting tools. In a well-designed platform, this layer is configurable without touching core code. For a broader view of how this fits into a scalable fintech architecture, see our dedicated guide.

Layer 4: API gateway. The interface through which your internal systems, third-party services, and your own developers interact with the platform. Proprietary API schemas at this layer are the primary mechanism of vendor lock-in.

Layer 5: Channels. The customer-facing products: mobile apps, web portals, branch tools, and third-party embedded finance interfaces. This layer is the most visible and the easiest to swap, which is why vendors with weak cores often emphasize it in demos. For a comparison of leading digital banking solutions at the channel layer, see our 2026 roundup.

Following One Transaction Through All Five Layers

The clearest way to understand where cloud banking solutions create value is to trace a single transaction. Take a SEPA credit transfer initiated by a customer.

The customer submits the transfer through a mobile app. That request hits Layer 5 (channels) and is passed as a structured API call to Layer 4 (the API gateway), which authenticates the session, validates the request format, and routes it inward.

Layer 3 (orchestration) takes over. It checks the fraud engine, applies velocity rules, confirms the beneficiary against screening lists, and constructs the SEPA message format required by the payment scheme. If any check fails, the transaction is rejected here before it touches the ledger.

Once cleared, Layer 2 (core ledger) executes the double-entry accounting: debit the sender’s account, reserve funds pending settlement, and log the transaction with the appropriate regulatory metadata.

Layer 1 (infrastructure) handles the persistence: writing the transaction to a durable store with replication guarantees, triggering audit log entries, and routing the SEPA message to the clearing infrastructure.

In a well-tuned cloud platform, the entire sequence completes in under two seconds. In a legacy system running on a cloud-hosted monolith, the same sequence can take 20 to 40 seconds because the layers are not decoupled.

Deployment Models: What You Actually Own

The deployment model you choose determines who bears legal and operational responsibility when something goes wrong. Each model carries a different allocation of that responsibility.

Most cloud banking platforms sold to banks and fintechs today are SaaS with PaaS extension points. You configure the product, connect your channels, and integrate your third-party providers. You do not manage the runtime. Let’s compare public vs. private vs. hybrid cloud in the table.

Deployment model choices in Europe are driven more by regulation than by technical preference. The ECB’s analysis of outsourcing registers across supervised banks found that nearly all significant institutions now hold contracts for cloud-based critical functions, with average cloud outsourcing expenditure per institution reaching around €57 million, up from €50.2 million the prior year.

Yet GDPR transfer rules and data localization requirements mean that where that cloud infrastructure sits is not a free choice: for EU-regulated institutions, regional deployment configurations are a compliance requirement before they are an architectural one.

That regulatory asymmetry is why most cloud core banking deployments in the EU end up on hybrid architectures. It is a compliance requirement before it is an architectural choice.

Cloud-Hosted vs. Cloud-Native Core

A cloud-based core banking system running on a managed VM cluster is not the same as a cloud-native core banking system designed for container orchestration. The operational differences compound over time.

When a vendor says they are “on the cloud,” ask one specific question: is your core ledger a monolith deployed to cloud VMs, or is it built as independently deployable services? The answer determines whether you get cloud economics or just cloud hosting costs.

The difference matters commercially too. A cloud-based banking platform built on a cloud-native core typically offers consumption-based pricing that scales with transaction volume. Cloud-based banking software built on a hosted monolith usually charges a fixed infrastructure fee regardless of usage. You pay for peak capacity even during low-volume periods.

This table matters before you sign a contract. Regulators will ask you, not the vendor, to demonstrate compliance. The vendor’s SOC 2 report covers their layer. Your controls cover yours.

Risk, Compliance, and Data Residency

Cloud banking solutions introduce three categories of risk that are specific to cloud deployment. Your risk team needs to document all three before go-live.

Security and Compliance Evidence to Request

Do not accept a vendor’s marketing summary as compliance evidence. Ask for:

• SOC 2 Type II report, not just a Type I attestation. Type II covers a period of operating effectiveness, typically six to twelve months. Type I only confirms controls were in place on a single date.
• PCI-DSS certification if the platform will touch card data.
• ISO 27001 certificate, including the certification scope statement. Scope exclusions matter.
• Penetration testing results from the past twelve months, conducted by a qualified third party.
• Regulatory certifications relevant to your jurisdiction: FCA authorization in the UK, BaFin registration in Germany, and CBN approval in Nigeria.

Data Residency

Most cloud banking platforms default to the vendor’s primary region. For institutions operating in the EU, this creates immediate conflict with GDPR Article 44, which restricts personal data transfers outside the EEA without an adequate transfer mechanism.

For institutions in markets with strict data localization requirements (India, Indonesia, and Saudi Arabia), the vendor’s standard contract may be technically non-compliant from day one.

Before signing, do three things: confirm the platform supports region-specific deployment as a standard contract term; request a data flow diagram showing every location where customer data is stored or processed; and include a data residency warranty in the contract itself.

Operational Resilience and DORA/FFIEC

DORA (EU Digital Operational Resilience Act): Status as of October 2026. DORA entered into application on January 17, 2025. It requires in-scope financial entities in the EU to maintain comprehensive ICT risk management frameworks, conduct annual resilience testing for critical systems, and notify regulators of major ICT incidents within defined windows. Cloud platform vendors that qualify as critical ICT third-party providers (CTPPs) are subject to direct oversight by European Supervisory Authorities.

FFIEC (US): Status as of October 2026. The FFIEC’s IT Examination Handbook, updated in 2023, requires US-regulated institutions to assess concentration risk when a significant portion of operations depends on a single cloud provider or platform vendor. It is one of the most detailed regulatory frameworks governing cloud computing in banking at the federal level in the US. Examiners expect documented third-party risk assessments, exit plans, and evidence of ongoing monitoring.

Your operational resilience documentation should include a tested exit plan from the platform before you go live. The concentration risk numbers give supervisors reason to push on this: according to the EBA Risk Assessment Report published in December 2025, outsourcing risk has increased considerably across EU banks, with ECB data showing that 30% of total outsourcing budgets across significant institutions is concentrated on just ten providers, most headquartered outside the EU. That concentration is exactly what DORA’s critical third-party provider oversight regime is designed to address.

Exit Planning and Vendor Lock-in

Vendor lock-in in cloud banking services happens through four mechanisms: proprietary data formats, non-portable API schemas, contractual limitations on data export, and pricing structures that make migration expensive as you scale.

To assess lock-in risk before signing:

• Request a full data export in a standard format (JSON, CSV, or ISO 20022-compatible) and test it before go-live.
• Confirm the API schema is not proprietary. Open API standards reduce the cost of switching integration partners if you change core systems.
• Review the termination clause. It should include a data transition period of at least ninety days with full export access.
• Ask for a migration case study from a client who exited the platform.

If the vendor cannot provide a migration reference, treat it as a risk signal worth addressing in your contract negotiation. Our blog covers how to avoid cloud vendor lock-in in more detail.

Migration Approaches: What the Data Actually Shows

Institutions moving from on-premises core banking to a banking platform have three structural choices. Each carries a different risk and cost profile.

The choice is not purely architectural. Regulators in most markets require notification of material system changes. The PRA in the UK and the ECB for significant institutions require pre-approval. Factor regulatory timelines into your migration plan.

If you need hands-on support navigating that transition, our cloud migration services team works across all three approaches.

Pre-Migration: The Work Before the Work

Most migration timelines underestimate one phase: the preparation that has to happen before you touch a cloud environment at all.

Before any migration starts, you need three things documented and agreed upon internally.

• A complete data model inventory. You need to know every data entity your current system owns, where it is stored, what format it is in, and which downstream systems consume it. This sounds basic. In practice, for institutions operating for more than five years, this inventory rarely exists in a current, accurate form.
• A reconciled regulatory mapping. Your current system generates regulatory reports in some form. Every field in those reports maps to a data source. You need to confirm that the cloud platform you are moving to can reproduce that mapping. The most common post-migration incident we see is a reporting gap discovered at month-end, not a payment failure.
• A tested rollback plan. For parallel run and big-bang approaches, you need a defined point at which you can revert to the legacy system without data loss. For strangler migrations, this is less critical per step, but you still need to know what a rollback looks like for each migrated service.

If you are still evaluating whether to modernize or replace your core, our core banking software development page covers the decision framework for licensed institutions.

What We Observed Across Delivery Projects

The two patterns that show up most consistently across our delivery work are that the legacy exit is always slower than expected and that pre-work determines the outcome more than the platform itself.

Nexus: When we built the Nexus platform for a client connecting legacy banking systems to cloud infrastructure, the primary constraint was not the cloud integration itself. It was the absence of a stable integration contract on the legacy side.

We spent the first six weeks defining and documenting the legacy system’s behavior before writing a line of cloud integration code. The result was a middleware layer that reached 99.9% uptime and processed over 100,000 transactions.

The lesson we took from that project: migrating to a cloud banking solution is often slower on the legacy exit than on the cloud onboarding. The legacy side deserves as much planning rigor as the cloud side. You can read more about how we connected legacy banking systems to cloud infrastructure for Nexus.

Dozens: For the Dozens UK digital bank project, we took a different path. There was no legacy system to migrate. The architecture was a microservices core orchestrating over 20 third-party APIs, and the team launched a production digital bank in nine months.

Speed was possible because every component was chosen for its API quality, not its feature breadth. The core was lean. The integrations did the heavy lifting.

The pattern we observe consistently across both types of projects: institutions that move fastest are the ones that define their integration contracts first and their vendor shortlist second.

From the very early days, I was struck by DashDevs’ pragmatic approach of balancing development and business needs. It’s really rare to find a company that not only does tech for the sake of tech but also makes grounded decisions, taking into account business considerations. We built together a pretty complicated platform with 40 vendors in less than 18 months. - Aritra Chakravarty, CEO and Founder, Dozens

Before you issue an RFP to cloud banking companies, issue one internally. Ask your operations, compliance, and engineering teams to document what they actually need. The answers will often surface the digital transformation challenges banks face before the vendor conversation even begins.

Evaluation Checklist and Segment Map

You now have the architecture, the deployment models, the risk framework, and the migration options. Here is how to apply them to a vendor evaluation, and our core banking vendor selection guide covers the reference-call questions in more detail.

Cloud Banking Platform Evaluation Checklist

Architecture:

• Is the core ledger cloud-native (microservices/event-driven) or cloud-hosted (monolith on VMs)?
• Does the platform support horizontal scaling without scheduled maintenance windows?
• Are the five layers (infrastructure, ledger, orchestration, API gateway, and channels) clearly documented and independently configurable?

Compliance and residency:

• Does the vendor hold SOC 2 Type II, ISO 27001, and relevant jurisdictional certifications?
• Can you deploy in your required data residency region as a standard contract term, not a custom engagement?
• Has the vendor completed a DORA third-party assessment for EU-facing deployments or an FFIEC third-party risk assessment for US-regulated institutions?

Integration and openness:

• Does the platform use open API standards (REST, ISO 20022, Open Banking) or a proprietary schema?
• Can you connect your own KYC, fraud, and AML providers, or are you required to use the vendor’s?
• How many integrations does the vendor maintain, and which payment schemes do they cover in your target markets?

Exit and portability:

• Does the contract include a tested data export mechanism in a standard format?
• Is the termination clause balanced, with a ninety-day or longer data transition period?
• Can the vendor provide a migration reference from a client who exited the platform?

Commercial structure:

• Is pricing based on transactions, accounts, or a flat SaaS fee? Each model has a different cost trajectory as you scale.
• Are there volume thresholds that create pricing cliffs?

Segment-to-Option Map

Different institutions have different constraints. The right starting point varies accordingly.

• Licensed bank modernizing its core: Your primary constraint is regulatory continuity. You cannot take a big-bang approach, and you likely need to satisfy both a board-level risk committee and a prudential regulator before proceeding. Start with a strangler migration. Identify two or three services (typically payments processing or digital onboarding) that can move first, and use those as proof-of-concept for the broader program. Evaluate platforms with explicit large-bank migration references and a mature shared-responsibility model. Our fintech infrastructure for licensed institutions page covers what that engagement looks like in practice.
• EMI launching in the EU: Your primary constraint is speed to authorization and regulatory compliance from day one. DORA applies from the start, so the platform you choose must be documentable in your ICT risk framework before you apply for authorization. Choose a cloud-native platform with an EU data residency option, open APIs, and a strong integration library for the PSPs and banking partners you will need in your first twelve months. DashDevs’ fintech integration services team can map your initial integration requirements before you commit to a platform.
• Fintech launching a first product: Your constraint is capital efficiency and speed to production. You do not need a full core banking platform on day one. What you need is a composable infrastructure layer that lets you configure the modules you actually need now, add more as you scale, and avoid paying for a 200-feature enterprise system when you are running three products.

This is the use case Fintech Core addresses directly. Fintech Core is DashDevs’ composable fintech infrastructure and orchestration platform for launching, expanding, or modernizing regulated financial products. It gives teams a faster starting point than a custom build, with more flexibility and control than traditional white-label or SaaS platforms. Teams typically reach production in 12 weeks, with 16+ modules and 20+ vendor integrations available from day one. Kleos’s move to a unified platform on Fintech Core illustrates how an existing regulated business reduced operational overhead while expanding its product range.

For a broader framework on whether to build, buy, or partner for your infrastructure, see our build, buy, or partner framework for fintech infrastructure guide.

The Architecture Is Table Stakes. The Contract Is Where You Win or Lose

The vendors that dominate cloud platform searches (Oracle, Microsoft Azure for financial services, AWS, and Google Cloud) all offer capable infrastructure. Capable infrastructure and a well-governed vendor relationship are two different things, and the contract is where the difference lives.

What Separates a Good Platform Decision from a Costly One

Three patterns show up consistently in platform decisions that create long-term problems.

1. Evaluating platforms by feature count. A vendor’s feature list reflects their existing customers and markets, not whether the architecture can support your roadmap twelve months from now. Evaluate the API layer and the integration model instead.

2. Treating the SaaS agreement as standard. Banking platform contracts include data processing addenda, shared-responsibility clauses, and termination provisions that may carry no data export obligation unless you negotiated it in. Have qualified technology counsel review it.

3. Selecting a platform before defining the integration architecture. Know which PSPs, card processors, KYC providers, and banking partners you need in year one. Confirm the platform can accommodate them before you sign.

Most of the platform regrets we see come from the contract, not the technology. The exit clause is the last thing anyone reads and the first thing they need.

Start with the five-layer architecture model when you evaluate any new platform. Confirm which layers the vendor controls and which you control. Negotiate data portability before you sign. Check the exit clause as carefully as you check the feature list.

Cloud banking solutions have changed what a 20-person team can build and what a 200-year-old bank can modernize. A UK digital bank launched in nine months. A legacy core connected to real-time payment networks without a full replacement. The technology delivers. The risk sits in the contract terms most teams review last.

For a broader market view, our roundup of best core banking platforms compares leading options by segment and deployment model.