Why Treasury Liquidity Looks Like a Digital Twin Problem

A recent job advert for a data engineering role in global treasury described an ambitious liquidity management capability. It called for intraday visibility, fine-grained controls, forecasting and automated positioning across currencies and jurisdictions.

It didn't mention digital twins. It made me ask whether the concept was a particularly good fit for a liquidity network.

This article isn't an attempt to infer the hiring company's architecture. The role described a hard operational problem. The model below is my own extrapolation from it.

My practical liquidity experience comes mainly from bank ALM and liquidity data. I wanted to understand what changes once treasury teams recalculate positions and make funding decisions throughout the day.

That left a simple question:

What must a treasury system understand before it can safely recommend moving money?

That question leads somewhere more interesting than a balance dashboard.

Total cash isn't usable liquidity

An organisation can hold plenty of cash and still miss a payment. In banking, the Basel Committee treats available intraday liquidity and time-specific obligations as separate monitoring concerns.¹

The cash can sit in the wrong account, currency, legal entity or jurisdiction. It can arrive after the payment falls due. A settlement cut-off can block the route. A clearing account can have a hard ceiling. Moving the cash can consume more time or capacity than treasury has left.

So a group-wide balance answers the wrong question. Treasury needs to know what value can reach a particular place by a particular time.

That led me to the central idea:

Liquidity is the stock plus the ability to move value through constrained edges before it is needed.

The stock matters, but the route matters just as much.

Liquidity is a temporal network

The natural model is a directed graph.

Each node represents a controlled liquidity resource. A bank account is the clearest starting point. Other node types can represent a credit facility, an investment or an internal pool. Their meaning must stay explicit. Undrawn credit isn't cash, and treating it as cash would count the same capacity twice after a draw.

Each edge represents a permitted movement. The edge has a direction, a capacity and a completion time. It can carry cut-offs, fees, legal restrictions, approvals and current availability. A route from A to B says nothing about a route from B to A.

Time turns this from a static network into an operational model. Five million pounds available tomorrow can't fund a payment due this morning. A cheap route that closes in ten minutes can be less useful than an expensive route that stays open for another hour.

The governing question becomes:

Can enough confirmed liquidity reach the required node before it is needed, within its limits, at an acceptable cost?

At its core, this is a time-dependent, capacitated network-flow problem with legal, operational and policy constraints. Cost becomes part of the objective only under a policy that prefers it. Treasury can prefer speed, certainty, headroom or lower cost.

None of this needs a new class of mathematics. Network-flow methods have long been used in international cash management.² Flows-over-time research covers the wider case: capacity-constrained movement where transfer isn't instantaneous.³ The distinctive software problem is constructing a trustworthy operational state for those methods.

Balances need time and provenance

The model needs an authoritative starting point for each account. That can be the latest settled balance from the bank or ledger. Confirmed payments and accepted transfers then roll the position forwards.

There is no credible global t0. Accounts have different settlement points, source systems and refresh cadences. Each balance needs its own timestamp, source and reconciliation state.

The model must keep four views apart:

• Observed: settled and available liquidity now
• Confirmed: observed liquidity plus binding future movements
• Expected: probabilistic inflows and outflows shown beside the confirmed curve
• Scenario: explicit assumptions used for testing

That separation is a basic control. Expected receipts can't fund confirmed obligations. Historical analysis or machine-learning models can flag a likely shortfall, but they don't turn uncertain cash into confirmed cash.

Known future commitments belong in the state too. Payroll, debt repayments, tax, accepted transfers, investment maturities and forward-start movements all change what remains usable at a later time.

Hierarchy keeps the model manageable

A global treasury has too much underlying detail for one calculation to rebuild every account and payment on each run. Local teams already own the accounts, constraints and operating knowledge.

The network can mirror that ownership:

Account → Entity → Jurisdiction → Region → Global

Each child graph calculates its own position. It applies local buffers, known commitments and transfer constraints. It then publishes a versioned liquidity envelope to its parent.

An envelope answers questions such as:

• how much confirmed liquidity can leave
• how much funding is required
• when either amount becomes relevant
• what receiving capacity remains
• how fresh the underlying data is
• which calculation and contract versions produced it

Local teams calculate and own each part of the network. The global layer composes those parts. A global operator can still inspect the detail, but the global calculation doesn't need every payment record to decide what a jurisdiction can deliver.

