Press Release template

Document Sample
Press Release template Powered By Docstoc
					What are the technology
requirements of corporate
treasurers today?
By Joergen Jensen, director of product management, Wall Street Systems, February 2008

A modern corporate treasury is bound to use a number of systems to support different
functions. These systems will have some level of integration and functionalities may
even be bundled together in a single application.
There are many factors to consider about technology for corporate treasuries today. Depending on which
application is being used, different things have to be considered such as:
    • Infrastructure
             o Hardware and operating system
             o Database
             o Backup and disaster recovery
             o Hosting vs. in-house installation
    • Application architecture
    • Interfaces
    • Rich client vs. thin client
    • Real-time processing

When it comes to the technology in the corporate treasury department, the organisation’s internal IT staff are
naturally involved in choosing the right solution. But there are many other factors that also play a role. These
     • Company IT policies
     • Volume and scalability requirements
     • Geographical rollout and reach
     • Security
     • Budget

In some cases, the systems and technology comes with the chosen business partner. For example when you
choose a partner bank it will supply the technology for sending payment files and receiving bank statements. In
other cases, such as choosing a treasury management system, the technology and application structure will
play a far more important role.


With most corporate treasuries, the choice of hardware, operating systems, and selection of database is left to
the IT department, or is dependent on what the chosen application can run on. Furthermore, arranging back-up
and providing disaster recovery is left to IT. In some companies – even in a multi-billion Euro turnover company

                                                                                                        Page 1 of 4
– the treasury department is relatively small, so it is often difficult for them to get the appropriate resources from
IT to install and support the corporate treasury system.

This is where hosting or the application service provider (ASP) delivery model may be a more viable choice.
This means the corporate treasury system is hosted on the supplier’s servers, and back-ups and recovery
processes are carried by the supplier rather than by the company. The treasury department gains access to the
system via the internet or a direct leased line.

Depending on a company’s transfer pricing a choice of hosting may look more or less attractive. If internal IT
costs are not charged to the treasury department using the IT resources there is no transparency of the internal
IT costs, so hosted services may not look the most cost-effective option. However if internal IT charges the
treasury department for the services it uses, there is more transparency and therefore it will be easier to
determine whether hosting is cheaper than running the system internally.

But ASP is not just about budget – it is also about service levels. When a leading corporation headquartered in
Germany recently had to choose a new corporate treasury system it was important that the solution was a
hosted one. Its internal IT department did not have specific treasury management system knowledge and was
also engaged with other projects. “We chose the hosted solution not simply because it was less expensive, but
because it could bring a higher service level to the treasury department,” said the deputy treasurer.

Today any hosted service provider has to fulfil the SAS 70 standards, which tests the effectiveness of a service
organisation’s internal controls and data security safeguards. Using a SAS 70 certified ASP solution will
guarantee high levels of service, while also delivering a more transparent service level.

Application architecture

Most organisations aim to use their treasury management systems for five to eight years, before looking to the
market again. It is therefore vital that the chosen treasury management system also has a modern architecture
that can scale with the business as it grows and has enough capacity to handle increased volumes. Corporates
should not invest in a treasury management system that simply suits them at the present time, as this could be
a straight jacket for future growth.

Choosing a treasury management system with the right architecture can be a trade off between flexibility on one
hand, and implementation effort and time, on the other. A mid-sized corporate treasury might not have the
resources to implement a complex treasury management system, whereas some cash and treasury
management packages, for example, won’t be able to fulfil the needs of a corporate treasury with a large debt
portfolio and complex risk management requirements.

At the same time the treasury management system should also be future-oriented in several respects:
     • It should be able to cope with higher volumes for the future if it is likely that the business will expand
     • It should be able to cope with investments and acquisitions of new companies
     • It should be flexible enough to keep up with technology developments

The corporate treasury’s activities and scope may change over time, so it is also important to choose an
application with a future proof architecture. Today virtually all treasury management systems have a
client/server architecture and are using a common database for storing the data. However, how the system
distributes the computation load between the client (typically a PC) and the server (for example a UNIX
machine) can be very different and can greatly influence the performance of the system. The ability to scale the
system is limited with a client based application, whereas if the system makes more utilisation of the server
there is increased opportunity to improve performance. This is especially true if the system can scale
horizontally (adding more machines).

                                                                                                           Page 2 of 4
