Integration

Treasury Sciences -SWIFT Connectivity

Sujith Nair — Mon, 11 Oct 2010 20:18:51 GMT

This post provides an overview of our support for SWIFT. You may know already that we support the MT and ISO 20022 payment formats for payments, transfers, credit notices etc and SWIFT 940/942 for current and prior day reporting. In addition to that, if you utilize the SWIFT network you could use one channel to communicate with all the banks- this is especially true if you need connectivity to multiple (say more than 8 or 10) of banking institutions.

The key benefit here is that you can utilize our cash management, payments system and integration capabilities - the ability to configure your own payment controls, approvals workflow, forecasting from internal systems and positioning and the ability to push data through (STP) to backend GL Systems along with the ability to utilize SWIFT Network for all bank and financial institution connectivity.

Do note that since we have in-built support for SWIFT payment formats, all you will need to utilize SWIFT is for the SWIFT network. If you would like to know more, please send me a note.

Cash Position, Multi bank payments, Payment workflow implementation, Treasury Management , Treasury Management System , Treasury Reporting

Payments, Positioning & Integration for Hedge Funds - Overview

Sujith Nair — Thu, 07 Oct 2010 06:07:41 GMT

The last 2 posts detailed out various aspects of our implementation for a large hedge fund. Todays post or picture provides an overview of the complete implementation - this picture is an early version of the picture that will appear in a case study of our payments and cash management system implementation for hedge funds. Will post a link to it when available. Meanwhile, here is the overview.

Automated Accounting Treatment, Cash Position, GL Integration, Hedge Fund Treasury, Hedge Fund Treasury Worstation, Multi bank payments, Netted Payments, Payment workflow implementation, Reporting, Straight Through Processing, Treasury Management , Treasury Reporting, Treasury Workstation, Treasury Workstation Reporting

Transaction Manager for Netted Payments from Portfolio Management Systems - Hedge Fund Implementation

Sujith Nair — Wed, 06 Oct 2010 04:51:09 GMT

In the last post, I described the integration features provided by TS EFT into Sungard VPM and other portfolio management systems. Today, I will discuss the transaction manager dashboard within TS EFT that enables end users net transactions and some other value added features.

Note: These screenshots are created from our implementation of TS EFT for a hedge fund customer. Even though the screenshots are from a test environment (we provide a user acceptance environment where end users at the customer can test and verify a feature before we push the feature out to production) I have hidden some data fields to ensure that I don't expose any customer data inadvertently.

The screenshot above shows the transaction manager screen and all features provided by it. On the left of the screen, you can see the options to view this dashboard, ability to import files manually from Sungard VPM or other portfolio management systems, the ability to map payment templates to certain fields to enable auto population of data and a screen that lists all submitted transactions.

On the top part of the screen, are the various filter criteria- here we have the ability to filter by account, fund, security type and multiple other filters. Also available is the ability to filter based on transactions that are mapped or not mapped to a template.

Do note that this screen including the fields listed and the filter options available are completely configurable to a customer's needs.

Below the filters we have the table that lists all the transactions imported from the portfolio management system - Sungard VPM in this case. Each column is sortable, the columns are configurable per deployment as well. On the left of the table are the check boxes that users can select to net transaction together.

As mentioned in my previous post, we have an automated scheduler that pulls data from VPM into TS EFT module. Additionally, we provide a quick end user import feature that enables end users to import file s manually into the system - the import screen is shown below.

Finally, a quick look at the mapped payment templates via the template mapping option on the left nav of the screen- here the system lists all the templates mapped and criteria based on which the templates are mapped.

Note that the payment template mapping criteria for this hedge fund customer is based on account type, security type and currency. This mapping criteria is again configurable and can be setup differently for another deployment.

End users can also add additional template mappings and remove existing template mappings using this screen.

Thank you for reading. Do let me know should you have a question or if you have similar needs.

Hedge Fund Treasury, Multi bank payments, Netted Payments, Treasury Management

Netted Payments from Sungard VPM - Credit Notices, Transfers and Wires - Hedge Fund Implementation

Sujith Nair — Tue, 05 Oct 2010 06:59:49 GMT

In a previous post, I had described some of the challenges and implementation details of a recent payments system implementation for a hedge fund customer. You can read that post here.

This post further details the integration of our payments module (TS EFT) with Sungard's Virtual Portfolio Manager (VPM), subsequent details of netting and eventual transmission of payments, credit notices and transfers to the banks. The picture below provides an overview of the integrated system, details follow.

