Real-Time Treasury and Intraday Liquidity Architecture (2026)

For thirty years, corporate treasury ran on a comfortable rhythm: pull yesterday’s bank statements in the morning, build a cash position by mid-day, decide funding before the wire cut-off, and go home. Instant payment rails have quietly demolished that rhythm. When money can leave your account at 2 a.m. on a Sunday and arrive at a counterparty in under ten seconds, the end-of-day statement is a historical document, not a control. A real-time treasury architecture is the engineering response to that shift: a continuously updated view of cash across every account, currency, and legal entity, fed by structured ISO 20022 messages and wired directly to the rails that move the money.

This is a systems and architecture analysis, not financial advice. Nothing here recommends a funding, hedging, or investment action.

What this covers: the six-layer reference architecture for intraday liquidity, how ISO 20022 camt messages drive a real-time position engine, the ledger-as-source-of-truth pattern, event ordering and idempotency for payment execution, cash concentration flows, and the specific failure modes that break real treasury systems.

Context and Background

Treasury technology has historically been a batch discipline. The dominant integration pattern was the overnight file: a bank sent an MT940 end-of-day statement, a treasury management system (TMS) ingested it, and analysts reconciled against an ERP. Intraday visibility, where it existed at all, came from MT942 interim reports polled a few times a day. The whole apparatus assumed that liquidity decisions happened at discrete points, bounded by payment-system operating hours and clearing cut-offs.

Three forces broke that assumption. First, instant payment schemes went mainstream and global: FedNow and RTP in the United States, SEPA Instant Credit Transfer across the euro area, UPI in India, and PIX in Brazil all clear and settle in seconds, 24 hours a day, every day of the year. Second, ISO 20022 replaced terse MT messages with rich, structured, machine-readable XML, giving systems enough context to book and reconcile transactions automatically. Third, regulators formalised the expectation. The Basel Committee’s BCBS 248, “Monitoring tools for intraday liquidity management”, defined seven quantitative monitoring tools and made intraday liquidity a supervised risk rather than an operational afterthought.

The combined effect is that the batch cut-off, the organising principle of legacy treasury, is dissolving. If a payment can settle at any second, then your available balance, your intraday credit usage, and your ability to meet the next obligation are all moving targets. Treasury has to be re-platformed as an event-driven system that maintains state continuously, the same architectural shift that transactional banking and exchanges went through a decade earlier. The rest of this article lays out that architecture layer by layer, and is a companion to our deeper pieces on real-time payment infrastructure and ISO 20022 migration.

The Six-Layer Reference Architecture

A real-time treasury platform is best understood as six cooperating layers, each with a single responsibility and a clean contract to its neighbours. The pipeline runs left to right, from raw bank events to executed payments, with reconciliation and controls wrapped around the whole thing as a feedback loop.

Figure 1: The six-layer real-time treasury architecture. Balance and transaction events flow through an ordered event bus into a position engine backed by an immutable ledger, which feeds forecasting and decisioning, which in turn executes against payment rails and loops back through reconciliation.

The diagram shows ingestion (bank APIs, SWIFT host-to-host, ISO 20022 camt messages, and ERP feeds) landing on a partitioned event bus. The bus feeds a real-time cash position engine that maintains intraday balances and writes every state change to an immutable double-entry ledger, the system’s source of truth. The position engine also feeds a liquidity forecasting service, whose projections drive a decisioning layer that automates sweeping, concentration, and just-in-time funding. Decisions are executed against payment rails, and every rail acknowledgement flows back onto the bus. A reconciliation and controls layer continuously compares the engine’s view against authoritative bank data and closes any discrepancies.

In one sentence: a real-time treasury architecture ingests structured balance and payment events onto an ordered bus, folds them into a continuously maintained position on an immutable ledger, and uses that position to forecast, decide, and execute cash movements across rails and accounts within intraday latency budgets.

Layer one is ingestion, and its hardest problem is heterogeneity

Balance and transaction data arrives in wildly different shapes. A modern bank exposes a REST or streaming API that pushes ISO 20022 camt.052 intraday reports and camt.054 debit/credit notifications. An older relationship still runs over SWIFT FIN or a host-to-host SFTP drop delivering batch files. An ERP contributes expected flows: payroll runs, tax payments, receivables due. The ingestion layer’s job is to normalise all of this into a canonical internal event schema without losing fidelity.

