Posted by Peter Orr on Wed, Dec 31, 2008 @ 04:19 PM
"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.
Posted by Peter Orr on Tue, Dec 23, 2008 @ 04:25 PM
"Risk comes from not knowing what you're doing."
- Warren Buffet
In his 1921 dissertation, University of Chicago economist Frank Knight made an important distinction between risk and uncertainty. He maintained that risk and uncertainty are different in one critically important respect: risk involves events whose odds of occurrence can be known with precision or, at minimum, are based upon some statistical evidence or scientific methodology producing estimable likelihoods. The probability distribution of the event in a risky situation can be known. Uncertainty on the other hand is associated with those events whose odds or probability distributions are not known or not reliably quantifiable.
For example, there is risk inherent in the roll of a die. However, we know with certainty that the result will be an integer number with a minimum of 1 and a maximum of 6. If we bet on a 3 turning up prior to the roll, we have assumed some amount of risk. However, there is no uncertainty as to the possible outcomes or the odds of those outcomes; this event can be modeled quantitatively with absolute confidence.
Contrast this simple die roll with the infinitely more complex sets of possible outcomes that can occur on any day in the capital markets. Risk is certainly present, as in the roll of a die, but uncertainty also abounds. Events that are nearly if not entirely impossible to predict happen with some frequency, and as such, no amount of fancy number crunching (even from our applications!) is going to remove the danger inherent in financial exposure management. This lesson has been taught repeatedly throughout the history of finance, perhaps most notably with the portfolio insurance providers during the 1987 crash, the fall of Long Term Capital Management, and even today's, umm…challenging, credit market.
It may seem curious to find a cautionary warning about the limited power of quantitative finance tools in a blog post by a company that, in part, creates financial models. Nevertheless we cannot overemphasize the importance of humility in the face of capital market uncertainty. Market movements have been and will likely remain impossible to forecast with any meaningful degree of accuracy – that is, until we can with confidence statistically model the behavior of crowds and foresee the bouts of excessive optimism and fear that are characteristic of capitalist societies. Some practitioners within the burgeoning field of behavioral finance are attempting to do just that with encouraging results.
"Doubt is not a pleasant condition, but certainty is absurd."
- Voltaire
Since we know we need to consider both the knowable and unknowable range of future outcomes, are the risks alone worth quantifying? Do they only inject a false accuracy or worse, false security into the decision-making process? The unfortunate truth is that even in the face of looming and unknowable uncertainty (black swans?), we are compelled to make financial decisions. We unavoidably find ourselves in situations where we are forced to manage exposures as borrowers, as investors, or both. We don't have the luxury of "doing nothing." Doing nothing means we have either not removed or not assumed exposure to something; in both cases we are inevitably exposed to risk and uncertainty. Since we are forced to play our hand, I believe it is essential to have tools that at least give us a glimpse into the potential magnitude of the changes we might face.