Market deep-dive: How to choose the right Treasury Management System

Introduction

The first treasury management system (TMS) was released way back in the mid-80s, a standalone machine that literally sat in the corner of the treasury department. And yet, almost four decades later, the demand for treasury software is rising again – according to one study the market is growing by 14% year over year.

Increasing financial complexity has helped drive demand. As financial markets, regulation, and multi-currency operations become harder to navigate, companies turn to dedicated tooling. Then there’s the current macroeconomic environment. High inflation, low yields, and restricted financing options have left companies needing to maximize working capital.

A new wave of market entrants – today’s successors to the TMS – is also spurring demand. Modern SaaS platforms like Atlar are making treasury software more accessible to a broader pool of companies. These platforms are growing at the fastest rate within the treasury software market, outpacing the TMS and other solutions.

A consequence of all this is that more and more businesses are now exploring treasury software for the first time or reevaluating their existing tooling. It’s a decision that can have long-term implications and is a common pain point for many teams. A TMS can be the central lynchpin of the finance stack but can also easily turn into software that's costly to maintain and difficult to dispose of.

A previous post compared the different options for treasury tooling, from Excel to Enterprise Resource Planning (ERP) systems and modern platforms like Atlar. This post zeroes in on one of those options, the Treasury Management System (TMS).

‍

What is a treasury management system?

For many large enterprises, the TMS is the centerpiece of their treasury technology, connecting external and corporate systems such as banks and ERPs. It works by aggregating data from multiple sources, presenting it in a standardized format, and enabling certain actions to be taken off the back of it.

Some of the key data points that a TMS can help surface include account balances, financial transactions, and expected cash flows across the entire business. This makes it easier for decision makers to get a sense of the company’s finances and simplifies tasks like reporting and cash forecasting. Typically a TMS is not a read-only tool: most systems include ways to automate and schedule payments, which helps when dealing with large transaction volume.

For thirty years and counting the TMS has been the de facto tool of choice for enterprises in performing core treasury activities. The core functionality is delivered through modules which are installed and configured separately. Given the associated cost and complexity, for most of its history the TMS was reserved for large, well-resourced enterprises.

A new category of treasury software is starting to change this dynamic. Modern, cloud-based platforms are similar to a TMS in that they connect to banks and ERPs but also support real-time API integrations with other finance tools and are quicker to implement.

The recent advancements in treasury software are being driven by a fundamental shift in technology. Specifically, the continued adoption of banking APIs and growth of real-time payments and data availability. Taken together, these developments represent the biggest change in treasury management for over twenty years and are altering expectations for what a TMS is and does.

While a legacy TMS typically receives and processes data in batches every 24 or 48 hours through traditional channels like host-to-host and Swift, newer platforms can receive data continuously, in real time, from any financial provider.

What does a TMS actually do?

Here are some of the key functions that a TMS performs:

• Automate manual work: A key benefit of a TMS is the automation of repetitive tasks like transferring data and processing transactions. It helps you track things like exchange rates and payments while simplifying time-consuming processes such as reconciling accounting entries with bank statements.
• Connectivity: The ability to connect directly to banks or other financial institutions through traditional, file-based channels such as host-to-host underpins a lot of TMS functionality. Newer platforms like Atlar can often support a wider set of financial connections with API-first platforms like modern banks and payment platforms. 
• Consolidate financial data: TMS software aggregates financial data from banks and other sources, such as an ERP, into one standardized view. This makes it easier to analyze information and simplifies decision-making.
• Liquidity management: Knowing how much cash you have on hand and where it’s located is a basic need of any business. TMS software simplifies cash management by providing a single overview of your liquidity, much like Atlar’s Cash Management product.
• Financial reporting: Most systems come with reporting capabilities that allow companies to generate custom reports for use internally.
• Data security: Protecting sensitive financial data is non-negotiable for most businesses and TMS software includes security features such as encryption, role-based access controls, and audit trails.
• Risk management: A TMS can identify financial risks, such as exposure to interest rate and currency fluctuations, helping businesses to mitigate them and protect their capital.
• Deal management: Some systems, either directly or through third-party services, offer features to manage deals and contracts relating to loans, investments, and FX hedging, and more.
• Multi-currency support: A TMS can typically handle multiple currencies in a way that makes it easier to manage conversion rates and currency risk. This can be a key benefit for businesses with operations in multiple countries.‍
• Regulatory compliance: For businesses that operate across multiple jurisdictions, a TMS helps in adjusting to new regulations and reduces the risk of noncompliance. Most systems offer approval workflows to help enforce internal policies around payments and transfers.

‍

Evolution of treasury management systems

At a high level, the evolution of TMS software can be broken into two phases: the first generation of locally installed, self-hosted machines and, from the early 2000s onwards, cloud-based systems which can be accessed remotely via a web browser.

The TMS first appeared in the 1980s, shortly after the very first spreadsheet programs replaced physical ledgers. These early systems were installed locally and let businesses send and receive information with their banks electronically instead of using physical documents.

The arrival of cloud-based technology in the early 2000s opened up a new TMS delivery channel: software as a service (SaaS). These systems lowered the effort required to implement and maintain a TMS but, though the delivery model changed, the underlying technology remained largely the same.

Crucially, early cloud-based TMS software predates the use of APIs – now the main way that software programs communicate with one another. The gradual adoption of banking APIs set the stage for another major advancement: real-time financial data and payments. As of today, banking APIs are increasingly widespread and real-time payment schemes like Faster Payments in the UK, the EU’s SCT Inst, and FedNow in the US are experiencing exponential growth. 

Most incumbent TMS providers, cloud-based or otherwise, are yet to fully adopt these technologies and still rely heavily on traditional file-based connectivity and batch processing – described by Andreessen Horowitz as “incredibly antiquated” tech. This may or may not be a critical issue, depending on a company’s treasury use cases. It does mean, though, that these systems generally show data that’s a day or two old and don’t integrate well with API-first systems such as PSPs and modern banks.

‍

Overview of the current treasury software market

Today there is a growing range of technology solutions available to support treasury teams, including but not limited to TMS software. Our guide to treasury management tooling compares each of these options in more detail. 

In addition to ERP treasury modules and bank-provided services, there are also a variety of middleware systems offering more niche aggregation services such as electronic bank account management (eBAM) systems and Swift or EBICS connectors. Extremely well-resourced treasury departments can also choose to build their own homegrown solution or a ‘best-of-breed’ systems architecture made up of several systems. Modern treasury platforms are a relatively new addition to this software market.

Focusing on TMS software, today’s market is dominated by a relatively small number of global players. According to Deloitte, Kyriba, FIS, and ION Group’s TMS are the three most popular systems among larger enterprises alongside SAP Treasury and Risk Management, technically an S/4HANA module.

A TMS is no new solution – most of these systems were released between the late 1980s and early 2000s – and by now most TMS providers share several characteristics:

• Core functionality: Almost all systems offer equivalent core treasury management features including cash and liquidity management, cash flow forecasting, and reporting.
• Lengthy implementation projects: On average, most TMS software takes a minimum of six months to implement, extending to 18 or 24 months for more complex setups.
• Specialist support: It is widely recommended to contract the help of specialist consultants when implementing and configuring a TMS, regardless of the provider, and to support ongoing maintenance and updates.
• UI complexity: There is generally a steep learning curve for team members to familiarize themselves with a TMS. The UI can be unintuitive for first-time users and formal training is recommended. Some providers, like Kyriba, offer paid courses and certifications.
• Platform updates: TMS providers update their systems at most once per quarter, and the vast majority (including Kyriba, GTreasury, and ION Group) perform major updates biannually or annually, during which time users will likely experience some downtime.‍
• Provider lock-in: The investment required to implement a TMS means that the cost and effort of switching to another system is high. Depending so heavily on a single provider can lead to less favorable terms over time.

‍

How do treasury management systems differ?

In some fundamental ways, the TMS used by the largest and most complex treasury departments in the world will be similar to that used by a finance team adopting a TMS for the first time. The basic functionality is similar: cash can be managed, transactions can be entered and monitored, and financial risk exposures can be dealt with.

The main way that these systems differ is how it operates. First, TMS software is delivered in different ways, from local installations on company premises to a cloud-based SaaS model. Second, systems differ in the amount of complexity they can handle. All systems can perform the core treasury functions, but some have deeper functionality for certain tasks. 

Last but not least, treasury systems vary in their connectivity options. In other words, the breadth and quality of their connections to other systems such as banks, ERPs, and services like PSPs and spend management tools. These three variables are important to consider when choosing a new treasury system and help determine factors like cost, ease of implementation, and business value.

Treasury software is delivered in one of three ways

A TMS can be installed locally on a company’s servers, provided as a hosted service in an environment dedicated to a single customer, or delivered through a SaaS model in which the software is fully managed by the provider. In a 2022 survey of enterprise-level treasury leads, 42% used a cloud-based SaaS platform (up from 36% in 2019), 32% favored a locally installed system, and 7% used a hosted or managed service.

Most systems founded in the last twenty years are provided as a SaaS solution. Locally installed systems are preferred by the largest enterprises due to their configurability and lack of external dependencies, but come with a higher price tag and a much longer implementation.

