What tomorrow's TMS looks like...

By Steve Whalley

Working with technology in enterprise treasury, either within the treasury team or as an external consultant can be frustrating. The technology available is comprehensive but there are elements of all the solutions available that are difficult to use without ‘expert’ guidance from the supplier.

It should not be this way.
​
The tools available should be able to be configured by any competent treasury professional without the need to understand the vagaries of the system’s original design, often lost in the mists of time.

A roadmap to breaking the cycle of ever decreasing satisfaction and innovation in treasury systems

Historical perspective

Nobody set out to design treasury software that was difficult to use or to require large amounts of professional services from the vendor to implement. The leading systems have all evolved in functionality and complexity since their inception (mostly in the 1990’s) and are now complex toolkits within a ‘one size fits all’ philosophy. This complex web of technology results in a disproportionate technical debt, the proportion of development time that needs to be devoted to maintaining and testing old code. The systems become slow to respond to customers’ needs. “Customer Silos” form that are difficult and expensive to break out of.

These customer silos are self perpetuating. Once the initial technological barriers have formed, a complete internal mechanism grows up around the them. Account management shifts from a focus on customer success to revenue generation. Innovation is stifled for fear of disrupting the income stream, a case of “Don’t rock the boat”.
​
The usual suspectsDiscussing requirements with treasurers from all parts of the world and how they plan to address these issues leads to the same conclusion. They tend not to innovate or change, not because they are satisfied with their technology support, but because of the complexity and risk associated with change itself. They could move from a legacy vendor that is weak in cash forecasting but the only choice they see is to move everything to another vendor silo that produces weakness and problems in another area they were happy with.
Deloitte's survey below from 2019 still holds true.

Not only does the nature of the current TMS (Treasury Management System) landscape prevent people from changing and improving systems, ironically it fundamentally stops people adopting them in the first place. It’s like an expensive entry fee to join a club with old furniture.
In the 21st century it is ludicrous that large multi-million revenue enterprises use outdated systems for their treasury management, or worse still have none, relying on spreadsheets and the known financial and operational risks that involves. But this is still the case.
​
Escape the confusionThe current TMS landscape can be thought of like a giant Jenga tower. Impressive structures can be built and do exist, but each attempt to make a small change risks the entire system collapsing.

The situation that has grown up is the fault of no one. It is simply the result of the evolution of treasury systems over the last 30 years. They have grown organically from serving one niche bespoke area of finance very well, or through M&A activity to amalgamate systems.
If you were starting afresh, with modern technology paradigms, treasury could be redefined as “commoditised components”. Each would operate individually to known rules and solve a specific problem, but more importantly, interoperate with others in a standard and real-time way. The whole really is greater than the sum of the parts.

Following the lead of technology and innovation specialists such as Google in today’s SaaS (software as a service) world, it is now possible to efficiently and securely split the data presentation layer away from the background processing. Services can be interconnected and delivered to the presentation layer in real-time via APIs (Application program Interfaces).
Component-based development in this way reduces technical debt over the longer term. Any unit can be disconnected, upgraded and replaced at any time, without the need for large scale changes throughout the software, and real-time automated testing immediately validates the new or updated component as it is plugged in.

A complete API structure also allows flexibility in presentation. Front-end technology has been continually and rapidly expanded over the last 20 years, from Java to Java 2, Active-X to Silverlight, today the leading frameworks are Google Angular and Facebook React, new ideas arise and just as rapidly been replaced. By separating the back-end business logic, a lighter front-end application is more responsive and able to take advantage of industry-wide innovation.

As Microsoft et al move on, you are not left behind with Internet Explorer or Silverlight legacy systems that cannot progress, regardless of the quality of the underlying business application itself.

You might have a TMS system you are happy with overall but in today’s pandemic world, you really need to improve in key areas. Look for Apps that add the value you want and get your suppliers to open communication with others. If they won’t or can’t do this then prepare to change. Don’t be stuck in a silo of their making.

Play nicely together In forward-looking  solution providers, developers working with modern development tools and languages only think of communication between elements with properly documented API routines. It is second nature to them. Going even further, a single function as a Treasury user might perceive it, is broken into a collection of smaller connected modules that talk seamlessly to each other, with each piece optimised for the function it needs to perform.
​
They are many elements that go to form a comprehensive TMS. They can be broadly defined as a finite number of elements as detailed below.

---

There are different solutions available to all of these areas. The important factor is to make sure that they really operate in the cloud and can freely talk to other components, whatever the source. Some ‘private cloud’ systems may reduce internal IT overhead in managing systems, but ultimately do little to improve the quality of the service a treasury experiences.

By ensuring a component of a system has a published API environment that easily and readily talks to software from any supplier, a component-based TMS can be built that suits your needs today and allows you to quickly adapt should your business or the world change.  Swap components in and out as your need evolves and technology improves.

You could still source all your components from the same provider if that best fits your business, but importantly you don’t have to. Every component then needs ongoing care, attention and investment or it should be replaced. This brings innovation back to the industry and allows change to happen in days not months or years.

Break the CycleBy embracing new apps into your technology ecosystem you avoid one of the main roadblocks to change; risk. If you are not replacing an expensive TMS in one ‘big bang’ but gradually changing through osmosis you de-risk the whole process, keep yourself relevant and future-proof your treasury. 

If you are just embarking on the journey of treasury automation, do not tie down your long-term evolution. Simply solve your current needs in a framework that is easy and safe to expand or adapt later.

Choose modern apps that operate in the cloud and play nicely with others. Break the cycle, you’ll be surprised what you find.
_____________________________________________________________________________
Steve Whalley is co-founder at Crowd Data Systems. A longer version of this article appears here
​