12.5 Build vs. Buy
The question of whether to build or buy a system is often more about what to build and want to buy. If thevalue-at-risk implementation is occurring as part of a larger implementation of front-, middle- and/or back-office software, there is the question of whether to purchase all the technology from a single vendor or to select different components from different vendors. In either case, it is likely to make sense to implement some components or some interfaces between systems internally. A firm that builds its own system internally will still want to incorporate vendor toolsets, add-ons or database software into the system.
Depending on the industry and intended application for thevalue-at-risk system, there may be numerous vendor systems available, or there may be few. The best way to address the “what to build and what to buy” question is to research available vendor software and assess what might reasonably be incorporated into the planned system.
12.5.1 Vendor Software
The market for vendor software is fragmented both by application (limits monitoring, portfolio optimization, corporate reporting, etc.) and by mix of asset types (equities, natural gas, soft commodities, etc.). Avalue-at-risk implementation suitable for a commodities wholesaler to monitorvalue-at-risk limits would not be useful for, say, a portfolio manager interested in optimizing an equity portfolio. The problem is that user interfaces, key factors, remappings and ancillary analytics differ too much from one market and/or application to another. This market fragmentation, combined with the fact that budgets are sometimes modest, means that many market segments are not well served by vendors.
Banks and other large financial institutions installing systems for regulatory or internal reporting purposes have plenty of excellent vendor software to choose from. Motivated largely by regulatory requirements under the Basel Accords, financial institutions have a compelling need. Their requirements are fairly uniform, and they have large budgets for purchasing the software. Solutions are typically bundled with complete front-to-back office applications.
Energy trading firms installing systems for internal monitoring are also reasonably well served by vendor software, but quality is not as good. These firms don’t have an explicit regulatory requirement to monitor value-at-risk. Generally, it is auditors, rating agencies and counterparties that expect them to do so. With the need less explicit, budgets are smaller. As with banks,value-at-risk software is generally purchased bundled with other front-, middle- and/or back-office applications. In many cases an afterthought, thevalue-at-risk software that comes with these bundles can be rudimentary.
Another segment that is reasonably well served by vendor software is institutional investors and investment managers implementing software for asset allocation and portfolio optimization. The software tends to be a stand-alone package, perhaps bundled with a subscription for data and updates. It generally isn’t promoted asvalue-at-risk software, but it does have a value-at-risk measure embedded in its analytics.
12.5.2 Choosing Vendor Software
Your search for vendor software should start with a list of possible vendors. Consult industry contacts, vendor directories, or the Internet to identify candidates. You can initially screen vendors by turning to their websites. Once you have narrowed your list, send out a request for proposal (RFP).
The RFP should solicit information about the vendor’s ability to meet your requirements, as well as the cost and timeline for doing so. You need specific information about the software’s existing features. Be weary of functionality a vendor promises to implement in the future—it’s called “vaporware” for a reason. Ask how a vendor’s software is licensed. How is it documented? How can it be modified or customized by the user?
You also need detailed information on the vendor. How many years have they been in business? How are they owned? What is their existing installed base? What is their financial condition? Ask for references.
Send out the RFP to your list of vendors. While you await responses, go through the exercise of replying to your own RFP to assess your firm’s ability to implement software meeting the specified requirements internally.
Once you receive responses to the RFP, you can further narrow your options. At this point, you should contact references—not only those provided by the vendor but any you have discovered in your research. Vendors sometime identify clients on their websites or in other promotional materials. If you call around to contacts you have at other firms, you should be able to find existing or past users of any established vendor’s software.
The final step before settling on a vendor is to conduct vendor interviews along with product demonstrations. A vendor may send personnel to your offices, but it is preferable that your personnel visit theirs. Your team should include quantitative finance professionals who can discuss thevalue-at-risk analytics as well as IT professionals who can address systems issues. Visiting a vendors’ offices will allow you to assess the corporate culture, employee morale and other intangibles.
It is an unfortunate fact that good marketing is more effective for selling vendor software that is good analytics. Horror stories of software with fancy user interfaces backed by rudimentary analytics abound. Ask to see the software documentation, if it has not already been provided. Ask plenty of technical questions. Don’t accept bait-n-switch promises of proprietary analytics offering something better than value-at-risk. It isn’t. Don’t accept undocumented black-box software. There really aren’t any trade secrets invalue-at-risk technology, so vendors should have nothing to hide.
Do not rule out small or start-up firms. They may have cutting edge solutions you need, whereas more established firms may be straddled with yesterday’s technology. But keep in mind the possibility that a vendor might fail or be acquired. Even if a firm doesn’t fail, poor cash flow may prevent it from upgrading its software or providing adequate client support. Use the interview process to address these issues. Ask about provisions for these contingencies. It is, for example, not unheard of for small vendors to place their source code in escrow with a law firm to be made available to clients in the event they fail.
If any references were dissatisfied with the vendor, ask the reference if you can raise their experience with the vendor. Don’t rule out a vendor because of one or two bad incidents, but assess if they learned from mistakes and made changes to avoid similar situations in the future.
Do more than observe the product demonstration. Participate. Ask to see specific screens or functionality described in the vendor’s product literature. The product demonstration is one of the most important steps in selecting vendor software. If it goes poorly in the controlled environment of the vendor’s offices, that is a clear warning sign.
Once the interviews and product demonstrations are complete, follow-up with any final questions, and then select a vendor—or opt to develop the system internally.