HSBC transformation: the architecture behind the ambition

A public, outside-in view of selected HSBC changes and what they imply for enterprise architecture.

My first encounter with @HSBC was around 20 years ago, in London, when I was a student. I managed to open a student account online and only visited the branch a few days later to deposit cash.

At the time, coming from a branch-based banking experience, this felt unusually digital. In a good way, of course.

Today, I look at it differently. I work as a product owner for corporate finance platforms, so my curiosity is no longer only about whether a bank has digital services. The more interesting question is how a large, complex organisation actually transforms without turning every good idea into another disconnected system.

HSBC is an interesting case, but not because every public initiative is automatically impressive. Public sources show a bank is trying to simplify its organisation, standardise parts of its platform landscape, adopt distributed ledger technology, and scale AI across internal workflows. At the same time, public sources do not prove that the full transformation is complete or that the technology estate is simple.

That distinction matters.

A transformation story is easy to write. A transformation architecture is harder to build. Extracting the value is an ultimate test.

How I read the evidence

To make this less abstract, I prepared a simplified HSBC enterprise architecture diagram based on publicly available information. It is not an official HSBC model, and it should not be read as a complete representation of the bank’s internal architecture.

The purpose of the diagram is more practical: to test whether selected public initiatives can be connected into a coherent architecture story. In other words, if HSBC says it wants to become simpler, faster, and more digital, where does that show up? In the operating model? In business capabilities? In application platforms? In data objects? In integration patterns?

If those questions cannot be answered, behind the transformation may still be just a portfolio of enhancements rather than a fundamental shift.

The diagram connects strategic intent to business domains, capabilities, processes, application services, data objects, technology services, and external partners. It is deliberately simplified, but it helps move the discussion away from isolated initiatives and towards the enterprise architecture behind them.

Architecture diagram (Lucid version):

Figure 1. Simplified HSBC enterprise architecture view based on public information and selected examples. It is not official or exhaustive.

1. Operating model simplification: fewer boxes should mean clearer ownership

HSBC’s Annual Report 2025 says that since 1 January 2025, the Group has operated through four businesses: Hong Kong, the UK, Corporate and Institutional Banking, and International Wealth and Premier Banking. The same report says this was intended to simplify the organisational structure and accelerate delivery against strategic priorities. It also refers to becoming a “simple and agile organisation” and reports USD 1.2bn of annualised impact from cost-saving actions taken during 2025.

What is done: HSBC has simplified its top-level business structure and linked this to cost reduction, faster decision-making, and a more focused strategy.

What it implies: This is not only an org chart change. If it works, it should simplify decision rights. It should make it clearer which business owns which capabilities, which platforms deserve investment, and where duplication should be removed.

What it supports: The stated goal is organisational simplification. Architecturally, the real value would be clearer capability ownership and fewer competing local priorities.

The risk is that the structure changes faster than the technology estate. Large banks often reduce management layers without reducing the number of processes, controls, applications, and data definitions underneath. So the useful question is not “did HSBC reorganise?” It did. The better question is whether the new structure changes platform ownership and investment decisions.

From an EA perspective, this is where the operating model and application landscape need to meet. A simplified structure should eventually show up as fewer duplicated platforms, clearer service ownership, and cleaner investment governance.

2. HSBC Trade Solutions: trade finance starts looking like a domain platform

The strongest architecture signal I found is in trade finance. A Euromoney article describes HSBC Trade Solutions as a front-to-back trade platform supporting letters of credit, guarantees, trade loans, and supply-chain finance from a single digital core. It also says HTS is deployed across 25 markets and supports API and host-to-host connectivity within a unified data architecture.

What is done: HSBC has deployed a trade-finance platform across multiple markets, with several product types supported from one digital core.

What it implies: This points to a common global platform pattern rather than separate local trade-finance systems per country. The API and host-to-host options also suggest that HSBC is not only digitising screens. It is building integration patterns that can connect to corporate clients on their terms (read: flexibility).

The phrase “unified data architecture” is important. It suggests a more serious change than workflow digitisation. Trade finance has historically been document-heavy, local, and process-fragmented. A unified data layer implies that HSBC is trying to standardise how trade data is captured, reused, and exposed across products and markets.

What it supports: This supports standardisation, integration, straight-through processing, and faster product change.

This is a more advanced architecture pattern than simply adding a portal. A portal can make the front end look modern while the underlying process remains fragmented. A front-to-back platform is different. It creates the possibility of common services, reusable interfaces, consistent data, and better scalability.

N.B. The Euromoney article is sponsored by HSBC, so I would not treat it as independent proof of implementation quality. But the architecture facts it contains are useful; taken together, they point to “platformisation” rather than feature-led digitisation.

3. Payments: the change is not only in payment speed, but also in information speed

HSBC’s cash-management article with Tom Halpin makes a point that is easy to miss: payment velocity matters, but payment information velocity is just as important. The same article says HSBC is focusing on integrating back-office data with clients’ ERP systems via APIs, allowing clients to use real-time ( quote: near-instantaneous) information for reconciliation and planning.

That is more interesting than a generic “faster payments” message.

What is done: HSBC is positioning payments around client workflow integration, data visibility, ERP connectivity, and reduced operational friction. In a separate American Banker article, Halpin is also linked to HDSU, a blockchain platform connecting digital payment rails with traditional fiat settlement systems.

What it implies: Payments are being treated as an information architecture problem, not only a transaction-processing problem. That is the right direction. In corporate banking, the pain is often not the payment itself. The pain is in matching the payment to invoices, conditions, approvals, exceptions, reporting, and internal controls.

If HSBC is integrating payment data with client ERP systems through APIs, the architectural pattern is clear:

Banking Service > API Layer > Client Workflow > Reconciliation and Decision Data.

What it supports: This supports client experience, operational efficiency, API-led banking, and better integration between bank systems and corporate systems.

The HDSU example adds another angle. If a payment depends on conditions being met, a shared-state model can make sense. That does not mean blockchain is always the right answer. It means the architecture should start from the workflow problem, not from the technology label.

This is where HSBC’s “painkillers before vitamins” idea is simple and elegant. A good enterprise architecture should remove friction from the process before adding another feature to the channel.

4. HSBC Orion: tokenisation is a market-infrastructure capability, not just a blockchain story

Digital assets are another area where it is easy to apply DLT, yet to overstate the case. Tokenised bonds are still a small part of the overall market. The Reuters report on the UK digital gilt pilot says the UK selected HSBC’s Orion platform for the pilot (though still impressive), but it also notes that the timing of issuance was unclear, which is sort of flirting with the idea.

That caution is important.

What is done: HSBC Orion has been used as a platform for digital bond issuance, and it has been selected for the UK digital gilt pilot. HSBC said Orion had enabled more than USD 3.5bn in digital bond issuance globally.

What it implies: Orion looks less like a one-off blockchain experiment and more like a reusable digital assets platform. The relevant architecture is not just “distributed ledger”. It includes issuance, register, custody, lifecycle events, controls, settlement, and regulatory auditability.

What it supports: This supports capital markets innovation, regulatory resilience, transparency, and potential settlement efficiency.

In the EA diagram, Orion does not sit as a technology box floating on its own. It belongs in a business context: Securities Services, tokenised securities issuance, tokenisation service, tokenised securities register, and distributed ledger infrastructure.

That is the difference between a technology experiment and a capability. The experiment proves that something can be done. The capability proves that it can be reused, governed, controlled, and connected to the rest of the operating model.

What these changes tell us about HSBC

Taken together, these examples suggest a few things.

First, HSBC is trying to reduce organisational complexity. The operating model change is the visible part. The harder part is whether it simplifies ownership of platforms, processes, and data.

Second, HSBC is using platform patterns in selected domains. HTS is the clearest example because it combines multiple markets, multiple products, API connectivity, and a unified data architecture.

Third, HSBC’s payments work suggests a shift from transaction execution to workflow integration. That matters because corporate clients do not only need money movement. They need visibility, reconciliation, controls, and data.

Fourth, HSBC Orion suggests that HSBC is treating digital assets as a potential part of future capital markets infrastructure, not just as a standalone innovation experiment. At the same time, tokenised bonds are still an emerging market, so this should not be read as proof of large-scale adoption.

I would, of course, also put AI in the “watch closely” category. HSBC’s Annual Report says it has more than 100 GenAI solutions in use, that around 85% of colleagues have access to its HSBC Productivity Suite, and that more than 31,000 engineers use an AI-enabled coding assistant. Reuters has also reported on HSBC’s partnership with Mistral AI. This is directionally significant, but it is still harder to assess from the outside because many benefits are internal. The real test is whether AI becomes embedded into controlled business processes, not whether many people have access to tools - we all do.

What this means for enterprise architecture

The common thread is standardisation and integration.

That does not mean everything becomes one giant global system. A bank the size of HSBC will always need justified local variation, regulatory adaptation, and product-level flexibility. But the architecture direction seems to be moving toward common platforms where commonality matters, and configurable services where flexibility is genuinely required.

Using the operating model framework developed by Ross, Weill, and Robertson at MIT CISR, this looks closer to a unification model: high process standardisation, high data integration, but still with controlled local variation where the business or regulatory context requires it.

A local system can be fast for one market and expensive for the enterprise. A global platform can be efficient, but too rigid if poorly designed. The hard part is finding the middle ground: common data, common services, standard interfaces, clear ownership, and controlled variation where there is a real business reason.

That is where enterprise architecture becomes practical.

What I would watch next

There are a few indicators that would show whether HSBC’s transformation is becoming architectural rather than initiative-led.

Application rationalisation. If HSBC continues to reduce (read retire) non-strategic systems while scaling common platforms, that would support the simplification story.

Platform reuse. HTS, Orion, payment APIs, and AI services are more valuable if they become reusable enterprise capabilities, not isolated success stories.

Operating model alignment. The four-business structure should make investment decisions clearer. The test is whether delivery following a decision will become clearer as well.

Measurable outcomes. The most credible transformation examples are those where HSBC can show cycle-time reduction, lower manual work, better risk detection, lower support cost, or better client experience. Over time, there is also a broader external test: whether these changes are recognised by the market and reflected in HSBC’s valuation. The HSBC share price is not a clean measure of transformation on its own, but it is still one useful signal of whether investors believe the bank is becoming simpler, more efficient, and more valuable.

Final thought

HSBC looks like a useful transformation case because the public evidence shows change at several levels: organisation, trade finance, payments, digital assets, and AI. But I would not frame it as a clean success story. The more balanced view is that HSBC is showing some of the right architectural patterns, while the harder execution questions remain open.

For me, the interesting part is not the technology label. It is the connection between business intent and delivery reality.

A bank, or any other enterprise, can buy tools, launch platforms, and announce partnerships. The difficult work is making sure each change has a clear owner, a clear data model, a reusable platform logic, a sensible integration pattern, and a measurable business outcome.

That is where product and architecture work becomes useful. Someone still needs to sit between strategy and delivery, challenge where complexity is being added, and make sure transformation does not become a collection of disconnected initiatives.

Selected public sources

HSBC Annual Report and Accounts 2025

Euromoney article on HSBC Trade Solutions

HSBC cash-management article with Tom Halpin

American Banker profile of Thomas Halpin and HDSU

Reuters report on HSBC Orion and the UK digital gilt pilot

Reuters report on HSBC’s Mistral AI partnership