A banking report may be accurate for yesterday evening and still provide insufficient support for a crisis decision today. Liquidity therefore makes me connect the business meaning of information with its timeliness, availability and use. The objective is not merely a faster spreadsheet. Decision-makers need to know what can actually be used, when and under which restrictions. This article presents my proposed analytical approach, not a claim of professional experience managing a bank's liquidity.
The real case: Silicon Valley Bank in March 2023
Silicon Valley Bank in California experienced deposit outflows above $40 billion on 9 March 2023 and was closed on 10 March. The Federal Reserve's April 2023 review described risk-management weaknesses, business-model concentration and failures of internal liquidity tests. It also identified changes in assumptions that reduced measured risk rather than addressing the underlying exposure. This was not simply a reporting-speed problem, and I would not present it as one.
What I infer, and what I do not
My conclusion is not that a new dashboard can solve every banking problem. A faster output based on an inappropriate assumption may deliver false reassurance more quickly. I would separate observed conditions, modelling assumptions and management decisions. Data checks can validate sources and calculations; evaluating a risk scenario requires specialist knowledge and the responsible function's judgement.
I would ask whether an improved indicator reflects a change in circumstances or a change in measurement. Reducing an assumed outflow may improve the reported buffer without adding any usable resources. I would want the effects of new data, methodological changes and completed actions shown separately. This supports a more precise discussion of what has actually changed.
A hypothetical example: available does not always mean available now
Imagine a fictional bank reporting CZK 20 billion in potential liquidity sources. Eight billion can be used immediately, seven require a transaction, and five have a restriction whose release is unverified. A single total of twenty billion may be mathematically correct while remaining incomplete for the question of what payments the bank can settle today.
If today's hypothetical outflow is ten billion and the only unconditionally available resource is eight billion, the bank needs evidence that another two billion can become available in time. The second group does not automatically cover the gap. Timing, asset eligibility, counterparty availability and operational readiness matter. These figures neither describe SVB nor represent a regulatory calculation.
I would organise the source information by amount, availability time, restriction, owner and last verification evidence. A separate schedule would show the timing of outflows. This reveals a time mismatch rather than a disagreement about the overall total. Specialists responsible for liquidity, risk and management decisions would assess the available responses.
How I would handle uncertainty
My proposed crisis view would distinguish confirmed values, informed estimates and unverified items. An estimate is not necessarily unusable, but its basis, owner and expiry conditions should be visible. Two decimal places should not conceal the fact that the source does not support that level of confidence.
I would check for double counting across data connections. An asset shown as an available resource may also be committed elsewhere. Separate teams can maintain individually accurate lists while the combined total overstates what the bank can do. Checking identifiers, restrictions and dependencies is concrete analytical work that supports specialist judgement without replacing it.
The last update time also matters. One input may be continuously available, another dependent on overnight processing and a third on manual confirmation. I would show these differences rather than attach the report-generation time to every item. The time a document was produced is not the same as the reference time of its underlying information.
A scenario is a question, not a forecast
I would read a stress scenario as a way to investigate conditions, not as a claim about what will certainly happen. It helps identify when existing arrangements become insufficient and which actions remain feasible. When specialists change an assumption, I would want the rationale and a comparison with the previous version. Sensitivity to a few key parameters may reveal more than a single headline result.
In the hypothetical example I would compare slower and faster outflows with the same overall volume. This can expose an operating constraint hidden by a daily total. I would also examine a temporarily unavailable source and a simultaneous delay in information delivery. These are proposed tests of a process, not assertions about an undisclosed bank's condition.
From information to an executable decision
A rehearsal should cover the whole chain: detection, data validation, impact assessment and decision. If every role must independently request the same missing information, handover delays may outweigh the benefit of automated calculations. I would prepare a short decision record separating facts, uncertainties, options and the next update time.
I would also test whether an agreed action can be executed. A formal funding option does not establish that accounts, documents, permissions and contacts are ready. A proportionate practical exercise may reveal reliance on one person or a missing operating link. This is not necessarily a model defect: it is a distinct readiness issue that the model's result should not conceal.
Keep the evidence proportionate and usable
During a fast-moving event, collecting every possible detail can become a delay in itself. I would agree a minimum decision dataset in advance, with clear definitions and routes for escalation. Additional analysis should answer a specific uncertainty rather than expand the report indefinitely. A concise account of a known limitation can be more useful than a large document that arrives after the relevant decision window.
After the exercise, I would compare expected and actual preparation times. Did the source arrive when promised? Was the restriction understood consistently? Could another trained person reproduce the result? The review should produce practical changes to ownership, access or validation, with a date for retesting. A successful exercise is evidence about the tested conditions, not a guarantee for every future crisis.
Summary and recommendations
The SVB case makes me cautious about conclusions based on one reassuring indicator. I would separate current data, modelling assumptions and executable actions. Each liquidity source needs visible conditions and timing, while important conclusions need an explicit account of uncertainty. Analytical precision includes saying clearly what is not yet known.
My proposed contribution is to validate inputs, trace their relationships and communicate findings to specialists. The output should help a timely decision rather than manufacture confidence. I would therefore rehearse not only producing the report, but also the process that is supposed to follow it, and check that both can work within the time available.