|
Blog Stats
|
|
|
Blogs -
5
|
|
Posts -
60
|
|
Articles -
0
|
|
Comments -
9
|
|
Trackbacks -
22
|
|
|
|
Bloggers (posts, last update)
|
Sujith Nair
(51,
9/6/2011 1:18 PM)
Rajiv Popat
(6,
12/1/2010 7:32 AM)
Shashank Kajaria
(2,
4/20/2011 9:45 AM)
Soumik Bose
(1,
4/29/2009 7:48 AM)
|
|
|
|
Treasury Sciences EFT is a web-based multi-bank payment origination system. It allows for custom payment workflows and controls, ability to set per-transactions and cumulative limits at multiple levels, allows free-form and bank independent template based and netted payment originations and supports ISO 20022, SWIFT MT and even custom bank formats for payment transmission to banks. The key differentiator between TS EFT and other systems (bank provided and otherwise) is that most if not all payment approvals processes and controls that are needed to meet an organization's specific needs is accomplished in TS EFT via configuration.
This post looks at couple of typical payment origination processes and controls that can be configured within TS EFT. The first scenario shown below is a typical configuration of TS EFT for an organization that utilizes one payment bank and needs free-form, template based and netted originations with dual approval. Note that TS EFT provides payment controls such as the differentiation of payments users from administrative users - ensuring that a user has permissions to originate or approve the creation of a bank account does not have the ability to originate or approve payments and vice versa.

The second scenario described below discusses a more complex configuration of EFT (note that this is still configuration and not custom development or customization of the product) wherein an organization needs 2 different approval processes - a one step approval process for payments originated from pre-approved templates for the treasury organization (typically for net-funding or concentration wires) and a dual-approval process for all payments from subsidiaries. Also note the connectivity to multiple payment banks as well.
|
|
This is the last in the series of posts that describes the ability of TS CMO to support multiple centralized and decentralized cash management and positioning needs of enterprise organizations. Today we will look at how TS CMO can be configured for a case of completely decentralized cash management. (Please read the first post the describes a centralized scenario as well as the second post on a decentralized cash management scenario and a third post on another decentralized treasury scenario)
Decentralized Cash Management - Consider an European corporation with operations in Europe, North America and in ASIA with each subsidiary managing their cash and investments respectively)

The scenario described above can be configured in TS CMO by creating the specific treasury operational entities needed viz. Europe, Asia, US and Canada and by assigning the respective users, user groups and accounts or account groups to it. Another treasury operational entity called "Enterprise" is created for management that needs visibility across all entities. A depiction of the the configuration is shown below.

To summarize this series of posts
Treasury Sciences CMO provides the ability for end users to configure the system based on their specific treasury operational needs- be it centralized, decentralized or a mix of centralized in certain areas and decentralized in others. It also provides the ability to adapt to changes in your organization, be it the acquisition of a subsidiary that you choose to run autonomously or consolidation of cash and investment management across subsidiaries.
|
|
This post continues the series of posts that describes the ability of TS CMO to support multiple centralized and decentralized cash management and positioning needs of enterprise organizations. Today we will look at how TS CMO can be configured for a case of decentralized cash management that is even more complex. (Please read the first post the describes a centralized scenario as well as the second post on a decentralized cash management scenario)
Decentralized Cash Management - Consider an European corporation with operations in Europe, North America and in ASIA, the European organization managing the treasury (cash and investments) for Europe and Asia while the US subsidiary manages cash and investments for North America (US and Canada)
Note that the above scenario is an example of a de-centralized scenario for the enterprise with centralized cash management across subsidiaries in specific regions. This scenario is described in a a bit more detail below that highlights the need, the various file types and connectivity involved as well as the need to support multiple backend GL systems. You can read more about the GL integration capabilities of TS CMO here and here.
To accommodate this need 2 Treasury Operations Entities are configured in TS CMO- "North America" and "Europe & Asia" and respective users or roles and accounts or account groups are assigned. US users are assigned the "North America" Treasury Operation Entity or Tag and European users are assigned the "Europe & Asia"tag. Now users in the respective organizations can perform their day to day forecasting, reconciliation, positioning, reporting and other functions w.r.t the specific set of accounts. As noted previously, not all accounts need to be used position and they can be classified as such.
A third Treasury Operational Entity called Enterprise is created with access to all accounts and is assigned to a specific set of senior management users who need access to data across the enterprise- Note that users using this entity will use it for view only access as the cash management functions are performed within the "North America" or "Europe & Asia" entities created earlier. This configuration is described below.

|
|
Todays post continues that series of posts that describes the ability of TS CMO to support multiple centralized and decentralized cash management and positioning needs of enterprise organizations. Today we will look at a case of decentralized cash management. (Please read the first post the describes a centralized scenario as well)
Decentralized Cash Management - Consider an organization head quartered in the US with operations in US and Canada, the US organization managing the treasury (cash and investments) for the US and the Canadian subsidiary managing their cash.
A decentralized cash management scenario is described below - the organization receives BAI files from banks and proprietary investment updates in the US and Bank proprietary files for cash and investments in canada. Cash management and Investments are decentralized and taken care of by treasury users in respective locations. Also note that two backend GL systems that TS CMO synchronizes with are part of this setup as well. You can read more about the GL integration capabilities of TS CMO here and here.
To accommodate this need 2 Treasury Operations Entities are configured - Canada and US and respective users or roles and accounts or account groups are assigned. Now users in the respective organizations can perform their day to day forecasting, reconciliation, positioning, reporting and other functions w.r.t the specific set of accounts. As noted previously, not all accounts need to be used position and they can be classified as such.
A third Treasury Operational Entity called North America is created with access to all accounts and is assigned to a specific set of senior management users who would need access to data across the enterprise- Note that users using this entity will use it for view only access as the cash management functions are performed within the US or Canada entities created earlier. This configuration is described below.

