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
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
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.
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.
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
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.
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
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
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
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 (firstname.lastname@example.org).