The Search for Portfolio Accounting Applications

By Bob Accola and Brian Luro

So, it's your job to get fund NAVs into the paper! There may be only a few for which you are responsible, but more likely there are dozens or even hundreds, and they have to be correct each and every day.  To be successful, you depend upon many people and large complex accounting systems.  Are your portfolio accounting systems up to snuff?  

There are numerous possible signs that your system needs an overhaul.  If your fund accountants cannot manage three to four funds on average (more in a trust environment) you may be using an outdated system.  If you are still using "off system work arounds" for securities that have been commonplace for a decade (e.g. GNMAs), you may have a system problem.  If the number of pricing errors is high (more than a few each month), you may need a new system solution.  If you use multiple accounting applications to handle your complex of funds, you may need a serious overhaul.

Please keep in mind that these are only possible signs.  If the signs were infallible, your job would be easy.  For instance, if you have a disproportionate number of foreign bond funds or other complex investment products, you might not reach the three to four funds per accountant threshold. And as you know, erroneous security reference data, manual pricing of securities, or missing trades/corporate actions can cause pricing errors just as easily as a faulty system.

If you have reviewed your current system, keeping in mind these possible signs, and determined that it is time to replace the accounting software, welcome to a very large project.  Here is what you can expect.

Project Approach

Depending on the size and complexity of your organization, the process could take one to three years.  The first 2 months will be devoted to assembling the right team.  The next 4 months will be needed to execute a successful Request For Information (RFI) process.  The next year will be spent building or implementing the chosen software, and the final year will likely be spent converting existing business to the new system.   

1.     The first step is to assemble the right team.  While the team members may change over the life of the project, some continuity of people and certain skills are critically important.  Central to your project's success is finding a project manager who can effectively guide the team and keep management informed as the project progresses. Business analysts who understand both the different business functions involved and the systems development process are key.  Information Technology (IT) professionals who understand both technical and business issues are critical to your project's success. The IT staff ultimately will be responsible for building some or all of the software, and if they do not understand the difference between a tax lot and a parking lot they do not belong on this project.

2.     The second step is to undertake the RFI process. In order to make a meaningful recommendation to management an objective set of criteria must be developed.  The benefit and cost of each of the criteria must be established. The benefits are typically established in terms of increased business efficiency, reduced systems expense, or increased business opportunity. The cost will be calculated for each of the recommendations made to management. These criteria can be divided into business, functional and technical requirements.

    Business requirements include items of importance to the organization as a whole.  Perhaps you would like to change the organizational structure (e.g. the new system should allow you to combine the domestic and foreign corporate actions areas into a single group).  Current and future client mix should be considered (e.g. the new system must support Mutual Fund, Pension Fund and Individual Trust accounting).  Finally, future business volumes should also be taken into account.  Taking the time to carefully identify these requirements up-front will help ensure that your new system can support your business well into the future.  

    Functional requirements spell out the detailed functions that the system must perform.  An example might be multi-base accounting if you support non-US based accounts.  You may want both account level and sub-account level processing if a team of managers manages the funds in your complex.  The system must support a full range of security types.  Audit trails are important.

    Technical requirements specify issues that affect the software.  For example, if you have a client-server based environment, you probably do not want a mainframe-based solution.  You will also want to consider performance parameters (you do not want a system that takes 45 seconds to book a trade).  Finally, you will want to ensure that any product uses reliable database structures and programming languages, and that the IT staff is positioned to support them.

One of the most important technical issues is identifying the components that are real-time versus those that are executed in a batch environment.  This is important because many of the main processing routines in today's systems are batch functions. If you choose such a system you may be stuck running cycles throughout the working day.

The project team must then take all of the identified requirements and create a prioritized evaluation matrix.  This will form the basis for evaluating your options.  The project team should consider both in-house development solutions and external vendor packages against this matrix. This document combined with descriptions of your business and technical environments, your approach for selecting vendors, etc. will form the RFI document that will be sent to possible vendors (select about 10).

By comparing each of the responding vendors to the matrix, the team can narrow the field to three or four vendors.  Each of these vendors should then be put to a more rigorous review, including a financial review of the company, functional and technical reference checks, pilot tests, and benchmark tests.  >From this review, the project team can estimate hardware costs, software costs, the cost of enhancements (interfaces and reports) and the cost of conversions.  With these cost estimates in hand, the project team can readily prepare a thorough cost benefit analysis.

The end result of this second phase is a solid recommendation ready for senior management review.  The recommendation includes the findings and the supporting information developed during the RFI process.  This is a lot of work to accomplish in just 4 months. 

3.     Assuming your recommendation is to build or buy (the recommendation may very well be to do nothing at this time), the fun is about to begin!  During the next year you will be looking at developing the complicated software needed to complement a vendor package or in-house solution.

While surprising to many people, the most critical software development effort is usually the security reference data interface.  There are two reasons for this.  First, it is difficult to get dated dates, issue dates, pay dates, accrual methods, expiration dates, issue currencies, local currencies, variable rate indicators and OID indicators correct for all the different types of securities. While setting up equities typically is simple, foreign bonds, mortgage backed securities, discounted paper, and variable rate demand notes are generally more complex given the different attributes inherent in these securities.  The second difficulty is that typically, some of this information is not available systematically because the old application did not use it (this is perhaps why you opted for the new system).  The security reference development effort is almost always underestimated and can very easily derail your project if not done correctly.

The next tier of complicated development efforts may include interfaces from the trading systems to the accounting system, interfaces to/from the pricing system, the conversion software, cash availability interfaces or reporting, and portfolio valuation reporting.  Each of these components contains special challenges and should be carefully designed and built.

4.     After the development effort has been completed, or perhaps in parallel with it, the conversion will begin.  This can be a long process depending upon the number and types of funds being converted to the new system.  It calls for detailed procedures and is typically accomplished in waves (groups of funds converted together because of similar characteristics).  While this process may seem to become routine after a while, it still requires the detailed attention of experienced team members.

The four steps outlined above describe a somewhat generic project.  Your organization will need to tailor these steps to your own needs.  For instance, you may have already decided to develop the software in-house, or you may only need to enhance a portion of your system (e.g. General Ledger processing).  In these and other cases you will find it necessary to expand certain tasks and remove others.

Brian Luro is the president of Venture Financial Systems Group (VFSG), a medium sized consulting firm specializing in developing software for the financial services industry.  He has more than 12 years of experience implementing software solutions for financial services firms. Bob Accola is a senior consultant with VFSG and has more than 15 years of experience implementing systems in the mutual fund environment.

Venture Financial Systems Group has extensive experience assisting clients through this process.  We have participated in the RFI, recommended software solutions, and played a significant role in the development and implementation of these products.  For more information, please call (781-932-7544), visit our web site (www.venturefsg.com) or E-mail us (info@venturefsg.com).