Systems Design 101: Friction, Feedback, and Bank Runs
John J. Schaub
Apr 3, 2023
In this post I will discuss some fundamental system design principles and how things like removing friction can manifest instability in large complex systems like the banking system. Specifically I'm going to look at the recent bank run on Silicon Valley Bank (SVB) but these concepts and approaches apply to any system which has suddenly become unstable because friction has been removed.
To start you need to understand that all systems wither they are something as simple as a bicycle or as complex as the global banking system are really made up of interacting components and there are certain analogous behaviours that result when you make changes to these components. This field of study is called Systems Theory and it is one of those things that once you understand it a whole bunch of things in the world suddenly start to make sense. One of the foundational concepts in Systems Theory is the concept of a positive feedback loop. In life and in business there is nothing more powerful and more dangerous then a positive feedback loop. In fact if you have a background in any sort of mechanical engineering you likely have a visceral negative reaction to the term positive feedback loop because in physical systems positive feedback loops almost always end in something breaking or blowing up. If on the other hand you are a business person you think of positive feedback loops as the thing you need to make happen in order to suceed. Both of these perspectives are correct, positive feedback loops are incredibly powerful and powerful tools can go either way. In simplistic terms a positive feedback loop is a situation where thing A causes thing B and thing B in turn causes more of thing A which then causes more of thing B and so on until the system spirals out of control and breaks or explodes. In the case of a bank run thing A is instability at the bank, thing B was depositors pulling their deposits. So in the recent example as soon as word of SVBs instability spread people started pulling deposits which of course caused more instability and more people to pull deposits and about two days later a 200 billion dollar company didn't exist anymore. Again positive feedback loops are not to be trifled with.
Another foundational concept of Systems Theory is friction. In physical systems friction is caused by the interaction of surfaces and pops up to oppose motion. In organizational and software systems we refer to anything that delays movement as friction. Really the two concepts are not exactly analogous but they are close enough that the same term can be used. Wither you are designing an online banking app or an internal combustion engine 'removing friction' as a goal is one of those things that is taken as an obvious good thing. Friction in any process slows things down and wastes energy which is why most people (myself included) hate it with a deep and unrelenting passion and pretty much by default want to eradicate it on sight. The problem occurs though when we forget that slowing the system down is on occasion a good and valuable thing in that it helps prevent the sort of out of control feedback loops that blow things up. The recent bank run on SVB illustrates this problem perfectly. Historically bank runs developed over a matter of days or weeks as word slowly spread and depositors began to go to the effort of moving their funds to institutions they deemed safer. This delay gave the bank executives and the authorities a long time to intervene and help prevent the bank from collapsing. The problem for SVB was that a whole lot of friction has been removed from the banking system in the last few decades and the length of time between when they realized they might have a problem and when the public recognition of that fact made it a very real problem via massive capital outflows was a matter of a couple of days. The feedback loop simply spun up far too fast for any of the legacy systems to intervene and the only available response was to close the bank.
The first major change that brought this collapse about happened outside the banking system. Where historically people got their news through centralized media and informal networks we now have social media. So while previously it could take weeks for news of a banks troubles to spread now a few comments on social media and your entire deposit base becomes aware of the issue. This sort of rapid dissemination of news is a good thing (assuming the news is accurate) but it is a major problem if you are trying to address an issue before knowledge of the issue becomes widespread. The second game changer was online banking and online instant large value transfers. Where historically a company wishing to move a seven figure sum of money might need to at a minimum make a phone call they can now move funds via an app on their phone in seconds. The combination of these two things means that a CFO can read a piece of news (accurate or not) on Twitter and be withdrawing millions from an account in a matter of seconds and broadcasting that fact to other customers seconds later. Even if the original news was completely inaccurate the sheer speed and scale of the withdrawals that can occur become a real problem for a banks liquidity and could easily cause a very solid institution to collapse. In the case of SVB it has been reported that $42 Billion USD in deposits were withdrawn on a single day. There is no Financial Institution in the world that would be able to comfortably meet that sort of capital outflow and once things hit that level there was really no saving SVB.
So how do you address the issue? Having seen similar problems pop up at various times when we removed some friction from a system there are in general five routes to address the problem. First you can do the obvious and put the friction back. This is not the answer anyone wants but putting a simple delay in a process can restore the system to sort of the same level of stability as it was before and will hopefully allow the existing safeguards enough time to work. There is no putting the social media genie back in the bottle so this would need to be a delay on the movement of money in and out of accounts. I can tell you from experience working in the dusty depths of the financial system that artificial delays already exist all over the banking system for a variety of similar reasons. Honestly though artificial delays are an annoyance and really won't stop people from removing funds so while they will make the job of handling a bank failure easier they will not prevent it so this is not a viable avenue in this case.
The second and far more elegant approach is to break the feedback loop. That is redesign the system such that thing A no longer causes thing B or at least causes less thing B so the feedback loop doesn't perpetuate. This is a fantastic approach and should be the default if it is possible but it often is not. Breaking the feedback loop is exactly what the US federal government is trying to accomplish by ensuring all depositors funds were made good quickly. By making sure all depositors got all their money back they make it less likely that people are going to pull funds from the next bank which makes the whole system vastly more stable. That is if you can break the linkage between instability at the bank and deposit withdrawals you can prevent the system from spinning out of control in the first place. These sorts of changes are often imperfect and won't always work but they are certainly worth examining.
The third approach is to modify the system such that the safety factor is much higher. That is rework the system so that it can handle the new much higher stresses placed upon it when the feedback loop spins up. In the case of the banking system this approach would be to require that the banks keep 100% of their deposits liquid to allow them to meet the massive outflows that can result due to the combination of social media and instant large value transfers. This is not a viable solution here for a few reasons the most obvious of which is the fact that it would mean banks would no longer be viable as businesses. In this case you would be curing the disease by killing the patient but in other systems an increased safety factor might work or at least help.
Then there is the fourth approach which is to put in place a negative feedback loop that will step in to balance the positive feedback loop. That is you create a system such that thing A triggers thing C which counteracts thing A more strongly than thing B creates it. There are not always obvious negative feedback loops available and you have to dig pretty deep to come up with something that could be made to work in the case of instability at a bank. As a thought experiment the government could for example guarantee not just to return lost deposits in a bank failure but pay a profit on them as well. In this sort of model when a bank became unstable savvy investors might be incented to move money into the bank knowing that if it did fail the government would give them their money back plus a bonus. This influx of money would offset the capital that was being removed and stabilize the bank. There are however a lot of problems with this approach both in general and in this specific instance. First off in this specific instance this sort of approach is politically unpalatable and wildly too complex for the general public to accept so it is a nonstarter. Second from a general system design point of view you need to be extremely careful when you build counteracting feedback loops as they can exhibit a behaviour known as porpoising which is when a system begins to oscillate wildly because of counteracting forces being applied and removed. To understand this ask yourself what would happen when the influx of money stabilized the bank and made it clear that no bonus would be paid? All the savvy investors would begin to withdraw their funds which would put you in exactly the same situation as previously with the added bonus that the money movements you were causing would be more likely to impact other banks. In general when you have a problem with feedback loops adding more feedback loops is a questionable idea.
The final approach is to upgrade the safeguards so they respond much faster. The problem for the banking system is that the safeguards are government agencies and there is a limit to just how fast those sorts of systems can possibly move. Realistically it is hard to imagine a federal government agency being able to step in a craft a bespoke solution to a complex problem in less than 48 hours which is what it would have taken to save SVB if such a thing was even possible. In order to have an agency act that quickly they are going to need to be operating from an off the shelf play book which means doing exactly what they did, roll in, shut down the bank and insure the depositors get access to the funds within a few days. In the purely mechanical analogy option five is a big red button labeled emergency. Hitting that button will stop the system from exploding but it won't be pretty and will likely cause some collateral damage. Regardless every system needs a big red button marked emergency.
So what is the conclusion? Well first off and it should come as no surprise but complex systems are complex. If you are trying to manage risk for something as complex as a bank you need to be considering the impact of changes that happen well outside your physical four walls. Changes in how your customers communicate or travel or approach risk can all manifest potentially serious problems for you so you need to be keeping an eye on them in real time. In particular you need to spend real effort in looking at feedback loops that exist in your business because feedback loops are both the fastest way to grow or destroy a business. Finally when you are building something like a Fintech company that is going to impact peoples lives in a very serious way you need to understand that if things go wrong the government is going to step in and hit the big red button and when they do so the last thing they are going to be thinking about is the impact to you or your shareholders.