On 17 June 2026, at the Google Cloud Summit in London, HSBC announced a multi-year partnership with Google Cloud. The bank gains access to Google's Gemini language models and to the Gemini Enterprise Agent Platform, and intends to move more than 200 artificial intelligence (AI) use cases into production within two years. More than 600 of the bank's applications already run on Google Cloud infrastructure. The headline writes itself: another large-bank deal with a hyperscaler, another billion-dollar promise. Reading the announcement that way misses what is actually interesting about it.

The deal in numbers
200+
AI use cases
The bank's target on Google's Gemini Enterprise Agent Platform
600+
applications live
Already running on the bank's Google Cloud infrastructure
2 years
delivery window
Timeline for the 200-plus prioritised use cases
17 Jun
announced 2026
Unveiled at the Google Cloud Summit in London

Because for the operational leadership of a bank, for Chief Operating Officers and Chief Information Officers, the round numbers are not the news. It is three details that appear with varying prominence in the press release: a value filter that measures every use case against a threshold of 100 million dollars; the fact that HSBC is running a second, countervailing AI partnership in parallel; and a staffing model that redraws the line between vendor and client. These three points decide whether the announcement becomes an operating model or another statement of intent.

In brief

What: Multi-year AI partnership between HSBC and Google Cloud, access to Gemini models and the Gemini Enterprise Agent Platform

When: Announced on 17 June 2026, Google Cloud Summit London

Goal: More than 200 AI use cases in two years, building on over 600 existing applications on Google Cloud infrastructure

Filter: Every prioritised use case must deliver a value contribution of over 100 million US dollars (revenue or efficiency)

Not exclusive: A partnership with Mistral AI for self-hosted models has existed in parallel since December 2025

What was actually agreed on 17 June

The substance of the announcement is more concrete than the usual language of intent. HSBC names three initial deployment areas in which Google technology is to become productive straight away. The first is wealth management, where agents support advisory and analytical processes. The second is financial crime prevention: one use case is to screen the roughly one billion transactions that HSBC monitors each month more efficiently and to halve the time to intervention. The third concerns frontline support, where administrative preparation times are to fall from hours to minutes.

Notable is the role Google takes on in this. It is not about selling software licences, but a cooperation model in which so-called forward-deployed engineers from Google Cloud and researchers from Google DeepMind work directly inside HSBC's teams. Google Cloud chief Thomas Kurian framed this explicitly as a model.

Our partnership with HSBC is a blueprint for the future of the financial services industry. By accelerating AI adoption built with Gemini, our Gemini Enterprise Agent Platform, forward-deployed engineers, and Google DeepMind's research expertise, HSBC is building a more intelligent, resilient, and responsive bank. Thomas Kurian, CEO Google Cloud, 17 June 2026

Group Chief Executive Georges Elhedery framed the agreement from the other side, with a formulation that matters for the later governance discussion: the aim was to give each customer a personalised experience in real time and at scale, while keeping human judgement, decision-making and accountability at the core. The emphasis on ultimate human responsibility is no rhetorical garnish when it comes to agentic systems that act autonomously. It is the point most sensitive to regulation.

The 100-million filter: discipline or window dressing?

The most interesting steering instrument in the announcement is at the same time the least noticed. HSBC prioritises its use cases against a threshold: a project only moves into the top category if it is expected to deliver a value contribution of over 100 million US dollars, whether through additional revenue or efficiency gains. In an industry that has been flooded for three years with pilots that never make it into production, such a filter is initially good news. It forces selection.

Yet the filter cuts both ways. An expected figure is not a realised figure. To lift a use case into the 100-million category, one need only provide an estimate that clears the threshold, and estimates are malleable. Without an independent, downstream measurement of the value actually realised, the threshold remains a prioritisation tool, not a proof of success. The decisive question for the board is therefore not how many use cases pass the threshold, but how many of them can demonstrably show the promised value twelve months later. That back-measurement is the part announcements rarely contain.

Not a hyperscaler, but a portfolio

The most common misreading of such deals is the one about vendor lock-in: a bank chooses one hyperscaler and ties itself in for a decade. At HSBC that picture does not hold. As early as December 2025, the bank had struck a partnership with the French AI company Mistral AI whose logic runs counter to the Google cooperation. Whereas Google Cloud serves the agentic, cloud-native track, Mistral supplies self-hosted models that run on HSBC's own infrastructure and are specifically intended for use cases with high data-sovereignty requirements, for instance in credit, onboarding and anti-money-laundering processes.

HSBC is therefore not making a vendor choice, but running a vendor portfolio. This is not an isolated case but the pattern of the moment. Deutsche Bank is running a Google-Cloud-first strategy with Gemini, Commerzbank is betting on Microsoft Azure. On Wall Street, JPMorgan, Goldman Sachs, Citigroup and Visa have in parallel bet on Anthropic and its Claude models. There is no industry consensus on a single vendor, and that is a deliberate decision. For operational leadership one uncomfortable truth follows: the relevant competence is no longer the selection of the right model, but the management of a heterogeneous vendor base over years, with different contractual regimes, data flows and failure profiles.

