The "Buy versus Build" Decision for Credit Risk Solutions
Yuval D. Bar-Or
May 7, 2008
The decision to “build” rather than “buy” a solution can be a watershed event for a business. This is often because the “build” decision calls for significant budget allocation and the deployment of a variety of resources, which may not be necessary under the “buy” scenario. Furthermore, there can be great reputation and career risk for the sponsor(s) of a particular decision, as failure can lead to substantial corporate losses as well as delays in completion of mission-critical solutions.
Many financial institutions believe their modeling expertise represents a competitive advantage and, legitimately, wish to exploit it. In addition, the idea of having full control over the introduction of a solution is appealing. Development of a complete solution, however, requires far more than a good mathematical algorithm on paper. In almost all cases, software development is required. Often, for maximum benefit, the resulting solution(s) must connect seamlessly to other internal systems. There may also be a need for mastering data warehouses and or live data feeds. Most financial institutions don’t have expertise in such large scale (or even smaller scale) software development and implementation projects. Any business engaging in activities that are not core strengths subjects itself to the risks of underestimating the efforts and resources required for successful completion, as well as to distraction from its core functions.
A decision to “build” must take into account considerations such as:
The firm’s staff can gain important knowledge and skills which will likely serve it well in future.
While vendor solutions may sometimes come across as “black boxes”, an internal build has the advantage of being completely transparent.
The solution(s) can be fully customized to internal specifications, subject only to internal prioritization, rather than to external (vendor-dictated) development cycles and feature preferences.
There is full control over all resources, allowing the firm to mix and match skill sets, as well as dictating the pace of development and making adjustments and changes as necessary over time.
Some of the staff’s learning is done the hard way, by making mistakes. Some of these errors may be costly.
An internal build requires an ongoing commitment to maintenance, support, recalibration, and validation of solutions, as well as commitment of resources to data feeds and warehouses, as relevant.
A decision to build may call for additional human resources such as business analysts, information technology specialists, and project management resources, along with potentially significant hardware and software purchases.
Most institutions underestimate the scope of work required to build and maintain a risk management solution.
Some reasons to “buy” a solution:
The vendor(s) have already learned many important lessons (the hard way), which include the need for periodic model updates, software maintenance, and validation of solutions, as well as the need for appropriate data-handling infrastructure.
Building and maintaining such solutions is a core business for vendor(s). This applies to financial modeling, IT expertise, as well as implementation know-how.
Vendors receive feedback from multiple users and prospects, putting them in a favorable position to incorporate best practices into their offerings.
Vendors may have access to larger pools of data for building and testing their solutions.
Vendors often have a commitment to the necessary data infrastructure, as well as economically favorable agreements with third-party data providers.
The larger the scope of the project, the greater the risks. Outsourcing the project (or selected portions) to an entity that’s “been there and done it” can reduce some uncertainty.
A final and sobering thought. Experience has shown that completely successful internal builds are the exception—not the norm, and are often more costly than originally forecast.
