Financial Software: The Good, the Bad, the Ineffective

 digg it |  reddit |  delicious |  StumbleUpon 

"The dividend of the computer revolution to us did not come in the flooding of self-perpetuating email messages and access to chat rooms; it was in the sudden availability of fast processors capable of generating a million sample paths per minute."

- Nassim Taleb, Fooled by Randomness

Investment banking, and perhaps finance generally is no stranger to the giant ego. I must admit sometimes I judge Street pros with my own unspoken assessment of their "ego/ability ratio". Given Wall Street's current condition, many might reasonably assume that the numerator has proven to be, beyond a doubt, wildly out of whack with the denominator.

Perhaps because they've worked in finance for a number of years or because they can put together a spreadsheet with formulas referencing more than three tabs, one byproduct of the high ego/ability financier is the assumption that s/he can create good financial models and software. In response, below I detail a few of the considerations involved in building what we consider to be powerful, robust, well-designed, intuitive, serviceable financial software. In some ways, it would be nice to say it is pure science, but as any good pure scientist will tell you…it's always partly art. The topics below are presented separately but in practice are inextricably interconnected.

The People

Many technophobes may think of software development as a remote and inscrutable process that only specialists with spinning propeller-heads understand. Admittedly at some level, this may be true. But in the end, software is built by people for people. And those are exactly the two groups that are essential to a successful analytic: those who can build great financial software and those users/consumers who will benefit from its results. First the developers…

You want your financial software developers to be both outstanding software engineers and financial engineers, ideally with decent commercial intuition. In my experience, this is an extremely rare combination. Most professionals in the field are of one of two types: finance people who, due to the aforementioned ego, get bold enough to become reasonably dangerous hacking out (sometimes) functional code; or they're software engineers who happen to like the paycheck that finance-related jobs provide and as such, have picked up what present value means and perhaps the Black-Scholes-Merton formula. I wholeheartedly admit I'm in the former category (I try and control the ego), though at least I was prudent enough to fire myself from the development team once we'd experienced sufficient growth. It also doesn't hurt if they're personable, can speak with clients, gauge what's working well for users and what's not, and modify the software accordingly. As one consumer products company put it when describing their own quant group, "PhD's with personality." I've come across people from each end of the spectrum and everywhere in between, but the professional who offers all of these attributes is rare indeed. We're extremely fortunate to have found a few of those here at IA.

The next and all-important group of people you need to understand fully is the audience. How do they view their environment? What factors affect their financial decisions? How sophisticated are they? What features are required? Which would be nice? Which would be "over-the-top" and likely confuse as often as illuminate? I think far too many quants, who frequently find themselves in the role of developer, expect far too little of their user/audience and thus leave many financial black box people under-equipped. This information about the user/audience must be gathered in order to gain the background data required to thoughtfully respond to the questions that follow.

The Medium

Selecting the medium in which to develop software is an essential decision that drives many other design considerations and features. Far and away the most common tool among finance practitioners for financial model building is the spreadsheet. Any Street banking analyst on the job more than a year has ultimately either heard or made the joke about staying up all night with a model…of the Excel™ variety. Spreadsheets are fantastic for certain types of analyses; for doing basic financial statement projections, nothing beats a spreadsheet. However, for performing multi-factor, multi-period simulations or solving complicated optimization problems, it's a medium that suffers major drawbacks.

One important question is whether or not the software will be deployed locally using only the compute resources on the desktop, or will it be deployed on an enterprise server, grid, or in the "cloud" as a web-based application. At IA, we allow users to choose whether or not they want to calc locally or in a remote environment, a software-plus-services approach.

Languages like C, C++ or FORTRAN offer speed but require more software engineering skills: ideally a thorough understanding of memory management, object oriented programming techniques and more generally, development best practices. Developing in (relatively) lower level languages like this can also require a great deal of time spent on the user interface, though this will rightfully occur in varying degrees in any development environment.

Scripting languages like JavaScript, Python or Perl and RAD frameworks like Ruby on Rails have become popular in a Web 2.0 world. These tools usually excel at rapid prototyping, especially for specific tasks such as web application development. However, despite extensions designed for number-crunching such as PDL for Perl, like spreadsheets scripting languages are largely ill-suited to implementing industrial strength computational algorithms. Furthermore, scripting languages even when compiled (often to some intermediate state) can't offer the speed of a truly compiled language like C++.

Java and .NET (i.e. C#) one might say function as safer versions of C++ with vast libraries. Safer, however, does mean slower. Specifically they deliberately attempt to lower the bar for entry therefore ultimately compromising on speed and flexibility.

Computational languages environments like Mathematica and MATLAB (or its open-source imitator, Octave) provide many features and offer a range of built-in functions and sit on top of powerful libraries such as LAPACK. I believe MATLAB now has over 90,000 built-in functions. Like Java and .NET these environments obscure certain lower level functions like memory management. Some may complain about the sub-optimal memory management (automatic "garbage collection") features. Others may say these are difficult to deploy without expensive licenses.

In the end, pick a development medium ill-suited to what you want to accomplish (for today or tomorrow), and you'll find the project more expensive to create, less adaptable to changing objectives, and more onerous to maintain.

The Features

Once you've selected the medium, you've got to decide what features to include in the model. This obviously depends upon the goals and objectives of the application through the eyes of your typical user, whom you hopefully understand intimately. You want to model the problem completely enough to provide structure, but provide enough flexibility to capture the widest range of circumstances users are likely to face. If it's a risk analysis, what is the purpose? What horizon? What factors will be included? How will they be modeled? What types of distributions will be used? Will you try and capture kurtosis (fat tails)? Will the factors be correlated? What is the source of correlation? Will covariance be stable through time? If it's a pricing model, what model will be used? Will the application require data feeds? How will they be integrated? What will the interface look like? Will output integrate with other desktop applications? How will results be stored and shared? What visualization features can be employed to illuminate features of the problem or solution?

If you're a software provider, how will the licensing mechanism work? How will you implement protection? What if your servers are breached? Will you house data? Will you use encryption? How much will this effect performance?

This is a small sampling of the types of questions that are likely to deserve appropriate consideration as it relates to features, which ultimately inform overall design.

The Risks

In the age of information, intellectual property is a hot topic. That means that whatever you build may have been thought of by someone else, and further, may be protected by their copy or patent rights. Ignorance is no excuse. Stepping on someone else's patent can wind you and/or your firm up in serious trouble. Be found guilty of intentional infringement and the infringed can claim treble damages against you. Work for a large firm with deep pockets, and you are that much more attractive to IP lawyers looking to get payout on contingency. If your clients find themselves getting unfriendly legal letters because of something you designed, you're likely to find yourself with fewer and certainly less happy clients as well.

All together

There's certainly plenty I've left out but in the end, designing and creating good financial software is just the first step. Automated test procedures, informative, context sensitive help, tutorials, and web based training ultimately increases the length of the technology lever that the underlying algorithms themselves represent. But it's all irrelevant if you don't also provide a clear path towards value that your customers/clients/users can successfully take. In my experience, competing on analytics is not necessarily a natural activity for financial firms, at least not across all lines of business; but it's an incredibly natural and inevitable fit. I expect books such as Competing on Analytics and Super Crunchers will increasingly reflect common wisdom; the financial services industry has only begun to really use technology to better and more efficiently service clients. But to fully maximize return on the investment, think carefully about whether you have the in-house expertise to fully execute a strategy end-to-end.