The 2026 Treasury Technology Market Map

One label now hides several buying decisions

The traditional treasury management system category remains useful, but it is no longer sufficient. A buyer may be considering a broad TMS, an ERP treasury module, a forecasting platform, payment infrastructure, a trading venue, market data, hedge accounting or working-capital technology. These are different decisions and should not be forced into one vendor list.

This change is being accelerated outside the TMS itself. ISO 20022, the international standard for payment-message data, is raising data-quality expectations. Instant payments and verification of payee—the check that an account name matches the intended recipient—are changing payment controls. Direct software connections are making specialist products easier to combine. Artificial intelligence is increasing demand for accessible, well-controlled data.

Practitioner evidence supports the need to separate these decisions. The 2025 European Association of Corporate Treasurers survey placed technology-infrastructure review among the three leading priorities of more than 275 group treasurers. Association of Corporate Treasurers reporting found that 53% of surveyed treasury professionals used a TMS or treasury and risk management system, while others were considering specialist reconciliation, payment-factory and bank-fee tools. One technology programme may therefore contain several different buying decisions.

Function and product type are different questions

The eight areas describe what treasury needs the technology to do. Enterprise platform, modular suite and specialist solution describe the type of product being considered. Mixing those two dimensions makes the market look simpler than it is.

An enterprise platform may cover six or seven areas. A modular suite may start with cash and payments, then expand. A specialist may provide greater depth in forecasting, execution or hedge accounting. The correct product type depends on the client’s breadth, complexity, existing architecture and appetite for integration—not on the size of the vendor’s feature list.

Bloomberg and LSEG show why market data, valuation, risk and execution should not be hidden inside the TMS category. 360T shows the distinct role of trading and execution technology. SAP Taulia shows working capital and supply-chain finance as another separate technology decision.

The overlap is not a flaw

Many providers span more than one area. A payment platform may add cash visibility. A forecasting specialist may add payments. A trading platform may also provide market data. A broad TMS may cover most of the map. Products should therefore be cross-listed where they genuinely operate.

That does not make every product equivalent. A broad feature statement can conceal important differences in depth, control, geographic coverage, integration effort and delivery model. Market positioning is a starting hypothesis, not an assessment conclusion.

Treasury Today reports growing use of modular approaches and different tools for different purposes. It also records the practical limits: fragmented finance systems, banks, regulations and local processes can make apparently simple integration difficult. Modularity creates choice. It does not remove the need for architecture, controls and clear ownership.

Start with how the organisation works

The initial vendor list should be derived from the client’s legal entities, countries, currencies, banks, payment types, core finance systems, treasury instruments, controls and intended degree of centralisation. The organisation’s preference for one broad platform, a set of modules or specialist products matters just as much as the number of features.

This is why TRC separates product capability from client fit—how closely the product matches one client’s needs. A product may be strong and still be the wrong answer. Another may be narrower, but materially better aligned to the actual problem.

Academic research on treasury digitalisation is still limited, but its main themes are useful: risk control, liquidity efficiency, cash-management automation and information centralisation. These are operating outcomes, not product categories. The technology should be assessed against the outcome the organisation needs.

• Choose the functional areas that are genuinely in scope.
• Decide what should remain in the ERP or existing technology.
• Select the appropriate product type: enterprise platform, modular suite or specialist solution.
• Build the initial vendor list from the agreed scope and requirements.

What the map is—and is not

The map is a way to frame the buying decision. It is not a ranking, a complete vendor directory or evidence that every named provider has been independently validated. Vendor positioning changes and many products sit across category boundaries.

The market structure and conclusions are TRC’s independent analysis. TRC uses its vendor catalogue, product monitoring, requirements library, professional surveys, treasury publications, academic research and material from regulators and standard setters. Vendor material is used to confirm current product names, ownership and stated capabilities—not to determine market position.

The practical conclusion is simple: define the requirement first. Then determine which functional areas and product types deserve attention. Only after that should the vendor list be built.