How treasury software is delivered influences its implementation and maintenance. The variance can be significant: according to a 2019 Deloitte report, the average implementation time for a traditional TMS is between 4 and 18 months. Broadly speaking, SaaS platforms are faster to implement. Atlar customer Sellpy, for instance, was up and running inside four weeks while Loomis Pay had all of its bank accounts connected within three weeks.

Local installation

The traditional delivery method, where the system is installed on hardware at the company location. This is the most costly method but provides the most flexibility. 

The company’s IT team should be involved heavily in the selection process as most providers require significant effort from the customer and specialist consultants during implementation, from several hundreds up to more than a thousand hours of work. Given the upfront costs involved, these systems are seen as a multi-year investment and the high cost of switching systems tends to lock companies in with specific providers for several years.

Once implemented, treasury teams will require training before using a locally installed system due to its complex, highly bespoke functionality. System upgrades take place once or twice a year, during which time the system can be offline for up to 24 hours. Examples of providers that offer local TMS installations include FIS (Quantum), ION Group, and SAP.

Hosted service

These systems are hosted by the provider and often developed as a single tenant solution. This means that it’s deployed for a single customer and can be customized to their specific requirements. The provider is responsible for system upgrades, however it’s the customer’s responsibility to connect to the provider’s servers and pipe financial data into the system. 

This means that the company needs to have the necessary IT resources and expertise to manage the various bank connectivity channels. The IT team also ensures the system and any external connections (including those with a general ledger or ERP) continue to work after any system upgrades.

A hosted service is quicker to implement than a local installation while enabling some configurability. Again, the IT team should expect to maintain the system long term. Providers that offer a hosted service include Coupa, GTreasury, and EcoFinance.

Software as a Service (SaaS)

In a cloud-based SaaS solution, the company accesses the system via a web browser with no installation or maintenance work required. These solutions are by far the most cost-effective type of treasury software and can be chosen and implemented much more quickly.

Many cloud-based providers will handle the company’s bank connectivity on its behalf and may already have some connections already in place. Atlar, for example, has over thirty prebuilt financial connections covering major banks and PSPs, plus no-code integrations with NetSuite and Dynamics 365. Since SaaS platform interfaces are designed for web browsers and are more user-friendly, treasury teams will generally require less training and specialist help, boosting platform adoption.

SaaS providers can issue regular platform updates without disrupting the service or flow of data, as opposed to an annual update cycle. This allows for continuous product improvement, and also means the provider can take action quickly on any customer feedback. From an IT perspective, often all that’s needed is to provide a working internet connection.

Launched in 2004, Kyriba and Nomentia were two of the earliest cloud-based treasury systems, followed by HighRadius in 2006. Broadly speaking, this category also includes the new wave of SaaS platforms such as Atlar itself.

Depth and complexity of functionality 

Most if not all treasury software providers offer core functionality covering cash and liquidity management, cash flow forecasting, and reporting. Some providers, including Atlar, also offer integrated payment capabilities. Sometimes termed a ‘payment factory’, this functionality lets you process payments directly in the system, automatically import account statements, and manage aspects like approval workflows and counterparties in one central place.

Beyond the core features, some systems also offer more complex functionality aimed at larger treasury departments including risk management (interest rate and currency risk), asset and debt management, and in-house banking features like cash pooling and intercompany loans.

When assessing TMS functionality, a clear distinction should be made between business-critical and nice-to-have features. More does not always equal better: additional functionality and configurability comes with higher purchase, implementation, and maintenance costs. Plus, unnecessary complexity will slow user adoption if training or specialist help is needed before a treasury team can actually use the system. Companies should weigh the expected benefits against these costs carefully.

Traditional and API-first connectivity

Connectivity underpins all treasury software. Without bank connectivity, treasury teams lack the necessary cash visibility. Without ERP connectivity, teams find themselves operating in an information silo that lacks the internal financial data needed to plan and forecast.

For a long time, connectivity in a treasury context meant bank connectivity, which in turn meant bank file formats. Legacy TMS software is designed to connect to traditional banks through well-established channels such as host-to-host, of which a Secure File Transfer Protocol (SFTP) is one example, and Swift connections. These connectivity channels use batch-based processing, meaning that data is sent on a predefined schedule every 24 or 48 hours.

Some TMS providers offer more prebuilt bank connections than others, and some have integrated more channels than others. Not all providers support regional channels like Europe’s EBICS, for example. Still, connectivity has not been as a major point of differentiation.

