7. Five UK banks, five different cloud estates, and the same three structural constraints

The situation

UK banks face unique pressures: PRA/FCA/DORA regulations constrain data residency, legacy core banking limits migration speed, multi-cloud adds complexity, and scale means small percentage improvements save millions. NatWest manages a $120M+ cloud portfolio. All five major banks have established FinOps functions.

The gap with US big tech is not about capability. JPMorgan, Goldman Sachs, and Morgan Stanley have been investing in cloud infrastructure for over a decade. UK banks started later, face heavier regulatory constraints, and carry more legacy infrastructure. The comparison is not entirely fair, but it is useful: it shows what mature FinOps looks like at financial services scale.

The complication

Four challenges beyond typical cloud-native companies. First, hybrid infrastructure: core banking remains on-premises for most UK banks, and the full migration timeline stretches years into the future. Second, regulatory fragmentation across jurisdictions: PRA, FCA, DORA, and national data residency laws all impose constraints on where workloads can run, and the cheapest region is not always the compliant region. Third, outsourced operations mean the people provisioning resources are often not the people paying for them, which creates a structural misalignment of incentives regardless of which supplier holds the contract. Fourth, enterprise agreements (EDPs, EAs, CLAs) lock spending for 3-5 years, which means commitment decisions made today constrain cost optimisation options for the next business cycle.

Bank-by-bank profiles

Barclays

Barclays runs a multi-cloud estate across AWS, Azure, and GCP with HPE GreenLake private cloud hosting 100,000+ workloads. The bank adopted a Cloud-First policy and has migrated 75%+ of global applications to public cloud. Technology budget exceeds GBP 2 billion annually, making Barclays one of the largest technology investors among European banks.

On the AI front, Barclays has deployed Microsoft Copilot to 50,000+ colleagues and established a GenAI Centre of Excellence that runs hackathons to drive responsible AI adoption across the organisation. The Copilot deployment alone introduces a new cost category: per-user AI licensing that compounds at scale. At 50,000 users, even modest per-seat pricing represents a significant annual commitment.

The FinOps challenge at Barclays is complexity. Four cloud environments (three public, one private) mean four billing systems, four discount structures, and four sets of native tools. No single platform provides a unified view across all four. The bank is building its FinOps capability with Power BI dashboards and the GenAI Centre of Excellence.

Barclays presented at the Microsoft Global Technology Conference in December 2025, discussing AI adoption strategy. The scale of their AI investment (Copilot for 50,000+, GenAI CoE, hackathons) positions them as a leader among European banks on AI adoption.

HSBC

HSBC runs a hybrid model with Google Cloud for analytics and private cloud for core banking. The bank partnered with Accenture to migrate Teradata workloads to BigQuery, a multi-year programme that shifts a significant analytics estate to GCP consumption-based pricing. Natalie Daley presented at FinOps X 2023, discussing how HSBC is extending FinOps scope beyond public cloud to cover SaaS, licensing, and private cloud infrastructure.

The hackathon model (described in Section 4) originated at HSBC. Quarterly competitive sprints where teams compete on verified savings work because HSBC has a strong engineering culture with multiple product teams. The model does not work everywhere, but it works well in organisations with competitive engineering cultures.

HSBC's stated FinOps focus is scope expansion. Extending cost governance to SaaS (hundreds of applications), licensing (complex enterprise agreements), and private cloud (which uses different cost allocation models) multiplies the complexity. Natalie Daley was explicit about this: the hard part is not public cloud anymore. The hard part is everything else.

The BigQuery migration introduces specific cost risks. BigQuery pricing has two models: on-demand (per-TB scanned) and flat-rate (reserved slots). An analytics team that runs ad-hoc queries against unpartitioned tables can generate substantial bills quickly. HSBC's FinOps function needs to govern query patterns alongside infrastructure provisioning.

HSBC's size creates both challenge and opportunity. The bank operates in 62 countries, which means 62 regulatory jurisdictions constraining where workloads can run. A cost optimisation that works in London may not be permissible in Hong Kong, Singapore, or Dubai. At the same time, the scale of spend means that even marginal improvements compound: a 2% efficiency gain on a $200M+ technology estate is $4M annually. The bank's FinOps function must balance global standardisation (one governance framework, one set of metrics) with local adaptation (regulatory constraints, market-specific workloads).

