Real Time Treasury Platform Design for Bank Cash Positioning
Seeing the Bank's Cash Position While It Still Matters
Most bank treasury functions can tell you exactly what the cash position was yesterday and roughly what it is now. That was a workable arrangement when money moved on business-day cycles and the only thing that happened overnight was interest accrual.
It stopped being workable when settlement became continuous. A position assembled from files that arrive at cut-off times cannot support a decision at 11 a.m., let alone at 11 p.m. on a Sunday, and the gap between what treasury sees and what is actually happening is now where funding errors and unnecessary buffers live. Building a real time treasury platform is mostly about closing that gap honestly, including being explicit about the places where it cannot be closed.
Why is a daily cash position no longer good enough?
Because outflows became continuous while funding windows did not, so a stale position can be wrong by more than your buffer.
The asymmetry is the whole problem. Payments leave continuously on instant rails, card settlement and collateral calls arrive on their own schedules, and the wholesale funding market that fixes a shortfall keeps conventional hours. A position computed once or twice a day was a reasonable approximation of a slow system. It is a poor approximation of a fast one, and the cost of that approximation shows up as excess buffer that nobody can justify precisely.
What changed on the outflow side?
Continuous settlement removed the overnight pause that daily positioning quietly relied on.
Instant rails operate on a full calendar. The FedNow Service, for example, runs a 24-hour business day on every day of the week including weekends and holidays. That means the balance you are managing changes while your reporting stack is idle, and any process anchored to an end-of-day snapshot is measuring a system that no longer stops. Treasury platforms designed around that snapshot inherit its blind spots regardless of how modern the interface is.
Which decisions does a stale position break?
Funding size and timing, intraday borrowing, sweep decisions, and the judgment call on whether to fund at all.
If the position is hours old, every decision built on it gets padded for uncertainty. Treasury funds more than necessary because the alternative is a shortfall, borrows earlier than needed, and sweeps conservatively. None of those is visibly wrong, which is why the cost stays hidden: it appears as a slightly larger buffer and slightly worse net interest income rather than as an incident. The same dynamic appears wherever a control depends on data that arrives late, which is the argument in this analysis of building earlier cash forecasts when reporting lags.
Funding decisions padded because nobody trusts the intraday number?
What does a real-time position require architecturally?
A consolidated event-based view of every account, with source, timestamp, and confidence attached to each observation.
Coverage and latency differ by source, and a platform that pretends otherwise produces a confident number that is quietly wrong. Model the differences explicitly instead.
| Data source | Typical latency | Coverage | Reliability concern |
|---|---|---|---|
| Your own payment platform events | Seconds | Complete for your flows | None if the event stream is durable |
| Intraday reporting from account holders | Minutes to hours | Varies by institution and product | Gaps, differing formats, missing intraday support |
| Settlement and clearing confirmations | Minutes to end of cycle | Complete but late | Amounts may differ from authorisation |
| Internal transfers between entities | Seconds if instrumented | Often invisible | Frequently the largest blind spot |
| Card and scheme settlement | Daily | Complete | Netted, so intraday detail is unavailable |
| Collateral and margin movements | Event-driven | Complete but bursty | Large values arriving with little notice |
Why is the account balance feed the hard part?
Because you depend on other institutions to report, and their coverage and timeliness are outside your control.
Some account-holding institutions provide rich intraday reporting, some provide it for certain products only, and some provide an end-of-day statement and nothing else. You cannot engineer your way past that, so the platform must represent each account's reporting capability as data: expected update frequency, last observation time, and staleness threshold. Then surface staleness in the interface rather than smoothing over it, because a treasurer who knows a figure is four hours old makes a better decision than one shown a single confident total. Improving coverage becomes a relationship conversation with a technical specification attached, which is a far more productive framing than a complaint.
What is the difference between a balance, a position, and a forecast?
A balance is reported, a position is computed from observations plus known unsettled items, and a forecast is projected.
Keep the three separate in the data model, in the interface, and in the vocabulary your teams use. The position engine should be deterministic: given the same observations, it always yields the same number, and it can explain which observations produced it. The forecast is a different artefact with confidence attached and no authority over the position. Institutions that blend them end up unable to answer the only question that matters during an incident, which is whether a number is something they know or something they predicted. Building this on a stream rather than a nightly load is what makes the distinction operationally possible, and the ingestion patterns in this guide to a data warehouse with real-time ingestion transfer directly.
How should the position engine handle imperfect data?
By storing immutable observations and recomputing the position as a function of them, never by overwriting.
Late data, corrections, and duplicates are normal. Store each observation with its source, its timestamp, the time you received it, and its type, then compute the position from the observation set. That makes a correction a new observation rather than a destructive update, lets you reconstruct what you believed at any past moment, and gives you a defensible answer when someone asks why a decision looked right at the time. It also makes reconciliation between your computed position and the eventual statement a routine automated check rather than an investigation, which is the same discipline behind continuous payment reconciliation.
How should intraday monitoring and forecasting work?
Short-horizon projection driven by calendar, known obligations, and observed intraday patterns, reported alongside supervisory indicators.
The Basel Committee's framework for intraday liquidity sets out seven monitoring tools together with stress scenarios and a reporting regime, with monthly reporting for internationally active banks having started in January 2015. Those measures are a useful design brief regardless of whether they apply to you directly, because they encode what supervisors consider a complete intraday picture: peak usage, available intraday liquidity, throughput, and timing of payments. Build the platform so those measures fall out of the data model natively rather than being assembled quarterly by an analyst, and you get both compliance reporting and genuinely useful operational metrics from the same source.
Which forecast horizon actually matters?
The next few hours and the next few days, not the next quarter.
Intraday treasury is a nowcast problem. What treasury needs is the projected low point today, the expected position at the next cut-off, and the position across the coming weekend, including known obligations, calendar effects such as paydays and month end, and observed drain rates. Long-horizon forecasting belongs in planning and asset liability work, where it connects to the interest rate and behavioural modelling covered in ALM and IRRBB system design. Keeping the two apart prevents a planning model from being pressed into service for a decision it was never built to support.
Reporting supervisory intraday measures by hand every month?
Talk to Digiqt about automating intraday liquidity monitoring
How do you make the platform usable by treasury rather than impressive to engineering?
By designing for one screen that answers today, with alerting that reaches a person who can act.
Treasury teams do not want a data platform, they want the answer to three questions: where am I now, where will I be at the next decision point, and what needs my attention. Build the primary view around those, show staleness and confidence honestly, and make drill-down available without making it necessary. Then design alerting around thresholds treasury actually agreed, delivered to a named on-call role rather than to a shared mailbox, with escalation to someone who has authority to move money. An alert that arrives in an inbox nobody reads overnight is not a control, and the response-path thinking behind instant payment liquidity management applies directly to how those thresholds should escalate.
What controls belong inside the platform?
Threshold alerting, limit monitoring, four-eyes on manual adjustments, and a full audit trail of every position input.
Any manual adjustment to a position should be a recorded, attributed, reversible entry with a reason code, not an edit. Limits by counterparty, currency, and entity should be monitored continuously rather than checked at end of day, and breaches should alert rather than appear in a report. Every input to the position needs lineage back to its source observation, because during an incident the first question is always where a number came from, and the second is who changed it. The regulatory dimension of that requirement is set out in this guide to data lineage and audit trails. Counterparty exposure deserves the same continuous treatment, for the reasons described in counterparty credit in real time.
How should delivery be phased?
Consolidated view first, then automation of feeds, then forecasting, then optimisation.
| Phase | Duration | Deliverable |
|---|---|---|
| Consolidated today view | 2 to 3 months | All accounts in one view with source, timestamp, and staleness |
| Feed automation and coverage | 2 to 4 months | Intraday feeds where available, event ingestion from internal payment platforms |
| Position engine hardening | 2 to 3 months | Immutable observations, recomputation, reconciliation to statements |
| Intraday monitoring and alerting | 1 to 2 months | Supervisory measures, thresholds, on-call alerting |
| Short-horizon forecasting | 2 to 3 months | Nowcast with confidence, calendar effects, weekend projection |
| Optimisation | Ongoing | Sweep automation, funding recommendations, buffer reduction |
Resist the temptation to start with forecasting, which is the phase everyone wants to demo. A treasury team with a trustworthy consolidated view of today and no forecast is in a far better position than one with a sophisticated forecast built on feeds nobody has validated.
Which metrics prove the platform is working?
Position accuracy against eventual statements, feed timeliness and coverage, buffer reduction, and alert quality.
Measure position accuracy by comparing the computed intraday position with the eventual reported balance and tracking the error distribution, not just the average. Report feed coverage as the share of balances received intraday and feed timeliness as observation lag per source, because those two numbers explain most accuracy problems. Track the buffer treasury holds and the trend, since a genuine improvement in visibility should let it fall while incidents stay at zero. And review alert quality honestly: alerts per week, share that led to an action, and time from alert to action. A platform generating alerts nobody acts on is producing noise with a dashboard attached.
The value of a real-time treasury platform is not the real-time part. It is that a treasurer can finally distinguish what the bank knows from what it assumes, and size decisions to the first rather than the second.
Frequently Asked Questions
Why is a daily cash position no longer sufficient?
Because outflows now happen continuously on instant rails while funding windows have not expanded proportionally. A position that is hours old can be wrong by more than your buffer.
What is the difference between a balance, a position, and a forecast?
A balance is what an account holder reports, a position is your best current view including known unsettled items, and a forecast projects future movement. Conflating them is the most common design error.
Where does real-time position data actually come from?
Intraday reporting from account-holding institutions, your own payment platform events, settlement confirmations, and internal transfers. Coverage and latency differ by source, which the model must represent.
What do supervisors expect banks to monitor intraday?
The Basel Committee set out seven intraday liquidity monitoring tools with stress scenarios and monthly reporting for internationally active banks, so build the platform to produce those measures natively.
How do you handle late or corrected balance data?
Store every observation with its source and timestamp, never overwrite, and recompute the position as a function of observations so a correction reprices history without destroying the audit trail.
Should the platform hold the forecast model or just the data?
Both, but separately. Keep the position engine deterministic and auditable, and treat forecasting as a distinct component whose outputs are labelled as projections with confidence attached.
How real time does the position need to be?
Fast enough to act on, which in practice means minutes for balances and seconds for your own payment events, with staleness shown explicitly wherever a feed lags.
What is the fastest way to deliver value?
Start with a single consolidated view of today across all accounts with staleness flags. Most treasury teams gain more from that than from any forecasting sophistication added later.
