Posted by Peter Orr on Wed, Mar 10, 2010 @ 12:33 PM
"Knit Cap Creates Huge Hangover" is Not a Good Headline
I know the "Complicated Stuff You Don't Understand Is Secretly Destroying You" theme is an eminently reliable one that reporters have used since time immemorial. Couple it with the now wildly popular "Wall Street Fat Cats are Stealing Your Money" theme and you've got a ready-made recipe for some uber-potent journalistic catnip. Reporters from WSJ,Bloomberg News (covering this for years and still looking for that Pulitzer...), and most recently the NYTimes have gotten wild highs off of combining these two stories into some variant of, "Wall Street Robs a Town Near You with Interest Rate Swaps." The facts in these stories, if discernible beyond the often fuzzy innuendo, are usually distorted at best or flat out wrong. So let's get the story straight. Much of it ain't that sinister or complex and the talented public finance professionals who work to save tax and rate payer money deserve it.
No different than the homeowner who must decide on either a fixed or adjustable rate mortgage, public finance officials must make tough decisions about interest rates. Most of the time they employ traditional fixed rate bonds, or as I call them, Boring Old Bonds (BOBs). However, history has shown us that over substantial periods variable rate bonds have offered a lower cost of capital than BOBs. Yes, this is obviously not a rule and far from a prediction about the future. However, it was not unreasonable or uncommon for an issuer to decide to have a certain portion of its debt exposed to the short end of the yield curve. If the issuer had working capital or short duration assets on the balance sheet, this was in fact the prudent risk management decision. The rating agencies even had a rule of thumb: no more than 20-25% debt in a variable mode, unless it came with a compelling story.
Public finance borrowers used auction rate securities (ARS) and traditional variable rate demand bonds (VRDBs) with bank liquidity support as floating rate instruments. Now enter the subprime meltdown and subsequent credit/liquidity black hole from the last 18 months. In retrospect, ARS were sold in an extremely thin and fragile market which evaporated during the crisis; ARS rates went to a failure rate, which was often, though not always, very high. VRDBs performed well if the issuer was lucky enough to have a strong bank name behind them. Others suffered and had rates go to the moon. Where are the interest rate swaps in all this? NOWHERE! And that's the point.
Interest rateswaps were used to hedge the interest rate risk inherent in the ARS or VRDBs. Over the last year, the difference between 67% of LIBOR and SIFMA was 0.14%. For the record, historically that's an extremely narrow spread. These swaps were never designed to hedge MBIA falling off a cliff, the ARS market vanishing, or Dexia's credit rating. And therein lies the absurd (and I suppose predictable) conflation mistake reporters make on these stories. It's the interest rate swaps fault for not hedging all the credit events that occurred with the issuer's bonds. Blaming the interest rate swap for these problems is a bit like having a fearsome headache after a late night and blaming the pain you have on the hat you're wearing in the morning. Here's the headline, "Knit Cap Causes Enormous Hangover." The cap is there to keep your head warm, not fix your hangover. And it certainly didn't create your headache in the first place.
Don't get me wrong. I'm hardly naïve. I realize that having used interest rate swaps to hedge the interest rate risk in ARS and VRDBs has often made the situation more difficult to workout or refinance into fixed rate bonds. Collateral calls if applicable have further pinched liquidity at just the wrong time and the negative mark-to-market value of the swaps can be large with rates this low. If refinancing with BOBs, at least the MTM is partially offset by the issuer selling BOBs into a lower fixed rate market than the one in which the swap was executed. I realize that's all just financial reality and shouldn't get in the way of a good ol' beat up the Street story, particularly not these days. And that's where the real meat of this story is - whether these contracts are enforceable given the clear verdict in the court of public opinion. Are our legal institutions powerful enough to withstand our political ones? I'll save that for another post but it was actually covered recently by the press...and relatively well; you can read it here.
In the meantime, if you're a reporter and you want to do a balanced, factually accurate article about municipal swaps, I'm available. We're installing new lines to handle call volume...
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.