The narrative in treasury technology is often too simplistic:
APIs = modern, fast, real-time
Batch = legacy, slow, outdated
In reality, most banks operate a hybrid model. Some processes are real-time, while many critical ones still run in overnight or scheduled batch cycles. This is not a failure of technology. It is a deliberate design choice.
This article explains:
- what API vs batch actually means
- what still runs overnight
- why batch processing remains essential
API vs Batch: what’s the real difference?
API-based processing (real-time or near real-time):
- Data exchanged instantly between systems
- Transactions processed individually
- Immediate confirmation and feedback
Typical use cases:
- real-time balances
- payment initiation
- system integration (TMS, ERP, banking APIs)
Batch processing (scheduled or periodic):
- Transactions collected and processed together
- Runs at defined intervals (e.g. overnight)
- Optimized for scale and consistency
Typical characteristics:
- deferred ledger updates
- bulk reconciliation
- efficient handling of large volumes
Key point: this is not “old vs new”. These are two different processing models solving different problems.
What still runs overnight in treasury systems?
Ledger posting and settlement finalisation
Even if payments are initiated instantly, final posting to the official ledger is often delayed to ensure accuracy, reconciliation, and audit integrity.
Payments settlement
Many payment types still use batch cycles:
- ACH and clearing
- payroll and bulk payments
- interbank transfers
These require coordination across systems and institutions.
Reconciliation and matching
Reconciliation works best with complete datasets. Batch processing allows stable, consistent matching across systems.
Regulatory reporting and ALM calculations
Outputs such as liquidity reporting, IRRBB metrics, and risk reports require consistent, auditable datasets. These are naturally batch processes.
Risk calculations and scenario runs
Processes like NII simulations, EVE calculations, and stress testing are computationally heavy and run on scheduled cycles.
End-of-day position building
Treasury decisions are still often based on consolidated end-of-day views, which rely on batch processing.
Why batch processing still exists
Scale and efficiency
Batch processing allows banks to handle very large volumes of transactions efficiently.
System coordination
Treasury processes depend on multiple systems (banks, networks, payment platforms) that do not operate continuously in sync.
Risk control and validation
Batch provides a controlled window for fraud checks, validation, and error handling.
Audit and regulatory requirements
Regulators require consistent, reproducible datasets. Batch supports traceability and control.
Stability and operational simplicity
Batch systems are predictable and easier to manage than always-on real-time systems.
Legacy constraints
Many core systems were designed around daily cycles, and replacing them fully is high-risk and costly.
Where APIs are actually transforming treasury
APIs are not replacing batch—they are changing where real-time matters.
Cash visibility
Real-time balances and intraday liquidity monitoring
Payment initiation
Event-driven and instant payment flows
System integration
Continuous data exchange between TMS, ERP, banks, and risk systems
Event-driven treasury
Ability to react immediately to business or market events
The reality: hybrid architecture
No treasury system is purely API-based or purely batch-based.
Modern architectures combine:
- real-time (APIs): visibility, payments, alerts
- batch: settlement, reconciliation, reporting
This hybrid model balances speed with control.
Final takeaway
Batch processing is not disappearing.
It remains critical for:
- settlement
- reconciliation
- regulatory outputs
APIs are transforming:
- visibility
- connectivity
- responsiveness
The future is not real-time replacing batch.
It is real-time layered on top of batch.