It is important to note here that we went from centralized positioning (described in the previous post) to decentralized positioning purely via end user configuration. It is also important to note that in the event that a new user or set of users need to perform a cash management function, all an administrator has to do is to assign that user or the role of the user to the appropriate tag using a web browser. We will look at the same feature set in even more complex scenarios in the next couple posts. Thank you for reading.
|
|
Over the next 4 posts, I will describe the ability of TS CMO to support multiple centralized and decentralized cash management and positioning needs of enterprise organizations. To start, we will look at less complex scenarios and move towards the more complex models.
Centralized Cash Management - Consider an organization head quartered in the US with operations in US and Canada, the US organization managing the treasury (cash and investments) for the entire enterprise.
The centralized cash management scenario is described below - the organization receives BAI files from banks in US and Bank proprietary files for cash and investments in canada and investments in the US, it has one backend GL system that TS CMO synchronizes with. You can read more about the GL integration capabilities of TS CMO here and here.
TS CMO allows for the configuration of this model via the creation of cash operations entities or tags. In this case, since all cash management is done by the central US organization one cash operations entity (tag) called North America is created by the end user. All bank and investment accounts across the enterprise (US and Canada) that are used for cash management purposes (note that accounts can be marked as not used for cash management as well, useful when concentration accounts are used for positioning) assigned this tag. Appropriate users or roles (groups of users) from US treasury organization are assigned this tag as well ensuring that they can position for US and Canada.