Forward-deployed engineers: the Palantir model moves into the bank

The quietly grown core of these partnerships is a staffing model that comes from an entirely different world. The term forward-deployed engineer was coined by Palantir in the early 2010s for intelligence and government clients. Instead of selling software and leaving the client alone with it, the vendor deploys its own engineers directly at the client, where they work with the internal teams on concrete problems. Since 2026, Anthropic and OpenAI have been copying this model for their financial clients, and Google Cloud now brings it to bear at HSBC.

For implementation speed this is a blessing. For governance it is a new category. Vendor staff with deep, permanent access to the internal processes, data holdings and systems of a regulated bank move beyond what classic outsourcing and access concepts capture. Questions arise that no press release answers: what control rights apply to these engineers? How is the outflow of the bank's process knowledge prevented? And what happens to the dependency built up over years when the vendor changes or fails?

The governance gap: DORA and the EU AI Act

At this point a gap opens between the announcement and the European supervisory framework that is addressed in none of the sources reviewed. Two sets of rules are directly affected. The Digital Operational Resilience Act (DORA) requires financial institutions to manage critical information and communication technology third parties strictly, including mastering concentration and fourth-party risks. A model in which a single hyperscaler supplies not only infrastructure but also embedded personnel shifts precisely this concentration risk into a new dimension. In DORA's logic, the forward-deployed engineers are not ordinary service providers.

The second set of rules is the European regulation on artificial intelligence, the EU AI Act. The financial crime use case, which assesses one billion transactions a month and helps decide on interventions, is a candidate for classification as a high-risk system, with the corresponding requirements for transparency, human oversight and documentation. Against this backdrop, Georges Elhedery's emphasis on ultimate human responsibility reads less like a value statement and more like an anticipated compliance position. For European institutions watching HSBC's path, that is the real lesson: the competitive advantage lies not in the fastest deal, but in the ability to build agentic systems that meet the supervisory framework from the outset.

Recommendations for operational practice

For institutions sharpening their own AI vendor strategy, the HSBC deal is less a blueprint to copy than a checklist to think through. Five fields of action stand out.

1. Complement the value filter with a back-measurement

Immediate: Anyone prioritising use cases by a value threshold should, in the same breath, define the process that independently measures the realised value twelve months later. Without this feedback loop, prioritisation discipline turns into a self-confirming culture of estimates.

2. Run vendor strategy as a portfolio, not a choice

Short term: The relevant competence is managing a heterogeneous vendor base. A deliberate portfolio of cloud-native and self-hosted models reduces dependency but raises the demands on contract, data and failure governance. That capability belongs on the competence agenda, not the question of the best model.

3. Contain forward-deployed-engineer access contractually

Before signing: Vendor staff with deep system access need their own control and access regime: defined rights, logging, knowledge retention and an exit scenario. Anyone using this model should not map it onto the classic outsourcing contract, where it does not belong.

4. Reassess DORA concentration risk

Ongoing: A hyperscaler that supplies infrastructure, models and embedded personnel at once concentrates dependency in a way that goes beyond ordinary cloud outsourcing. Mastering concentration and fourth-party risks under DORA should capture this case explicitly.

5. Classify high-risk use cases early under the EU AI Act

Before go-live: Agentic systems in financial crime prevention or credit decisioning are candidates for high-risk classification. Anyone retrofitting transparency, human oversight and documentation only after go-live risks an expensive rebuild. The compliance requirement belongs in the architecture, not the afterthought.

Timeline: HSBC's AI vendor strategy
From the Mistral partnership to the Google Cloud deal
December 2025
Partnership with Mistral AI
HSBC agrees on self-hosted models for use cases with high data-sovereignty requirements, focused on European sovereignty.
17 June 2026
Google Cloud partnership announced
Access to Gemini models and the Gemini Enterprise Agent Platform, target of 200+ use cases in two years, forward-deployed engineers.
2026 to 2028
Implementation phase
Scaling of the three initial deployment areas: wealth management, financial crime prevention and frontline support.
Open
Proof of realised value
The decisive test will be how many of the prioritised use cases demonstrably deliver the 100-million value contribution.
Christian Schablitzki

Christian Schablitzki

Strategy & Management Consultant · Agentic AI expert for financial institutions

More than 20 years in investment banking and derivatives trading, followed by over 10 years advising financial institutions. Currently a Partner at Infosys Consulting in Germany. Certified in Google AI, Generative AI Leader (Google Cloud) and IBM RAG and Agentic AI.

LinkedIn profile →
newsletter
the agentic banker

Keep reading – every 14 days in your inbox.

Capital-markets insights, regulatory updates and AI trends. Concise, well-founded, free of charge.

GDPR-compliant. Unsubscribe at any time.

← Back to overview