Two recent developments have broadened the scope of treasury connectivity beyond that of the traditional TMS. One is the unbundling of corporate banking services by API-first tools for spend management, procurement, payments, and more. Think Revolut, Adyen, PayPal, Spendesk, and others. These systems, which connect to one another almost exclusively over API, have gone from niche, specialized tools to critical parts of the modern finance stack in just a few years – leading to financial data being spread across multiple systems.

The second trend is the proliferation of real-time payment and data capabilities. Over the last decade, key parts of the payment infrastructure in Europe and the US have been upgraded to support real-time payments. Banks, in turn, have exposed their APIs to make real-time payments available to customers, leading to the exponential growth of several instant payment schemes – now used widely by consumers and increasingly businesses too.

Thanks to these mutually reinforcing trends, treasury connectivity in the future will revolve around APIs and real-time processing – as opposed to file transfers and scheduled batches. The ability to manage cash positions on demand, rather than viewing the prior day’s data, is a major advantage. In a Deloitte survey of 245 treasury leads, 86% of respondents had already implemented API connectivity or are considering doing so in the near future.

This shift presents a challenge to the legacy TMS. As of today, many such systems are unable to integrate with API-first platforms or even a traditional bank’s modern API offering. This results in siloed systems, a reliance on outdated data, and an incomplete financial picture.

‍Modern treasury platforms that have emerged over the last five or so years, in the midst of the API revolution, are one alternative. Fundcraft and Mynt are just two examples of Atlar customers that today leverage real-time bank data and payment capabilities in their treasury processes.

‍

When and why companies invest in treasury software

Broadly speaking, companies purchasing new treasury software fall into one of three categories. When considering if a TMS is right for your business, it’s helpful to think about which kind of buyer your organization represents:

• Companies with no dedicated treasury software in place and relatively standard processes
• Companies looking to change or their treasury software as part of a transformation project
• Companies that are reviewing a TMS that has been in place for several years

Companies without dedicated treasury software

The first type of new treasury software user is looking to improve existing, relatively standard processes carried out mostly manually using bank portals, file transfers, and spreadsheets.

Their overarching goal is to simplify treasury processes through the use of software. The new system should allow activities to be automated, reducing the need for time-consuming file transfers and manual data entry, and make information more accessible, leading to a more efficient use of cash. All activities will be recorded in the system too, allowing the company to demonstrate better control over its finances and provide audit trails if needed.

Companies fitting this criteria may be setting up a dedicated treasury function for the first time, or the amount of time being spent by the treasury team on manual tasks may have become unmanageable. The company’s feature requirements will be relatively standard and can be met without the need for a highly configurable TMS.

Since most treasury systems should be able to meet the company’s requirements, the selection process should focus on ease of implementation, ease of use, and the ability to connect to the company’s existing tools. Usability is a key factor since treasury software traditionally caters to the needs of large, complex enterprises. Modern treasury departments may find older systems hard to adopt without specialist help.

Companies seeking a wider treasury transformation project

The second type of new user is one which sees new treasury software as supporting a wider transformation project. These users may have a treasury solution in place, such as a TMS, but feel held back by it. It may lack specific functionality, take too much time and effort to maintain, and integrate poorly with other systems.

A common issue for this type of user is having to use multiple systems that don’t connect to one another, resulting in siloed data, multiple logins, and manual file transfers between systems. If there’s a TMS already in place, it may not connect to another finance tool that the company implemented recently. Finding a new treasury platform that unifies these systems lets the team reshape its way of working from the ground up.

Another driver could be the team’s desire to shift to more efficient, synchronous processes. Perhaps the existing solution is only capable of receiving new data in batches every 24 or 48 hours, impacting the company’s ability to manage working capital in a more agile way day-to-day. New treasury software can be used to re-engineer processes within the team itself and enable new, faster ways of working. 

Companies looking to change or upgrade treasury software will first need to validate that any new system offers the core functionality. Beyond that, the company may look to capitalize on the rise of API connectivity and real-time processing. This enables any and all sources of financial data to be unified in one platform, setting a scalable foundation.

Companies with a solution in place for several years or more

The third type is a company that adopted a TMS or similar solution a few years ago and is looking to compare it against the solutions available in the market today. The process may be driven by the company’s internal review policies or there may have been some kind of corporate event that changed its treasury requirements, such as an acquisition that introduces additional banks and currencies. Alternatively, the treasury department may be looking to reduce costs by changing the method of delivery, such as by switching to a SaaS solution.

Having had a dedicated solution in place for a while, the treasury department is likely already well-established and has a clear list of functionality requirements. The challenge here is to avoid the selection process becoming a box-ticking exercise that loses sight of the bigger picture. A bespoke, heavily configured TMS implementation may meet the company’s short-term requirements but will be less adaptable to new technologies.