Once a US treasury user logs, he or she will be able to position both in USD and CAD for the enterprise without any custom development effort. Exports to the backend GL system can be automated . In the above example the only transformations needed are to transform the proprietary bank and investment formats into TS XML format and transformation of the TS XML GL export to Oracle GL Specific format. Note that these transformations are fairly quick and either the TS managed services team or your internal IT team could do that.
In the next post, we will look at a decentralized cash management scenario.
|
|
Hi folks, this time I will be introducing you all to our new product from the Treasury Science Product Suite in the field of Analytics namely Enterprise Treasury Analytics (ETA). This would be our very first step towards data analytics, and as it is popularly said and believed that “Charity begins at home” we too stuck to this and developed a tool which is integrated with one for our flagship product CMO and analyzes the data stored by it. ETA’s rich user interface and graphical presentation allows you to decipher the data in a very interactive manner. The web based application comprises of two kinds of reporting capabilities, i.e. Adhoc and Canned. Adhoc Reports are easy to create because of its XML based configuration, whereas Canned Reports are system defined and are developed based on certain specific user requirements and criteria. Canned Reports also give the capability to view both the chart and the data together for a more comprehensive analysis. Currently we have created a couple of reports both Adhoc and Canned based on the data stored with CMO which are generic in nature and gives a birds eye view of the treasury to our existing clients. Let me explain a few reports which we have been working on: Investment Position Report: This is an Adhoc Report providing you with details of your Investments. Based on the simple logic that your Total Investment would be equal to all you Current Investments minus any Redemption/Maturities for the period you are running the report. You have the ability to drill down into minute details of your investments and redemptions and identify any kind of pattern.   Balance Report: This Canned Report, reports the different kinds of summary balances of each account which you have with your banker such as the Opening Available Balance, Closing Available Balance, Opening Ledger Balance, and Closing Ledger Balance and so on. Balance of each accounts are reported and grouped allowing you to analyze the data by viewing the charts. The report equips you with the ability to run a trend analysis of different balances across currencies for each account across all your banks.  Transaction Summary Report: You can view the summary of the different type of transactions executed by you using our treasury products both EFTNextGen and CMO across currencies over a period of time and determine the most availed service from your banker and the volume of the transactions.  Daily Cash Position Report: To sum up all your daily treasury activities which would also work as an icing on the cake at the end of the day is this Cash Position Report which would not only define the Preliminary Cash Position and the Final Cash Position but also by how much the two differ in both absolute and percentage terms.  ETA’s ability to tailor views and groups of data based on your organization's unique needs is sure to make a difference in the way you have been managing your Treasury.
|
|
Ideally, you would like to try out the software or application with your data, see if it works for you and then make a purchase decision. We make that option- Free trials of the product - available to any organization that wants to try out our products as well. Over the last few years, many organizations have tried out our products and made purchase decisions after their key users were comfortable with the product features.
Now, more than once we have been asked how we are able to let users try out our products so easily and why deployment of the product for a customer is so quick.
The answer lies in how we built the product, how it is hosted and how the product team has made it easy for us to make an instance available to an organization.
One of my favorite lines when I talk about the product is that "This product was built from the ground up". What that means is that the suite of treasury sciences products were designed and built - every screen, every feature built, every element of the user interface - everything was built by our product team. In other words, no other product or products were modified or customized or tailored to make this suite of products.
Starting from a blank slate gave our product team the opportunity to make the appropriate and best available technology, architecture and design choices for the business problem we were trying to solve. One of the goals we had upfront was to enable organizations to try our product out as easily as possible and adopt very, very quickly. Usability of the product was always critical and was considered every step of the way.
Secondly, everything we offer is web-based. The application is hosted on our datacenter, it can be hosted on the cloud as needed as well.
Finally, I get a notification when an organization registers for a trial and I have one button to click - the system is automatically deployed and emails with credentials are sent out to the organization that registered along with a wizard that helps them get started very very quickly. The product team has set it up such that it is that easy for me to setup an instance for a potential customer. Here is the process in a bit more detail.
|
|
There are multiple ways to assign accounting information to your transactions using Treasury Sciences. This is the information that typically flows through to your accounting system when you use our Cash Management Operations product for straight through processing. Each one of these methods is potentially a blog post in themselves but we thought we'd take some time and give you a quick overview of options that exist. I. Accounting Information using Forecasts. This by far is the most round about way to apply accounting information to your transactions. Having said that this is also the most convenient way if you are used to the idea of entering accounting information when you are creating EFTs or when you are forecasting the transactions that will show up first in your current day file and eventually in your prior day files. The implementation is fairly straight forward. You go into the Treasury Sciences Administrator and define the fields that you want to pass on to your accounting system. While creating the fields you define the basic meta data associated with the fields. For example, the data type of the field, the validations associated with the field etc. Creation of these fields is also an interesting topic that we will cover in a separate post but for now, lets just say that the creation of these fields is a one time task that you can undertake using the user interface the product provides you with. Once these fields are created for a subsidiary, every time that subsidiary makes a wire (or you make a wire on behalf of that subsidiary) you are presented with a form which allows you to enter values for these fields. The same form also shows up when you are making a forecast which you plan on reconciling with the BAI line items when the actual transactions are reported by the bank using the BAI file. Now, assuming that you have entered the right accounting information for the forecasts and the forecasts get reconciled with the BAI line items (this could be either auto reconciliation or manual reconciliation done by a cash analyst) we have a means to getting to the accounting information you entered while creating the forecast, finding out which actual transaction it belongs to and exporting it out with your GL export which you can then feed into your GL system. In cases where GL export is being created using prior day files we also provide reconciliation facilities (both automatic and manual) between current day and prior day BAI files. This allows us to get to the accounting information in the forecast which is reconciled with a current day transaction which is in turn reconciled with a prior day transaction. All of this sounds complicated, but the bottom line is if you are creating the wires using EFT or entering the accounting information while doing forecast, the system pretty much does the auto reconciliation logic and figures out the accounting information that should move to your GL export automatically in most of the cases. II. Accounting Information using Prior Day Files. Approach I. works perfectly and accurately if you are into the habit of using our EFT product for wires or entering accounting information while forecasting. However, if you do not forecast extensively or are not in the habit of entering accounting information with each forecast we allow you to directly enter accounting information for each transaction that you see in your prior day file. When the GL export runs on prior day file, all the accounting information that you entered here flows through to your GL export as soon as you run it or every time you schedule it. This is fairly simple, but the downside of this approach is that you end up entering this information manually. III. Automated Accounting Information Using Rules On Prior Day Files This is the best of both the worlds where you do not rely on extensive forecasting by your subsidiaries and you also do not end up entering accounting information for each transaction which shows up in the prior day file. Here is how it works: -
You start out by creating basic rules for automatically creating the accounting information. E.g. In the below rule I am stating that for any transaction where the amount is 36,000$ and the transaction belongs to an account which in turn belongs to Campus 2, I want two accounting information rows created. One will have the value "Portfolio1" and the other will have value "Portfolio2" in the accounting information field called PortfolioID which I had created using the administration console. -
Note that here complex rules containing multiple other Transaction fields are also possible. The rules can be created using the following fields: [TransID], [ABA_Number], [AsOfDate], [ValueDate], [AcctNo], [TransCode], [Amount], [FundsType], [Description], [SameDayAvail], [OneDayAvail], [OverOneDayAvail], [CustomerReferenceNumber] [currency] [CompanyID] and even company name. Of course you can also club them up using and / or conditions. -
Once the rules are defined and when the BAI files start coming in, the system automatically starts applying accounting information to your BAI files. Here is a sample BAI file which has an amount field containing 36,000$. -
As soon as you import the BAI file (either manually or through an automatic feed that you have configured with the Bank) the accounting information rules engine kicks in and evaluates every single transaction in the previous day file with the rules that you have configured. If the transactions match the rules, the relevant accounting treatment is applied. You are of course free to modify the automatically applied accounting treatment or add new rows to it if you wish. The point: when we started off the product we started off with finite number of fields and one single way to getting your straight through processing to work. The first major step that we took towards making our accounting information piece stronger was to allow end users to define the fields that they wanted to flow through to their accounting system, themselves using a simple user interface. Then we allowed manual entry of values for accounting information fields (that the users had defined) while creating forecasts, EFTs and then manually as the previous day BAI files were imported. Adding a full blown rules based component which allows you to define rules which in turn allow automatic application of the accounting information was the next natural step. It is worth mentioning that besides supporting all these three methods we also allow you to mix and match these options. For example if you are doing a few forecasts we can continue to pick accounting information for those transactions from the forecast, for a few others that match the rules that you might have created accounting information gets automatically applied (which you can manually override) and for some transactions where none of the approaches are applicable you can continue entering the accounting information for transaction which show up in the prior day file. We are continuously building cleaner, smarter and faster ways to get you straight through processing and a full blown rules based component which you can configure yourself to get the accounting information automatically entered, is our latest addition on this front. Of course, we aren't stopping here. We plan on adding significant enhancements to all the three methods we discussed in this blog post and are continuously looking at newer and better ways to give you and accurate, hassle free and fast straight through processing that is not just powerful but fun to use.
|
|
Several posts earlier, I had described some of the typical challenges that an organization adopting a TMS faces and some of our integration capabilities in detail. A few days ago we created a quick one page chart that provides an overview of all of our integration capabilities. This new chart is shared below.
Integration options outlined above include the ability to integrate with any backend GL or Portfolio Management Systems, almost any internal system that has the ability to send us forecasts (this could be trading systems, debt systems, internal payment systems such as TS EFT etc) and the ability to integrate with banks.
We support payments integration with banks using the new ISO 20022 standard or SWIFT formats and we can connect either directly with the banks or via the SWIFT network . Bank reporting files are typically sent to us via FTP in the BAI2 or SWIFT MT 940/942 formats. Also, do note that we support multiple mechanisms for file based communication including FTP/SFTP (typically for integration with banks, internal systems) and have web services (typically for external systems to send us forecasts) as an option as well. .We also have the the ability to subscribe to web services as well (typically to retrieve up to date currency rates).
So there you have it, a very quick overview of the integration options provided by the TS suite of products.
|
|
We recently did a post on the Treasury Sciences Cash Management Dashboard where we described it at a high level. In this post we thought we would dive a little deeper and look under the hood of how Treasury Sciences cash management dashboard is different and the subtle features that are working behind the scenes to give you a wonderful user experience when you are working with it. If you are used to working with a basic bank activity report using excel sheets, chances are that you might have already drawn similarities between the excel file and this web based cash management dashboard. One of our major focus was to keep the dashboard very similar to something that you might be already used to or something that is rather easy to understand. The Flow-Codes on the Y-Axis and the Banks on the X-Axis was a quick but powerful way of letting cash managers monitor how the money is flowing through the banks. Do a wire from Bank A to Bank B and you can literally see the balance on Bank A go down and the balance on Bank B go up in near real-time with the ability to drill down and find out exactly what happened. Depending on which flow-codes you have used, you will also be able to see the transaction's impact on the flow-code in the dashboard itself. For example, in the out of the box configuration on CMO, you will also be able to see the WOD (Wire out Domestic) figure on Bank A go up and the WID (Wire In Domestic) figure on Bank B go up, telling you exactly what happened at a very high level. Of course you could always drill down into the transactions level by clicking the Transactions button and see the transaction itself. Even though the dashboard comes fairly close to looking like a simple excel based daily activity report it is much more powerful when it comes to features and gives you a layer of visibility that would be rather difficult to get using Excel spreadsheets. Here are just some of those features that are working silently and subtly behind the scenes when you are using the simple looking cash management dashboard: Bolded Forecasts: Each forecast that you see is bolded on the dashboard. But then it automatically "un-bolds" itself and turns into normal font when a new BAI file comes in and it auto reconciles with the forecast, if the forecast is manually reconciled or if the forecast is suppressed. The underlying idea here is that the "bolds" on the dashboard are warning flags or things that you need to give attention to before you submit a projection. There are multiple reasons why you might want to leave an non reconciled forecast in your projection, but the bolds are primarily targeted towards making you aware of these so that the decision is a conscious one rather than an overlooking error. Besides, there is a certain visual appeal in being able to see the forecasts dim out in real-time as incremental BAI files are automatically sent by the banks. We have seen our clients monitor the dashboard for hours and they love the "un-bolding" of the forecasts in real time as the BAI files are coming in. It tells them that everything is on track and moving along as planned. Behind The Scenes Calculations: The mere fetching of Opening Available Balance, which is often reported by the bank in a BAI files seems like a simple task for a Daily Cash Position, but Treasury Sciences allows you to forecast and project for the future (for as far a day to about a month) and what this means is that the dashboards needs be highly intelligent and aware of a lot of additional items that are at play here. A Classic example is if you were to do a projection for day after tomorrow. Given this scenario, you obviously do not have the bank statements or BAI files for day after tomorrow. Getting to the opening available balance for day after tomorrow and showing it you accurately does not just means we start with the balance of today and consider two day floats for today, but also three day floats from yesterday and all other long term floats (both variable and date based availability) as reported by the banks in the near past. To add to that we also need to look at future EFTs that you have scheduled using our EFT system. If Debt payments, other payments or standing instructions in your organization have an impact on the opening available balance for the near future we need to consider these as well which is where we have a capability for writing additional plug-ins for your organization which impacts the short term future opening available balance. The Float Adjustment line item that you see in the last line of the list, also has multiple calculations associated with it. Similarly every time you make a concentration wire we remember it as a concentration wire, create double entries for it and give you an option of suppressing both sides if you are suppressing a concentration wire. Long story short, Every line that you see in the cash management dashboard has a high level of intelligence associated with it so that you don't have to scribble numbers in a notepad and remember them while doing your projections. We take our ability to project accurately rather seriously and have tweaked the calculations and the ability to reach out to multiple sources for years now and are constantly on the process of making these calculations smarter and better than most other cash management systems out there. Subtle Visual Elements, Usability And Other Features: Ability to see commas in the amounts, ability for a bank to get automatically added to the worksheet every time it is added to the Treasury Sciences system and reporting or forecasts begin on the bank, ability to see alternating colors for the grid to help you avoid parallax errors, ability to drill down by clicking on any figure and seeing how it was formed. These are just some of the countless features which are so subtle that you hardly tend to notice them but they all contribute towards giving you an overall better user experience with the system. We have also spent time considering the most readable fonts and sizes so that cash managers who spend hours looking at the dashboard do not have to strain their eyes to look at figures. The cash management dashboard, reflects the overall thought process of the application, which is, handle the complexities behind the scenes and keep things as simple as possible for the end user. Give him clear visibility, ease of use and functionality that is most relevant in that context. Even though it sounds like a Cliché one the core philosophies, one that our development team takes rather seriously, when it comes to the end user experience is, Simplify what you present, even if it involves multiple steps and complex calculations in the background. After all, Simple is smart. Simple is intelligent. Simple is a whole lot of fun.
|
|
As part of our look at product features, todays post focusses on the cash management dashboard that is part of our cash management operations module.
The dashboard provides a consolidated, real time look all transactions across banks and provides you with your cash position at this point in time. Please see below a screenshot of our cash management dashboard that reports on transactions across 3 banks with totals per flow code, grand totals per bank and your consolidated cash position (bottom right).

Flow codes are nothing but groupings of transactions. Banks send transactions with transactions codes that identify the transaction types - for example the BAI transaction codes that are part of a BAI file. Flow codes allow end users to group multiple transaction codes into a readable format.
For example the ACHC flow code above stands for ACH Credit and is mapped to following BAI Codes - 142 (ACH Credit Received), 143 (Item in ACH Deposit), 165 (Pre-authorized ACH Credit), 166 (Pre-authorized ACH Credit), 169 (ACH Credit) and 201(Automatic Transfer Credit). As you can see, all of these BAI transaction codes pretty much mean that these are ACH credits into your bank accounts. You can of course change the flow code to transaction code mapping using the application itself.
Now, the numbers in dashboard are auto-updated on receipt of transactions or forecasts (Note that forecasted transactions are highlighted in bold). Each number listed above is clickable and you can drill down to the transactions screen to view what transactions make up these numbers.
Down below are a series of buttons, ones that let you drill down to view and reconcile transactions with forecasts, view and manage forecasts, ability to access a few reports quickly, originate concentration and net funding wires and of course the ability to Submit - ie. to create a snapshot of the data or create a cash position at this point in time.
In the next few posts, we will look at the transaction reconciliation and forecast management features that a cash analyst would perform before submitting a position.
Thank you for reading.
|
|
Ever since we announced the going live of BAI to Excel service last year we have had a fairly high number of people try it out. For programmers who wanted to access our service using their own code and utilities we decided to make the API's for this service available for free so that folks can build on top of the service. This time around too we received better responses than what we had expected. There were folks who wanted to use the service using technologies ranging from their own .NET code to the VBS scripts. For business folks who like the service but do not like the idea of logging in every day we provided a smart client application that sits on your machine and lets you convert BAI files to excel by calling these services literally at the click of a button. Our single point focus with the Labs initiative has been to bring a little bit of 'fun' into the treasury space and make a dent in the universe of treasury workstations by genuinely trying to help folks who are not yet ready for a full blown treasury management system. This is one of the primary reasons why all our lab initiatives are free. Some, like our SQL Encryption engine, are even open sourced. Taking this philosophy of introducing openness in the Treasury workspace, we have gone ahead and decided to bring all our free offerings under one roof. We are calling it Treasury Applications and this suite of free applications can be access online using the URL: https://applications.treasurysciences.com. If you have been using BAI to Excel, BAI to Excel API or BAI to Excel Windows Client, you can use the email with which you registered for BAI to Excel and the same password that you picked while registering for BAI to Excel for accessing Treasury Applications. All of these products are Free. Clubbed with these products you can even chose to try out Flagship Treasury Management product for a month but that is totally optional and if you just want to activate other products without trying out the trial of our Flagship Cash Management Operations product you can totally do that. During registration (or any time later) you have the freedom of activating and deactivating the application you do (or do not) want to use. We will continue to do more posts on some of these products, for example we have a post which introduces you to our free Bank Fee Analysis product right here, but here is a bird's eye view of the free products treasury sciences brings to the table using a single free web based signup. We personally feel that there is a lot of free goodness here for small businesses who are still working with Excel sheets. You can start with basic BAI to Excel services, use our IBAN validator, import transactions into the system using BAI files and then use them for Bank Fee Analysis, use the transaction manager to manage imported transactions and above all use our Cash Management Operations product to do projections, investment positioning, forecasting, reporting and a lot more. We take our free products fairly seriously and have a support email just in case you need help with any of them. For support on any of these products you can reach us at: support@treasurysciences.com. Go ahead. Give it a shot. Do a free sign up at: https://applications.treasurysciences.com or you can directly visit the sign up page at: https://applications.treasurysciences.com/TSApplications/Common/Registration.aspx and sign up there. Go on. Sign up, try the products out and let us know what you think. We will be more than happy to answer your questions and help with any comments, ideas and suggestions that you might have.
|
|
In a recent product demonstrations, we have been discussing our Electronic Funds Transfer Module extensively with multiple organizations. There are multiple benefits to an organization that utilizes our electronic funds transfer module - bank independence, ability to attach supporting documents, custom approval processes, no per user fees, ability to capture accounting treatment upfront, netting capability from backend A/P systems, our standardized and configurable approach to building systems to name a few.
Now, if you look at the types of organizations that are typically interested in our Electronic Funds Transfer Module there are a couple factors that stand out- key benefits offered by our payments module that make our product extremely useful to these enterprises.
The first being bank independence. If you are an organization that utilizes multiple payment banks (hedge funds as an example with multiple Prime Broker and Custodial relationships) the benefits of adopting a bank independent payments system (a payment system that can originate payments from multiple banks utilizing standards based integration) far out weigh the costs.
The second (not in the order of importance) key factor is internal control requirements and related benefits. i.e. If you are an organization that needs to enforce rule-based netting and controlled origination via payment templates offered by the product or if you are an organization that originates hundreds of payments and need a more configurable system (than what is offered by you bank) to better manage your internal users and processes such as paperless approvals and upfront capture of accounting treatment or as in the case of one of our current customers who utilize custom organization specific approvals and controls for payment approvals and account management for hundreds of users.
Thank you for reading. I would love to hear you thoughts on why you decided to adopt or not adopt a payments system from a third-party vendor and what your reasons were; you can reach me at sujith@treasurysciences.com
|
|
Treasury Sciences Applications a consortium of free web based treasury tools extracted from our flagship products namely EFTNextGen and CMO. It’s an effort to equip organizations with small but powerful tools to efficaciously manage their big-small treasury. BAI2Excel which was one of our very first effort towards free web based applications has been integrated with other products like Bank Fees Analysis, Transaction Manager, IBAN Validator and CMO (trial) delivering a smooth single sign on experience. You can start using all the mentioned tools by registering with us. In this post my main focus will be to get you familiarized with Bank Fees Analysis. Bank Fees Analysis also known as Bank Account Analysis, and as the name suggests that you are able to manage and analyze your bank accounts with respect to the services availed by you from your banker in a time period. Bank Fees Analysis has two sections, first being the data input (you will have to feed in bank charges per bank per service for a time period), second being the report which will calculate the total bank fees for all your accounts for all your banks for a given time period. The system has the ability to fetch data from dual data source namely BAI2Excel and CMO. Transaction data will be fetched from both Prior Day and Current Day Bank Reporting Files converted by you in Excel using the BAI2Excel application or imported by you in CMO. If you are going to use BAI2Excel and would want the same data to be used for bank fees analysis, you will have to allow Treasury Sciences to save the data being converted into Excel and you can do the following by checking the preference in BAI2Excel as shown below: Apart from this you will also have to define the data source in the preference section of Bank Fees Analysis as shown below: Once this is done you are all set to start your bank account analysis, and get in a position to crack better deals with your banks as it will provide you with a comprehensive picture of all your banking relations. You can start off by entering some basic information about your contractual agreement with different banks in the following manner: You are provided with some standard and globally accepted services and can also add customized services. Banks will be populated based on the ABA Number or the Bank Routing Code in your Bank Reporting File or created by you in CMO based on the preferred data source. To begin with we support two Service Type Models namely the Flat Charge and Volume Times Price including Tier Pricing. When you have finished entering the basic information you can go to the reporting section and generate the report for a time period grouped by bank and flow codes, enabling you to analyze your banking expenses and reduce cost wherever required. This application not only allows you to keep track of your banking expenses but also empowers you to get much better deals with banks as you have a clear picture of your expense across banks.
Feel free to get in touch with us at support@treasurysciences.com
|
|
While originating payments using any EFT system, the most time consuming activity is of course to make sure that all information- especially the beneficiary information is entered correctly. Approval is also time consuming as the approver has to check supporting documents and make sure that the data entered is correct (payment controls). This process of origination and approval for each one-off payment becomes even more painful if you are using multiple bank proprietary systems to originate payments.
Treasury Sciences EFT, as you know is a bank independent payments system. We solve it by using generic, bank independent payment templates. Payment templates also go through an approval process and once approved, originators can use the templates to originate payments by entering the value date and amount. Approvers can approve payments originated out of templates faster knowing that the beneficiary details have been approved earlier (while approving the templates). That may be the reason why templates are one of the most used features within the Treasury Sciences EFT Module.
Now, here is a quick walkthrough of templates and payments via templates. See below a listing of templates that lists the beneficiary and transaction type. Templates can be created by originating a new template creation request or by asking a specific payment originated in the system to be approved as a template as well- Approvers can approve the template and once approved, the template will be available for payment originators.
When originating payments from the EFT request tab, users have the option to choose originate with templates or use free form origination. If they choose, the originate with templates option users are asked to select a template (please see below). There are filtering option and a quick search option (you can search by beneficiary as well)

