Real-Time Treasury: What Actually Requires Instant Processing (and What Doesn’t)

“Real-time treasury” has become a standard ambition across banks.
But in practice, not everything in treasury needs to be real-time, and pushing everything in that direction creates unnecessary complexity.

The real question is not how to make treasury real-time everywhere.
It is how to decide where real-time processing actually matters.

The shift toward real-time treasury

Treasury in banks is moving from batch-based decision-making toward continuous visibility and faster execution.

This shift is driven by:

  • Instant payments and 24/7 settlement expectations
  • Increasing demand for up-to-date liquidity information
  • The need to react quickly to market and funding changes

Real-time capabilities allow treasury functions to move beyond end-of-day reporting toward intraday awareness and faster decision-making.

However, this does not mean every process should become real-time.

Where real-time processing is essential

Some treasury activities depend directly on timing. In these areas, delays create real risk.

Payment execution and authorisation

Payments that are initiated by clients, internal systems, or market events often require immediate processing.

Examples:

  • Instant payments
  • Time-critical funding movements
  • Customer-driven transactions

Real-time execution ensures:

  • Immediate confirmation
  • Accurate balance updates
  • Reduced operational and settlement risk

Without this, banks lose control over intraday liquidity and payment flows.

Intraday liquidity management

Liquidity moves continuously throughout the day, not just at end-of-day.

Effective liquidity management requires:

  • Current balances
  • Live exposure visibility
  • Up-to-date positions across accounts and entities

Real-time visibility allows banks to:

  • Avoid liquidity shortfalls
  • Reduce excess buffers
  • Optimise funding decisions as conditions change

Fraud detection and risk controls

Certain risks must be managed before a transaction is completed.

Examples:

  • Payment fraud
  • Sanctions screening
  • Transaction anomalies

These require immediate data and decisions.
If detection happens after the transaction is completed, intervention is no longer effective.

Cash visibility and position monitoring

Banks cannot make effective treasury decisions based on outdated data.

Real-time visibility supports:

  • Accurate liquidity positioning
  • Faster funding and investment decisions
  • Reduced reliance on conservative buffers

Without it, treasury operates with delayed information, which increases cost and risk.

Where real-time processing is not necessary

Many core treasury functions are not time-critical. What matters here is consistency, completeness, and control.

Settlement and clearing

Settlement is not about speed—it is about accuracy and coordination.

These processes:

  • Involve multiple institutions and systems
  • Depend on clearing cycles
  • Require agreement between counterparties

Batch processing provides:

  • Complete datasets
  • Coordinated execution
  • Reliable settlement outcomes

Reconciliation

Reconciliation is often assumed to benefit from real-time processing, but this is not always the case.

In practice:

  • Transactions may still be pending
  • External confirmations are delayed
  • Data is incomplete during the day

Batch processing allows:

  • Stable, final datasets
  • Consistent matching across systems

Regulatory reporting and ALM calculations

Regulatory outputs are fundamentally point-in-time.

Examples include:

  • Liquidity reporting
  • Interest rate risk metrics
  • Balance sheet analysis

These require:

  • Consistent inputs
  • Controlled assumptions
  • Reproducible results

Batch processing supports auditability, traceability, and regulatory compliance.

Scenario analysis and risk modelling

ALM-related processes such as:

  • NII simulations
  • Stress testing
  • Behavioural modelling

are computationally intensive and scenario-driven.

They are not dependent on immediate data refresh.
They require controlled execution rather than real-time responsiveness.

Bulk payments and operational processing

Not all payments require immediate settlement.

Examples:

  • Payroll
  • Supplier payment runs
  • Internal transfers

These benefit from:

  • Batch execution
  • Operational efficiency
  • Lower processing cost

Real-time processing in these areas adds complexity without providing clear value.

Why the distinction matters

Treating all treasury processes as real-time creates:

  • Unnecessary system complexity
  • Higher infrastructure cost
  • Increased operational risk

Treating everything as batch creates:

  • Delayed visibility
  • Slower decision-making
  • Inefficient liquidity management

The key distinction is between:

  • Processes where timing affects outcomes
  • Processes where completeness and control are more important than speed

The practical reality: hybrid treasury

In practice, treasury in banks operates as a hybrid model.

Real-time processing supports:

  • Payments
  • Liquidity monitoring
  • Risk and control functions

Batch processing supports:

  • Settlement
  • Reconciliation
  • Regulatory reporting and modelling

Most workflows combine both.

For example, a payment may:

  • Be initiated and approved in real time
  • Settle through batch-based clearing
  • Be analysed later in reports and risk models

The challenge is not choosing one model, but orchestrating both effectively.

Final takeaway

Real-time treasury is not about making everything instant.

It is about applying real-time processing where it changes outcomes.

Real-time is essential when:

  • Decisions depend on immediate data
  • Risk exists at the moment of execution
  • Liquidity moves continuously

Batch remains essential when:

  • Consistency matters more than speed
  • Processes depend on complete datasets
  • Outputs must be controlled and auditable

The future of treasury in banks is not fully real-time.
It is selectively real-time—built on top of structured, reliable batch processes.