Posted by Peter Orr on Mon, Feb 16, 2009 @ 05:05 PM
"Finally, the business model of the investment banks is almost certainly going to change. Over the last 20 years, investment banking went from primarily an advisory business to being mostly a business where firms traded their own accounts – so-called proprietary trading."
- It's Not the Bonus Money. It's the Principle. New York Times, January 30, 2009
In Part 1 I described how investment banks in the current day are no longer organized to adequately address the needs of their clients. This will take a great deal of soul searching to correct. If this weren't challenge enough, the longer term secular trend is a more fundamental problem resulting from the information age and how it affects the traditional IB business model. In fact, I spoke to a comptroller of a state agency just last week on this very topic. His situation embodied the challenge (details below).
The Rise of Navigators
We live in an age of practically boundless information; we can consciously process far less than the 20 Mb/s rate I have at this computer. This information deluge, unorganized, paralyzes and renders us fearful of making suboptimal or just plain bad decisions. What has naturally emerged to help us cope with all this data is the information aggregator, or "navigator", which at this point we all find pretty valuable. There are many types of navigators, from Consumer Reports to Orbitz to the parent most qualified to give advice about raising the kid(s). In this day, the canonical ones are those with the big market caps: search engines like Google, Yahoo, YouTube, etc. Now we even have social navigators to organize our professional and personal relationships i.e. LinkedIn, Spoke, and Facebook. The feature that navigators share is that they aim to be (largely) unaffiliated with any particular buyer or seller. In fact, information businesses everywhere must understand that affiliation is now a very real and powerful axis of competition.
So what does any of this have to do with investment banks? Don't they sit at the top of the economic food chain above all of this stuff? Not remotely. This leads me back to my story about the comptroller. This particular state finance official was wrapping up an advisor request-for-proposal process and was curious about our capabilities. In response to why he was going through this process now, he told me that for the decade plus that he'd worked there, their investment bank (whom they only changed once) had run all of the numbers. But now, they're planning on a financial advisor running the numbers because, "We want to make sure the advice we're getting is solely in our interest."
What Information?
Obviously, one instance does not make a rule. But the increasing awareness and commensurate skepticism associated with the sources of our information is surely not an isolated trend. Investment banking clients want either unaffiliated information or better yet, information that they feel is purely and unfailingly affiliated with them. Investment bankers always walk through the door with their bank's name on their business card. In the back of the client's mind is that name. Rightly or wrongly, along with it is an ongoing question of whether the information coming from that banker isn't perhaps a bit influenced by the interest of her/his employer.
Bankers are hardly defenseless; they can do a great deal to fight the good fight. I personally haven't seen it yet, but that's a topic for another post…
ps Many thanks to Professor Orr for the penny image above.
Posted by Peter Orr on Sun, Feb 08, 2009 @ 03:14 PM
"Number 10: Never give up on an idea simply because it is bad and doesn't work. Cling to it even when it is hopeless. Anyone can cut and run, but it takes a very special person to stay with something that is truly stupid and harmful…"
- George Carlin, Fifteen Rules to Live By
It's popular these days to jump onto the "Wall Street versus Main Street" bandwagon and say all investment banks are inhabited by dark lords of money, all blood relatives of Gordon Gecko, though more greedy and substantially less charming. I'll go out on a limb here and say that I generally don't agree. I've known plenty of investment bankers – many of them extremely dedicated, hard working, and bright, and in my experience kind (unless you're a starting analyst, but that's another story…). Yes, they're commercially minded but that's the nature of the business. And though I admit that the ego/ability ratio by which I occasionally assess a finance professional can be skewed towards the numerator (sometimes grotesquely) all in all these are usually talented, driven professionals.
That said, whatever new financial regulatory system comes down the pike, investment bankers will still exist and will still serve a critical function as capital raisers for companies that need it. However, they've got two big problems that need to be addressed: one is a functional and organizational misalignment with clients (discussed below); the other is a more fundamental conflict between the information age and the traditional IB business model.
The Organizational Challenge – Misalignment with the Client
Investment banks are not organized in a way to efficiently provide services that the client wants. To a large degree, investment banks today remain silos of product knowledge organized through a traditional command and control hierarchy with managers and staffs. Each business manager and her/his team tries to achieve certain budgetary goals and targets set at the beginning of each fiscal cycle. Within investment banks these groups tend to line up with the various services and products that the bank provides. Many are divided along market lines: interest rate, currency, energy, commodity, etc. This structure has been exacerbated in recent years as IBs have moved more and more away from their traditional roles as consultants and deal-makers for raising capital, to levered risk takers managing the IBs balance sheet aggressively through prop-trading. To add to the problem, every two or three years the IB alternates between organizing across market lines and geographic lines. In both cases, IB management seems to either ignore or misunderstand the functional needs of their clients.
Investment banking clients by contrast are concerned with some combination of risks due to the nature of their current or anticipated balance sheets. However, concepts behind risk across multiple asset classes are subtle and often counterintuitive. Standard deviation or "volatility", the most frequently used proxy for a risk measure is not a simply additive term. In volatility terms, one plus one can equal anything between zero and two, and is usually somewhere in between. This truth currently manifests itself in the frequently misunderstood topic of "asset/liability management".
In short, clients face multiple market risks at once and are managing them in a portfolio. A bank is a conglomeration of products that buy/sell each of the risks the client faces but have little cross-product interaction or understanding. And the incentive structure internally at an investment bank amplifies the silo problem. An investment bank is not functionally aligned to understand its clients perspective, and therefore, to really address their needs. Investment banks are set up to sell products; IB clients want to receive high quality analysis of those products in aggregate as it relates to their specific situation, as a service. Do banks want to provide this service and if so, what does it look like? How does the bank get paid for it? Why should the client believe in the analysis? Does the banker's affiliation with her/his employer result in an increasingly skeptical client perspective? I'll leave some answers to that for part II….
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 Fri, Dec 26, 2008 @ 04:04 PM
"Appreciation is a wonderful thing: it makes what is excellent in others belong to us as well."
- Voltaire
Many very talented finance professionals are out looking for work these days. If they want to stay in finance they may need to move more towards seeing the box as glass instead of black. Let me explain…
A long way back a friend of mine told me that finance is really just the marriage of economics and math. In that vein, I sometimes think of finance professionals in two flavors: black box people and glass box people. This often informs my sense of their ego/ability ratio. Some practitioners don't have the desire or background to ever look behind the curtain and see the inner workings of the math inside the "box". These are black box people. Most finance professionals are black box people and they don't need to have built a model or application from scratch in order to use it effectively. For example, only a small percentage of people in the field can derive the Black-Scholes-Merton formulas from first principles. That said, many, many more can use them profitably without this detailed knowledge.
To be truly effective as bankers/advisors dealing with clients, however, these black box people need to be skilled enough to convey insight about what's going on inside the box and why. If it's a well designed box relevant to its audience, it can shed unique light on the risks faced by institutions or individuals. Good black box people are efficient translators, educators, and consultants. Training black box people requires developing interesting, relevant, digestible materials for a non-quant audience. To put it gently, this is often not a quant's strong suit.
Glass box people on the other hand can get their hands dirty building powerful, relevant models that are intuitively easy to use. They must know or extract from users (usually black box people) the cares and concerns that would drive high quality, high impact, and accessible analytics. Further, a good glass box person can see when additional features will add another two weeks to development and only 1% more utility. Those types of bells/whistles don't survive a good glass box person's planning process. Perhaps most importantly, a good glass box person knows a bit of the perspective of the black box thinker – and it is this skill that makes her/him most valuable.
Good glass box people are rare, though their numbers are growing. Many black box people would aspire to become glass box people if the managers to whom they reported cultivated the development of the requisite glass box skills. Unfortunately, most senior finance professionals were never glass box people themselves and as such don't really know how to manage or encourage the growth of the glass box group. Look around as the financial services industry necessarily reinvents itself – more and more of the ones who survive and thrive will be of the glass box variety.