Users would double click to select templates and proceed with origination. All they have to add in this case will be the amount, note that the system is setting a default value date based on the date of origination and the transaction type, it is editable of course.
Thank you for reading, Hope that explains the use of payment templates and related ease of use and control benefits that templates provide.
|
|
I have been writing our hedge fund solutions overview and case study this last week and thanks to our creative team's efforts with the pictures and formatting, it is ready for release now. Look for it on our website later this week. Here is a quick excerpt that provides an overview of treasury sciences solution for hedge funds.

Treasury Sciences offers a configurable solution that is tailored to hedge fund specific needs. Key features include:
Centralized configurable payment controls and templates across financial institutions provides one system for all users across operations and management
Multi-currency support for wires, transfers, credit notices, ACHs and forecasts with the ability to systematically capture accounting treatment and supporting documents. Near-real time reporting, automated alerts and notifications
Multi-bank connectivity for payments based on SWIFT and ISO 20022 and automated integration for statement reporting, automatic reconciliation of transactions with payment forecasts and automated application of accounting treatment
STP - End user configurable, scheduled automated updates in transformable XML format that can be applied to backend Portfolio Management System for Straight Through Processing
Best in class reporting capabilities; end users can create rule based reports, share, export into MS-Excel and PDF and schedule automated delivery of reports via email
|
|
Over the last few years, we have discussed the configurability of our treasury management system and how that translates into better and faster return on investment for our customers. The picture below compares our approach to Treasury Management Systems to our competitors/typical approach of treasury workstation adoption.
If this were a boxing contest, in the BLUE corner we have our competition and the old school way of treasury management system adoption. In the GREEN corner, we have Treasury Sciences and our approach. We obviously think that GREEN corner wins every contest by a knock out.
Here is why and how...
Note that we understand that the RFP/RFI process may be mandatory for certain organizations - however, we ask if it would it not be better if you could try the product out while you read the multiple checklists, documents, more documents and attached documents that are part of an RFP document?
Thank you for reading, do let me know should you have any questions.
|
|
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.
|
|
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
|
|
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.
|
|
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.
|
|
Daily cash positioning capability is probably the most basic, yet key function offered by treasury management systems. Today, we will look at cash positions at a high level- the types of cash positions that can be created using our Cash Management Operations module.
CMO supports two types of cash positions, a preliminary cash position (PCP) and a final cash position (FCP). The key distinction between the two being that preliminary cash positions are created for a future date and hence created based on forecasted data while final cash positions are created for the current day and would include any unsuppressed forecasts, reconciled current day transactions (reconciled with matching forecasts either automatically or manually by the cash analyst) and any current day transactions that were not forecasted.
Screenshot below shows positions for 9/29- both the PCP that was created yesterday and the multiple final positions created today utilizing the current day data in USD for the enterprise (enterprise is a tag and is a topic for another day). The multiple final positions shown above are based on changes in available cash based on intra-day updates from banks.
Note that since we support near-real time positioning of cash, positions are created using current day data. Eventually, when we do receive the prior day files the next day, the system reconciles these with matching current day transactions as well. However, for daily cash positioning purposes we utilize current day data. Having said that, we do offer the ability to position on prior day data only- the catch being that your positions will be a day late.
In short, CMO allows for multiple users within the treasury to collaborate and create forecasted positions (PCP) as well as near-real time final positions (FCP) based on current day data that is automatically imported from the banks.
|
|
Today's post addresses what your enterprises global position would look like within our cash management operations module. Assuming that you have multiple banks that you work with (I have created four here) and say you position in multiple currencies, central cash management organization users will of course be able to see individual positions submitted for each currency.
The global position report enhances the enterprise wide view by providing a consolidated position across subsidiaries, currencies, banks and accounts.
Say we run the report for today. The system shows you the high level information upfront - i.e your total position across subsidiaries, currencies and all accounts at this point in time in your base currency - here USD is set as the base currency.

