My views in this article are based on work with a wide range of European and US treasuries, and others further afield, e.g. South Africa, and covers corporate, financial institutions and finance ministries. Despite the differences in terms of culture and practice, it is remarkable how similar treasury is from country to country, organisation to organisation, and how the same issues arise for treasury system implementation.
Most treasuries are not in a ‘steady state’ in terms of systems and technology; most have some issues – big or small – to be addressed. Many treasuries struggle with problems of data integration, analyses and reporting, and the ongoing business of transaction processing and control. Others get by with inadequate systems, knowing that they carry cost inefficiencies and control weaknesses. Spreadsheets are still widely used because they are readily available, they can be easily changed and initial costs are low. Therein lays their weakness. ‘Treasury by spreadsheet’ can lead to a plethora of fragmented models and reports, duplication of data, methodology that is regularly changed and, as a result, understood only by the current expert.
‘We Must Do Something About Our Systems’
The prompt for change comes from either growth, corporate change, acquisitions and spin-offs, or some requirement – small in itself, but the final straw that breaks the camel’s back is creaking ‘legacy’ systems. In terms of company/treasury size, once the transaction volume reaches a certain level, ‘treasury by spreadsheet’ is no longer a viable option. The critical size-threshold for treasuries to upgrade is actually not that high because spreadsheets mean too much operational risk. For the same reason, legacy systems that no longer support the current business, or are poorly supported, also lead to the one conclusion: ‘We must do something about our systems’.
On top of the cost/risk pressure to upgrade, there is the added value. The treasurer is a knowledge worker. Information, judgement and decisions are the essentials of the trade. Working at the interface with the financial markets, and managing the exchange that takes place, the treasurer either takes value from, or gives value to, the market. Knowledge workers cannot function without information. Raw data is not good enough. It has to be ‘information’ – it has to inform, add knowledge and insight.
Treasury cannot afford process failures; the potential costs are too high. Rather than thinking that treasury systems should support the business process, my view is that the treasury system should be the business process. This means that the workflow, business rules and controls should be embedded within the system. A large part of the risk management process in the broadest sense should be within the treasury system. Security and control should be achieved through the treasury system. In the past, locked doors were important for security; now secure systems through which all transactions must flow, subject to embedded controls, are the critical component.
The critical prerequisites and decisions in the upgrade decision are two-fold: the requirements specification, i.e. ‘what do we need’, treasury system versus enterprise resource planning (ERP) system, and the available time and resources for the implementation process itself.
I am taking it as a given that no organisation today would dwell on the ‘build versus buy’ decision. The systems available on the market mean that an internal systems development simply does not make sense. The costs and the risks are too high. The costs include the resources/time requirement for treasury to provide the functionality specifications; the risks include the probability that project will fail to meet requirements. And then there is the longer-term issue of maintaining and developing the system into the future.
‘What Do We Need?’
The critical part of any project is getting the basic concept right. Too often this is the stage that is rushed. The treasurer is the key player obviously and must ensure that the basic concept is the right one. False assumptions at the beginning can incur high costs later on.
Many systems upgrade projects get stuck at this point. Documenting the requirements is a one-off or, at most, an infrequent task for most treasuries. In my view, this is a task that is primarily for treasury. The essential components to specify are:
- Transaction types.
- Business process/scope.
- Analytical/reporting outputs.
It is critical that the treasurer describes these in detail, and they are documented and brought to the level required to ensure that the requirement is fully understood by the vendor. A pitfall to avoid is to let IT determine the solution or create a requirements specification that focuses on technology.
The concept/specification need not be set in stone at the beginning. Most treasurers will get system presentations and seek indicative quotes during the procurement phase, and this will allow the specification to be filled out. However, the treasurer must guard against ‘design creep’, i.e. an accumulation of a lot of small additions, each perfectly justifiable on their own but when taken together, results in a moving target of ever expanding size. Importantly, the treasurer needs to watch that they are buying – and not getting sold – functionality. In my view, one of the common over-specifications is in relation to value-at-risk (VaR), a methodology that is applicable mainly to bank dealing rooms.
Treasury System or ERP?
ERP systems are those that seek to cover all business function within the organisation – manufacturing, supply chain, HR, etc – and treasury. By definition, they are big systems, albeit available on a modular basis, and are priced accordingly.
Other than for the largest organisations, if an organisation is not already using an ERP system, it is a very big step to acquire such a system to fulfil treasury’s needs. If an organisation is already an ERP user, it is still an open question. The ERP cost and functionality should be assessed in comparison with the alternative.
The alternative is a treasury system, generally lower priced and generally quicker and easier to implement.
Treasury/IT does not need to adopt a stance on this at the beginning. The cost/functionality can be assessed from the proposals submitted, bearing in mind that it is a moot point that ERP systems are integrated: all modern systems can be integrated. Importantly, the requirements specification needs to identify the integration points and scope of the upgrade; typically these would include the accounting, payments and market information systems.
‘What Should We Spend?’
Everyone knows of a systems project ‘from hell’ – it cost a fortune, took forever and in the end failed to deliver. My view is that treasury systems have been overpriced, probably reflecting the extent of consolidation and amalgamation on the vendor side, as well as the pricing power of some of the larger brands. In the past, treasury had a certain mystique and, for example, if you understood options, you were something of a wizard. Treasury had become more mainstream, and treasury systems equally so. My perception is that treasurers recognise the overpricing and that there will be a move towards more modest-sized, smaller footprint systems and implementations that do not overwhelm users and their budgets. Certainly, treasury systems can be expensive projects – but they don’t need to be.
The hosted system approach from an application service provider (ASP), where effectively you rent the system, has been a response to the high cost of the standard in-house solution. The ASP approach does not in itself change the underlying economics, i.e. the costs of software development, configuration and customisation. Yes, it is a different method of deployment and a different pricing model, but is it really the case that vendors are pricing their system on a lower real cost basis when their business economics are fundamentally the same?
The Selection Process
The key point I would emphasise in relation to the selection process is that treasury needs to allow enough time to look into the shortlisted systems in detail. A standard system presentation is sufficient only for short-listing purposes. Treasury systems are complex – ‘functionally rich’, if you prefer. It is actually difficult to see all that a treasury system can do – and cannot do – in less than a full day going through the system with the vendor.
The format of the ‘specification of requirements’ varies a lot from company to company, but a common approach is to produce a checklist of requirements. This checklist approach has a number of weaknesses, the main one being that two very different systems can give the same ‘yes’ and ‘no’ responses to any such list of requirements. In other words, this is a fairly broad-brush approach to comparing complex systems. For example, most systems can do ‘mark-to-market’ but the real question is how do they do this: what is the methodology? A much more in-depth approach is needed to bridge the gap between the vendor and the treasurer. This needs to go beyond the traditional system ‘demo’.
There is a challenge for systems vendors to make the acquisition of new systems as painless as possible. This means having the necessary treasury expertise to bridge the gap between the two specialist worlds of IT and treasury. Without this, there are two sets of experts, talking different languages. If the vendor has to involve another company to achieve this, a ‘Big 4’ company for example, this can be a source of cost escalation, a second bite of premium pricing to be factored in to the overall cost.
Making the Leap Forward
The financial crises and resulting austerity climate has created a cost reduction environment with all budgets, including IT, being cut. On the other hand, it has put a focus on more rigorous financial management. Sound financial management is vital for survival and good systems are key to this. My view of the market is that there is an appetite for systems investment but with an added emphasis on value for money. This underlines my view that the market wants affordable systems – systems that meet real, practical business needs at an economic cost.
Modern business requires that we are all knowledge workers. In the overall evolution of things, time spent just looking for things or collecting data is a waste of valuable resource, especially in treasury where there is huge scope to add enterprise-value. Treasury will continue to embrace technology.
When Mark Cuban declared that "Data is the new gold" he highlighted why information is possibly the most valuable asset a business has. APIs are the unsung heroes that make it possible to extract that value.
How treasury stands to benefit from blockchain: Ripple’s goal to revolutionise cross-border transactions
Imagine a world where cross-border transactions can occur in real-time, at a few cents per transaction, to and from any bank, in any ... read more
Europe’s opening banking regulation is finally here. After months of preparation across the continent, the Revised Payment Services Directive comes into effect on January 13.
The revised Payment Services Directive regulation, regarded as one of the most disruptive in Europe’s financial services sector, will begin to make an impact on January 13, 2018.