Intraday liquidity forecasting in practice

Most corporate cash forecasting answers the question “where will we end the day”. Intraday liquidity forecasting answers a harder and more useful one: where are we right now, and will we clear the next settlement peak without breaching a buffer or scrambling for funding. The distinction matters because funding problems do not happen at end of day. They happen at 10:40 when a large receipt is late, payroll is queued, and the position you are looking at is an hour old.

For banks, this discipline has a regulatory anchor: BCBS 248 expects institutions to measure expected gross inflows and outflows, anticipate their intraday timing, forecast the range of potential net funding shortfalls at different points in the day, and monitor positions against available resources such as central bank reserves, remaining intraday credit, and mobilisable collateral. For corporates there is no equivalent mandate, but the operational logic transfers directly: continuous visibility across entities, banks, and currencies, a policy buffer above expected peaks, and the ability to act before a shortfall becomes a failed payment.

The honest name for what works in 2026 is nowcasting. The target is the current position and the next few hours, refreshed continuously, with an action attached to every threshold. Long-horizon cash forecasting is a different problem with different data, and conflating the two produces systems that are precise about next month and wrong about this afternoon.

The data determines the ceiling

No model outruns its feeds. The practical stack has three layers.

• Bank reporting. camt.052 intraday account reports are the workhorse: balance and transaction updates during the day, in ISO 20022 form, at whatever frequency your banks provide. Where banks expose API balance and transaction endpoints, use them; they deliver balance snapshots, pending items, and booking statuses at lower latency than batch reporting and are the difference between a position that is minutes old and one that is hours old.
• Your own forward book. Scheduled payments, expected settlements, ERP open items, and TMS deal flows are the most predictable part of the day, and they are data you already hold. A large fraction of intraday movement is your own initiated activity; a forecast that ignores it is guessing at things it should simply know.
• Message enrichment. ISO 20022 payment data carries structured counterparty and purpose information that makes far better model features than legacy formats allowed. Counterparty behaviour, purpose codes, and historical timing patterns per payer are the inputs that let a model say “this receipt usually lands by 11:00” with a confidence interval.

The recurring pain points are latency mismatch, where the reported balance lags the real one because payments move faster than reporting refreshes, and timestamp quality, where booking time and value time get conflated and quietly corrupt every timing feature built on them. Sort the semantics out at ingestion, per bank, before any modelling. Fragmentation across ERP, TMS, bank portals, and payment hubs is the other tax; the fix is a single treasury data layer that everything lands in, which is duller than modelling and worth more.

Models: earn complexity, do not assume it

The evidence argues for a benchmark ladder rather than reaching straight for deep learning. Classical baselines, autoregressive and HAR-type models and dynamic panels, are fast, interpretable, and hard to beat: one European liquidity study found a dynamic panel model had the lowest forecast errors, and Diebold-Mariano tests showed no statistically significant advantage for Random Forest, XGBoost, or SVR over it. In other liquidity settings, gradient-boosting ensembles have outperformed both Random Forest and LSTM benchmarks, and the broader literature finds ML pulling ahead mainly where dynamics are nonlinear or regime-dependent, including under stress.

The pattern we recommend: a rules-based forecast first, because it encodes what treasury already knows and gives you a floor; statistical baselines second; then a gradient-boosted model, and sequence models only where timing dependence demonstrably matters. Forecast at multiple horizons, next 15 minutes, end of hour, end of day, because different decisions hang off each. Keep every rung of the ladder running in production and report them against each other, since the comparison is your ongoing evidence that the complex model still earns its keep.

Explainability is not optional here. A treasurer who is about to delay a supplier run or draw an intraday line needs the driver, “the model expects the usual 11:00 concentration sweep to be late”, not a bare number. Feature attribution on tree ensembles gets you most of the way, which is another argument for them over less transparent architectures.

From forecast to action

A forecast that does not change behaviour is reporting. The design step that makes the system operational is mapping predicted buffer breaches to a small menu of actions: sweep from another entity, delay a discretionary payment, accelerate a receipt, draw intraday credit, pledge or mobilise collateral, or reroute a payment to a different bank or rail.

Buffers make this concrete. For corporates the buffer is a policy floor per entity, bank, and currency, sized against timing uncertainty, receipt delays, and payment bunching, and tied to the real calendar of settlement windows, payroll, and supplier cycles. For banks, buffer design is constrained by the actual inventory of usable resources under BCBS 248. Either way, the useful output is probabilistic: not “the 14:00 balance will be X” but “there is a 10% chance the 14:00 balance breaches the floor”, because the buffer exists precisely to absorb the tail, and the action threshold should key off the tail probability.

Tier the responses. High-confidence, low-cost actions such as an internal sweep can trigger automatically; anything that touches counterparties or costs money routes to a human with the forecast, the driver, and the recommended action in one view.

The operating reality

Most of the lifetime cost of this system is not the model. Continuous ingestion has to survive a bank changing its file schedule, a duplicate camt delivery, and a public holiday that shifts every pattern at once. Drift is structural, not incidental: payroll calendars move, counterparties change behaviour, quarter-ends distort everything, and a model trained on calm markets degrades exactly when it matters most. That means monitoring forecast error by horizon and by account, alerting on degradation, and retraining on a schedule plus on trigger.

Failure modes deserve explicit design. When a feed goes stale, the system should degrade to the rules-based forecast and say so, not present a confident number built on old data. Every automated action needs a log of the position, the forecast, the threshold, and the rule version that fired, both for auditors and for your own post-incident reviews. And the cross-functional seam, treasury owning decisions while a data function owns the pipeline, needs a named owner on each side. In our experience the modelling is the quick part; the ingestion, monitoring, and ownership are where intraday liquidity programmes succeed or quietly stop being used.