Below, the rolled up top level position, you would see the details- first data from day to day operations accounts grouped by currencies. Within each currency, you will be able to drill down to see the banks, the major transaction group (flow codes with CMO) totals and you will be able to view these in either the base currency or the transaction currency.
The third part of the global position report would show you your investment activity for the day. Data from operations plus data from investments would provide you with your consolidated top-level cash position.
So there you have it. Your top level enterprise wide position and drill downs by currency and banks to view details across operations and investments. Thank you for reading.
|
|
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.
|
|
A few weeks ago, we added our solution offerings to the Treasury Sciences website. The idea here is to provide concise description of features that are part of our corporate, enterprise and extended enterprise editions for the private sector, our public sector edition for the public sector and our white label solution for banks so that potential customers can take a look at one quick page and understand what we offer w.r.t their situation/needs.
For example, here is a picture that represents our extended enterprise features for large enterprises. User can access this page and hover over the various features to quickly understand what is part of our extended enterprise product offering - note that hovering over a feature provides more information. Any product videos are also accessible from these pages.
Thank you for reading, please visit our solutions page to find a solution that is tailored to your needs.
|
|
While demonstrating the product to potential customers who have multi-currency reporting, payments or positioning needs, a very common question that is asked is the ability to input, upload or integrate multi-currency feeds into Treasury Sciences products. This post addresses currency feeds and related integration options.
Treasury Sciences CMO allows end user administrators to setup currency rates in there different ways. You could input rates manually for each day or multiple times during the day and the system will use the last updated value as shown below.
Alternately, you could upload a list from a spread sheet- this option is typically useful if you utilize negotiated rates for multiple currencies for the day from your banking institution. As shown below, you would select the file and click upload. The file contains you base currency, the currency code for the converted currency and the rate.
Finally if you need a real time currency update, you could point to a third party web service- this could be one of the many currency feeds out there and you can get a real time currency update (note that additional parameters as needed to consume the feed can be configured as well). As you can see here, the TS system is consuming a web service (an internal test URL is shown below) from a third party source.

