Global financial services cloud spending surpassed $80 billion in 2025, on track for $83 billion by end of 2026. JPMorgan Chase runs over 60% of its workloads in the cloud. Goldman Sachs has a multi-year cloud partnership with AWS. HSBC, BNP Paribas, and Deutsche Bank are all mid-migration. The question of whether banks should move to the cloud has been settled by the market.
The question that remains is how. Financial services cloud deployments that fail do not fail because the technology doesn’t work — they fail because the architecture was designed without accounting for the specific regulatory, resilience, and data sovereignty requirements that apply to regulated financial institutions. DORA (Digital Operational Resilience Act) in the EU, FFIEC guidance in the US, and PRA rules in the UK impose requirements on cloud deployments that generic cloud architecture patterns do not address.
This article covers what compliant, resilient financial services cloud architecture actually requires.
The Regulatory Framework: What Changes in 2026
Financial services cloud deployments operate under a regulatory layer that does not apply to most other industries. The key frameworks in 2026:
DORA (EU — effective January 2025): The Digital Operational Resilience Act imposes mandatory requirements on all financial entities operating in the EU, including: ICT risk management frameworks, mandatory incident reporting to regulators within defined timeframes, operational resilience testing (including penetration testing and scenario-based resilience exercises), and — most significantly for cloud — third-party ICT risk management requirements. Every cloud provider used for critical or important functions must be assessed, contracted with specific resilience requirements, and monitored on an ongoing basis. Cloud concentration risk — where a single provider outage could affect multiple financial institutions simultaneously — is an explicit regulatory concern under DORA.
FFIEC IT Examination Handbook (US): The Federal Financial Institutions Examination Council guidance covers cloud service provider due diligence, contract requirements, and ongoing monitoring. US banks must document their cloud risk assessment, ensure contractual rights to audit and examine, and demonstrate that the cloud environment meets the same security and resilience standards as on-premises equivalents.
PRA SS2/21 (UK): The Prudential Regulation Authority’s supervisory statement on outsourcing and third-party risk applies to cloud services used for material business services. UK banks must notify the PRA of new material cloud arrangements, conduct exit planning, and maintain data portability to prevent vendor lock-in.
Common regulatory requirements across all frameworks:
- Right to audit and examine the cloud provider’s controls (directly or through third-party assessors)
- Data residency requirements — customer data must remain within specified jurisdictions
- Exit strategy — ability to migrate off the cloud provider without prohibitive cost or data loss
- Concentration risk management — limits on the percentage of critical workloads on a single provider
- Incident notification — cloud provider outages affecting financial operations must be reported to regulators within specified timeframes
Architecture Patterns for Regulated Financial Cloud
Multi-Region Active-Active for Critical Systems
Payment processing, core banking, and trading systems cannot tolerate the recovery time objectives that standard cloud disaster recovery architectures provide. A single-region deployment with cross-region backup may have an RTO of 30–60 minutes — unacceptable for real-time payment rails or equity trading systems.
Active-active multi-region architecture runs the same workload simultaneously in two or more cloud regions, with requests load-balanced across regions and automatic failover when one region degrades. This achieves near-zero RTO for most failure scenarios.
The engineering cost: Active-active architecture requires distributed transaction management — ensuring that a payment initiated in EU-WEST-1 and processed in EU-WEST-2 cannot result in a double-payment or lost transaction. This requires distributed consensus patterns (two-phase commit, saga choreography, or idempotent operations with reconciliation) that add significant engineering complexity compared to single-region deployments.
For most fintech applications, active-passive with sub-15-minute RTO is sufficient. Active-active is warranted for payment processing, real-time settlement, and trading systems where downtime has immediate regulatory and financial consequences.
Data Residency Architecture
Financial customer data — account records, transaction history, KYC documents — is subject to data residency requirements in the EU (GDPR), Switzerland (nDSG), and many APAC jurisdictions. Some regulators require that certain data never leaves the country’s borders.
Architecture approach:
- Tag all data with residency classification at creation (personal data, financial transaction data, operational data, public data)
- Deploy separate storage environments per jurisdiction with network policies that prevent cross-jurisdiction replication for restricted data classes
- Use cloud providers’ regional services that guarantee data residency (AWS EU regions, Azure Germany North, etc.)
- Implement data access controls that enforce jurisdiction-based access restrictions at the API layer
Data residency is simpler to enforce in greenfield cloud deployments than in migrations from monolithic on-premises systems where data residency was never a data-layer concern.
Core Banking Modernisation: Strangler Fig Pattern
Legacy core banking systems — often running on IBM mainframes with COBOL codebases dating to the 1970s — cannot be replaced in a single migration. The risk of a big-bang core banking replacement is existential; several major banks have attempted it and created multi-day outages that cost hundreds of millions in regulatory fines and customer remediation.
The strangler fig pattern decomposes migration into incremental steps:
- Place a façade API in front of the legacy core that intercepts all requests
- Migrate one domain at a time (accounts → then payments → then lending) to cloud-native microservices
- Route traffic for migrated domains through the new services; legacy system handles unmigrated domains
- Decommission legacy modules progressively as migration completes
This pattern keeps the legacy system operational throughout migration, allows rollback of individual domains if issues arise, and enables parallel testing of new and legacy systems against the same input. The migration takes years, not months — but each year reduces the legacy risk surface.
AI Infrastructure for Financial Services Cloud
Financial services AI workloads cluster into three categories with distinct infrastructure requirements.
Real-Time Risk and Fraud (Sub-300ms)
Fraud scoring, sanctions screening, and credit risk checks that run synchronously with transactions require inference latency under 300ms — ideally under 100ms. This constrains the model architecture (simpler models that run faster) and the deployment topology (inference infrastructure co-located with transaction processing, not in a separate region).
Infrastructure pattern: Gradient boosting models (XGBoost, LightGBM) deployed on CPU instances close to the transaction processing layer. GPU inference is not justified for tabular fraud models — the instance startup and data transfer overhead eliminates the compute advantage. Feature computation must happen in a real-time feature store (Redis, AWS ElastiCache, or a purpose-built feature platform like Tecton or Feast) that serves pre-computed features with sub-10ms latency.
Batch Analytics and Model Training
Credit portfolio analysis, AML transaction monitoring batch jobs, and regulatory stress testing run on batch schedules rather than real-time. These workloads benefit from the elasticity of cloud compute — spinning up large GPU or CPU clusters for the duration of a training or batch job, then releasing the instances.
Cost architecture: Spot/preemptible instances for fault-tolerant batch workloads reduce training costs 60–80% compared to on-demand instances. Financial batch jobs are typically fault-tolerant (a failed training run can be restarted from a checkpoint), making them well-suited for spot pricing. Regulatory stress tests and compliance reports that cannot tolerate interruption should use reserved or on-demand instances.
Generative AI for Financial Operations
Large language models in financial services are deployed primarily for internal operational use cases — document analysis, regulatory filing drafting, customer inquiry routing, code generation for analysts and engineers — rather than customer-facing applications where hallucination risk is higher.
Deployment options for regulated financial institutions:
- Private model deployment: Self-hosted open-weight models (Llama, Mistral) on cloud GPU instances within the financial institution’s cloud environment. Customer data never leaves the controlled environment. Higher infrastructure cost; full control.
- Azure OpenAI Service / AWS Bedrock: Managed LLM APIs with enterprise data handling terms and regional data residency options. Data does not train OpenAI models when using Azure OpenAI Service. Requires BAA-equivalent data processing agreements appropriate for financial data.
- On-premises GPU infrastructure: For institutions with strict data sovereignty requirements that preclude any cloud-based model processing. Highest capital cost; most control.
Most large financial institutions are using Azure OpenAI Service or AWS Bedrock for internal applications while evaluating private model deployment for use cases with the most sensitive data.
Cloud Concentration Risk: The Architecture Question Regulators Are Watching
DORA and equivalent frameworks explicitly require financial institutions to manage cloud concentration risk — the systemic risk that arises when a large fraction of the financial sector’s critical infrastructure runs on a single cloud provider. A prolonged AWS or Azure outage could simultaneously affect thousands of financial institutions.
Practical approaches:
- Maintain critical workloads across at least two cloud providers for the most systemic-risk-sensitive functions (payment processing, real-time settlement)
- Maintain an exit plan for every material cloud provider relationship — documented migration path, estimated timeline and cost, and tested data export capability
- Use cloud-agnostic infrastructure tooling (Kubernetes, Terraform, Pulumi) that reduces the platform-specific migration cost
- Participate in industry resilience exercises (SIMEX in the UK, sector-wide tabletop exercises coordinated by regulators) that test cross-institution coordination during cloud outages
The concentration risk requirement does not mandate multi-cloud for all workloads — it requires that institutions can articulate their concentration exposure and demonstrate they have managed it proportionate to their systemic importance.
How we approach this at Insoftex
The regulatory compliance and resilience architecture described in this article is the context in which we have delivered cloud-native financial services platforms. Our automated SaaS lending risk assessment platform was built from the ground up with DORA-relevant principles embedded in the design: immutable audit logging via event sourcing, multi-region deployment for the core decision service, and contractual data handling terms reviewed before vendor selection — not after the architecture was set. The compliance posture was a design input, not a later-stage addition.
The SaaS for business loans platform involved the same architectural discipline applied to a different regulatory context. Both engagements confirmed a pattern we now scope as standard for regulated financial services builds: the compliance architecture review happens before the infrastructure decisions are finalised, because those decisions constrain what compliance controls are practically achievable. A team that selects a cloud data warehouse before reviewing data residency requirements will often find itself working around the residency constraint rather than designing for it.
The concentration risk and exit strategy requirements under DORA are where we most consistently see planning gaps in financial services cloud migrations. Teams have detailed migration plans for getting onto the cloud and no documented plan for getting off — or for operating if a critical provider has a sustained outage. We treat exit strategy documentation as a deliverable in every regulated financial services cloud engagement, because the regulator will ask for it and building it retroactively is significantly more effort than building it as part of the initial architecture design.
Architecting a financial services cloud platform or migrating a fintech product to cloud infrastructure? Our fintech engineering team specialises in regulated financial systems and compliance-first cloud architecture. Start with a Product Pilot for compliance design, resilience architecture, and build planning in three weeks.
Frequently Asked Questions
What does DORA require specifically for cloud providers used by financial institutions?
DORA requires financial entities in the EU to apply specific risk management requirements to ICT third-party providers, including cloud providers, when those providers support critical or important functions. The specific requirements: (1) Pre-engagement due diligence — assess the provider's security, resilience, and concentration risk before contract signing; (2) Contractual requirements — contracts with critical ICT providers must include specific provisions: right to audit, data portability, termination rights, defined SLAs, and subcontractor disclosure; (3) Ongoing monitoring — annual review of the provider's performance and risk posture; (4) Exit planning — documented exit strategy with tested capability to migrate workloads within a defined timeframe; (5) Reporting — notify the relevant competent authority of new arrangements with critical ICT providers above defined thresholds. DORA applies to the cloud provider relationships of banks, insurers, investment firms, payment institutions, and other regulated financial entities — not to the cloud providers themselves (unless a cloud provider is itself a regulated entity).
Can a fintech startup use a single cloud provider, or does regulation require multi-cloud?
Regulation does not require multi-cloud for all financial institutions. DORA requires managing concentration risk proportionate to the institution's systemic importance — a small fintech is treated differently than a systemically important bank. For most early-stage fintech companies, a single cloud provider with multi-region deployment (active-passive or active-active depending on RTO requirements) satisfies the resilience requirements of applicable regulation. What regulation does require, even for small fintechs: documented risk assessment of the cloud provider relationship, contractual rights including audit rights and data portability, and an exit strategy. Multi-cloud becomes warranted as the institution grows in systemic importance, as regulator guidance is more explicit for larger institutions, and when specific workloads have resilience requirements that a single provider's SLA cannot meet.
How should a bank handle data sovereignty requirements when using US-based cloud providers?
AWS, Azure, and GCP all operate cloud regions within EU member states, the UK, Switzerland, and other jurisdictions with data residency requirements. Using EU-based cloud regions for EU customer data — and configuring storage, databases, and processing services to operate within those regions — satisfies GDPR data residency requirements for most use cases. The additional considerations: (1) Ensure that support access, telemetry, and operational data flows do not transfer customer data out of the required jurisdiction; this requires reviewing the provider's data handling terms and disabling any features that send data cross-region; (2) For jurisdictions with more restrictive requirements (certain banking data in some countries must remain in-country, not just in-region), verify that the cloud provider operates a local zone or on-premises option in that country; (3) Document your data residency controls — regulators increasingly request evidence of technical controls, not just contractual commitments.
What is the right cloud architecture for a core banking system?
Core banking systems have two distinct architectural requirements that pull in different directions: extreme reliability (payment processing cannot go down) and extreme longevity (the data model and business logic must remain consistent over decades). The recommended pattern: keep the core ledger — the accounting engine that records and tracks financial positions — on the most reliable, simplest infrastructure available. This often means a managed relational database (Aurora PostgreSQL, Azure SQL, Cloud Spanner) in active-active multi-region configuration. Build around the core ledger as microservices that can be deployed, scaled, and updated independently: payments processing, product management, customer management, reporting. Use event sourcing for the core ledger — transactions are immutable events, balances are derived — ensuring the audit trail is a first-class architectural concern. Migrate from legacy core systems using the strangler fig pattern rather than big-bang replacement. The goal is to get the benefits of cloud scalability and modern development tooling without introducing the reliability risks of over-engineered microservice architectures in the most critical system.