Wednesday, August 11, 2010
A cash position is the cash you have/don't have or expect to have/not have across your banks at a given moment in time. You create one or multiple positions during a day, multiple if you have considerable current day fluctuation in cash and make short term investment decisions based on it. All treasury management systems or workstations should let you do that - i.e create multiple positions during the day.
During our early days at Treasury Sciences (some 3 years ago now) while responding to one of those lengthy RFP's ; we responded to a series of questions on cash positioning. The reason I recall this particular RFP is because the questions were vague. They asked if the vendor's system could create cash positions, if the system could position by currency, by country, by subsidiaries and finally by departments within subsidiaries. These were followed by a series of questions on how much effort was needed for each and so on. Well, they may not have known what they wanted when they wrote the RFP.
Since this RFP, we have met with multiple organizations who needed some combination of the above mentioned cash positioning groups (It be noted that we are yet to meet anyone who has all of the above needs). For example, some organizations would want their subsidiaries to position for themselves across currencies with the ability for central treasury/management to view the global enterprise position.
Our product team went to work and came up with a solution - TAGS.
Tags are generic, yet a very effective solution that has been used by web based applications for a while now. So, we let end users (mostly administrators) create TAG's within TS CMO. Customers can call the tag what they want (typically named a Subsidiary or a Region or a Department or something that is meaningful to the organization) and create as many tags as needed. Then administrators assign accounts and users to these tags. The system ensures that users assigned to a certain tag work within the confines of the tag- i.e they can work with only those accounts that are associated with the tag.
Within tags, users have the ability to create positions in multiple currencies- the only restriction being the accounts that they have access to based on the tags they are associated to. Finally, there is the global enterprise position - the ability for central treasury or management to view the enterprise position across currencies and tags.
From a security perspective, roles still exist and overlap with tags. For example, a user with view only access based on her role would be able view data in the accounts that she has access to based on the tag she is associated with.
We think that use of TAGS is the most effective way of providing a large organization with flexible cash positioning capabilities - end user driven, flexible, easy to manage and secure. And it just takes several minutes for an administrator to setup or change using a web browser.
Do let me know if you have questions, especially if you have similar needs and have alternate solutions to this problem.
Monday, August 02, 2010
Several posts earlier, I had described some of our Multi-GL Integration capabilities including the ability for the end user to define accounting treatment specific to their GL System(s), the ability to input data for accounting treatments upfront - while creating a payment or a forecast. I had briefly mentioned rules based application of a/c treatment to transactions as well.
Now consider typical usage of a treasury workstation.
Not every transaction is a payment originated by you and more importantly not every transaction is forecasted (even though you would like it to be). Adding a/c treatments to each transaction becomes cumbersome. Thus automated ways of application of accounting treatment to transactions become necessary, even critical to ensure STP for majority of banking transactions into the backend GL Systems.
Typically this is achieved by definition of rules in the backend, we take it a step further and let end users define these rules themselves.
In this post, we will discuss how we handle rule-based automatic application of accounting treatment to bank transactions so that these are ready to exported to backend GL System(s).
The picture above pretty much describes our approach. i.e we allow end user administrators in TS CMO to define rules per field (more than one rule per field is possible as well) in the input data. The system then applies these rules automatically to the transactions that it has imported. Note that you still have the ability to manually apply a/c treatment to transactions and any manually applied a/c treatment would take precedence over an automated rule that is setup - you will get your warning of course.
Now, let us look at couple of examples of possible rules.
A simple rule could be if Account # = XYZ, then apply the following a/c treatment - GL Number = 1000, assuming that your GL system uses one field called GL Number to book transactions.
A second example of a rule could be if Comments in the BAI file contains 'Vendor 5637829' and if transaction type is an wire, then apply the following a/c treatment Ledger=3425, Sub Ledger = 4527, assuming that your GL system uses 2 fields to define accounting treatment.
Putting it all together, what you have is flexible a/c treatments to ensure support for any GL system/ any number of GL systems and the ability to automatically apply a/c treatments that ensure that a very high percentage of your banking transactions have a/c treatment ready, to ensure accurate and fast integration to the GL system(s).
I hope this was informative and would like to hear your thoughts. Thank you for reading.
Friday, June 25, 2010
Over the last few months our product team has received multiple requests on whether we can white label our product suite for a bank or another financial institution. i.e. can we make the treasury sciences suite of products available to say, the customers of a bank via the banks portal. This post describes how a bank or a financial institution can go about white labeling our products and how it will work providing potential benefits for the bank and the bank's customers.
I am making an assumption upfront that you are the bank and that you have had conversations with us, have seen our product demonstrations, believe that our Cash Management Operations module (for the purposes of this post) will be beneficial to your customers and have decided to white label one or more of our modules- say our Cash Management Ops module.
Working backwards from the end result, the integrated white labelled solution will work as shown in the picture below.
Your bank's customer's account manager would be able to login into your banks backend administration portal and make the TS CMO product available to the respective customer - the integration that is needed will be accomplished by our product team working with the technical folks at the bank. The TS CMO system can be setup such that all relevant customer accounts are automatically loaded into it from internal bank system - again an integration point that can be accomplished at the backend. In addition to this, the third integration point at the backend between TS CMO and bank internal systems will ensure that prior and current day reporting files are automatically loaded into the TS CMO instance for the customer.
Now let us discuss some of the other key questions or features that potential customers of the bank would expect out of a Treasury Management System.
Multi Bank Connectivity
So the bank's customer is now ready to use the bank branded TS CMO product for their cash management purposes using the accounts at the bank fairly quickly . What if the customer has additional accounts at other banks that would contribute their cash position? The customer has 2 choices, they could manually upload any bank reporting files from any number of banks into their CMO instance with minimal end user setup OR setup automated connectivity between their other banks and TS CMO. Our product support team could do the integration or the bank's internal IT staff could do that.
Training
A key element here with regards to bank customer on-boarding is training the customers users. Each feature and functionality provided by our products is available as short videos that are available to users 24x7, so users can view the demonstrative videos and perform their daily tasks. Our product support team could always train the bank's support staff as well as needed. Most importantly, all our products are intuitive and easy to understand and use, there by reducing the training needs considerably.
Product Features
All treasury management features that are supported by the product module chosen will be available to the customers of the bank. A detailed look at all our product modules and the features and functionality supported can be viewed here. For this post I have chosen CMO as the product module being white labelled but do note that all our product modules can be white labelled.
Integration with a customer's internal systems
Configurability and Integration are a core strengths of our product- be it integrating into one or more GL systems to enable straight through processing or multiple systems that can forecast transactions; our product suite enables XML based standard integration features out of the box. What this means to the bank's customer is that they can use the integration features provided out of the box to integrate with any internal system they have by simply transforming the output file provided or input files required by the treasury sciences suite. Our product suite could always help them with these needs as well.
We believe that by white labeling our CMO module, a bank or financial institution can provide enterprise treasury management functionality to their customers in a seamless, cost effective way. Do let me know should you have any questions.
Saturday, June 12, 2010
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.
Monday, February 01, 2010
Recently I saw two job postings on Linkedin, I saw both on the same day which is probably why I noticed the subject matter of this post. There is something very surprising in these postings, if not bothersome. Here are some of the typical needs that you may expect and see
Prior Experience, Forecasting, Daily Positioning, Bank relationship management capabilities, Certification etc..
Now, here is the other set of requirements for a Treasury Analyst that I will discuss today which are also very common to most postings out there.
Proficient in advanced Excel or MS Access and SQL
or in some others
Must have experience with Sungard products or Oracle suite of Treasury Management Products or another vendors products. Some even go to the extent of saying that the Treasury Analyst should have worked on one of these systems for more than 2 years.
If you get a chance, please go through some of the job postings out there in the Treasury Management space. There is a good chance that you will be surprised as well.
From what I understand of business software applications (treasury management systems or treasury workstations included), the primary goal is to help the business function; whatever that function may be. Help via automation, faster processing, elimination of errors, repeatability among other but primarily - Efficiency. On a side note, I still remember (I can almost hear him even now!) an old teacher of mine yelling "Efficiency, Efficiency" on the top of his lungs explaining applied sciences and engineering.
There surely has to be something wrong with the job postings mentioned above. After all, you can't expect to add another totally different and unrelated skill set set to a cash analyst's resume and then hope that it will help with efficiency of the core skill set.
If you look carefully, you would realize that there is one of the two possibilities for the job postings mentioned above. What is even more interesting is that these two possibilities are interconnected.
Let us take the need for specific software product experience for a cash analyst first. The very reason that a specific product has to be mentioned in a job posting for a user of the system indicates that there is a learning curve involved. Users of the system have to spend considerable amount of time understanding and learning the product before they can be functional users of the product. Hence the need for specific experience; after all we all want to hit the ground running.
Now the first point. If someone is interested in expertise in MS Excel, Access and SQL it is unlikely that the organization has a treasury management system. They are making do with something less, something which was never meant to be a treasury management system. Why? Here again, chances are that these organizations realize that making do with something lesser but something much more common like MS Excel is better than hunting for users with expertise in a specific vendor's product.
Going back to my applied science and engineering reference earlier, the very point of using software is to make a business function easier, better, faster. It is to improve efficiency. Unfortunately, a lot of the products out there have missed the point.
Our group of engineers here at the Treasury Sciences are trying not to make these mistakes by providing better usability, better and faster training via product videos and making the adoption process smoother. In fact, our most important selling point or differentiator is that we can get your organization and users up and running on a enterprise class Treasury Management System faster than anyone else.
Our hope is that there will never be a job posting that says "Need cash analyst with 2 years of experience with Treasury Sciences products".
Thank you, feel free to email any comments to sujith@treasurysciences.com.
Powered by:
Copyright © Sujith Nair
|