So, there you have it. Depending upon your need, you could either manually input currency rates, upload negotiated rates for the day from a file or setup an integrated, realtime feed.
|
|
In my last 2 posts on our Ad Hoc reporting capability, I have covered most of the key features of ad hoc reporting. You can read about those here and here. Today, we will look at another key product feature. The ability to schedule reports and export data into MS Excel and PDF formats. So, the report we created earlier is listed on the Ad Hoc reporting dashboard and on clicking the schedule button, on the right bottom corner of the picture below you can schedule that report.

Any available, already created schedules for the report will be listed, there are none here yet and you can click on add to create your first schedule.

To highlight a key strength of scheduling I wii go ahead and edit one of the conditions in the report we created earlier. Instead of asking the users to input one flow code (such as say ACHD for ACH Debit), we will let users input more than one Flow Code. To do that, I will go back to the dashboard and edit the report, delete the condition that says FlowCode = ? and add a new one as shown below. I will then prompt the end user executing the report enter the conditions at runtime.


Once the changes are made, the conditions selected for the report will be as shown below.

Now we will schedule this report. Note that on clicking add,the user is prompted to enter scheduling information. End users with appropriate privileges can schedule reports to be delivered via email to inbox of selected users or even deliver it to a folder in the network. You also have the option to choose whether to create the report in MS Excel or PDF and you can also password protect it. You can also specify the scheduled time for the report to be executed. You can also choose users within the system and any external users (you can choose not to as well) to receive the reports on the schedule created.
The final, yet most interesting point is that users are also prompted to enter any runtime conditional information while creating the automated schedule as well. For instance, if your A/P organization wants to look at all outgoing payments for the day you could add a schedule (as shown below) for a daily report run at 3 PM each day that reports on ACHD and WOD, WOI - assuming you do ACH debits, and Wires out International and Domestic.
Note that you can schedule the same report as many times as you want. For example, say your receivables department wants to review the list of al Lock Box Deposits at the end of the day we can add another schedule that with FLowCode = LBDEP, as shown below and schedule it to be delivered to the receivables users.

