My Links
Home
Contact
RSS 2.0 Feed
Login
Archives
September, 2011 (1)
August, 2011 (2)
July, 2011 (2)
March, 2011 (1)
November, 2010 (1)
October, 2010 (9)
September, 2010 (8)
August, 2010 (2)
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
Cash Forecasting (rss)
Cash Positioning (rss)
Decentralized Cash Management (rss)
Features & Functionality (rss)
General (rss)
GL Integration (rss)
Hedge Fund Implementation (rss)
Integration (rss)
Multi-Currency Support (rss)
Payments (rss)
SWIFT (rss)
Training (rss)
Treasury System Adoption (rss)
Treasury Workstation Reporting (rss)

Saturday, June 12, 2010

Treasury Management System Implementation for a Hedge Fund - Electronic Payments

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:


Screen shot 2010-06-10 at 6.36.49 AM.png

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).


Screen shot 2010-06-10 at 7.01.05 AM.png

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.


Screen shot 2010-06-12 at 10.15.31 AM.png

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.


posted @ Saturday, June 12, 2010 10:36 AM | Feedback (1)


Powered by: