My Links
Home
Contact
RSS 2.0 Feed
Login
Archives
June, 2010 (2)
February, 2010 (1)
January, 2010 (1)
October, 2009 (3)
September, 2009 (2)
August, 2009 (5)
June, 2009 (1)
April, 2009 (3)
March, 2009 (4)
February, 2009 (3)
Post Categories
Features & Functionality (rss)
General (rss)
Payments (rss)
Treasury Management System Adoption (rss)

Barriers to Treasury Management System Adoption - Integration

Integration capabilities are a must have while considering Treasury Management Systems. Even if you are choosing multiple or all features and functionality from one TMS vendor, you still need to integrate the TMS with banks and accounting & GL systems. If you are choosing a best of breed approach, then you need a TMS module from one vendors to integrate with modules from other vendors as well. There is no getting away from integration.

A very important fact to remember regarding integration is that most organizations implementing Treasury Management Systems spend most of their time and resources on integration. Typically, Integration is the single most expensive element of a TMS implementation and lack of seamless integration options and the added cost act as a major barrier to adoption of Treasury Management Systems.

Multiple systems need to talk to each other to achieve significant business operational benefits such as Straight Through Processing. The problem with multiple systems talking to each other is that not all systems are created with similar technologies or design philosophies or with the thought that this system would have to integrate with these many other systems at a later date. It ends up more like a typical tourist asking a question in English and a native providing a response in French (or vice versa). There are two parts to successful integration, one is the ability of the native to provide a response in English and the second is the information contained in the response- hopefully the native knows that answer and can provide it in a way that the tourist understands or tell him otherwise and point the tourist to possible channels where the tourist can receive such information.

Blogs...jpg

This is where standards come in. Standards based integrations ensures that two systems meet a certain standard and use that standard (typically a format, XML) to communicate with each other. The internal implementation of functionality for each product is totally up to them, however they conform to a standard to communicate. Now this approach ensures that all products that meet the standard can talk to each other. For example, In the case of payment origination systems that support the ISO 20022 standard, a customer ultimately gets the flexibility to switch payment banks seamlessly, without any custom development if the both banks support the ISO standard.

However, not all standards are adopted, or adopted in time. Unfortunately for all of us, most of the TMS vendors, banks, ERP and other system vendors are notoriously slow in adopting the latest standards as the standards become available. Unfortunately for me, I have first hand experience in waiting for a large bank to adopt the ISO 20022 standard. It took us the best part of 8 months, hours and hours of meetings and escalations to finally get this done. Well, in the most part we actually helped the bank test their end of the system. This also leads me to how integrations are executed- note that this is of significant importance. In the case of this bank, they of course had their internal payment systems and internal payment formats. Based on my understanding of their system, what they did to integrate using the ISO 20022 standard was to create a wrapper; a wrapper on top of their existing payment format and thereby passing on any of the inefficiencies of their internal, outdated payment format to the newer format. This is a very common problem with integration- most systems do not provide enough flexibility inherently to accommodate newer standards and integrate with other systems. Like any other problem, this one has consequences as well. The system had added an additional layer of complexity and maintenance and chances are that these costs will be passed on to the customer. What is worse is that any improvement in the standard or inclusion of more features in the standard will not be implemented in the product easily.

Blogs1...jpg

There is one other thing to consider, not all integration is absolutely necessary and not all integrations provide adequate benefits and justifiable ROI. Most organizations that implement TMS do not analyze each integration from an ROI perspective. An example is a company with 1 banking relationship (for cash management reporting purposes) and one that utilizes only one current day file per bank deciding to automate the communication between the bank and the TMS. Typical integration of bank reporting files takes between a week to 3 weeks depending upon the responsiveness of the banks. Of course, banks do charge for it as well. Is it really worth it to integrate in this case?

Another example in the case of a large implementation- Integration of bank accounts from multiple backend systems to a TMS. I spoke with a large fortune 100 organization recently and found that they are integrating their multiple backend GL systems to their new TMS that they are adopting. They decided to integrate such that bank account creation, modification and deletion in any backend GL system reflects in the TMS and vice versa. So, changes could be made in any GL system or the TMS; the systems would sync information with each other and thus all systems will reflect the latest information. Cash concentration and management in their case is centralized and the have a limited small set of TMS users that help create the cash position for the day. When I spoke to them, they were 2 years into implementation and they were still integrating. From a technology implementation perspective, I can tell you that if the GL systems were considered the master record system and if this organization choose to implement one way integration- i.e. allows changes and additions to accounts only within the GL systems and reflect these changes in realtime or near realtime into their TMS; they would be done with the implementation and would be using the product now. I am not second guessing them and saying that they were absolutely wrong, they could well have had a legitimate need for complex integration. However, what I am not sure is if the question regarding ROI on this integration need was asked upfront.

Would love to hear you thoughts and experiences.

Print | posted on Sunday, August 16, 2009 2:09 AM

Feedback

# Barriers to Treasury Management System Adoption - Enterprise Wide Rollout

Barriers to Treasury Management System Adoption - Enterprise Wide Rollout
8/28/2009 2:19 AM | Sujith Nair

# Barriers to Treasury Management System Adoption - Implementation Timeline

Barriers to Treasury Management System Adoption - Implementation Timeline
9/15/2009 11:57 PM | Sujith Nair

Post Comment

Title  
Name  
Email
Url
Comment   
Please add 8 and 4 and type the answer here:

Powered by: