[Want to get automatic updates on ethel cofie’s blog post of Africa, technology, ecosystems and doing business in Africa sign up here ]

When Every Bank Uses the Same Technology Providers, Is It Still an Institutional Risk?

Five banks. One failure point. Who is actually managing the risk?

Picture five banks. Different customers, different apps, different continuity plans. On paper, five independent systems.

Now look underneath. Their digital channels sit on the same cloud. Their technology vendors run on the same cybersecurity platform. Their data moves across the same network. And the “alternative provider” named in each of their disaster-recovery plans turns out to depend on the same handful of services as the primary.

How many genuinely independent banking systems are in that room? The honest answer is often: fewer than five. Sometimes: one.

Let me be clear about what this is not. It is not an argument against cloud, specialist vendors, or outsourcing. Shared infrastructure buys African banks security, scale, and skills that almost none of them could build alone, and frankly, better resilience most days than an in-house server room in a load-shedding economy. Interdependence is the modern financial system; there is no going back, and no reason to want to.

The governance problem appears at a specific seam: : when many independent institutions quietly converge on the same underlying infrastructure, who is counting the exposure that no single institution can see?

The concentration is measurable, and it is steep

Start with the layer everything else sits on. In the third quarter of 2025, the three largest providers accounted for approximately 63% of global enterprise spending on cloud-infrastructure services, with the largest alone accounting for close to 30% (Synergy Research Group). That is not five suppliers competing for a bank’s business. For the workloads that matter, it is a very short list.

In Africa the funnel is tighter still. The continent holds approximately 18% of the world’s population but under 1% of global data-centre capacity, and the cloud regions African banks can access are concentrated in a small number of physical locations, many of them in South Africa. This concentration increases the possibility that apparently separate institutional services ultimately depend on common locations and infrastructure.

None of this means banks have been careless. Quite the opposite.

 The Central Bank of Kenya’s 2025 Survey on Third-Party Technology Service Providers shows an industry that is actively managing: banks updating contracts, tightening monitoring, treating cyber and data-privacy risk as top-tier concerns (named critical by more than 70% of respondents). The same survey is candid about the gaps: around 26% of banks lacked systems to continuously monitor their third-party providers, against a backdrop where detected cyber threats in Kenya rose 146% in a single year, from 3.5 billion to 8.6 billion events.

The point is this: good vendor management inside every bank does not add up to resilience across the banking system. Each institution can run its own house perfectly and still, collectively, be leaning on one wall.

The regulatory question is moving from the contract to the dependency chain

The old supervisory model asked three questions about a contract: Has the bank assessed the supplier? Does the contract protect us? Do we have an exit? Sensible questions. Institution-level questions.

The frontier has moved from the contract to the dependency chain, and it has moved fast:

• The Basel Committee’s Principles for the Sound Management of Third-Party Risk, published in December 2025, superseded the 2005 outsourcing framework for the banking sector. The principles place responsibility on banks to identify and manage their own third-party concentration, while requiring supervisors to assess how those dependencies aggregate across institutions and the wider banking system.
• The Financial Stability Board’s 2023 toolkit on third-party risk pushed authorities toward subcontractors, nth parties, substitutability, and cross-institution interconnections: the plumbing beneath the plumbing.
• The clearest signal is the European Union. On 18 November 2025, EU regulators used their powers under the Digital Operational Resilience Act (DORA) to formally designate 19 “critical ICT third-party providers”, a list that names the largest cloud operators directly, and place them under direct supervisory oversight. The UK is building a parallel “critical third parties” regime, with a memorandum of understanding already signed to coordinate across the two.

Read that again, because it is the whole argument in one fact. Regulators elsewhere have stopped treating the largest providers purely as private vendors to individual firms and started treating them as financial infrastructure to be supervised. The relevant question is no longer whether a provider is important to one bank. It is whether the provider, or the data centre beneath it, has quietly become important to the functioning of several institutions at once.

The same provider is two different risks, depending on where you stand

At the institutional level, a provider is a concentration problem because it supports several of a bank’s critical services and migrating away would be painful. That is a board and management matter.

At the system level, the same provider is a different animal. If most institutions use it, and the notional alternatives could not possibly absorb everyone migrating at once, then its failure is not a bank’s problem. It is the market’s. That is a financial-stability matter.

For the bank, it is third-party concentration risk. Across the market, it is a financial-stability dependency. One provider; two risks; two different people who ought to be losing sleep over it.

Supplier diversity is not infrastructure diversity

This is where registers lie to us.

