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.
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.
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.
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.
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.
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.
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.
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.
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.
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.