When Colt Technology Services, a multinational telecoms company headquartered in the UK, decided to replace the spreadsheet-heavy processes underpinning parts of its treasury operations, it was not looking for a technology upgrade so much as a change in operating model. The company was becoming bigger and more complex. Treasury, its leadership concluded, had to catch up.
This was the clearest message from a recent webinar hosted by Redbridge with the Association of Corporate Treasurers (ACT). Also joined by two members of Colt Technology Services – Will Foster-Kemp, Vice President, Tax and Treasury and Pascaline Barbier du Doré, Group Treasurer – the discussion amounted to a case study of how companies should think about selecting a treasury management system: not as a simple procurement exercise, but as a strategic decision with consequences for the next 5–10 years.
This long horizon matters because a treasury management system has an impact on much more than just treasury. It touches payments, cash visibility, controls, forecasting, accounting interfaces, bank connectivity and, increasingly, the data architecture on which future automation and AI use cases depend. Choose a system that has limited functionality, and it will limit you even before the implementation dust settles. Buy one that’s too complex and your business risks years of cost for functionality it may never use.
“The whole concept of onboarding a new treasury management system can be daunting. It’s expensive, it’s quite complex, and it’s going to have a massive impact on the existing organization”, Foster-Kemp explained during the webinar.
At the end of 2023, Colt acquired the EMEA business of Lumen Technologies, a US telecoms firm. This $1.8bn deal changed the treasury equation. Colt’s operating environment had become larger and more demanding, with revenue above €2bn, a wider country footprint and increased currency complexity. The existing treasury set-up was no longer proportionate to the business it was designed to support. Notably, its treasury processes had become too manual to ensure cash was always available in the right currencies.
In Redbridge’s experience, this pattern is common. Companies don’t usually change their TMS because they’ve suddenly developed a taste for transformation projects. They do it because manual work starts taking too much of their highly qualified teams’ time, because control structures become inadequate to cope with the value of payments being handled, or because the business has begun to demand analytics and forecasting capabilities that spreadsheets and legacy tools cannot deliver. While a TMS project often begins as a discussion about technology, it is really about efficiency, governance and visibility.
This was certainly the case for Colt. Its shareholders wanted better reporting on the company’s cash positions, investments and forecasts, while its treasury team needed something more resilient than a patchwork of manual processes. The company’s response was not to start with vendors. Instead, Pascaline Barbier du Doré described how the firm first took the time to understand the current state before trying to define the future set-up.
Colt’s treasury team, working in partnership with Redbridge, began by mapping what it was producing manually, what worked, what did not and where the weaknesses lay. Only then did it address broader issues, asking questions such as: what might change over the next 5–10 years? could legal entities be separated? might it make another acquisition? would its investment strategy evolve? would its foreign exchange hedging become more sophisticated? what new payment types or bank statement formats would have to be accommodated?
In Colt’s case, the TMS project was going ahead at the same time as changes resulting from the ISO 20022 messaging standard and the firm migrating its ERP platform. This shows how treasury technology decisions can take place against a rapidly evolving regulatory and corporate backdrop and that companies need to take into account a wide range of variables.
It’s in this kind of environment that an external adviser can add considerable value. Redbridge’s involvement provided Colt with an experienced, independent sparring partner to envision and co-construct the roadmap for its treasury function. This enabled Colt to choose a system that not only looked right during the demonstration phase, but also proved a good match for the organization’s size, operating model and future needs.
An adviser, in Foster-Kemp’s words, provides “a sober voice in the room” – someone able to give an informed opinion, taking into account a company’s size, ambitions and critical requirements, on which TMS providers truly deserve a place on the shortlist of contenders. This is vital because treasury teams can easily be drawn towards systems that are powerful in theory but burdensome in practice. “Don’t end up spending a lot of time and money implementing something that is just way too complicated for you”, was the essence of his warning.
This was pertinent for Colt’s own decision-making. While cost and flexibility were high on its list of priorities, the treasury team faced significant internal pressure to consider SAP. This platform is often an excellent choice for large organizations but, according to Foster-Kemp, seemed complicated and would be expensive to adapt to the specific needs of Colt’s treasury team. The challenge, then, was not merely to find a good system, but to find one that was a good match for Colt’s.
Redbridge made it clear to Colt that a strong request for proposal process is about focus, not breadth. Longlists can provide a sense of false comfort, and considering more than five or six providers in an RFP tends to create noise rather than provide additional insight. The aim of the RFP process is to eliminate ambiguity early on, translate treasury requirements into concrete use cases and require vendors to provide demonstrations based on the workflows the team will use every day. A product can outperform its rivals on paper but be a bad match if users dislike the interface, the logic or the way key processes are executed. In treasury technology, usability is not a cosmetic issue – it’s part of risk control.
The project also exposed an enduring debate about TMS implementations: cloud versus on-premise. Most implementations now sit in the cloud, with some larger organizations favoring private cloud structures. True on-premise deployments have become rarer, partly because the economics have changed. Fifteen years ago, a critical payments environment might have justified the cost of hot standby systems, maintenance teams, disaster recovery sites and test environments. Today,infrastructure and service capacity can be bought from specialist providers, often more efficiently and with greater resilience than corporates can attain in-house.
The shift to the cloud does not remove security concerns – it simply changes how they are addressed. For Colt, which has experienced a cyber incident in the past, data protection and operating resilience were non-negotiable. Pascaline Barbier du Doré and Will Foster-Kemp both made clear that security protocols had to be built into the implementation from the start. That meant scrutinizing attestations such as SOC 2, reviewing penetration testing standards, understanding encryption of data flows and ensuring authentication requirements align with internal security expectations.
Connectivity is also an important consideration. Banks, the speakers suggested, are largely agnostic when it comes to which TMS their clients select. But the shape of the banking footprint still matters. In some cases, a host-to-host connection may make more sense than SWIFT, especially if a company has a concentrated banking structure in a given country. In others, API connectivity is becoming more attractive because it can deliver real-time information rather than end-of-day reporting. The broader point is that a TMS must fit the reality of the company’s connectivity requirements, not an abstract model of best practice.
If selection requires realism, implementation requires stamina. On this point, Barbier du Doré was unequivocal. Companies routinely underestimate the burden a TMS project places on company resources. In particular, the work can’t be done in the background alongside people’s day jobs. Colt assigned a full-time dedicated resource to the project, and even then the effort demanded sustained involvement from treasury, IT and other teams including accounting and FP&A.
Three stages, she noted, are especially time-consuming: data consolidation and cleansing; discussions with banks about connectivity; and integration and testing. Each sounds manageable in theory. In practice, however, each can involve weeks of work and expose unresolved issues elsewhere in the organization. That’s why project management becomes so important. The project manager is not there merely to make sure timelines are adhered to, but to preserve momentum across functions that all need to support the project but may struggle to prioritize it in practice.
It’s also important to remember that not every challenge a treasury team faces should be dealt with in a TMS project. For example, Colt chose to keep bank rationalization and bank fee optimization separate from the system implementation, having already reviewed cash management pricing during the integration of Lumen. This seems a sensible decision – trying to renegotiate services, rationalize accounts and establish new connectivity arrangements at the same time can overwhelm both the treasury team and its banking partners, especially in more fragmented or administratively demanding markets. Redbridge notes that some countries, particularly in South America, can be especially challenging in this regard.
The webinar also broached the topic of AI. Despite the hype, Pascaline Barbier du Doré said AI did not play a direct role in Colt’s TMS selection or implementation. Yet neither she nor Redbridge dismissed its relevance. In treasury, AI’s near-term value lies less in choosing systems than in exploiting the data they generate and centralize, forecasting, predictive trend analysis, anomaly detection and fraud management. A well-implemented TMS that is connected to ERP, trading and investment platforms can create the kind of structured data environment. But using AI is not a substitute for getting the foundations right.
The most important conclusion from Colt’s experience is that the case for a TMS is rarely sector-specific and is increasingly hard to reduce to a simple revenue threshold. It is a question of operational complexity: how many banks, how many accounts, how many currencies, how much manual reconciliation, how much visibility is missing. Once treasury moves beyond a handful of banks and manageable account structures, the cost of not industrializing the function begins to rise quickly.
The deeper message from the discussion was that a TMS project is won or lost long before the system goes live. It is shaped by the honesty of the initial diagnosis, the discipline of the shortlist, the realism of the implementation plan and the willingness of the business to resource the project properly. For Colt, growth made the decision unavoidable. For other companies, the trigger may be different. But the aim should be much the same: make a strategic choice of platform not just for the treasury you have today, but for the one your business will require over the next decade.