The critical design choice is to preserve the bank’s own identifiers, the account servicer reference, the end-to-end ID, the message ID, on every normalised event. These become the keys for deduplication and reconciliation downstream. Ingestion should be thin: parse, validate against the schema, stamp with ingestion time and source, and publish. Business logic belongs in the position engine, not here.

Layer two is the event bus, and ordering is non-negotiable

Financial state is order-sensitive. A debit that overdraws an account, followed by a credit that restores it, produces a very different intraday credit picture than the reverse. The bus must therefore preserve per-account ordering. In practice this means partitioning by account or by entity-currency pair so that all events touching one balance land on the same partition in sequence, while different accounts scale out across partitions.

The bus is also the system’s shock absorber. When a bank floods you with a backlog of notifications after an outage, the bus buffers them so the position engine consumes at a sustainable rate. This decoupling is what lets the architecture stay responsive under load instead of collapsing.

Layer three is the position engine over an immutable ledger

The position engine consumes ordered events and maintains the live intraday balance for every account, currency, and entity. It does not store balances as mutable rows that get overwritten. Instead it appends double-entry postings to an immutable ledger, and the current balance is the fold of all postings for that account. This is the same double-entry, append-only pattern covered in our ledger database architecture piece, applied to treasury rather than to a payment processor.

The immutability matters for three reasons. It gives you a complete, tamper-evident audit trail, which auditors and BCBS 248 reporting both demand. It lets you reconstruct the position as of any past instant, essential when investigating a break. And it makes the system deterministic: replay the same ordered events and you get the same position, every time. That property is the foundation of testability and disaster recovery.

Walk-Through: How a Position Updates in Real Time

To make the architecture concrete, follow a single balance event from a bank notification to an updated treasury dashboard. This is the hot path of the whole system, and its latency budget, typically a few hundred milliseconds end to end, defines what “real-time” means in practice.

Figure 2: The intraday cash-position update path. A bank emits a camt.052 intraday report; the event bus delivers it in order; the position engine deduplicates by message ID, posts a double entry to the ledger, and pushes the revised position to the treasury dashboard.

The bank sends a camt.052 BankToCustomerAccountReport when a transaction books. The bus delivers it to the position engine in account order. The engine first checks whether it has already processed this message ID; ISO 20022’s structured identifiers make this deduplication reliable in a way that free-text MT messages never allowed. If the event is new, the engine derives the double-entry posting, writes it to the ledger, receives confirmation of the balance delta, and pushes the updated position to the dashboard. If the engine detects a gap in the transaction sequence, it can request a camt.054 notification or re-poll for the missing item.

The dashboard is a projection, not the truth

A subtle but important point: the dashboard, the API that mobile treasury apps call, and the reporting warehouse are all read models projected from the ledger. They are eventually consistent views optimised for their consumers. The authoritative state lives only in the ledger. Conflating the two, letting a dashboard hold state the ledger does not, is a classic source of reconciliation breaks. Keep the write path (events to ledger) and the read path (ledger to projections) cleanly separated, a CQRS discipline that pays for itself the first time you need to rebuild a projection after a bug.

Value dating complicates the naive balance

A booked balance is not the same as an available balance. Banks apply value dating: a credit may post today but only become good funds, usable and interest-bearing, on a later value date. The position engine must therefore track at least two balances per account: the ledger (booked) balance and the value-dated available balance. Intraday liquidity decisions run off the available balance, because that is the cash you can actually deploy. camt messages carry value-date fields precisely so downstream systems can compute this distinction; a position engine that ignores them will systematically overstate deployable cash.

Multi-currency and multi-entity turn one balance into a matrix

A global corporate does not have “a cash position.” It has a matrix: entities down one axis, currencies across the other, with accounts as the cells. The position engine maintains each cell independently, then aggregates upward, converting to a reporting currency at reference rates for a consolidated view. Crucially, aggregation for reporting is not the same as availability for use. Cash trapped in a restricted-currency subsidiary cannot fund a payment in another jurisdiction, however healthy the consolidated number looks. Encoding these availability constraints, and not just summing everything into one comforting total, is what separates a real treasury system from a spreadsheet with a live feed.

Forecasting, Decisioning, and Cash Concentration

Visibility is necessary but not sufficient. The value of a real-time position is what you do with it, which is where the forecasting and decisioning layers earn their place.

The real-time liquidity forecasting service projects the intraday cash trajectory of each account: known scheduled flows (payroll, tax, debt service), statistically expected flows (receivables that historically arrive around now), and the confidence bands around them. Under instant rails, forecasting horizons compress from days to hours and minutes, because the buffer that batch timing used to provide is gone. Modern forecasters blend deterministic scheduled items with machine-learning models trained on historical intraday patterns to predict, for example, the low-water mark an account will hit before the next expected inflow. The output is not a single number but a distribution, and the decisioning layer consumes the distribution, not just its mean.

