How Banks Manage Liquidity Day to Day

In practice, liquidity management is a daily routine with a clear rhythm. The day starts with a review of the overnight position, the expected inflows and outflows, and the collateral available. The treasury team sets a plan for the day, including how much intraday credit to arrange, which large payments to prioritise, and what thresholds will trigger an escalation. As the day progresses, the team monitors actual flows against the forecast, watching for large unexpected payments, delayed receipts and queue build up. Regular check ins, often hourly, keep the plan on track. Technology plays a large role. Most banks use a liquidity management dashboard that shows the central bank balance in real time, the queue of unsettled payments, the forecast for the rest of the day and the collateral position. Alerts fire when the balance falls below a threshold, when a large payment is queued for more than a set time, or when a major counterparty is delayed. The dashboard is shared between treasury, payments operations and risk, so that everyone sees the same picture and can act consistently. A business analyst involved in building or improving such a dashboard needs to understand which metrics matter and how quickly they must update to be useful. The human element matters just as much. Liquidity management depends on relationships and communication, both within the bank and with counterparties and the central bank. If a large payment is delayed, a quick call to the counterparty can clarify whether it is a technical issue or a genuine funding problem, and that information changes how the bank responds. If the bank itself is short, early communication with the central bank and with key counterparties can prevent a local problem from becoming a market wide concern. Good liquidity management is therefore part systems, part forecasting and part communication. For example, take a bank that expects to pay out EUR 200 million in salary payments on a Friday morning, while EUR 150 million of incoming funds is due only in the afternoon. The treasury team spots the gap at the start of the day, arranges EUR 50 million of intraday credit against government bonds, and schedules the largest outgoing payments after the expected inflow. When the incoming funds arrive on time, the credit is repaid the same day, and the salary run completes without a single payment queuing. This is the daily routine in action. Forecast the gap, arrange cover early, and monitor until the day closes. Intraday credit is the tool that bridges the gap between morning outflows and afternoon inflows. A bank pledges collateral, usually government bonds, to the central bank, and the central bank grants an intraday overdraft limit against it. The bank draws on the limit when its settlement account runs low and repays it before the close of business, so the credit never becomes an overnight loan. In T2 this works through auto-collateralisation, where the system itself pledges securities held in T2S and releases the credit automatically when a payment needs it. The cost is the haircut on the collateral and any fee the central bank charges, which is far cheaper than holding idle cash all day. When the forecast is wrong, the day gets difficult fast. Suppose a major corporate customer pays EUR 80 million at 10 in the morning, two hours before the expected inflow, and the settlement account falls to EUR 5 million with EUR 120 million of payments still queued. The treasury team must act within minutes: draw intraday credit, call the counterparty to confirm the inflow time, and reprioritise the queue so that time critical payments go first and the rest wait. If the inflow is delayed past the cut off, the queued payments roll to the next day and the bank must explain the delay to its customers. The lesson is that liquidity management is measured in minutes, not hours, and the escalation path must be agreed before the day starts, not improvised during it. A BA building or improving a liquidity dashboard should start from the decisions the dashboard supports. Treasury needs the current balance, the forecast for the next four hours, the collateral available, the queue depth and the largest single payment still to settle. Operations needs the age of the oldest queued payment and the reason it is queued. Risk needs the intraday peak usage and the number of times the bank came close to its limit. Each of these is a data requirement, a refresh frequency and an alert threshold, and the BA must specify all three. A dashboard that refreshes every fifteen minutes is useless for a decision that must be made in two minutes.