The treasury management market has never been more sophisticated. Platforms can access real-time dashboards, multi-bank connectivity, cash position forecasting, automated reconciliation, and AI-powered liquidity optimisation. The tools are excellent. The problem is that they are solving the wrong layer.
Treasury software optimises what existing banking relationships provide. It gives better visibility into existing costs. It cannot change the underlying economics of those relationships. The distinction between the software layer and the infrastructure layer is the most consequential decision a growing platform's treasury team will make. Getting it wrong means investing in tools that optimise friction rather than removing it.
What treasury tools do well
Treasury management platforms have made genuine progress. A platform operating across ten currencies no longer needs to log into ten different banking portals. Cash positions can be aggregated in real time. Payment files can be standardised. Reconciliation that once took days can happen in hours. For platforms with stable, well-functioning banking relationships, these tools add real value by reducing manual effort and improving visibility.
The PwC 2025 Global Treasury Survey found that 94% of organisations now operate a dedicated treasury management system, with leading platforms handling cash positioning, forecasting, payments, and risk oversight. Adoption has become near-universal among organisations with more than $10 billion in revenue. APIs are gaining ground rapidly, with 65% of organisations planning to expand API use in the next few years. The software layer has moved from spreadsheets to sophisticated platforms, and that progress is real.
The ceiling becomes apparent when the infrastructure itself is the constraint. PwC's own data reveals the gap: average TMS satisfaction for short-term forecasting is just 3.4 out of 5, and bank fee analysis scores only 3.5. Over 20% of respondents still use offline or homegrown systems for key treasury activities. The software is widely adopted. The problems it cannot solve remain unsolved.
The ceiling: what software cannot change
Consider a platform settling payroll across fifteen currencies. The treasury team has invested in a bank connectivity platform that aggregates balances and initiates payments across all fifteen banking relationships. The dashboard is comprehensive. The reporting is clean. But the constraints are structural, not informational:
- No dashboard can shorten a settlement queue at a correspondent bank. The platform still prefunds each market individually because settlement timing varies by correspondent. The software shows the prefunding requirement. It cannot reduce it.
- No forecasting tool can predict when a nostro account will be credited if the correspondent's processing schedule is opaque. Cash forecasts remain probabilistic rather than deterministic.
- No automation platform can create a compliant custody structure if the underlying accounts are pooled. The software automates reconciliation against omnibus accounts. It cannot eliminate the need for it.
A TD Bank survey of 246 treasury professionals found that 80% still rely on manual or fragmented systems, ranking this as their top challenge alongside macroeconomic uncertainty. Three-quarters said digital cash flow visibility has transformed their growth strategies, but adoption of the underlying infrastructure changes remains low. The software shows the cost more clearly. The cost itself remains unchanged.
Infrastructure economics vs. software economics
The difference becomes visible in the unit economics. A treasury management platform charges a software fee, typically per transaction or per month. It sits on top of existing banking relationships. The banking relationships themselves carry separate costs: correspondent fees, FX spreads, nostro prefunding, settlement float, and compliance overhead per jurisdiction. These costs are structural. They exist regardless of which software layer sits above them.
An infrastructure approach consolidates these structural costs:
- A single correspondent relationship replaces fragmented banking across markets, reducing compliance surface area and operational overhead.
- Settlement timing becomes predictable, reducing prefunding requirements and freeing working capital that was previously trapped as a timing buffer.
- FX is priced at wholesale interbank rates rather than through embedded markups, making the cost visible and auditable.
- Custody is structural rather than ledger-based, reducing reconciliation burden and audit complexity across jurisdictions.
The software layer and the infrastructure layer are not in competition. They serve different functions. But platforms that invest in software without first addressing infrastructure are optimising a system that is structurally more expensive than it needs to be. The visibility improves. The underlying economics do not.
When the infrastructure changes, everything above it improves
When settlement becomes predictable, treasury forecasting becomes reliable rather than probabilistic. Cash positions can be managed against known settlement windows rather than estimated ranges. When custody is segregated by design through named custody accounts, reconciliation moves from a daily operational burden to a verification exercise. The audit trail is the account structure itself, not a ledger reconstruction.
When FX is priced transparently at interbank rates, the platform captures margin that was previously invisible in the spread. The treasury software still has a role. Dashboards, reporting, and forecasting tools remain valuable. But they become dramatically more effective when the data they display comes from infrastructure designed for clearing, custody, and liquidity management rather than infrastructure that treats these as secondary to a lending balance sheet.
Lorum provides the infrastructure layer: cash management infrastructure, named custody accounts, and wholesale FX through multi-currency clearing across 30+ markets via a single API integration. The software layer sits on top. The infrastructure layer determines what the software has to work with. Treasury teams evaluating new tools should first identify whether the constraint lives in the software layer or the infrastructure layer, and invest accordingly.