Trust that provides a detailed review of the ad hoc reporting functionality. Note that while we originally built the ad hoc reporting module to be part of CMO, we are now making it available as part of all treasury sciences product modules. As a final note, you can export any report from the system- just execute the report and click export to excel or pdf or schedule the report to be delivered to you in the format you choose. Thank you for reading.
|
|
In the last post, we created a conditional ad hoc report. If you have not read that post yet, please read it here. The newly created report appears in the reporting dashboard for users to invoke it. Users with appropriate permissions can edit the report, copy and create a similar report,schedule the report to be delivered via email and of course delete the report.
Today, we will look at additional capabilities of ad hoc reporting. So, you edit this report and navigate to the wizard again. On the main page of the ad hoc reporting wizard, you have a button for configuring display details.
Clicking this button you can configure display details of the report - provide your own field names, specify formatting, apply sums and averages (see below). In a later version, we will let you input your own formula and create calculated fields as well.
Additionally, you could also choose fonts, colors and attach logos to the report as well - see screen below.
Finally, you have the ability to further improve your report by sorting on as many fields as needed, group by multiple fields and total numeric fields. Flow codes within the system identify +ve and -ve transactions and thus you can be rest assured that your sub and grand totals are accurate. See example of sorting and grouping below.
Thus we have created an ad hoc report that reports on current day transactions, sorted by account number and transaction code, grouped and totaled by flow code and with summations on amount. In the next post we will run the report, export it and see how to schedule reports using the ad hoc reporting tool.
Thank you for reading so far, do let me know should you have any questions or comments - especially if you have recommendations on how to improve our ad hoc reporting tool.
|
|
For the next several weeks, I will be focussing on multiple features of our product suite. Today, I will take a look at our ad hoc reporting capability.
A while ago, I had covered how our ad hoc reporting capability came about in a post- you can read about it here. In this post, we will highlight key capabilities of our reporting module. In short, the TS reporting module allows end users to create conditional reports, save them, export reported data into MS Excel or PDF and schedule reports to be delivered either to a network folder or your email inbox.
To start creating a report, you would select a view from the available list of views. Views are essentially groups of fields from your database that you can select to include in your report - for the technically minded this is really a database view - a view that exposes selected fields from multiple tables. Now here is why we use views- its is simpler for end users to use and quick enough (a day's turn around) for our product team to create it. We also have most of the views that you would need already in there.
For this report, I have selected the "Current Day Transactions" view and choose a few fields from the list of Available fields for this new report. Now, I have added 2 conditions setting the as of date to the current day (the day an end user runs this report) and have asked the system to prompt the use for the flow code (i.e. the type of transaction you are looking for - for example ACHD for and ACH Debit). I clicked on the conditions link (can use the +,- links to add and remove conditions), the pop up below shows the ability to add multiple conditions and either provide values for these conditions or prompt users to enter the values at runtime.
Now, you can preview and save to create an ad hoc report that reports on transactions for the current day for the transaction types that you choose at runtime. This report can be made available to either yourself or other users based on the permissions you have and based on the features available below.
So, we have created a quick conditional ad hoc report and shared it with our users. In the next post, we will discuss some of the more advanced features of ad hoc reporting.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
The reason for the post is a question from a potential customer of ours. After spending an hour or so on our Cash Management Operations Module, a cash manager of a large retail chain told us that they were intrigued by it, believed that the features provided by our product will be very useful to them and wanted like to try the product out. Then he had a question.
"How do I justify the cost of a Treasury Management System? I can hire an analyst and use a spreadsheet to continue daily positioning, it has worked for us so far".
I will make an attempt at looking at the possible benefits in the rest of this post. Hard cost benefits of using an enterprise TMS typically include 3 types of cost benefits (reduction in cost).
Detection of Errors: Detection of errors in forecasted data or in early detection and cancellation of inaccurate electronic payments can result in operational cost savings. Detection of errors in banking data can result in accurate positions.
Reduced reporting costs via consolidation: Reports are run enterprise wide. Ensuring that all data from banks and other internal and external systems are consolidated and reported via an easy to use interface results in efficient reporting and reduces reporting costs considerably. Typically financial institutions charge customers for each generation of a report. As an example, a customer of ours with 8 subsidiaries is currently saving over 15,000 USD a month by not paying the bank for each report run- the data is extracted from the bank once and stored in our TMS, the data (up-to 7 years of historical data) is reported to over 150 users via our reporting tool.
Accurate and timely positions resulting in accurate investible cash sooner: The actual dollar benefits derived varies from one organization to another- the more complex an organization is, the larger the risk of inaccuracy and the better the chances of improvements in accuracy via the use of a system. In typical large implementations, we see improved position accuracy in tens of thousands of dollars almost daily; we also see improvement in predicting tens of millions of dollars of investible cash on a pretty regular basis.
The primary benefit in utilizing an enterprise TMS vs. manual process for cash positioning is the improvement in accuracy and the timeliness of cash positions day after day provided by automated forecasting, bank connectivity, reconciliation and positioning capabilities of an enterprise TMS.
There is more to a Treasury Management System but unfortunately not all of it is visible upfront, when you are making a choice. Let us look at some of the se benefits in a bit more detail.
Accuracy & Timeliness: Reduced manual intervention and increased automation results in more accurate forecasts and positions. Typical spreadsheet errors such as typos, formula errors etc are eliminated. Additionally, automation ensures that data that needs to be collected for forecasting and positioning is collected at the earliest available time - this typically results in automated, systematic positions being available sooner than manual positions. Accuracy results in better-informed investment decisions and timeliness ensures that your investments can be made at the earliest, ensuring that the best available investment options are available to you.
Scalability & Manageability: As the positioning process becomes more and more complicated, say by the introduction of new subsidiaries in multiple countries; it becomes more and more difficult to position cash on an enterprise basis using a manual process/spreadsheets. Organizations that stick to manual positions in such scenarios typically have 2 choices –(1) position each country/subsidiary/currency separately thereby losing visibility of enterprise cash or (2) try enterprise positioning with an excel spreadsheet typically resulting in inaccurate positions.
Consistency & Reliability: Systematic processes eliminate issues with consistency, not matter how complex or simple the cash positioning needs are resulting in reliable, consistent cash positions day after day. Typically, this eliminates the need to double-check each calculation. More importantly, it has been a regular experience for us to find errors reported by banks. If positions were created manually, typically there is limited ability to double check data reported by the banks. Enterprise TMS's typically calculate the CAB, OAB along with floats and compare it to the numbers provided by the banks ensuring that any discrepancy can be identified. Again, the more the number of banks and accounts the more likely an organization will find errors.
Security: An enterprise TMS typically encrypts all confidential data and the use of roles in a system ensures that users with the appropriate privileges see the data. The level of security and access restrictions provided by an enterprise TMS is way better than what can be achieved via an Excel document.
Multi-user Access: Enterprise web based TMS like the Treasury Sciences Suite of Treasury Management products provide unlimited access to multiple users of the treasury and across the enterprise. For example, delegating forecast input and management directly to the departments that are responsible for the forecast can ensure accountability and accuracy of forecasts. Additionally, you can have subsidiaries create their own positions in multiple currencies while having the ability to view consolidated enterprise free cash in a currency of your choosing. An excel system is typically useful for one user.
Compliance & Audit-Ability: Manual approvals and audit are not efficient ways to ensure the enforcement of organization policies and controls. Use of a TMS considerably reduces chances of fraud by tracking and reporting on each action by all users of the system and provides you the ability to enforce organization policies and processes across the enterprise. A system audit is typically much faster than a manual process audit as well.
Who wrote the macros in that spreadsheet?: This is something we have seen in multiple instances - a spreadsheet is created and updated over a long period of time. The person who wrote the macros is no longer with the organization and typically the organization is stuck with it. Even if the author is around, it does not take much for a spreadsheet to get very complex- well, it was never meant to be a treasury management system.
Focus on more important things: There are typically more important things that a cash analyst or a treasury manager can do instead of downloading bank files manually or printing out multiple reports from multiple banks and entering the data into a spreadsheet. An enterprise Treasury Management System makes your life much simpler and lets you focus on how best to manage your cash.
All of the benefits mentioned above have a cost and a cost saving associated with it. What it is depends on your organization, the scale of your operations and your situation. Also note that the improvements in cash positions, cost savings and improved investments via the use of a Treasury Management System are typically not easily predicted upfront as there is an element of unknown-unknown's (manual positioning and related processes over a period of time in an organization typically result in hiding the possibilities of better forecasting and positioning) here.
The only way to find the true benefits for the organization is by trying out an enterprise TMS for a reasonable period of time and by comparing it to an organization's manual process. This has become a very long post. Thanks for reading and do let me know your thoughts at sujith@treasurysciences.com.
|
|
|