It is difficult to determine which architecture is best because this depends on the individual company’s industry,
size, policies and future.


Interfaces play an increasingly important role. No treasury management system today is a self-contained island
– it must have a number of interfaces.

“When we last chose a new treasury risk system, the software’s ability to interface with other systems was
essential,” said the deputy treasurer at a major European corporate that has recently chosen to implement a
new treasury and risk management system. “It was important to us that the interfaces were flexible and could be
changed without the help from the supplier.”

This is a view that is echoed by many other corporate treasurers. Interfaces now take care of increasing
amounts of data coming in and out of the systems used by the treasury department in the name of straight-
through-processing. Re-keying is no longer an option for many corporate treasuries.

But implementing an interface must also be outweighed against the benefits. If you only need to upload a few
accounting figures once a month, it can cost more to implement, test and maintain the interface than it costs to
do key in of the data.

Corporate treasuries also have to consider the security and confidentiality of data when creating interfaces. Very
often files are downloaded and uploaded as data moves between systems. This opens up a possibility for
manipulation of the files.

Banking interfaces are especially vulnerable because fraudsters typically have a lot to gain from their
manipulation. Different technologies are used to encrypt and sign files, but the data is still modified in mapping
tools, which can also be used by a fraudster to manipulate data to their advantage. It is a matter of making it as
difficult as possible and here internal policies and processes count just as much as the technology itself.

SWIFT is now promoting the corporate access to SWIFTNet more than ever and it is likely that more and more
corporates will use this way to communicate with their banks for payments and confirmations. Using a direct
connection from the ERP system, treasury management system, cash management system, or payment factory
to SWIFTNet will also increase the security as SWIFT will guarantee the delivery of the message once SWIFT
has received it.

Rich client or thin client

The importance of integration is echoed by Jan van Trigt, treasury controller responsible for Treasury IT at ICI, a
major producer of paints, adhesives and specialty products. He stresses that it is also important to be able to roll
out the access to the treasury management system worldwide in an easy way. This is best done through the
usage of web-interfaces. “With a web enabled application it is easier to operate when people in a number of
sites are working in the same chain. “

He uses the example of how access to banking portals for corporates has improved, making it easier to spread
the process of approving payments across many sites. You may have shared service centres in India that do
the first level of approval for payments and people in the treasury department of the head office making second
level approvals. With a web-enabled banking application this is not a problem, whereas with a traditional
banking application on a PC in the treasury, this would not be possible.

Depending on the functionality required rich clients can be more appropriate. When it comes to delivering real-
time information and providing real-time monitors to the user’s desktop, rich clients have been the choice for
system vendors. However, the differentiation between rich and thin clients is blurring. Traditional thin client web

                                                                                                         Page 3 of 4
applications are quickly improving thanks to new web technology. On the other hand, Java applications can be
delivered via the internet. The end-user does not know that the system downloads an application before it runs.
This removes the need to distribute the software to desktops, and can therefore bring the full advantages of the
rich and thin clients’ approach.


Right now there are discussions and movements around bank mandate processes and the processes for
signing of payment files, for example. The next level in the system architecture is the so called Service Oriented
Architecture (SOA), where you can exchange the “services” in a system. This may also be applicable to treasury
systems where you will be able to exchange a valuation library without changing the risk management system.

There is no such thing as a final list of technical requirements from a corporate treasury today. The
requirements depend on many factors and internal priorities, as we have seen in this article. But it is clear that
corporate treasuries today are demanding more than they were a few years ago. They now demand true and
secure straight-through-processing with a treasury management system that is easy to roll-out worldwide,
supporting processes that span the globe. So when choosing the technology for the treasury department today,
one should be vigilant about what is going on in the market and what the requirement of tomorrow is likely to be.
They should also ensure that the treasury management system can either be easily replaced or upgraded to
fulfil these requirements.

                                                    – ENDS –

                                                                                                       Page 4 of 4