What's Driving Change in Treasury Technology?
The major drivers in treasury technology in recent years have more to do with changing attitudes than actual technological advances. Many of the technologies currently being taken up have been around for some time, but until recently the business case for their use by treasury had not been made. But things are different now due to a number of factors:
We are also beginning to see some new developments in the areas of service-oriented architecture (SOA), electronic bank account management, and unified digital personal signatures. Uptake of these developments is still low, however, and they do not yet have broad acceptance.
Hosted solutions, or application service provider (ASP), have been available for many years, but until recently they were not well accepted by the treasury community. They are widely used in other disciplines, notably customer relationship management (CRM) with Saleforce.com, for example. But many treasury professionals were concerned that their sensitive data could be compromised if it were stored outside the company on another organisation’s servers. There were also worries over whether hosting companies could guarantee system access.
These fears have now been laid to rest and ASP has now taken off for real, more because of client acceptance and changed expectations than changes to the underlying technology. ASP are all SAS70 compliant, so the client knows that the hosting company has processes in place to guard and secure the data. A particular benefit is the dedicated support that comes with an ASP. Treasuries are often small departments with little visibility in a large corporate IT department. With a hosted solution they will typically get better service levels and a guaranteed up-time for the system.
So far it is mainly smaller and medium-sized treasuries that have accepted ASP but now some major treasury departments are beginning to use ASPs.
Corporates are now requesting web-enabled solutions, particularly for the systems they want to roll out to their subsidiaries and regional treasuries. IT departments no longer want the burden or cost of having to install client software on hundreds of PCs worldwide. They are now demanding that applications that require global installation must be web-based, and this is becoming the norm.
Today treasury departments are becoming increasingly centralised, but they also have to service their subsidiaries and so need to reach out to them through their treasury software for information such as cash flow forecasting and hedging transactions. Again, they have found that web-enabled applications are the best way to do this.
SWIFT has, over the years, gradually been opening its network to corporates to allow them to communicate with its banks via SWIFTNet. This process has been very slow, but the beginning of 2007 saw a change of attitude. Since then, the organisation has been heavily promoting SCORE, which allows corporates to join the SWIFT network directly, with just one agreement, instead of having to join several bank-specific user groups. Furthermore, SWIFT has standardised the messages that are allowed when using SCORE, simplifying the task of integration and connection to many banks.
Unlike ASP solutions, SWIFT adoption started with the largest corporates; only those organisations that are listed on major stock exchanges may join SCORE. For small to medium organisations, other options exist.
Even though the XML format was 10 years old in February this year, it has not yet been used in any widely accepted standard payment format. However, we are now seeing a big interest in the ISO 20022 format, especially in Europe. This has definitely been given a big push by the adoption of the ISO 20022 format for inter-bank messages related to SEPA payments. We find that many corporates now ask their vendors whether they are SEPA compliant.
SWIFT is also driving the standardisation of the formats under ISO 20022, and as SWIFT is an influential organisation that in the past has set de facto standards with MT formats, it is very likely that the ISO 20022 format will be widely used in the future.
Furthermore, several big banks have declared that bank connectivity and formats are no longer a competitive area, and they wish to co-operate with industry peers on this to make bank-to-corporate connectivity easier and less costly for all parties.
Other technologies that are around but not yet widely adopted in the treasury technology include service oriented architecture, single sign on and portal integration.
SOA is the promise of being able to string together business processes from various services, such as being able to create a process for managing financial transactions from front office to back office to accounting. The different steps in the process are services that could come from different vendors and should be easily exchangeable, such as the confirmation of the transactions or the valuation of positions.
One of the first examples of SOA we may see is portal integration. The integration of different applications into a flexible work portal has also been around for some time. This is particularly useful for occasional users, especially for reporting purposes, but it is rarely something that heavy users want. Again, at the moment this is an occasional request, however, it will definitely become more popular in the future.
Looking forward, there are two other technological developments we can expect to rise in popularity: electronic bank account management and unified digital personal signatures.
Management of bank accounts and authorised signatories is today still largely a manual process. But here SWIFT is the driving force; helping to define new XML based electronic standards. Some major banks and corporates are participating in the work group that will come up with a new ISO 20022 format for electronic bank account management. This could streamline the process and bring it into the 21st century.
Today, payments that go to a bank are generally signed by the computer that sends them. However, some corporates would like to have their payments electronically signed by real people. While this is possible, it can create a nightmare for the individuals involved, as they would have to have a different token to sign for each bank – and maybe even for each bank branch. So if the cash manager has the authority to sign for 100 bank accounts at 20 banks, that obviously means at least 20 tokens. There are initiatives that are trying to solve this problem. Identrust has a solution, but it requires that all the banks sign up to this, which they haven’t so far. In addition, SWIFT is also looking into this and has been commissioned to make a feasibility study.
Best practice in this area has not yet been established as other corporates rely on internal processes to be sure that no unauthorised payment orders leave the company. Hence this space is still open for new inventions and processes that may become the future standard.
We haven’t seen any revolution in the treasury technology space in recent years, but more of an adoption of existing technology. It is generally the job of treasurers to avoid risk rather than take it on, which may explain why they are usually not early adopters of new technology.
It is likely that technological progress in the treasury area will be driven in the near future by the emergence of standards around the communication between corporates and external parties, especially the banks. SWIFT is now a big player in standardisation, working within the ISO 20022 format and this will certainly be a major driver behind the adoption of more XML-based interfaces in the industry.