Sungard VPM Integration: Scheduled exports from Sungard VPM are created and uploaded to folder from which the TS scheduler pulls the data into the TS EFT module. The file imported has a list of transactions and each transaction has a unique transaction identifier and a field that indicates whether the transaction is a new one, an update or a delete request from VPM. Note that transactions from VPM can only be updated or deleted ONLY if the VPM transaction is not part of a netted EFT transaction already. If not, the EFT has to be rejected and only then will the transaction be updated or deleted.

Transaction Manager & Netting Capabilities: The EFT transaction manager lists all imported transactions and allows users to select transactions to net based on rules that can be defined per combination of fields - for example, only certain transactions maybe netted together based on multiple configurable fields (say the clearing broker and currency) from the VPM import file. As the transaction manager is completely XML driven; the product can easily be configured to support other portfolio management systems such as Advent Geneva. It can even be configured to integrate with in-house portfolio solutions.

Template Mapping: TS EFT supports creation and use of templates for all payment transaction types - note that these are templates that are independent of the banks themselves. The transaction manager also allows to map templates to end user selected mapping criteria based on data in the VPM input file. Here again, you could create and map templates - one per clearing broker and currency thereby requiring the user who nets the transactions to create the EFT to enter minimal information on EFT origination.

Payment Types: For this customer deployment, their custodial accounts are at BONY and CSFB has their prime broker accounts. Cash positioning for the custodial accounts held at BONY is done via TS CMO module and hence the need for forecasting for BONY accounts. Based, on the mapped templates or banks and accounts selected on free form transactions, the system presents the appropriate forms. The payment type selection criteria and associated transaction types for payments, notices and forecasts is described in the picture below.

A note about SWIFT for transmission: Our customer choose to utilize SWIFT for transmission to the banks (CSFB only, we communicate directly with BONY). It should be noted that if the payment bank supports secure transmission via FTP and since Treasury Sciences EFT supports standard formats such as ISO 20022 and SWIFT MT files, you do not need to use SWIFT only for transmission- it may not be cost effective.

I will describe some of these features using screenshots from the application in a later post. Thank you for reading.

Hedge Fund Treasury, Multi bank payments, Netted Payments

Customer Hosted Treasury Management System Deployment

Sujith Nair — Mon, 27 Sep 2010 22:05:51 GMT

This morning, we responded to a request from a large corporation wanting to know if we support customers hosting our treasury management system in-premise at their location and what our self-hosted deployment model would be like. This post talks about what we offer for customers who need the treasury workstation deployed in-house.

As you probably know by now, Treasury Sciences provides hosting, managed services and support for all treasury management system modules, but if your organization's policies require you to utilize an in-house or in-premise hosted system we offer that as well. In fact, we have a hedge fund customer that has deployed our cash management operations and electronic funds transfer modules at their data center.

This chart shows you at a high level what an in-premise deployment would look like (our managed services team would provide relevant details to your IT folks). All modules and services shown below are deployed behind a firewall, we will need in-house IT involvement to provide us the connectivity, access etc but for end users of the treasury workstation it will be the same- they will access all features via a web-browser. We do offer managed services and support for in-house deployed systems as well.

Thank you for reading, do let me know should you have any questions.

In Premise Deployment, Treasury Management , Treasury Management System , Treasury Workstation

Treasury Management System Implementation for a Hedge Fund - Electronic Payments

Sujith Nair — Sat, 12 Jun 2010 17:36:51 GMT

We recently completed an implementation of our product suite (cash management operations module and electronic funds transfer module) for a large Hedge Fund. This customer uses our EFT module to make payments for margin calls, to manage excess collateral, netted transfers between accounts or to make vendor payments.

In this post, I will share some of the key implementation details of the electronic funds transfer module for this customer, hopefully this information would be useful for other organizations (especially hedge funds) that are planning on implementing an electronic payments solution.

Systematic enforcement of Payment Policies & Procedures: One of the primary needs of this hedge fund customer was the ability to systematically enforce their specific payment policies and procedures. Their policies of payment approval and release described a group of payment originators and another group of payment approvers. The originators would originate payments- either free form wires or wires based on pre-approved templates. One approver would then approve the payment and then the policies requires another approver from the same group of approvers to approve the wire again before systematic release to the payment bank. Note that template based originations made it easier to approve- i.e. the approver already knows that the template is approved which implies that all beneficiary information is approved, so all an approver has to verify is the specific value date and amount.

The TS product team configured the a 3-step workflow as described above and created 2 roles- originators and approvers. These are the only 2 roles that would now participate in the workflow (Yes, system administrators do not have any visibility into the payment approval or release process) .The procedure/policy implementation for this hedge fund customer is below:

