The Conversation You Are Having Right Now

Your AWS account manager is in a meeting room across the road. Your CTO has a slide deck that says Azure. Someone has raised GCP. The vendor reps are polished, their financial services certifications are real, and their reference clients include names you recognise.

What nobody in the room is saying — because it is not in any of the slide decks — is that the cloud AI decision for a mid-tier bank is not primarily a technology decision. It is a risk management decision with a technology wrapper.

I have spent the past three years advising mid-tier banks on cloud migration and AI adoption, working with institutions from £2bn to £40bn in assets. The pattern that repeats: banks engage with cloud providers, accept the capability pitch at face value, and discover the structural problems only after the contracts are signed and migration is underway.

This article is about those structural problems. Not to argue against cloud — the case for cloud in banking is real — but to give you the picture your vendor is not going to put in front of you.

What Providers Are Honest About

AWS, Azure, and GCP all have genuine financial services capabilities. They are not making these up.

AWS has the Banking Competency programme and Well-Architected Framework for financial services. Azure has dedicated financial services regions and sovereign cloud options. GCP has financial services landing zones and Workday-level enterprise references. These certifications are real. The underlying infrastructure meets the claims.

AWS Bedrock, Azure AI Foundry, and Google Vertex AI are all production-grade platforms. If you are building a fraud detection model, a credit decisioning engine, or a regulatory reporting automation layer, these platforms can do the job.

Where providers are honest: they will tell you what their platforms can do. They will demo the capabilities. They will show you reference architectures. They will provide compliance documentation. None of this is misleading.

What Providers Do Not Tell You

The Managed Services Trap

The pitch most providers lead with for mid-tier banks is managed services: let us handle the infrastructure, the security patching, the scaling, the compliance baseline. You focus on the banking logic.

This is a reasonable pitch. For many use cases it is the right answer.

What the pitch omits: managed services create a new category of vendor dependency. Not the dependency you have with a Temenos licence — where you own the implementation and can hire any vendor to support it — but the dependency where the provider controls your operational parameters.

When your managed fraud detection model needs a parameter changed, you file a ticket. When you need the API rate limits adjusted for a new product launch, you negotiate. When you discover that your audit logs are structured in a way that makes your SIEM integration harder than it should be, you work around it.

The mid-tier banks that navigate this well are the ones that established strong internal cloud engineering capability before they migrated. They have engineers who can debug integration problems, manage Terraform modules, and audit IAM policies without calling the provider. The banks that treat managed services as a reason not to build internal capability are the ones that end up hostage to the vendor's roadmap priorities.

The decision: if you go managed services, build the internal engineering depth to manage the relationship, not just consume the service.

The Sovereignty Gap

Data sovereignty is the issue that surfaces last in cloud migration programmes, and it surfaces in the worst possible moment — during an audit or a regulatory review when someone asks where your payment transaction data actually resides.

Providers offer sovereign cloud options. AWS Outposts, Azure Sovereign Clouds, GCP Sovereign Cloud. These are real products and they address a real problem. They are also expensive, operationally complex, and not the default on any standard enterprise agreement.

What the standard pitch omits: most enterprise agreements default to the provider's standard commercial regions. Those regions have data residency guarantees at the country level. But banking data sovereignty is not just geographic — it is logical (which systems process which data types), temporal (where do backups live and for how long), and operational (who has access to what under which jurisdiction's laws).

I have reviewed three cloud architectures in the past eighteen months where banks discovered — during a DORA operational resilience review — that data they understood to be UK-resident had infrastructure dependencies in Ireland, the US, or Singapore, either through backup replication, shared compute resources, or managed service dependencies that the original contract had not scoped.

The fix: contract for data residency explicitly, at the service level. Make your legal team review the data processing addendum with the same rigour you apply to your core banking contract. Assume the default is not what you want.

The Multi-Cloud Myth

Multi-cloud — running workloads across two or more cloud providers — is presented in vendor marketing as a resilience and independence strategy. For large banks with dedicated cloud architecture teams and the traffic volume to justify it, it can be.

For most mid-tier banks, multi-cloud is a complexity amplifier, not a resilience improvement.

The operational overhead of multi-cloud includes:

The failover story — if AWS goes down, we route to Azure — requires that you have the traffic volume, the engineering depth, and the operational experience to execute a real failover under pressure. Most mid-tier banks have not tested this. The ones that have tested it have discovered it is considerably harder than the vendor failover documentation suggests.

