Lessons learned from Silicon Valley Bank's collapse

Following the collapse of Silicon Valley Bank (SVB), there are many questions being asked across the financial and tech space: what caused the bank to collapse? Could it have been prevented? What could the bank itself and indeed its 40,000 customers - mostly in tech – done differently to mitigate risk and minimise impact.

Given SVB’s involvement in funding many fledgling tech start-ups and scale-ups, we look into what the Bank’s failure could have spelled for the viability of these businesses, and indeed the customers they supply into.

This article discusses the lessons learned from this failure, as well as what can be done to protect the fragility of supply chains and the tech ecosystem globally.

Pressure on supply chains

This is the most significant bank failure since the crash of 2008 plus in recent years we've undergone some of the biggest economic shocks in history, a pandemic, war, and a looming global recession.

All these risks combine to put significant downward financial pressure on supply chains. Given these risks, and the fact that no organisation is too big to fail, having risk mitigation and business continuity strategies that would work when tested is critical.

How do regulations come into play?

From a regulatory perspective, financial institutions are some of the most heavily regulated in the world. For example in the UK, The Prudential Regulatory Authority introduced a set of regulations to mitigate the risk of supplier failure for financial institutions.

However, in the US where SVB is headquartered similar regulations are yet to be put into place. Given the sheer size of this market and how closely linked it is to other countries, we require a coordinated global approach to protecting the financial services industry.

Who is impacted?

Let’s remember that the fall-out of SVB’s failure is not limited to banking alone - the Bank heavily invested in tech start-ups and scale-ups. Many of these companies are involved in the development of software, for example, that businesses, other tech companies and consumers alike rely upon, for their daily operations.

However, there is also an argument to be made that organisations have a responsibility to check the resilience of their software supply chains, given these risks. If your supplier disappears overnight, taking its valuable source code, IP or data with it, could your organisation function the next morning? If a financial institution that a software vendor relies on gets into trouble, what’s the plan for the software vendor’s ongoing viability and its commitment to its customers? Both end users and software vendors must take ownership of their resilience, and check for risks within their supply chain and wider network to ensure business continuity.

The development of business continuity and incident management plans that outline how you can respond to and recover from an event that disrupts the ongoing provision of critical functions and services is key.

What does this look like in practice?

There are some simple steps to take. Review your material supplier lists - confirm if said suppliers have a stressed exit plan in place, in the case of their own failure. Add supplier failure to existing scenario tests - even use the unfolding of the collapse of SVB as a test case to see how things would play out.

SVB truly underscores the importance of resilience in every element of your supply chain and tech stack, to ensure business continuity.

However, two things are certain.

1. We can’t always rely on public and private bailouts of failing banks. There is too much at risk, from the companies intimately linked to SVB to the wider networks’ borrowers are part of. One of the only ways to properly mitigate the impact of inevitable future crashes is proper regulation and due diligence globally - both for the financial institutions themselves, and the third parties and suppliers intimately linked to them.
2. Resilience is not a given at any level - from large banks to small software start-ups. You can never predict that the provider of your business-critical software will fail as a result of its primary investor going under - but you can plan for it.