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

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 in
their professional lives. Many will do it just once. Being an infrequent experience, it can be a
difficult task. Because of the perceived difficulties, many treasuries put off the job and
struggle on with inadequate systems and manual processes far longer than they should. This
presentation looks at the process from the treasury perspective and offers guidance on how to
best structure and manage the key elements of the process so as to achieve the desired
outcome.
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,
© FTI 2012

2. 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 Requirements
The 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
© FTI 2012

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 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 Responses
Treasury 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.
© FTI 2012

4. 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.
Budget
Treasury 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-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 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.
© FTI 2012

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: efogarty@fti.ie or efogarty@fikon.co.za
FIKON TREASURY AND I.T. (PTY) LTD, UNIT 10, GOLF GARDENS OFFICE PARK, HIGHVELD, CENTURION, SOUTH AFRICA
© FTI 2012