The cloud hackathon model, which HSBC pioneered, has been adopted or adapted by at least two other UK banks. The concept is simple: give engineering teams a defined period to find and implement cost savings, with recognition and budget credits for winners. The mechanism works because it converts cost optimisation from a compliance obligation into a competitive challenge. Engineers who would never voluntarily read a cost report will spend a weekend hunting for savings if there is a leaderboard involved.

Lloyds Banking Group

Lloyds is primarily GCP with a TCS partnership for operations. The bank presented at Google Cloud Next 2025 on FinOps Hub 2.0, which uses Gemini Cloud Assist to provide AI-powered cost recommendations. Over 300 data scientists work on Vertex AI, making Lloyds one of the most AI-intensive UK banks relative to its size. The Thought Machine partnership for cloud-native core banking is the most ambitious modernisation programme among UK retail banks.

The FinOps Hub 2.0 is notable because it represents a provider-specific approach to FinOps tooling. Rather than buying a third-party platform like Apptio, Lloyds built a custom solution on GCP using native tools and Gemini AI. This works well for a single-cloud organisation but creates concentration risk: the FinOps tooling is as locked into GCP as the workloads it monitors.

Single-cloud concentration is the defining structural feature of this estate. GCP pricing is competitive today, but a single-provider estate carries less negotiating leverage at renewal than a credible multi-cloud alternative would. Where operations are delivered through a managed services partner, a second structural feature applies: optimisation recommendations flow through an organisation whose commercial incentive is to maintain or grow the managed estate rather than shrink it. A recommendation to right-size an instance reduces the partner's managed scope. That misalignment is structural rather than a failing of any particular supplier, and the place to address it is the contract.

NatWest Group

NatWest runs multi-cloud with AWS as the primary provider, supplemented by GCP and an internal Enterprise Cloud Platform (ECP). The bank signed a five-year AWS/Accenture collaboration starting July 2025, which anchors its cloud strategy to AWS for the medium term. The payments modernisation programme (SEPA/CHAPS on AWS with Icon Solutions) is the flagship migration and the largest single source of cloud cost growth.

NatWest uses Apptio Cloudability, AWS/Azure native tools, Power BI, and ServiceNow for FinOps governance. The tool estate spans several layers, with Apptio Cloudability as the enterprise platform alongside native provider tools used in parallel where refresh cadence matters operationally.

The portfolio is approximately $120M across all cloud providers. The structural challenge in any estate of this shape is distributed decision-making: multiple teams make cloud decisions independently, which raises the bar for consistent governance across providers and business units.

The payments migration introduces specific cost risk. Parallel-run periods (old system and new system running simultaneously) double infrastructure costs temporarily. If the migration takes longer than planned, parallel-run costs accumulate. The FinOps function needs to track migration milestones alongside infrastructure spend to identify slippage early.

The NatWest FinOps operating model is worth examining because it is the most documented among UK banks. Apptio Cloudability provides the governance layer with cost allocation, chargeback, and forecasting. AWS Cost Explorer and Azure Cost Management provide the native visibility layer. Power BI provides the executive reporting layer. ServiceNow provides the ticketing layer. The architecture covers all five layers of the reference model. The general constraint on any such architecture is data quality: where tagging compliance sits below 80%, allocation models produce outputs teams do not trust, and the cost function spends its time defending the data rather than acting on it.

The five-year AWS/Accenture collaboration signed in July 2025 anchors NatWest's cloud strategy to AWS for the medium term. This has FinOps implications: the commitment is large enough that AWS will provide dedicated support, custom pricing, and architectural guidance. But it also limits negotiating leverage with other providers. The FinOps team needs to model the total cost of the Accenture partnership (managed services fees + cloud infrastructure + migration costs) against internal delivery alternatives to ensure the partnership delivers value.

Standard Chartered

Standard Chartered is Azure-preferred under a 3-year Microsoft partnership. The bank operates in 60 markets, with cloud-first for new development. Trade finance was the first major workload migrated to Azure. The Microsoft partnership includes Copilot deployment and Azure-based modernisation across key markets.

The 60-market footprint creates a FinOps challenge that no other UK bank faces at the same scale. A workload cheapest in us-east-1 might legally need to run in Singapore, Frankfurt, or Mumbai at higher cost. Standard Chartered cannot optimise purely on price because regulatory constraints override cost considerations in 50+ jurisdictions. This is Gap 2 from Section 9: regulatory-aware FinOps.

The 60-market complexity means that even basic cost allocation requires understanding which entity in which jurisdiction owns which workload. The Microsoft partnership provides tooling structure (Azure Cost Management, Azure Advisor), but the regulatory overlay remains manual across the market: no tool automates the question of whether a workload sits in the cheapest compliant region.