Bank A contracts Provider X. Bank B contracts Provider Y. Bank C contracts Provider Z. Three names, three relationships, a tidy picture of diversification. But if X, Y, and Z all host their critical workloads in the same cloud region, or the same building in the same city, then at the infrastructure layer there is one dependency wearing three logos.

A bank can hold three fallback providers on paper and still have zero genuinely independent fallbacks in reality. South Africa hosts nearly half of Africa’s installed data-centre capacity, with much of that capacity concentrated in a limited number of major facilities and metropolitan areas. The “diversity” above them can therefore resolve to the same concrete floor below them. Supplier diversity is a procurement fact. Infrastructure diversity is an engineering fact. They are not the same fact, and only one of them saves you at 3 a.m.

What African regulators have already built, and the layer that’s missing

Africa is not starting from zero. The foundations are real:

• Institutional accountability. Ghana’s 2024 Outsourcing Directive makes it explicit that the bank remains accountable even when delivery is external. You can outsource the work; you cannot outsource the responsibility.
• Cloud-specific scrutiny. The Bank of Mauritius requires institutions to look past the contract to portability, interoperability, and genuine contingency for material cloud services.
• Market-wide curiosity. The Central Bank of Kenya’s dedicated provider survey is itself an admission that common dependencies cannot be seen from any one bank’s records.
• Systemic framing. The South African Reserve Bank explicitly names concentration, vendor lock-in, and the risk of cloud outages cascading through the national payment system.

That is a serious first layer. The gap is not architectural intent. It is aggregation. These are still, overwhelmingly, institution-by-institution controls. Nobody is visibly stitching them into a single, consolidated view of what the financial system as a whole is standing on. The World Bank has made a related point about African cloud governance more broadly: fragmentation across separate agencies weakens both oversight and the continent’s bargaining power with global providers, and it has urged governments toward a single coordinating lead. The banking sector needs the same instinct.

What a board must actually ask

A bank board cannot map the financial system. But it can, and should, refuse to accept comfortable answers from management. The standard dashboard asks about uptime, cyber, and compliance. When your dependency is part of a national-scale concentration, the questions have to get harder:

• “We use multiple providers.” Do those providers sit on genuinely separate underlying infrastructure, or on the same region and the same data centre?
• “We have a fallback supplier.” Is it technically live and rehearsed, and could it absorb the load during a market-wide disruption when everyone reaches for their fallback at once?
• “The contract gives us exit rights.” Can we actually move our data and operations inside an acceptable window, or is that clause theatre?
• “The provider has a recovery plan.” Has that plan ever been tested against a simultaneous failure hitting several of its major financial clients together?

The board governs the bank’s dependency. Only the regulator can determine whether that dependency has become systemic.

The SHARED lens

Here is a practical way to keep both altitudes in view at once. Run each critical provider through SHARED:

• Service criticality (S): Would an interruption materially hit market access or customer confidence?
• Hidden concentration (H): Do “different” suppliers trace back to the same infrastructure or the same location?
• Availability of substitutes (A): Are the alternatives genuinely independent and operationally ready, today, not in a slide?
• Reach across institutions (R): How widely is this provider used across the whole system?
• Exit and recovery feasibility (E): Could affected institutions actually recover within an acceptable period?
• Disruption propagation (D): Could one failure spread across firms, sectors, or borders?

A bank should run SHARED across its own architecture. A regulator has to run it across the market. Same six letters, two different maps.

The African question !

Now scale the problem up to where Africa is actually heading: regional interoperability, cross-border payment integration, continental digital infrastructure. The ambition is right. But it sharpens the exposure, and it lands on a governance void:

What happens when a single provider supports banks in five African markets at once? Which regulator sees the aggregate: the Ghanaian one, the Kenyan one, the Nigerian one, or none of them? Who coordinates a resilience test that spans borders? And how does a national exit plan mean anything when the provider, the region, and the data are regional or global by design?

The EU answered its version of this by naming its critical providers and placing them under shared oversight. Publicly, African jurisdictions do not yet appear to have operationalised an EU- or UK-style regime for directly designating and overseeing technology providers because of their system-wide importance. Building such a framework here would require not only technical intelligence, but also legal authority, common information standards and cross-border coordination among central banks whose mandates remain principally national.

Shared efficiency creates shared exposure. And shared exposure cannot be governed by a stack of separate contracts between individual banks and their suppliers, however well each contract is drafted.

So the question stands, and it is not rhetorical. When every bank is diligently managing its own relationship with the same small set of providers, who is managing the dependency they have built together?