Features & Functionality

Configuring Centralized & Decentralized Cash Management in TS CMO - Part 2

Sujith Nair — Wed, 27 Jul 2011 21:40:44 GMT

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.

Configuring Centralized & Decentralized Cash Management in TS CMO - Part I

Sujith Nair — Mon, 18 Jul 2011 19:47:56 GMT

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.

Treasury Workstation Features - Cash Management Dashboard

Sujith Nair — Tue, 26 Oct 2010 22:49:19 GMT

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.

Bank Independent Payment (EFT) Templates

Sujith Nair — Tue, 19 Oct 2010 03:58:57 GMT

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.

Payments and Cash Management solutions for Hedge Funds

Sujith Nair — Wed, 13 Oct 2010 20:43:03 GMT

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

Cash Position, GL Integration, Hedge Fund Treasury Worstation, Netted Payments, Reporting, Straight Through Processing, Treasury Management , Treasury Management System , Treasury Workstation

Treasury Sciences -SWIFT Connectivity

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

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

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

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

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

Payments, Positioning & Integration for Hedge Funds - Overview

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hedge Fund Treasury, Multi bank payments, Netted Payments

Treasury Workstation Features - Preliminary & Final Cash Positions

Sujith Nair — Thu, 30 Sep 2010 05:44:41 GMT

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.

Cash Position, Treasury Management , Treasury Workstation