Selecting a Treasury Management and Modelling Tool at PPL

Published: August 01, 2010

Linda McDonald
Manager, Financial Settlements and Controls, PPL

Selecting a Treasury Management and Modelling Tool at PPL

Featuring Linda McDonald, Manager, Financial Settlements and Controls, PPL

During 2009, PPL embarked on a selection process for a new treasury management system (TMS) to provide treasury front-office capabilities for deal capture, risk analysis and cash management. 

PPL has centralised its domestic financial activities into a treasury centre in Pennsylvania. Its European operations are managed through a centre in the United Kingdom which reports back to the head office but has a separate processing and technology environment. Our treasury centre is responsible for all the domestic treasury and cash management requirements across the United States. Payments and collections are managed in a central treasury operations group and over the past 10 years the processes have been consolidated but each group uses different systems.

Financial processing optimisation 

Around five years ago, encouraged by requirements under Sarbanes-Oxley Section 404 and our own desire to increase financial and process efficiency, we completed a business case for a new system to combine payment and collections processing. We recognised the similarities between these two areas, and wanted to realise the potential synergies in processing and internal controls. Based on this business case, we established a single set of business processes. This was a particularly important element of our overall strategy as we maintain our own internal lockbox and process a very high volume of utility payments. This settlement centre incorporates imaging software and effectively acts as a digital mailroom. Payments and collection advices are generated within the business, approvals are conducted through front-office systems managed by the relevant departments, and approved instructions are then passed electronically to the settlement centre.

Front-office technology requirements

While the settlement centre has proved very effective for processing our payments and collections, we also need a more robust front-office system for managing our treasury activities, which would then be integrated with our settlement centre for transmitting treasury payments. We have an existing treasury management system (TMS) that we acquired in 2002. Although this system met our requirements for a number of years, we need additional functionality for our current portfolio.

Although cash management may typically lead most treasury system selection projects, our debt requirements were more significant for our technology choice, as we are a capital-intensive business with a large asset base. We have a very substantial, complex debt portfolio with a variety of structured deals. Just as our options for a new system were limited in 2002, it was evident that while our cash management needs could be supported, most TMS currently available would not be capable of managing our debt modelling and risk analytic requirements, which include Value at Risk (VaR) and Cashflow at Risk modelling. We briefly considered building our own TMS, based on our experiences with our settlement system, and built a requirements specification for a bespoke system in parallel with sending requests for information to potential third party TMS vendors. However, one of our objectives is to maintain our systems environment according to industry best practices and we recognised that the resource and investment requirement to achieve this with an in-house system was likely to be too high. 

System selection process and decision-making

We initially reviewed three alternative systems in detail, as well as looking more widely at systems available in the market, but in many cases these vendors needed to propose combined solutions involving multiple systems. We decided that a multi-system solution would not be sufficiently integrated or cost-effective for our needs; in addition, we considered the treasury module provided by our ERP vendor, but this module was not able to meet our requirements either.[[[PAGE]]]

We also needed to decide whether to have a hosted solution or to manage our TMS environment in-house. We opted for in-house management in order to have greater control over the environment, such as the timing of upgrades, and to enable us to develop our own reports and system interfaces. During the selection process with our short-listed vendors, we worked through examples of actual PPL deals and saw how each of these could be modelled in each system, including reporting output, accounting etc. 

Based on our functional and technical requirements, we ultimately decided to implement Wallstreet Suite, delivered by Wall Street Systems. There were various reasons for this, including the system’s ability to support our instrument modelling requirements, cash forecasting capability, accounting configuration, integration abilities and reporting tools. In addition, these capabilities were all provided through a single database. We will use Wallstreet Suite as a front-office system for treasury, as opposed to leveraging its payment factory capabilities, except for producing treasury payments, which will then be passed to the settlement centre.

From selection to implementation

Having selected a new TMS, we have established clear implementation objectives. In addition to replacing our existing capabilities, we are seeking to automate our hedge effectiveness testing and hedge accounting, enhance the quality and transparency of the reporting that we produce, and improve our workflows and business processes. Ultimately, our aim is to manage all of our treasury and cash management requirements in a single system, as opposed to maintaining ancillary spreadsheets and manual workflow processes. 

We have recently started the implementation of Wallstreet Suite, with two weeks of initial training and additional workshops to scope the project and construct a project plan. The key project tasks will commence in July/August 2010, with the aim of conducting unit testing by year end 2010, and user acceptance testing during Q1, 2011. If we achieve these milestones, we should be able to go live on the new system at the end of Q1, 2011. The initial project will include replacing the activities we currently conduct in our TMS and re-mapping some business processes.  

There are some areas that we have not yet decided whether to include in the first or subsequent project phases such as in-house banking for inter company settlement and integration with our online investment portal to achieve straight-through processing. In a future phase, we will consider additional value-added functions such as SWIFT connectivity and electronic bank account management (eBAM).

We wish PPL every success with its implementation and look forward to speaking with Linda again once the project is complete.   

Sign up for free to read the full article

Article Last Updated: May 07, 2024

Related Content