‍

How much does a TMS cost?

Acquiring a TMS is costly. As with any significant expenditure, the CFO will expect to see a return on investment (ROI) analysis in advance. This can be challenging because, due to the length and complexity of the implementation, it can take several years for a traditional TMS to prove its ROI and some of the expected benefits will be qualitative in nature.

The total cost of a TMS is comprised of the initial purchase cost, a range of possible one-time and recurring fees covering implementation and data migration, and additional costs that will be felt over time such as ongoing maintenance, specialist support, and training. Most TMS providers vary their pricing models based on multiple factors, but there are some rough guidelines.

Generally, businesses with more complex treasury needs, international operations, and multiple entities can expect to invest over $100,000 per year for a robust TMS. Mid-size businesses with more straightforward needs can expect to invest up to $40,000 per year for a standard, off-the-shelf TMS solution.

On top of this, companies can expect to pay a one-time implementation fee up to 15% of the annual contract value. This fee may not include additional integrations such as bank-ERP connections, which typically cost around $5,000 per connection. Companies will also need one or more professional services during the implementation such as data migration, implementation support, and system configuration. This adds up to around 20-25% of the annual contract value.

In sum, a well-implemented TMS with some degree of configuration and up to three ERP-bank connections may cost around $160,000 in year one and around $140,000 annually thereafter. This is in line with a five-year cost estimate of $646,000 (adjusted for inflation) provided by Financial Sciences, maker of the ATOM TMS. Note that this does not include transaction fees, which TMS providers sometimes charge based on account and transaction volume.

Many users also find that there are significant ‘invisible’ costs associated with a TMS, ranging from extra implementation support and customization to delays and dedicated training resources. Specialist consultants are generally regarded as a must-have during implementation and most teams will require multiple training sessions before they can use a TMS effectively.

A TMS is a major investment that may only be worth it for more complex organizations. With an implementation time of 4-18 months, the investment can spans years even without the ongoing maintenance and consultant costs. Nonetheless, enterprises with clearly defined use cases and sufficient resources can be confident that they will see an ROI eventually.

‍

What are the alternatives to a TMS?

Until recently, any decision regarding treasury software was effectively a choice between a heavy-duty TMS with a long implementation project or sticking with spreadsheets and manual processes. A choice between legacy software or none at all. 

Given the cost of implementing technology such as a TMS (or finding the time to do so), most companies still use spreadsheets for at least a part of their treasury operations today. Spreadsheets are easy to develop, easy to use, and readily available. The issue is that they’re also prone to error, easily changed and corrupted, and require hours of manual work. Spreadsheets are a useful tool, but not a viable long-term solution in a team of any scale.

A middle ground is now emerging in the form of modern treasury platforms that combine the core functionality of a TMS with modern API connectivity, real-time reporting, and user-friendly tools. Quicker to implement and easier to use, businesses that use several or more banks but have a limited budget for tooling and IT support will find that these platforms tick a lot of boxes.

‍

‍

Implementing treasury software always requires some up-front cost and effort. Platforms like Atlar, however, greatly reduce the time it takes to see a clear ROI, lowering the risk of acquiring such software. It takes 2-3 months to implement Atlar on average – compared to up to 18 months for a TMS. And unlike legacy TMS interfaces, modern treasury platforms are designed with UX principles and ease of use in mind. This helps to make even advanced features like forecasting more readily usable without the need for specialist help or dedicated training.

Based on a SaaS model, modern treasury platforms cannot yet match the bespoke configurability of locally installed TMS software that has evolved over several decades. The largest, most complex treasury departments will likely continue to rely on their heavily customized, on premise solutions for some time. For the majority of teams, though, choosing the right TMS may increasingly mean not choosing one at all – and looking instead to its newer, more modern successors.

‍

How Atlar can help

The past twenty or so years have seen dramatic changes in financial technology for consumers. The world of business software, and treasury technology in particular, has not kept pace. The treasurer’s toolkit is overdue for an upgrade. Atlar is rebuilding it from the ground up using modern, real-time technology that lets finance and treasury teams level-up without needing a years-long implementation project, teams of specialist consultants, and never-ending maintenance work. 

Atlar provides customers like Acne Studios, GetYourGuide, and Forto with a single platform that connects to everywhere and gets you up and running in weeks. Finance teams are now better equipped to do the work that keeps our businesses running, saving hours on admin tasks and managing money more efficiently.

‍

‍‍Is your team considering a TMS but want to check if it’s really the best option? Book a demo and chat with our team about why modern teams are shifting to Atlar instead.