What is a treasury system?It may appear rather obvious, but many treasurers have questions about treasury systems, their scope and functionality, and how exactly they fit in with the others systems already in use. A treasury system typically covers the treasury front, mid and back office process, meaning that it processes transactions from and including the doing of the deal, up to and including settlement and generation of accounting entries. In addition, it provides all the analyses, risk management and reporting in respect of the transactions and positions within the system. There are some important aspects of this worth emphasising. Firstly, in relation to starting point, the treasury dealer should be simultaneously inputting the deal while on the phone. There is no ‘deal docket’ being completed; it’s an on-line activity, with no interim steps or recording. In some situations, there can be a requirement for a ‘pre-deal’ phase. The key point is that the TMS should support the business process from the earliest point possible, minimising or eliminating the manual or paper-based elements. Typically, the lifecycle of a treasury transaction is completed when settlement takes place and the transaction is posted within the accounting system.The TMS should generate the settlement instructions for the treasury transactions, delivering those in electronic form to a payment system e.g. Swift or a bank payment system, or in hardcopy if that is the business process. There is less uniformity when it comes to what the various TMS will do when it comes to accounting. Preferably, the TMS will generate all the account postings, including the revaluations, for all treasury transactions, passing those seamlessly to the accounting system. Given the ever-shortening month-end processes, this level of automation is quite important.Transaction processing is just one dimension of a TMS; another is risk management. Sometimes treasurers ask to see the risk management module of the TMS, implying that somehow ‘risk management’ is separable from the rest of treasury. In reality, ‘risk management’ is – or should be – all pervasive and embedded throughout the system, especially if seen as broadly-defined and including operational risks. For this reason, a ‘Risk Module’ is something of a misnomer, confusingly implying that ‘risk’ can be confined to a specific module. The key point is that the system should process the transaction from the point of deal entry, in accordance with an embedded ‘best practice’ control framework, that provides segregation, counterparty checks, limit checks etc.In summary, the TMS would typically interface with the accounting system to deliver the account postings, and with one or more payment/banking system to give settlement instructions and/or upload account balances. In addition, it would link with a market information system to upload interest rates, exchange rates and other market prices as frequently as required. Other interfacing may be required, for example with an on-line FX dealing system, or with secondary market bond trading systems, depending on the specific environment. Managing the Project Treasury should take responsibility for the project to select and implement the new TMS. In some organisations, the IT function takes the responsibility. This can be counterproductive, with technical IT issues becoming the focus and the actual treasury requirements being less than fully understood and somewhat muddled. Clearly, all systems and IT, including those in treasury, should be consistent with the overall corporate IT policy, however, treasury should determine its functional requirements, review these with the vendors, and lead the selection process. In practice, a small team, with enough seniority to take the necessary decisions, comprising treasury, IT and led by a project manager, is the ideal way to proceed. The role of the project manager should include ensuring ongoing coordination and problem solving with the project manager on the vendor side. An agreed project plan with clear milestones should be the constant reference point for managing the project. In terms of timetable, each situation is different but realistically it requires a minimum of three months for a very straightforward application and a maximum of twelve, depending on interfacing and customisation, with six months being a good average. A very important determinant of time required is the degree to which the key users engage with the implementation effort. The ‘business owner’ of the TMS, and the project manager, need to ensure that this engagement is maintained over the life of the project.Defining the RequirementsThe critical part of any project is at the very beginning, getting the basic concept right. The treasurer is the key player and must ensure that the basic concept is appropriate to the organization and the requirements. False assumptions at the beginning can have big costs later on. Treasury systems projects can often get stuck at this point of documenting the requirements because no one involved has been through the process before. It is not an easy task and requires a different mindset than that of day-to-day treasury. For this reason it is good to involve a business analyst to guide and drive the process. Basically, what’s needed is a concise description of the treasury business requirements and the environment in terms of other systems, users and locations. The essential components to specify are: transaction types (i.e. the money market, capital market and fx transactions, current and expected), the business process/scope (e.g. cashflow forecasting, cash management, bank accounts), and analytical/reporting outputs. This need not be a very detailed document, but it should be balanced e.g. not just about ‘front office’, and comprehensive. Rather than seeing this as a single-step exercise, it can be taken as a process, starting at a high-level and detailing this as the picture becomes clearer from interaction with vendors. Most treasurers will get system presentations and seek indicative quotes as part of the initial market scanning phase, and this will allow the specification to be more fully detailed. 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 s/he is buying, and not getting sold, functionality.Many treasurers are faced with a choice between taking the treasury module of an existing ERP system or acquiring a specialist TMS. This can be a difficult decision for treasury. To some extent the easier option is to favor the ERP Module, however, it is just another option to be evaluated against the criteria set for all the alternatives. An important point to recognise is that systems vendors are well used to reviewing and understanding standard treasury requirements. What is important then is to highlight the unusual or any company specific aspects.That said, it is necessary to guard against the tendency to think that ‘we are very different’ and the standard solution will require a lot of customisation to meet our requirements. It is very important to approach any new systems implementation with the readiness to change the existing business process to match the system, rather than requiring the new system to change to match the existing business process. The latter approach can be very expensive in terms of the customisation itself and, subsequently, the ongoing support and maintenance of such a bespoke solution. A new TMS is an opportunity to review and change the business process and this should form part of the project plan.Reviewing the RFP ResponsesTreasury should aim to get at least three, preferably five, strong RFP responses. While a review and shortlisting of the RFP responses is a necessary step, a system procurement should not be a paper exercise. It is not feasible to document requirements, send them to various vendors, evaluate the responses and select. At best, this can be sufficient for initial screening but beyond that, it is essential to get an in-depth understanding of what each system can actually provide – by focusing on the actual system itself. Frequently, a list of requirements will be issued to a number of vendors, asking for Yes/No responses in terms of fulfillment. However, a ‘Yes’ response to a requirement such as ‘does your systems generate the accounting entries’ is too little information. Each ‘yes’ means something different – maybe something very different – and those differences need to be properly understood. The only way to do this is by going through the system with the vendor in detail. This is more than a ‘system presentation’ – usually a high-level overview by the vendor – but a detailed walk through the system, allowing a full day for this exercise. This is not overkill; once the TMS is selected, treasury will have to live with it for a number of years with little or no room for second thoughts, so the due diligence is worth it.In reviewing the RFP responses, clearly the functionality and price are important but so too is the actual implementation process and ongoing support and maintenance. Critical for a successful implementation process is the team the vendor will assign to the project and commitments on this should be made explicit as part of the due diligence.Build, buy or rent?Very few treasurers 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 chance that the project will fail to deliver the requirements. And then there is the longer term issue on maintaining and developing the system into the future.However, the ‘buy versus rent’ option is something to consider. Basically ‘to buy’ means buying an initial licence (meaning the right to use the software) and paying an annual licence fee (to access ongoing support and maintenance and get system upgrades), with the software being installed on your in-house IT infrastructure. The alternative ‘application service provider’ (ASP) or Software-as-a-Service (SaaS) model means that you pay a periodic user fee and the software is installed/accessed at some external facility, rather than sitting on your in-house servers. From a user perspective, the functionality is the same. Pricing – or perhaps more correctly, cashflow – and contractual and IT policy issues are the differentiating points. The ASP/SaaS approach spreads the payments over time, avoiding the up-front expenditure.BudgetTreasury systems vary significantly in price. In a shortlist of five, it would not be unusual to find that the highest priced was almost double the lowest price. Given this wide range of in pricing, it can be difficult to set a budget at the outset. In practice, treasury should be talking with a number of vendors so as to get an indication of the price and scope/functionality of the various offerings. To avoid overruns on budget or indeed on contract, treasury should look for a fixed price contract, with clarity on what’s included and excluded, and the pricing for the optional extras.The main reasons why costs can get out of control are second-thoughts on requirements and too much customisation. As already explained, treasury should carefully consider the necessity for customisation and limit this as much as possible. Too much customisation means that the benefits of an ‘off-theshelf’ solution can be eroded and the risks on cost overrun and completion increased.As a rule of thumb, the implementation cost can be equal to the software cost. To manage this cost, treasury should spend time developing or agreeing a good project plan, one that includes all the tasks and correctly maps out the critical path. Importantly, treasury needs to recognise that a systems implementation is an additional and demanding task, and a concentrated effort is required to bring it on stream. The vendor cannot do it without that treasury commitment.Conclusion Good treasury systems are essential for effective treasury management. Risk management, control, analyses and reporting can be streamlined and the hidden costs of poor systems removed. The process of acquiring and implementing such a system is a big step but a proper approach means that it need not be a daunting task, and the outcome can be assured.Written by Eddie Fogarty and published in the ACT (Association of Corporate Treasurers UK) Yearbook 2012.