Real-time treasury position: an architecture that works with real banks

A real-time treasury position is built by normalizing balances and movements from every bank into one consistent model, reconciling them against your own records continuously, and exposing the result with a clear “as of” timestamp. The hard part was never the dashboard — it’s keeping the underlying numbers correct when the banks disagree with each other and with you.

Why “real-time cash” usually isn’t

Most teams piece their cash position together by hand: log into each bank portal, export balances into a spreadsheet, adjust for payments in flight, and hope nothing moved while you were copying. By the time it’s assembled it’s already stale, and it breaks the moment you add an entity, a currency or a bank. The problem isn’t visualization — it’s that there’s no single, trustworthy source underneath.

The data layer comes first

A position you can trust starts below the UI:

• Ingestion from every source. Bank APIs, statement files (MT940/CAMT), and manual entries, pulled on a schedule and on demand, with retries and gap detection so a missed file doesn’t silently corrupt the picture.
• A normalized model. Every balance and movement maps to one schema: account, entity, currency, value date, status (booked vs. pending). Without this, “total cash” is comparing things that aren’t comparable.
• Continuous reconciliation. The position is checked against your ledger as data arrives, not at month-end, so discrepancies surface while they’re still cheap to fix.
• An explicit “as of.” Every number carries the timestamp and source it came from. “Real-time” without provenance is just a faster way to be wrong.

Multi-entity and multi-currency, honestly

Cross-entity and cross-currency is where naive tools fall over. You need consistent FX handling (which rate, at what time, booked or indicative), clear intercompany visibility, and the ability to see both the consolidated position and each entity on its own. None of that is exotic — it just has to be designed in, not bolted on later.

What good looks like

The outcome is a position your treasurer trusts enough to act on: current, traceable to source, correct across every account and currency, and resilient when one bank feed is late. Forecasting and payment decisions get better because they sit on data that’s actually reliable.

This is core to the treasury systems we build — designed where correctness is non-negotiable, and shipped all the way to production.