Published  7 MIN READ
Please note: this article is over 12 years old. If you feel this article is inaccurate or contains errors get in touch here . Many thanks, TMI

Treasurer as Technologist

by Maciej Müldner, Treasurer, Skanska Poland

It is universally acknowledged by treasurers that the right treasury technology has a major role to play in increasing process efficiency, transparency of data and the quality of decision-making. In most cases, treasurers work with ERP or specialist treasury technology vendors to implement a technical environment that is appropriate to their business. In addition to these systems, however, treasury departments frequently have ancillary systems built in Microsoft Excel®, Access® or other database systems. By maintaining multiple systems, data may be fragmented and reporting integrity and security may be compromised by having different processes in place. In Skanska Poland’s case, we recognised the potential risks of a fragmented technology infrastructure, but our approach to addressing our technology objectives has been different from many companies, as we made the decision to develop our own systems internally.

Project background

When I joined Skanska Poland in 2002, we had a high volume of FX transactions (over 1,000 per year) including a large proportion of long-term forwards and derivatives. At that time, these transactions were stored and managed in a spreadsheet. Although this did not present any particular challenges at that time, as we had established a coherent workflow and a disciplined approach to maintaining the spreadsheet, we recognised that a spreadsheet would not be sufficiently sophisticated to manage our FX requirements once hedge accounting had been introduced. In particular, we would have had to integrate the underlying exposures, as well as the hedge transactions, into the spreadsheet, which would have made the volume of data unwieldy. Furthermore, our processes, security and data integrity could have been compromised with more people interacting with the data.

We looked more closely at the issue and recognised that firstly, we needed a database to store transactions and report on them in a consistent and secure way. Secondly, a solution had to facilitate an efficient transaction process, including input, settlement, confirmation and transaction management from inception to maturity. Furthermore, transactions would need to be linked to forecast cash flows for hedge account purposes. These would be likely to change over time, so we needed to be able to track effectiveness of a hedge, including the history of the transaction. Consequently, we needed a sophisticated and robust system that provided both analytics and reporting as well as transaction management.

We wanted the new system to demonstrate a high degree of security and prevent the risk of external intrusion.