Exportable liquidity isn't a sum

Suppose three entities publish surpluses of £10 million, £8 million and £5 million. Their arithmetic total is £23 million.

The first entity can deliver its full £10 million by the deadline. The second has only £3 million of route capacity. The third has no permitted route to the jurisdiction boundary. Only £13 million is reachable.

Now apply a £4 million jurisdiction reserve. The exportable amount is £9 million, not £19 million and not £23 million.

The reserve needs careful placement. Each child envelope has already applied its own buffer. The parent applies only the parent reserve. Applying child buffers again would understate the available position.

Costs follow the same hierarchy. Each transfer leg carries its own external cost. Group liquidity falls only once for each cost.

Published liquidity needs reservation

Hierarchy creates a less obvious risk. Two parent calculations can try to consume the same child surplus.

A published envelope is an offer of capacity, not an independently reusable fact. Acceptance must reserve the amount against that envelope version. It must reserve the source balance and every shared edge in the selected path too.

The same principle applies to a funding requirement. Once a parent accepts a reservation to meet it, the requirement is covered for further allocation. The system shouldn't fund it twice.

The state still matters:

Open requirement
        ↓
Covered by reservation
        ↓
Covered in flight
        ↓
Fulfilled pending local confirmation
        ↓
Locally confirmed fulfilled

A debit from the funding account proves that the value left the source. It doesn't prove that the destination received it. The amount moves into an in-flight state. Destination settlement fulfils the requirement.

The child still needs to publish a fresh envelope before any resulting surplus becomes exportable. This avoids duplicate funding without trusting stale surplus.

Stale data should fail conservatively

Staleness isn't symmetric.

A stale surplus should disappear from the exportable position. Treasury has lost evidence that the money remains available.

A stale requirement should remain as a lower bound. Treasury should presume that the entity owes at least the last confirmed amount. Confirmed new obligations can raise that floor. Expected inflows can't reduce it.

Parent-observed settlement can close the open funding need. It can't create new exportable liquidity for the child. Only a fresh local calculation can do that.

This gives the model a conservative rule that operators can explain:

Remove stale offers, retain stale needs, and recognise fulfilment from confirmed movement evidence.

Why call it a digital twin?

The term earns its place only with an operational feedback loop.

Proposed → Accepted → In flight → Settled → Observed state

The model has persistent identities for accounts, contracts and movements. It projects the result of an accepted decision. Later settlement evidence updates the observed state and tests the earlier projection.

The source ledger and bank remain authoritative. The twin doesn't replace them. It maintains a controlled, historically reconstructable model of liquidity and transfer capability.

Movement lifecycles won't always follow the happy path. A transfer can fail, settle in part, arrive late or reverse. The twin needs to retain the intended, reserved, instructed, settled and remaining amounts throughout those changes.

That is more than visualisation. It is a working model that changes with decisions and reconciles those decisions to external facts.

Movement selection, reporting and AI sit on top

Once the controlled state exists, a network-flow calculation can search for feasible movements under the declared timing, capacity, cost and policy constraints. The model of reality comes first. The selection method comes afterwards.

Intraday management, funding planning and regulatory reporting can use the same underlying state at different horizons and cadences.

Payment operations care about the next settlement and the rest of the day. Treasury planning looks further out. Liquidity reporting adds prescribed classifications, stress rules, controlled snapshots and attestation. Those are extra calculations and controls over the operational model.

AI has a narrower role. The graph finds feasible movements. Policy removes prohibited ones. AI can then compare the remaining options, explain their costs and flag missing or stale evidence.

It must not invent a route, ignore a limit or treat forecast cash as settled cash. The network constrains the answer. AI helps an operator understand it.

The deeper claim

The advert made me think about liquidity management as a data and decision problem. That problem led to accounts, commitments, constraints, routes, hierarchy and time. The digital-twin idea followed from those requirements rather than serving as the starting label.

The deeper claim is this:

Treasury needs an executable, historically reconstructable model of what liquidity exists, which claims have priority over it, and which movements remain feasible at each relevant time.

That model can support intraday control, planning, stress testing, reporting and controlled automation. Its first job is more immediate. It must tell treasury what money is truly usable, where it can go, and whether it can get there in time.

A companion article will set out the contracts, states, hierarchy, reservation rules and controls behind this concept.

References