The decision: multi-cloud is a legitimate strategy when you have the volume to justify it and the engineering depth to manage it. For most mid-tier banks, a single-provider strategy with contractual exit provisions is the more operationally sound choice.

DORA: What It Actually Demands for Cloud Migrations

The Digital Operational Resilience Act (DORA) has been in force since January 2025. Most banks have the high-level picture: DORA requires financial institutions to ensure their ICT third-party providers meet resilience standards, to conduct regular testing, and to maintain incident response capabilities.

What DORA does not give you is a prescriptive architecture. The regulation sets outcomes — your bank's systems must be resilient, your third-party providers must meet standards, your incident response must be tested. How you achieve those outcomes is your decision.

This creates an asymmetry that cloud providers exploit, perhaps unintentionally: they provide compliance documentation that looks comprehensive, but compliance documentation is not the same as compliance substance.

The gap I see most often: incident response ownership.

DORA requires that financial institutions have tested incident response plans for ICT failures. When your cloud provider has a significant outage — and they all have significant outages — the question of who drives the recovery, what your RTO and RPO commitments are, and how you test the failover process is not answered by your provider's DORA documentation. It is answered by your contractual SLA, which you negotiated (or did not negotiate) at contract signing.

The practical steps: audit your cloud provider contracts for RTO/RPO commitments, test those commitments with a documented failover exercise at least annually, and ensure your board understands that DORA compliance for cloud is a contractual question as much as a technical one.

The AI Question: Which Provider Actually Wins

Every cloud provider has an AI platform story. AWS has Bedrock with model choice and enterprise integration. Azure has AI Foundry with Copilot Stack and Microsoft 365 integration. GCP has Vertex AI with what is widely regarded as the strongest MLOps tooling in the market.

For banking AI applications, the choice matters less than most advisors suggest. All three platforms can build production-grade fraud detection, credit decisioning, AML surveillance, and regulatory reporting automation.

What the AI platform comparison misses: the real differentiator is not the model infrastructure. It is the data pipeline and model governance layer that sits above it.

Banks that build AI on cloud provider platforms and treat the provider's managed AI services as the complete solution end up with vendor-controlled model governance — where model updates, retraining schedules, and performance thresholds are managed by the provider rather than by the bank's risk and compliance function.

The banks that get AI governance right build an AI gateway pattern: they use cloud provider infrastructure for compute and model serving, but they own the model governance layer, the data quality pipeline, the decision audit trail, and the risk calibration. The provider is a compute and inference layer. The bank owns the model.

This sounds like more work. It is. It is also the difference between AI that your risk function can audit and explain to a regulator, and AI that your risk function depends on a vendor to explain.

The TCO Misalignment

Cloud providers price migration attractively. Professional services credits, migration support, and training programmes are structured to reduce the apparent cost of initial migration. For a mid-tier bank evaluating a cloud transition, the migration cost looks manageable.

The cost that does not appear in the migration business case is the ongoing operational cost.

Cloud infrastructure costs for banking workloads at mid-tier scale — £5bn–£30bn in assets — consistently come in 2–3x higher than the initial business case projected. The reasons are predictable: security tooling that was assumed to be included is not, compliance tooling requires separate licensing, data egress costs accumulate as integration patterns become more complex, and the specialist financial services support tier costs more than the standard tier.

None of this is hidden. It is in the pricing documentation. It is not in the pitch deck.

The Question to Ask Before You Choose

Before you ask which provider, ask one question: what happens to our data and our operations if this provider raises prices by 40 percent in three years?

If you do not have a credible answer to that question, you are not ready to choose a provider. You need an exit architecture — data portability, workload migration path, and contractual provisions that give you leverage — before you commit.

The banks that have navigated cloud migrations well are the ones that treated cloud providers as strategic partners with commercial interests that align with theirs most of the time, not as utilities whose interests are always aligned. That framing changes the questions you ask at contract signing, the engineering depth you build internally, and the governance you apply to AI model decisions.

Cloud AI for banking is not a technology purchase. It is an architectural commitment with a 10-year horizon. The providers are capable. The capability is not the hard part.

Need an honest assessment of your cloud architecture before you commit? Talk to Raj.

Raj leads Core Banking Technology advisory at Aicura Consulting, specialising in core banking modernisation, cloud migration strategy, and AI governance for financial institutions.