Decisioning turns forecasts into actions: sweep surpluses to a concentration account, fund deficits just in time, or hold a buffer. The canonical action is cash concentration.

Figure 3: A physical cash-concentration flow. Surplus balances in entity accounts are swept by a rules engine to a header account, with an FX conversion step where currencies differ, and the concentrated pool funds a deficit account just in time.

Physical pooling moves money; notional pooling does not

There are two structurally different ways to concentrate cash, and the distinction drives the whole architecture of the sweep engine. Physical pooling actually transfers funds: a sweep debits an entity’s surplus account and credits a header account, producing real payments, real ledger postings, and often real intercompany loans that must be tracked and priced. Notional pooling leaves the money in place and only nets balances for interest calculation; the bank offsets a subsidiary’s overdraft against another’s surplus without moving a cent. Physical pooling gives you a single deployable pool but creates intercompany-loan and tax complexity; notional pooling avoids the transfers but depends on the bank offering the service and on regulations permitting the offset. A real-time treasury platform must model whichever the organisation uses, because the ledger consequences are entirely different: physical pooling generates payment events, notional pooling generates only a nightly interest adjustment.

The sweep engine is a rules-and-thresholds system

In Figure 3, surplus accounts feed a sweep engine that applies target balances, minimum-transfer amounts, and threshold rules. It concentrates funds into a header account, inserting an FX conversion step where a surplus is in a different currency than the header. The concentrated pool then funds the deficit account just in time. The engineering subtlety is that every arrow in that diagram is a payment that can fail, arrive late, or be duplicated, which is exactly why the execution path needs the idempotency machinery described next. Over-automating this loop, letting the engine fire sweeps on a stale position, is one of the most damaging failure modes in the field, and it is covered in the trade-offs section.

Event Processing and Idempotency for Payment Execution

When decisioning decides to move money, the request crosses from your controlled world into external payment rails that offer weaker guarantees than you would like. Getting the execution path right is the single most important reliability problem in the architecture, because a duplicated payment is real money out the door.

Figure 4: The idempotent payment-execution path. A payment intent carries a client-generated key; the system checks whether the key has been seen, reserves funds in the ledger, submits to the rail, and on acknowledgement commits, or on timeout queries status and retries under the same key.

At-least-once delivery meets exactly-once intent

Distributed systems, and the rails you connect to, generally guarantee at-least-once delivery: a message may be delivered more than once, and acknowledgements can be lost. Treasury needs exactly-once effect: a payment must move the money precisely once. You reconcile these with idempotency keys. Every payment intent carries a unique client-generated key. Before submitting, the engine checks whether it has seen that key; if so, it returns the prior result instead of paying again. This is why Figure 4 begins with a “seen key before” decision.

The pattern extends through the whole path. The engine reserves funds in the ledger before submission (so the same cash cannot be committed twice), submits to the rail as a pacs.008 FI-to-FI credit transfer, and waits for acknowledgement within a timeout. If the acknowledgement arrives, it commits and emits a settled event. If the timeout fires, the dangerous case, it does not blindly resubmit. It queries the rail’s status with a pacs.002 payment status report, and only retries under the same idempotency key. Because the key is unchanged, a retry that the rail already processed is recognised as a duplicate and rejected safely.

The timeout ambiguity is the crux

The hardest state in any payment system is “I submitted and did not hear back.” The payment may have succeeded, failed, or still be in flight. Resubmitting risks a double payment; not resubmitting risks a missed obligation. The only safe resolution is to make the operation idempotent and to reconcile against the rail’s authoritative status rather than guessing. ISO 20022’s status-report messages exist precisely to answer this question. A treasury architecture that treats a timeout as a failure and blindly retries will eventually double-pay; one that treats it as an unknown and queries status will not.

Reserve-then-commit keeps the ledger honest

The reserve step deserves emphasis. By debiting a pending or reserved sub-balance the instant a payment is decided, rather than only when it settles, the ledger reflects committed-but-unsettled cash. This prevents the position engine from offering the same cash to two simultaneous decisions. It is the treasury equivalent of an authorisation hold, and it is what makes concurrent decisioning safe. When settlement confirms, the reserve becomes a real posting; if the payment fails, the reserve is released. Skipping this step is how systems accidentally spend the same dollar twice under concurrency.