TMS software needs to support configurable workflows and roles that can then be tailored to a customer's specific business requirements. If configurability is not an option, then either the customer has to live with a new process dictated by the system or spend significantly on customization.

Support for multiple payment banks: Ability to connect with multiple financial institutions to make payments and transfers while maintaining a seamless end user experience was another key requirement- well supported by Treasury Sciences EFT module. The additions we made for this implementation (and for future needs) was support for additional payment formats. EFT supports the ISO 20022 standard out of the box; now we have added support for SWIFT MT messages as well. Together with that we created a custom adapter for another financial institution; which will eventually be replaced by a standard payment message format (SWIFT MT or ISO 20022).

The key feature TMS's and financial institution's need to provide is the support for payment standards - a standards based implementation reduces time and cost and increases changes of successful implementation. From what I have seen so far, support for either the ISO 20022 (preferred because of the XML based implementation and improved definition) or the SWIFT MT format is required.

Netted Payments: The next key implementation need was the ability to net payments and transfers originating from an investment/portfolio management system (in this case it was Sungard's Virtual Portfolio Manager) and generate netted transactions to multiple financial institutions- the business benefit being the reduction in the number of transactions (wires) and thus cost. Netting capability for payments is a new feature that was introduced into the EFT module and here is a quick overview of its capabilities.

Some of the interesting challenges related to netting were in ensuring that the appropriate validations were in place so that a user does not net transactions that they were not supposed to be netted together, the ability to make sure that a netted transaction that was originated as a payment or transfer is not made available to be netted again, associating appropriate accounting treatments and approval processes to each payment. As part of the netting capability we introduced a transaction manager - a dashboard that lets users manage transactions, import, sort, filter and net. As has been our practice, we have made this functionality fairly configurable and ready to meet the next implementation challenge.

As a final note, one feature not to forget is Ad Hoc reporting capability. I have discussed the importance of reporting multiple times before, so would not go into details again. However would add that no business system or software should exist without a powerful and secure reporting engine- it solves so many problems and is typically very beneficial to users of the system.

Thanks for reading, I will discuss additional features and benefits in a later post.

Hedge Fund Treasury Worstation, Hedge Fund Treasury, Multi bank payments, Netted Payments, Payment workflow implementation

Treasury Sciences Cash Forecasting Capabilities

Sujith Nair — Fri, 23 Oct 2009 20:47:40 GMT

In this post I will highlight typical challenges in implementing a short term cash forecasting system and discuss the options we provide as part of our product suite to address cash forecasting needs.

Most potential customers and customers that I have talked to understand the importance of cash forecasting and have some form of cash forecasting capability- they have some systems that contain partial forecast data or could possibly provide partial forecast data. If not systematic, most organizations at least have a spreadsheet or multiple spreadsheets.

Typically, most organizations lack in timeliness and accuracy of their cash forecasts and in decision making capabilities based on consolidated enterprise wide forecast data from say multiple subsidiaries or multiple systems.

We will look at how we could help address timeliness and accuracy of consolidated enterprise wide forecasts systematically via our product suite.

Bulk Upload of Forecasts

If your forecast data is stored in a spreadsheet or can be put into a spreadsheet, we provide you with the ability to upload the spreadsheet into the system. This is the easiest and fastest way to manually upload multiple forecasts from multiple subsidiaries into the system. There are multiple value added feature associated with this as well- such as the forecast dash boards which lets users view the forecasts, edit and delete forecasts as well as roll back complete files that were uploaded into the system. You can reimport rolled back files as well.

Ours being a web based system users with appropriate privileges can upload data or view forecast data across subsidiaries and geographical boundaries.

Automated Import of Forecasts

Automated integration of forecasts from external systems that originate these forecasts via transactions (trades from a Trade Management System, Debt Payments or schedule from a debt management system and EFT origination data from an EFT system are examples) is the best way to ensure timeliness and accuracy of forecasts. Via a standard XML and web services exposed by our system, we have the ability to integrate with any system there is - provided the system we need to integrate with is an open system. i.e. the external system or an intermediate system needs the ability to communicate to a web service.

If you were to choose our Electronic Funds Transfer Module or upcoming Debt Management Module, it is already integrated to the CMO Module for Cash Forecasting purposes. Here again, there are multiple value added features that ensure upto-date information reporting and accuracy such as the creation of a forecast in CMO as soon a transaction is originated and the removal of the forecast from CMO if the transaction in EFT were to be rejected by an approver.

Manual Creation of Forecasts

We provide you the ability to create manual forecasts as well. Users with appropriate privileges can use web based forms, you can create and manage forecasts. This feature is typically useful while forecasting incoming transactions from systems that do not have integration capabilities.

Echo Backs

This feature is typically useful to forecast bulk payments. Say your AP system send a bulk file systematically to a bank with no human intervention. For forecasting purposes, we need to find out the appropriate amount that was sent to the bank with the appropriate value date. Now, there are 2 approaches to getting this data - (1) we could connect to the backend A/P system via the external integration capabilities discussed earlier or (2) we could have the bank tell us what they received- which is essentially the echo back.

An echo back is an automated transmission from the banks that lets our system know the most upto-date information on the bulk payment file. This communication typically contains totals and value dates and is sent by the bank as soon as it receives/processes the file. Our system in turn creates appropriate forecasts for the respective value dates automatically.

The four capabilities discussed above provide the ability for an organization, no matter what their situation is, to forecast enterprise cash accurately in a timely manner. There are multiple value added features in addition to the specific options listed above such as forecasting dashboards, calendar based views, ad hoc reporting capabilities, automated and manual reconciliation of forecasts, ability to capture accounting treatment on forecast creation and integration based on standards, all of which would help your organization forecast better.

Please do let me know if you have any comments or questions @ sujith@treasurysciences.com

Barriers to Treasury Management System Adoption - Integration

Sujith Nair — Sun, 16 Aug 2009 09:09:21 GMT

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.

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.

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.

Barriers to Treasury Management System Adoption - Customization, Lack of Configurability

Sujith Nair — Sat, 15 Aug 2009 04:28:41 GMT

In the last post, we discussed extensively about demerits of the "Big Bang" Approach and the benefits of prioritization of needs and incremental adoption. We also looked at configurability of software products and how it enables Treasury Management Systems to meet enterprise needs and challenges of an organization, as these needs arise. Technology is what brings us a Treasury Management System. However, in many cases improper use of technology combined with unnecessary processes act a barrier to adoption - I will look at each of these in some of my future posts.

This post focusses on configurability, or the lack of it and the unfortunate but all too common need for customization of a Treasury Management System to meet an organizations needs.

Configurability essentially provides the end users of a product or managed services and support users the ability to configure the product to meet the organization specific needs. A simple example here would be Ad hoc reporting. The ability for end users to create conditional query based reports, save, share and export data. A more complex sounding example here is the ability for and end user to configure their TMS to create an appropriate output for each GL system of theirs- each having its own defined accounting treatment. The second example may sound complex, and in most cases extensive customization of the TMS is required to achieve it.

Another example could be a organization that is in transition- say from a decentralized payment approvals model to a centralized payment approvals model or vice versa. Most TMS out there would require considerable time and effort to accomplish such a task and consequently most organizations wait till they have accomplished the transition and then consider adopting a TMS Payment module.

Now, let us not confuse customization with configurability- customization requires a product implementation consultant to create multiple reports for you or to write new code such that the TMS can integrate with each GL system or accommodate your specific payment approval processes. In other words, configurability acts as an enabler, enabling an organizations need for change. Need for customization reduces the ability of an organization to meet with changes, without considerable investment in time and effort and thus in cost. Customization acts as a deterrent to Treasury Management Adoption, and rightly so.

Let is first look at how configurability is achieved and why most systems fall short and need extensive customization. Most of the large TMS our there are a conglomeration of multiple products - well in most cases a conglomeration of products from multiple independent companies that were bought by a parent company and somehow sold as one product. Seamless integration of these products is in simple terms very difficult and requires time and resources; which unfortunately is challenging even for the largest of the TMS vendors out there. Hooks are built in at multiple places within each product so they can talk to each other. The problem with this is that any change or configurability of one product will affect the very functioning of the other products that are connected to it. These products were never meant to be working together. End result is that end user configurability options are not provided by the vendor and custom configuration for a customer is expensive. A possible solution to the problem mentioned above is to pick products that are built from the ground-up. Configurable products that use the latest stable technology and utilize standards where available.

Ultimately, lack of configurability and the need for extensive customization,both upfront and as and when an organization's needs change result in additional time and resources, impacting the ROI for TMS adversely. If you have not adopted a TMS so far or have limited adoption, chances are that you agree with and understand some of the challenges that I have described above. If you have implemented a solution and agree or disagree with the post, please let me know your thoughts. I will continue this thread on subsequent posts, meanwhile please feel free to post a comment on what your thoughts may be.