Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Acquiring & implementing a new treasury system


Published on

Article written by Eddie Fogarty, Managing Director of FTI. Published in the ACT International Treasurers Handbook 2012.

  • Be the first to comment

Acquiring & implementing a new treasury system

  1. 1.                    ‘Designed by Treasurers, for Treasurers’   Acquiring and Implementing a New Treasury System Written by Eddie Fogarty and published in the ACT (Association of Corporate Treasurers UK) Yearbook 2012.Most treasurers will implement a new treasury management system (TMS) at least once intheir professional lives. Many will do it just once. Being an infrequent experience, it can be adifficult task. Because of the perceived difficulties, many treasuries put off the job andstruggle on with inadequate systems and manual processes far longer than they should. Thispresentation looks at the process from the treasury perspective and offers guidance on how tobest structure and manage the key elements of the process so as to achieve the desiredoutcome.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 inuse.A treasury system typically covers the treasury front, mid and back office process, meaningthat it processes transactions from and including the doing of the deal, up to and includingsettlement and generation of accounting entries. In addition, it provides all the analyses, riskmanagement 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 startingpoint, 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 orrecording. In some situations, there can be a requirement for a ‘pre-deal’ phase. The key pointis 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 andthe transaction is posted within the accounting system. The TMS should generate thesettlement instructions for the treasury transactions, delivering those in electronic form to apayment system e.g. Swift or a bank payment system, or in hardcopy if that is the businessprocess. There is less uniformity when it comes to what the various TMS will do when itcomes to accounting. Preferably, the TMS will generate all the account postings, includingthe revaluations, for all treasury transactions, passing those seamlessly to the accountingsystem. Given the ever-shortening month-end processes, this level of automation is quiteimportant.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 thatsomehow ‘risk management’ is separable from the rest of treasury. In reality, ‘riskmanagement’ is – or should be – all pervasive and embedded throughout the system, © FTI 2012
  2. 2. especially if seen as broadly-defined and including operational risks. For this reason, a ‘RiskModule’ is something of a misnomer, confusingly implying that ‘risk’ can be confined to aspecific module. The key point is that the system should process the transaction from thepoint of deal entry, in accordance with an embedded ‘best practice’ control framework, thatprovides segregation, counterparty checks, limit checks etc.In summary, the TMS would typically interface with the accounting system to deliver theaccount postings, and with one or more payment/banking system to give settlementinstructions and/or upload account balances. In addition, it would link with a marketinformation system to upload interest rates, exchange rates and other market prices asfrequently as required. Other interfacing may be required, for example with an on-line FXdealing system, or with secondary market bond trading systems, depending on the specificenvironment.Managing the ProjectTreasury should take responsibility for the project to select and implement the new TMS. Insome organisations, the IT function takes the responsibility. This can be counterproductive,with technical IT issues becoming the focus and the actual treasury requirements being lessthan fully understood and somewhat muddled. Clearly, all systems and IT, including those intreasury, should be consistent with the overall corporate IT policy, however, treasury shoulddetermine its functional requirements, review these with the vendors, and lead the selectionprocess. 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 clearmilestones should be the constant reference point for managing the project. In terms oftimetable, each situation is different but realistically it requires a minimum of three monthsfor a very straightforward application and a maximum of twelve, depending on interfacingand customisation, with six months being a good average. A very important determinant oftime 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 thisengagement 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. Thetreasurer is the key player and must ensure that the basic concept is appropriate to theorganization and the requirements. False assumptions at the beginning can have big costslater on.Treasury systems projects can often get stuck at this point of documenting the requirementsbecause no one involved has been through the process before. It is not an easy task andrequires a different mindset than that of day-to-day treasury. For this reason it is good toinvolve a business analyst to guide and drive the process. Basically, what’s needed is aconcise description of the treasury business requirements and the environment in terms ofother 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 businessprocess/scope (e.g. cashflow forecasting, cash management, bank accounts), andanalytical/reporting outputs. This need not be a very detailed document, but it should be © FTI 2012
  3. 3. 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 ahigh-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 initialmarket 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 ofsmall additions, each perfectly justifiable on their own but when taken together, results in amoving target of ever expanding size. Importantly, the treasurer needs to watch that s/he isbuying, and not getting sold, functionality.Many treasurers are faced with a choice between taking the treasury module of an existingERP system or acquiring a specialist TMS. This can be a difficult decision for treasury. Tosome extent the easier option is to favor the ERP Module, however, it is just another option tobe evaluated against the criteria set for all the alternatives.An important point to recognise is that systems vendors are well used to reviewing andunderstanding standard treasury requirements. What is important then is to highlight theunusual or any company specific aspects. That said, it is necessary to guard against thetendency to think that ‘we are very different’ and the standard solution will require a lot ofcustomisation to meet our requirements. It is very important to approach any new systemsimplementation with the readiness to change the existing business process to match thesystem, rather than requiring the new system to change to match the existing businessprocess. 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 TMSis an opportunity to review and change the business process and this should form part of theproject 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 systemprocurement should not be a paper exercise. It is not feasible to document requirements, sendthem to various vendors, evaluate the responses and select. At best, this can be sufficient forinitial screening but beyond that, it is essential to get an in-depth understanding of what eachsystem can actually provide – by focusing on the actual system itself. Frequently, a list ofrequirements will be issued to a number of vendors, asking for Yes/No responses in terms offulfillment. However, a ‘Yes’ response to a requirement such as ‘does your systems generatethe accounting entries’ is too little information. Each ‘yes’ means something different –maybe something very different - and those differences need to be properly understood. Theonly way to do this is by going through the system with the vendor in detail. This is morethan a ‘system presentation’ – usually a high-level overview by the vendor – but a detailedwalk through the system, allowing a full day for this exercise. This is not overkill; once theTMS is selected, treasury will have to live with it for a number of years with little or no roomfor second thoughts, so the due diligence is worth it.In reviewing the RFP responses, clearly the functionality and price are important but so too isthe actual implementation process and ongoing support and maintenance. Critical for asuccessful implementation process is the team the vendor will assign to the project andcommitments on this should be made explicit as part of the due diligence. © FTI 2012
  4. 4. Build, buy or rent?Very few treasurers today would dwell on the ‘build versus buy’ decision. The systemsavailable on the market mean that an internal systems development simply does not makesense. The costs and the risks are too high. The costs include the resources/time requirementfor treasury to provide the functionality specifications; the risks include the chance that theproject will fail to deliver the requirements. And then there is the longer term issue onmaintaining and developing the system into the future.However, the ‘buy versus rent’ option is something to consider. Basically ‘to buy’ meansbuying an initial licence (meaning the right to use the software) and paying an annual licencefee (to access ongoing support and maintenance and get system upgrades), with the softwarebeing installed on your in-house IT infrastructure. The alternative ‘application serviceprovider’ (ASP) or Software-as-a-Service (SaaS) model means that you pay a periodic userfee and the software is installed/accessed at some external facility, rather than sitting on yourin-house servers. From a user perspective, the functionality is the same. Pricing – or perhapsmore 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 tofind that the highest priced was almost double the lowest price. Given this wide range of inpricing, 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 ofthe price and scope/functionality of the various offerings. To avoid overruns on budget orindeed on contract, treasury should look for a fixed price contract, with clarity on what’sincluded and excluded, and the pricing for the optional extras. The main reasons why costscan get out of control are second-thoughts on requirements and too much customisation. Asalready explained, treasury should carefully consider the necessity for customisation and limitthis as much as possible. Too much customisation means that the benefits of an ‘off-the-shelf’ 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 thiscost, treasury should spend time developing or agreeing a good project plan, one that includesall the tasks and correctly maps out the critical path. Importantly, treasury needs to recognisethat a systems implementation is an additional and demanding task, and a concentrated effortis required to bring it on stream. The vendor cannot do it without that treasury commitment. © FTI 2012
  5. 5. 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. Key Point Summary      For more information on FTI and our systems, or to arrange a system’s presentation, please contact: Eddie Fogarty, Email: or                                 FIKON TREASURY AND I.T. (PTY) LTD, UNIT 10, GOLF GARDENS OFFICE PARK, HIGHVELD, CENTURION, SOUTH AFRICA © FTI 2012