Intraday Liquidity Concepts the Architecture Must Encode

The architecture only earns its keep if it faithfully models the domain. Several intraday concepts have to be first-class citizens in the data model, not bolted on later.

Intraday liquidity itself is the funds available during the business day to meet time-specific settlement obligations. BCBS 248 defines monitoring tools around it, including daily maximum intraday liquidity usage, available intraday liquidity at the start of the day, and total payments. A treasury system aiming to support that reporting must retain intraday time series, not just end-of-day snapshots, which is another reason the immutable, replayable ledger is load-bearing rather than a nicety.

Nostro and vostro accounts encode correspondent-banking relationships: a nostro is “our account with them,” a vostro is “their account with us.” Reconciling nostro balances in real time, against the correspondent’s camt feed, is one of the highest-value use cases, because trapped or mispredicted nostro cash is expensive. The position engine must model these as distinct account types with their own reconciliation cadence.

Cut-off times used to be hard walls; instant rails are dissolving them, but they have not vanished. Wholesale systems, FX settlement, and many cross-border corridors still enforce cut-offs, and different rails have different operating calendars. The decisioning layer must therefore reason about a per-rail, per-currency, time-zone-aware calendar of when each movement can actually execute. A “24/7” instant rail for domestic retail payments does not mean your cross-border wire clears on a Sunday. Encoding this calendar correctly is unglamorous and absolutely essential.

Liquidity buffers are the deliberately held cushion against forecast error and operational risk. In a real-time system the buffer is dynamic: the decisioning layer can size it against forecast confidence, holding more when the forecast distribution is wide and less when it is tight. This is a systems-design lever, not a recommendation about how large any buffer should be.

Trade-offs, Gotchas, and What Goes Wrong

Real deployments fail in recognisable ways, and naming them precisely is more useful than any success story.

Stale positions from delayed camt messages. The whole architecture assumes reasonably fresh bank data. When a bank’s intraday feed lags, batches its camt.052 reports, or drops messages, the position engine’s view silently diverges from reality. If decisioning acts on that stale view, sweeping cash that is not actually there, you get real overdrafts. The mitigation is to attach a freshness or staleness indicator to every position and to make decisioning refuse to act on data older than a threshold. A position engine that cannot express “I am not confident right now” is dangerous.

Dual-source reconciliation breaks. Treasury sees the same transaction from multiple angles: the ERP that initiated it, the rail that carried it, and the bank statement that confirms it. These sources disagree constantly, on timing, on reference formatting, on FX rounding. Every unmatched item is a break an operator must clear. Underinvesting in the matching engine, the fuzzy, reference-based logic that pairs an ERP expectation with a bank confirmation, quietly buries the treasury team in manual work and erodes trust in the real-time position.

Over-automation risk. The most seductive failure. Once sweeping and funding are automated, it is tempting to close the loop entirely and let the machine move money without a human in it. But automated decisioning amplifies bad inputs: a stale position, a mispriced FX rate, or a forecasting model that has drifted will all execute at machine speed and scale. Guardrails, per-transaction and per-day limits, anomaly detection, and mandatory human review above a threshold, are not optional. The architecture should make the automated path fast and the override path always available.

Model risk in forecasting. ML-assisted intraday forecasting is powerful and quietly fragile. Models trained on historical patterns degrade when behaviour shifts, and a confident wrong forecast is worse than an honest wide one. Treat forecasts as distributions with monitored error, alarm on drift, and never let a point estimate drive an irreversible payment without a buffer sized to the forecast’s own uncertainty.

Dependency on bank API availability. The real-time promise rests entirely on bank connectivity you do not control. APIs have outages, rate limits, and maintenance windows. A resilient design degrades gracefully: fall back to polling when streaming fails, widen buffers when a feed goes dark, and clearly flag which parts of the position are running on stale data. Assuming the feed is always live is the fastest way to a bad decision.

Practical Recommendations

Building toward a real-time treasury architecture is an incremental systems programme, not a big-bang cutover. The pattern that works is to establish trustworthy real-time visibility first, then automate decisions only once the position you are acting on is provably reliable. Every layer of automation should be earned by the demonstrated accuracy of the layer beneath it.

Treat the ledger as sacred and everything else as replaceable. Dashboards, forecasts, and even the decisioning rules will change often; the immutable, double-entry ledger is the invariant that makes all of that change safe. Invest in it first.

A pragmatic sequence to evaluate:

• [ ] Normalise all bank connectivity to ISO 20022 camt where the bank supports it; keep MT and file feeds behind the same canonical event schema.
• [ ] Stand up an ordered, partitioned event bus keyed by account or entity-currency before building any engine on top of it.
• [ ] Make the position engine deterministic and replayable, with the ledger as sole source of truth and dashboards as projections.
• [ ] Track booked, available (value-dated), and reserved balances distinctly; never collapse them into one number.
• [ ] Build idempotent execution with client keys and status-query reconciliation before automating any sweep.
• [ ] Attach a freshness indicator to every position and make decisioning refuse to act on stale data.
• [ ] Add automation guardrails, limits, anomaly detection, and human override, from day one, not after the first incident.

Frequently Asked Questions

What is a real-time treasury architecture?

It is a systems design that maintains a continuously updated view of an organisation’s cash across all accounts, currencies, and entities, and connects that view directly to payment execution. Balance and transaction events, largely ISO 20022 camt messages, flow onto an ordered event bus into a position engine backed by an immutable ledger. Forecasting and decisioning layers consume the live position to drive sweeping, concentration, and just-in-time funding. It replaces the legacy batch, end-of-day model with event-driven state that updates within intraday latency budgets.

How does ISO 20022 enable intraday liquidity management?

ISO 20022 provides structured, machine-readable messages with reliable identifiers. camt.052 delivers intraday account reports as transactions book, camt.053 is the end-of-day statement, and camt.054 notifies individual debit and credit events. The structured fields, message IDs, end-to-end references, and value dates, let systems deduplicate, auto-reconcile, and compute available versus booked balances without human parsing. That richness is what makes near-real-time positioning feasible; the terse legacy MT formats could not carry enough context to automate reliably.

What is the difference between physical and notional cash pooling?

Physical pooling actually transfers funds, sweeping surplus balances from entity accounts into a header account, which produces real payments, ledger postings, and often intercompany loans to track. Notional pooling leaves the money in place and only nets balances for interest purposes; the bank offsets one account’s deficit against another’s surplus without moving cash. Physical pooling creates a single deployable pool at the cost of intercompany and tax complexity; notional pooling avoids transfers but depends on bank and regulatory support. The architecture must model whichever is used, because their ledger effects differ entirely.

Why is idempotency critical in treasury payment execution?

Because payment rails typically guarantee at-least-once delivery while treasury needs exactly-once effect: money must move precisely one time. Acknowledgements can be lost, leaving the ambiguous “submitted but no reply” state. Idempotency keys resolve this: each payment carries a unique client key, the system checks whether that key was already processed, and any retry under the same key is recognised as a duplicate and safely rejected. On timeout, the system queries the rail’s pacs.002 status rather than blindly resubmitting. Without this, systems eventually double-pay.

How does BCBS 248 relate to real-time treasury systems?

BCBS 248, the Basel Committee’s “Monitoring tools for intraday liquidity management,” defines seven quantitative tools, including daily maximum intraday liquidity usage and available intraday liquidity at start of day, that supervised banks report on. Meeting these obligations requires retaining intraday time series of positions and payment flows, not just end-of-day snapshots. That reporting demand is one reason the architecture centres on an immutable, replayable ledger: it lets an institution reconstruct its intraday liquidity usage at any point in the day for regulatory monitoring.

What are the main failure modes of a real-time treasury architecture?

The recurring ones are stale positions from delayed or dropped camt feeds, reconciliation breaks when ERP, rail, and bank views of a transaction disagree, over-automation that executes bad inputs at machine speed, model risk when forecasting drifts, and dependency on bank API availability. Each has a systems mitigation: freshness indicators that let the engine refuse stale data, a robust fuzzy matching engine, automation guardrails with human override, forecast-drift monitoring with uncertainty-sized buffers, and graceful degradation to polling when live feeds fail.

Further Reading

• Real-time payment infrastructure: FedNow, UPI, SEPA Instant — the rails that collapse the batch treasury model and their settlement mechanics.
• ISO 20022 migration and payments architecture (2026) — the message standard behind camt and pacs, and how to migrate to it.
• Ledger database architecture and double-entry (2026) — the immutable, append-only ledger pattern that underpins the position engine.
• BCBS 248, Monitoring tools for intraday liquidity management (BIS) — the primary regulatory source defining the seven intraday monitoring tools.
• ISO 20022 Bank-to-Customer Cash Management message definitions (ISO 20022.org) — the authoritative specifications for camt.052, camt.053, and camt.054.

By Riju — about