Treasury management systems

A treasury management system is software that automates the core functions of a treasury department. It pulls together information from banks, market data providers, the company's ERP and internal reporting, and presents it in real time so treasury can decide with current facts rather than yesterday's spreadsheet.

The natural question is why the ERP doesn't cover this — SAP already tracks every transaction. Because ERPs are built for the whole company's accounting ledger, and treasury's needs are different in kind: real-time cash visibility across many banks and currencies, FX trading and hedge accounting, deal capture and mark-to-market of derivatives, settlement and reconciliation of high-value transactions, counterparty exposure monitoring. A TMS is built for the speed, precision and risk visibility those demand.

Everything a TMS does flows from one discipline: a deal is entered once, and that single record feeds every downstream process.

The common thread is speed and accuracy: enter once, use everywhere, and the errors that live between spreadsheets have nowhere to breed.

A TMS is organised into three functional areas that mirror the treasury department itself — and deliberately so, because the separation is the segregation-of-duties control from the very first step of this course, built into software.

• Front office — the dealers' interface: pricing tools, comparative quotes, deal booking. Where positions are taken.
• Middle office — the risk and control layer: monitors positions, calculates risk, checks limits, enforces policy; large deals can require its approval before settling.
• Back office — operations: processes confirmations, reconciles trades to bank statements, manages settlement instructions, tracks fails.

The Barings lesson runs straight through this architecture: Leeson was front, middle and back office in one person. A TMS that gives dealing, risk-checking and settlement to three separate modules with separate users makes that concentration structurally impossible — the control is in the system's shape, not in a policy document.

The most-used screen in any TMS is the consolidated cash position. A multinational might hold fifty accounts across twenty countries in ten currencies; the system collects live balances from every bank and shows one view — total cash by currency, by bank, unallocated cash free for investment, and the forecast position 10, 30 and 90 days out from expected obligations and collections. Without it, a treasurer compiles the same picture by logging into each portal and pasting numbers into a spreadsheet: hours of work, stale on arrival, wrong somewhere.

The data arrives over four kinds of connection: SWIFT for payment instructions and confirmations (the standard for high-value and international flows), host-to-host direct links between bank and company for fast routine traffic, open banking APIs for balances and payment initiation where banks offer them, and market data feeds — Bloomberg, Reuters — for the rates that mark positions to market and drive the risk numbers.

This screen is where the earlier lessons become operational. The Miller-Orr limits need a live balance to compare against; the investment tranching needs to know what is truly unallocated; the forecast that keeps the overdraft cheap is only as good as the data feeding it. Real-time position is the input all of them share.

Building a custom TMS fits the company perfectly and costs millions, takes years, needs a standing IT team, and ages as the market moves. Most companies buy: Kyriba, FIS, ION Treasury, SAP TRM (the ERP vendor's own treasury module), Temenos on the banking side. The selection criteria are the questions to ask any vendor: does the scope cover your functions — cash, FX, derivatives, debt, investments, settlement; does it scale with new banks and entities; how does it integrate with your ERP, banks and data feeds; can workflows be configured without custom code; will the team actually use it; what is the total cost of ownership; and is the vendor stable enough to still exist in year ten?

Implementation is where TMS projects earn their reputation. Four challenges recur: data migration (moving history out of spreadsheets, where errors planted now surface for years), integration (every bank connection is its own project, and the work reliably overruns), user adoption (teams that lived in Excel resist, and a half-used TMS produces half-quality data), and complexity (most firms use a fraction of the features in year one — disabling the rest quietly creates problems when treasury's scope grows).

A TMS is also the enforcement mechanism for treasury policy. Rules that live in documents — counterparty caps, tenor limits, currency exposure ceilings, VaR limits, approval thresholds — are built into the system as hard limits, which block a breaching deal outright, or soft limits, which allow it but log it, alert the treasurer and demand approval before the next step. A dealer cannot exceed a counterparty cap that the booking screen refuses.

The business case rests on five quantifiable returns: errors eliminated (one failed or doubled payment can cost more than the licence), cash visibility (precautionary buffers of 20% "just in case" shrink toward 5% when the position is trusted, releasing millions), investment returns (surplus seen today is invested today, at term rates instead of call rates), borrowing costs (forecast shortfalls are funded in advance at better rates than emergency ones), and risk prevented (the counterparty blow-up or rogue position that limits stopped never appears in any ledger — which is the point).

And this is where the course closes, because the TMS is where all ten steps meet: the cash position and forecasts of lesson two run on its screens, the hedges of lesson three are captured and marked in its deal blotter, the debt book and investment tranches of lesson four live in its position modules, the settlement flows of this lesson pass through its back office — all inside the controls the very first step demanded. Treasury management is one discipline; the system is where it runs as one machine.