I recently joined a conversation about – inter alia – the pro’s and con’s of building tailored solutions vs buying off the shelf solutions. The conclusion was of course: “it depends”. Getting there brought up some interesting considerations.

The allure of made to measure is always seductive, and the thrill and instant gratification of walking out of a shop with a well-fitting outfit has strong appeal. While the analogy may not exactly fit treasury solutions, there are different benefits for both building and buying. More interesting would be to have one’s cake and eat it – apologies for the metaphor overload.

Build

The allure of building made to measure is always strong. Everyone dreams of a solution tailor made for their specific needs. But even assuming those needs are realistically specified, do they have the patience to work through to such a solution?

The conclusion from treasurers who have gone down this road include:

• Building is not the fastest solution.
• Clarity about the desired solution is critical.
• The process takes patience.
• Building takes more energy than buying.
• Outcomes are not guaranteed.

Treasurers who have been down this road (and remain willing to talk about their experience) all warn that it is neither the easiest nor the quickest way to implement solutions. Even successful projects carry high risk of failure.

Whereas with an established solution, existing users can be consulted to determine if the solution works, is scalable, is secure, and so forth, in the build or co-create scenario one cannot know that a viable outcome will come from the effort.

Even if the basic algorithm works, one cannot be sure that the underlying architecture will meet corporate standards for scalability and security.

This risk is compounded when the requirements are ill conceived or poorly expressed. Buying existing solutions allows treasurers to make detailed mapping of their needs against existing implementations with high certainty that if there is a good fit the solution will work properly.

Furthermore, buying existing solutions allows treasurers to benefit from other corporate experience. Corporates may vary, but it is a common misconception that corporate requirements are unique. In the end a loan is a loan, a hedge is a hedge, and forth. (Even if emerging markets can throw up requirements that surprise even experienced system vendors.)

Buy

Buying off the shelf solutions may have less cachet than co-creation, but for many overworked treasurers the line of least resistance is attractive. There is strong appeal in buying a solution with a proven implementation and user satisfaction record.

There used to be a meme that buying SAP meant buying best practice in code. Despite well publicised cases of big implementations thrown out because they did not meet the buyers requirements, there is certainly some truth to this concept. Implementing a well-established market leading solution can at best be an opportunity to challenge and re-think business as usual.

Buying established solutions generally allows treasurers a quicker and more reliable route to resolving process challenges than building or co-creation.

These are strong benefits for buying established solutions. On the other hand, treasurers are beholden to the wider organisation, and in many cases to its history. An organisation thrown together from mergers and acquisitions, with a diversity of internal systems, may generate very unique treasury requirements such that no single off the shelf solution really meets all requirements.

Since treasurers are generally not in a position to mandate, for example, a single instance ERP across their organisations, it is often incumbent on them to adapt to the corporate eco-system they inhabit.

Middleware and data warehouses (or data lakes or even data oceans) may provide an integration layer across heterogenous corporate systems, but, again, these are not normally within treasury scope. This can leave treasurers with uncomfortable compromises around functionality. For example, the TMS best suited to integrating heterogenous ERPs may not be the best at risk management or hedge accounting.

Mash-up

For readers not familiar with the term mashup, Wikipedia offers this explanation: “A mashup (computer industry jargon), in web development, is a web page or web application that uses content from more than one source to create a single new service displayed in a single graphical interface. … The term implies easy, fast integration, frequently using open application programming interfaces (open API) and data sources to produce enriched results that were not necessarily the original reason for producing the raw source data. The term mashup originally comes from creating something by combining elements from two or more sources.”

The basic concept is that, in this time of APIs and cloud services, solutions can be cobbled together by connecting best of breed solutions into an integrated solution meeting the requirements at hand.

The trick here is to use only very open software which allows data to be shared by the different components seamlessly. Unfortunately APIs are not as ubiquitous as the hype would suggest. Many even quite modern TMSs are not as open as one would wish.

Most treasurers do not want their non-treasury colleagues to have to learn the TMS and remember more user identities and passwords – not to mention pay per user licence fees. It is clearly good practice to feed commonly used treasury data into corporate Business Intelligence (BI) solutions for consumption across the wider organisation. Many even modern seeming TMSs do this by exporting data periodically to the BI. This means the data seen by non-treasury colleagues is not real time.

The alternatives to periodic data dumps include real time APIs and database views. The former posts updates to the external system as they occur. The latter involves creating live views (virtual tables, in SQL this is written as “CREATE VIEW view_name AS SELECT column1, column2, … FROM table_name WHERE condition;”) which can effectively provide real-time read only access to external systems.

Read only access – even though far from ubiquitous – is much simpler than writing to a system such as a TMS. For two way integration (read and write), this effectively requires APIs. (Writing directly to a system’s database introduces myriad risks, not least security.)

The most rigorous systems effectively separate the user interface from the business logic and from the database. They typically use internal APIs to connect the user interface with the business logic, and optimally these APIs would be published for access by other systems and data sources. (The business logic communicates with the database via data languages like SQL, which can be considered as data APIs.)

In such a scenario, treasurers can select best of breed or at least best fit solutions for each important aspect of their requirements and connect them through APIs. Thus achieving integration of their different requirements such as:

• Balance reporting/bank connectivity.
• Cash flow forecasting.
• Risk management and exposure reporting.
• Debt management.
• Investment management.
• System of record (typically a TMS).
• Business Intelligence (BI) (typically the corporate standard).

Again, such solutions require very open systems.

Conclusion

Most treasurers will be well served by off the shelf solutions that (should) offer predictability in performance and implementation. Thinking through the pros and cons of build vs buy opens some interesting avenues for treasurers to consider in creating wider solutions to best meet their needs when single solutions do not quite tick all the boxes.