-
israel nnanna
- September 10, 2026
A bank can have strong internal controls and still lose access to a critical service because a cloud platform, fintech, payment processor, data provider or AI partner fails. That is the new architecture of operational risk.
Digital transformation has created enormous value by connecting institutions to specialised technology ecosystems. Cloud services reduce infrastructure constraints. APIs accelerate product development. Fintech partnerships extend distribution. Software-as-a-service makes enterprise capability available without long implementation cycles. AI is now pushing that interdependence further into analysis, fraud detection, customer service and automated decision-making.
Yet every connection that improves speed and scale may also create a path through which disruption travels.
Recent regulatory warnings have brought the issue into sharper focus. The Reserve Bank of India highlighted the danger of financial institutions depending on a small number of cloud, technology and model providers. The Financial Stability Board has similarly warned that advanced AI can change the speed, scale and economics of cyberattacks, while common technology dependencies can transmit disruption across multiple firms.
The central management issue is no longer whether a vendor is important. It is whether the failure of that vendor would stop a critical business service—and whether the institution has a tested alternative.
Interconnectedness changes the risk
Traditional vendor management often focuses on the supplier as a legal entity: due diligence, contract terms, service-level agreements, financial stability and periodic performance reviews. Those controls remain necessary, but they are no longer sufficient.
A service may rely on several layers that are invisible to the customer organisation. A fintech may host on one hyperscale cloud provider. Its identity service may depend on another specialist. Its fraud engine may use an external AI model. Its communications may run through a separate platform. A failure in any one of these fourth-party relationships can affect the service purchased by the bank.
This is why a supplier-by-supplier view can create false confidence. Each vendor may appear manageable in isolation, while the combined ecosystem contains a significant concentration point.
From vendor management to dependency management
Dependency management starts with the business service and works backwards. The unit of analysis is not the contract. It is the outcome that customers, markets and regulators rely on.
1. Identify the critical business services
Executives should agree which services must remain available because their disruption would create intolerable customer, financial, operational or regulatory harm. In banking, these may include payments, cash access, digital channels, settlement, customer onboarding, fraud monitoring and regulatory reporting.
2. Trace every material dependency
For each critical service, map the processes, people, applications, data, infrastructure and external providers required for delivery. Extend the analysis to material fourth parties. The result should reveal shared platforms, geographic concentration, single points of failure and dependencies that are not adequately covered by contractual protections.
3. Define impact tolerance
Recovery-time targets are useful, but boards need a clearer business view: how much disruption can customers and the institution tolerate before harm becomes unacceptable? This connects technology recovery to customer, liquidity, revenue, reputation and regulatory consequences.
4. Design strategic optionality
The objective is not technological independence. That would be expensive and, in many cases, impractical. The objective is to create credible alternatives for the dependencies that determine strategic freedom. Options may include a secondary provider, portable data, manual workarounds, alternative payment routes, multi-region deployment, tested exit plans or deliberately retained in-house capability.
5. Test the service, not only the system
A technology component can recover while the end-to-end customer service remains unavailable. Resilience exercises should therefore test severe but plausible scenarios across business, technology, operations, communications, liquidity and third parties. Senior management should see the gaps, decisions and remediation commitments that emerge.
What boards should ask
Operational resilience cannot remain a technology dashboard presented once a quarter. It is a business-model and governance issue. Boards and executive committees should ask:
- Which external providers support our most critical business services?
- Where do several critical services depend on the same provider, platform, geography or technology?
- What material fourth-party dependencies are not visible in our current reporting?
- Where is critical customer and organisational data stored, processed and backed up?
- Which decisions are becoming dependent on externally hosted AI models?
- How long could each critical service be unavailable before the impact becomes intolerable?
- When did we last test a provider failure and demonstrate a viable alternative path?
The Nigerian and African imperative
Nigerian and African institutions are right to accelerate digital transformation. The growth of real-time payments, mobile channels, embedded finance, cloud services and AI can deepen access and improve productivity. But resilience needs to scale at the same pace as connectivity.
In markets where power, telecommunications, foreign-exchange access and specialist technology capability may already be constrained, hidden dependencies can combine with existing infrastructure risks. Institutions should therefore integrate operational resilience into architecture decisions, outsourcing, procurement, product design, transformation governance and board reporting—not add it after deployment.
Cybersecurity seeks to prevent the incident. Operational resilience determines whether the business can continue when prevention fails.
The organisations best prepared for the next disruption will not necessarily be those with the most controls. They will be those that understand the services that matter, can see the dependencies beneath them and have deliberately created another path.
A final question for the executive agenda
Which external dependency could stop our most important business service tomorrow—and what is our tested alternative?
The answer may reveal where the next resilience and transformation investment should go.
How Trimm Solutions can help
Trimm Solutions helps organisations connect operational resilience, process design, technology dependencies, governance and measurable business outcomes. Our support can include critical-service mapping, dependency and concentration-risk assessment, process and control redesign, resilience dashboards, scenario testing and transformation assurance.