22
Apr 2015

Looking behind the cloud: the technology of treasury

0

A while back I wrote a rather successful article about technology in treasury called “looking behind the cloud”. It covered some of the lesser known technologies that a treasurer (often unknowingly) deals with when using a treasury system, and how these details often get overlooked in standard treasury system selection processes. Today I am kicking off the opening for our newest series on treasury technology, based on the same premise.

Treasury is new. The first reference to it was in 1975, the same time as the development of the computer, and it has been evolving alongside technology since then. Early treasury relied on the same spreadsheets, and so the development of Excel resulted in one of the first “treasury applications”, the excel workbook. And the truth is, as treasury technology evolved, it rarely did a much better job.

  • Stationary treasury workstations were one of the early developments: a single machine with a custom application. But these were often so inflexible that they didn’t provide a huge advantage from basic spreadsheets.
  • Then came networked workstations, which brought multiple users into the mix. However, their cost per workstation, and months if not years taken for roll outs, often resulted in costs too high to justify widespread usage, and thus they were often limited to the head office.
  • Treasury management systems, web based workstations accessed through a browser, were a natural evolution. They brought faster rollouts, more frequent updates, SLAs that internal IT could never manage, massively reduced need for internal IT, and more importantly they introduced the idea that multiple people can all be using the system at once, all over the world.

But treasury management systems are far more complex than the simple application and database of the old school workstation, and understanding the details of not only their software, but the technology surrounding it is difficult, even for the tech savy. When you’re talking about the financial information of an international company you need to know more than software, you need to be assured of the environment the site is hosted in, you need to know how it stores your data, the information security management system of the service provider, how it’ll work with your other systems, and what it will mean for the future of your company.

Cloud Environment: Rented vs. Vendor-designed Physical Environment

SaaS is everywhere, but not all SaaS providers are managing their own network.  This distinction is something that can easily be missed during an RFP. Their applications run in a virtual environment and the underlying physical infrastructure is managed and maintained by a third party. 

This results in two main problems:

  • The environment cannot be designed specifically for the application. 

    If the service is shared, not much can be done to customize it to the application. With a vendor built environment, when the application needs more computing power, memory or storage, the whole environment can be tailored to fit.
  • Lesser data redundancy

    Backups are common, but without a custom environment it can be difficult to go the extra step and ensure that all data is replicated in real-time to a geographically separate datacenter. But when you have a treasury platform that’s connecting to banks to execute hundreds or thousands of payments, that’s pretty important.



    To give you a better idea of what this means: each packet of data which gets sent to the datacenter also gets sent to an independent data center in a separate location. If something goes wrong, the data is still all available in a secondary location, and to the treasurer nothing changes. This way, if there’s a fire (or worse) in the data center, you don’t lose a kilobyte.

Another consideration with cloud providers is where your data is being hosted. Many cloud systems send data across multiple network providers, resulting in data crossing multiple international borders. This can create a regulatory nightmare and violate corporate policies. You can only assure that this is not going to happen when the network infrastructure has been custom built.

Single vs. Multi-tenant SaaS

Here is another major consideration when looking at a SaaS provider, there are two main types of SaaS infrastructure: single-tenant and multi-tenant, and the argument about which is better has been a subject of debate since conception.

Single-tenant: Each customer has their own database, their individual application, which exists inside the vendors hosting environment. Based on how data is segregated and maintained, providers are able to offer more flexibility on what is developed for each customer’s instance of the software. It also enables the ability to operate outside of the hosted environment, making it quite easy to move into a self-hosted environment, or even run hybrid hosted environments.

Multi-tenant: In Multi-tenant, all customers use the same piece of software, with shared core code and shared databases. This means less flexibility per user, but also less administration and greater operational efficiency. This makes sense in instances where you have a very large number of users. For example, an application with millions of accounts, like Google’s Gmail service, wouldn’t make sense to run under a Single Tenant model.

Single-Tenant System

Multi-Tenanted System

Each customer has own unique application data

Less administration and resources required per customer

Ability to meet stricter security and legal requirements

Economies of scale can be passed on to the customer

Greater flexibility for customization

Updates and patches applied once for all customers

Updates and patches can be scheduled with customer if desired

More difficult to pass strict audit as data is shared between customers.

System performance not affected by other customers

Vendor gains some operational efficiency at the expense of flexibility for the customer.

Ability to run the system “in-house” if IT or regulatory requirements change

 

Greater security/privacy

 

Greater ability to backup data

 

How do you connect to the TMS?

We’ve talked about SaaS and had a look at what is behind the cloud.   But an equally important consideration is what you need in order to  connect. Do you need:

  • A thin client?
  • A proprietary application that will need to be installed on all PCs that will use the system?
  • Terminal software?
  • A utility that connects over the Internet to another machine which contains the application and data?
  • A specific web browser?  Browser extensions like Java and ActiveX?

In the case of a thin client, utility or application, it’s probably only available on very select platforms. If you need a web browser you’re in the clear, but you still need to keep in mind whether it requires extensions like Java and ActiveX, which don’t work on all mobile devices, and may violate your IT security policy.

How do you connect the TMS to other systems?

What good is a treasury management system if you spend all your time doing data entry? You want it to integrate with your internal system, and that means establishing which systems to integrate with before you choose your treasury system. Should it connect to ERPs? Trading Platforms? Banks? It’s easy to just say yes to everything, but how hard is it going to be to build that connection?

A common technology used here is Secure File Transfer Protocol (SFTP). This is file transfer extension of the Secure Shell Protocol (SSH), designed by the Internet Engineering Task Force (IETF) in order to enable secure file transfer across systems.

ERP Systems

  • Most can use SFTP
  • Most ERP systems have full featured transformation tools or plugins available for picking up and transforming CSV files into whatever format is needed

Trading Platforms

  • No clear standard among the different platforms

Commodity Platforms

  • Formats include CSV, proprietary formats, platform-specific XML
  • Transport includes SFTP, FTP, proprietary transfer software, or manual file handling

Banks

  • SFTP and ISO-20022 XML is quickly becoming the de facto standard
  • For multiple banks, SWIFT is still your best option.

SWIFT is split into two underlying networks: SWIFT FIN and SWIFT FileACT. FIN uses the MT message format, which has stricter format requirements, leading to easier integration with additional banks. However, it also carries a higher cost per transaction. SWIFT FileACT allows any message format to be used, but requires implementation efforts for the bank, vendor, and customer, making it more expensive to set up but less expensive ongoing.

These each need to be transported into the treasury system, so you need to keep in mind what options your TMS supports and how it gets data to you.

Looking to the future

There’s a term the “network effect” that gets used frequently online. It cites that a network becomes more valuable as you add more “nodes”. In a network of people, like a social media network, this holds as well with the network growing more valuable the more users there are.

We think that this is going to play an integral role in the future of treasury.

The expanding scope of treasury requires more and more collaboration between internal departments at the headquarters as well as all of the group companies. As treasury management systems add more and more functionality, the opportunities for collaboration between different users expand. If the goal is to have a system that has as much information in it as possible, in order to give a complete global picture as possible, there should be no barrier to getting that information into the system. And once you do, entirely new possibilities start showing up.

Unfortunately there has always been a barrier: cost. Terminal based workstations require dedicated hardware that often makes it prohibitively expensive to have more than a limited number of users.

However, 1 user or 1000 has nearly no cost difference to a web based system. A user is just a data set, often even a small one. The only cost to the provider is the overall cost of hosting the data, and the bandwidth required for all of the connections that are made.



So, fictional example, a company with 100 users all making 100 intra-firm trades, is going to be using far fewer resources than a company with 3 users, each making 300,000 money market deals.

To deal with this shift in cost, treasury providers have instituted a number of different license models, from flat fees per user, to different user types, to charges per action, to a flat fee for the system and unlimited users.

The next step in treasury is going to come when we start realizing the huge benefits that occur when we start thinking about the treasury as something that exists across the corporate group, not just a department in a back office at HQ. But we’re not going to see that until providers finally see that the cost to them of having unlimited users is far outweighed by the benefit to their clients from being able to bring more people into their treasury system.

Making a choice about a treasury system isn’t rocket science, but it does require some knowledge of the technology available so as to understand how it affects processes, security and compliance. There are a multitude of options available to you at varying levels of technological complexity that can enable, protect and assure that your treasury is on the right track. You should keep in mind that not all hosting is equal, SaaS comes in multiple forms, external connections should be considered, integration infrastructure need to work with your in office firewalls, and future expansion is something you may need to consider. When moving from spreadsheets to SaaS, the technology you choose can limit the treasury to a head office or enable it to expand into the future.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
CAPTCHA

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.