Cloud estate at a glance

Common themes across UK banks

All five share three structural challenges. Hybrid cost: no tool gives a unified view across public cloud, private cloud, and on-premises. Partner dependency: operations commonly delivered through systems integrators whose commercial incentives differ from the bank's. Regulatory tax: compliance adds irreducible cost that cannot be optimised away. The opportunity is significant: at 32-40% waste, even partial maturity across a $50-120M portfolio means $10-48M in recoverable spend per bank.

The partner dependency problem deserves closer examination. When a bank outsources cloud operations to an SI, the SI is incentivised to grow the managed estate (more infrastructure means more managed services revenue). The bank is incentivised to reduce the managed estate (less infrastructure means lower cost). This misalignment is not malicious. It is structural. The SI account team is measured on revenue growth. The bank's FinOps team is measured on cost reduction. Both are doing their jobs. The solution is contractual: build savings targets into the SI agreement and share a percentage of verified savings as a bonus. Align incentives at the contract level, not the operational level.

The regulatory tax is the least discussed but most significant structural cost in UK banking cloud. PRA and FCA requirements around operational resilience (PS21/3, SS1/21) mandate specific controls for material outsourcing, including cloud services. DORA (Digital Operational Resilience Act) adds EU-level requirements for ICT third-party risk management. These regulations do not prohibit cloud adoption, but they add cost: additional monitoring, audit trails, exit planning, and geographic constraints on data placement. A realistic estimate of the regulatory tax on cloud operations in UK banking is 10-15% above the equivalent cost for an unregulated company.

Despite these structural constraints, the trajectory is clear. All five banks are investing in FinOps. All are hiring. All presented at industry conferences in 2024-2025. The open question is what competitive advantage accrues to whichever moves furthest fastest on technology cost efficiency.

Beyond UK retail banking: investment banks and payment networks

A note on sourcing: the profiles above are built entirely from public signals, including conference presentations, press releases, published partnerships and investor materials. They describe publicly stated positions and the structural constraints that follow from them. They are not assessments of any institution's internal capability, which no outside party is in a position to judge.

JPMorgan Chase

JPMorgan spends $17 billion annually on technology, making it the largest technology investor in financial services globally. The bank has migrated 6,000 applications and 1 exabyte of data to AWS, with 70% of applications now on public or private cloud. 43,000 engineers work across the technology estate. The bank deployed its internal LLM Suite to more than 200,000 employees and generates $1.5 billion+ in annual business value from AI/ML across 300 production use cases.

At this scale, FinOps is not optional. A 1% inefficiency on a technology budget of $17 billion represents $170 million. JPMorgan's Investor Day materials reference a 15-20% infrastructure cost efficiency target and consolidation from 33 to 17 global data centres. The bank operates a multi-cloud strategy explicitly to mitigate lock-in risk.

What JPMorgan demonstrates is what happens when FinOps operates at genuine enterprise scale: workload-by-workload placement decisions, infrastructure cost efficiency as a board-level KPI, and AI investment that dwarfs most companies' entire IT budgets. Chase.com runs entirely on AWS with 15 releases per week. The speed of deployment combined with the scale of spend means that cost governance must be automated and embedded, not manual and periodic.

Mastercard

Mastercard is a confirmed FinOps Foundation member, indicating active engagement with the discipline. The company processes billions of transactions daily across a globally distributed infrastructure where latency is an absolute constraint: sub-100ms response times globally. This limits the cost optimisation lever that most companies rely on: region arbitrage. Mastercard cannot move a workload to a cheaper region if it adds 20ms of latency to a payment authorisation.

Mastercard has invested in GCP for data analytics and multi-cloud for resilience. The FinOps challenge is distinct from banks: transaction volumes are more predictable (seasonal patterns around holidays and payroll cycles), but infrastructure must be provisioned for peak (Black Friday, Singles Day) while being cost-efficient during troughs. Spot instances are unusable for payment processing. Reserved capacity must be modelled against peak-plus-headroom, not average utilisation.

The contrast with banks is instructive. Banks have variable workloads across hundreds of products. Mastercard has a more concentrated workload profile with extreme performance requirements. The FinOps discipline is the same (visibility, optimisation, governance), but the constraints are different: latency trumps cost in payment processing, and the cost of a failed transaction vastly exceeds the cost of over-provisioning.