|
|
|
|
|
|
|
Avoiding Software Time Bombs
by Rich Tanenbaum
(from
Derivatives Strategy
, August 1996)
When you hear ticking in your portfolio, you want the bomb squad, not the local electrician. But in a world where everyone wants to be your best friend, it can be hard to decide which vendor is telling you the truth. To help guide you (since I'm your real best friend) through the smoke, we present a set of features that are "must haves" for any derivatives software you might use to sniff out the bombs, and, better yet, to keep them from ever getting into your portfolio in the first place.
There are a lot of exotic structures out there, and being able to measure the risk of 90% of them sounds good on paper. In reality, all it takes is one or two bad deals to take down the whole portfolio, as we've seen so many times recently.
Ability to handle all structures
A sound derivatives system must be able to handle all different types of derivative structures: equities, fixed income, foreign exchange, commodities, options on cash or futures, American, European and Bermuda exercise, the list goes on. It must be capable of valuing Lookbacks, Barriers, Indexed Amortizing Swaps... the list still goes on. And the models must allow you to value structures with changing strike prices, changing notional amounts, changing coupons, changing barriers... and on and on, ad infinitum. Even if you don't currently have these instruments on your books, the software you buy today has to be able to handle them in case you own them tomorrow, or are being shown a new trade by a dealer.
It's not enough to know what an exotic option is worth, you also must be able to measure how that worth changes with the market. This is risk measurement, and it means all those greek letters options theoreticians love to use, like delta, gamma, theta, vega and rho. Risk measurement is important both before and after the trade. Before the trade, so you know in advance what type of risks you'll be taking on if you do the deal. And after the trade, so you can figure out how to hedge against the risks you don't want to keep.
For example, suppose you want to hedge a yen exposure you have in one year. One hedge could be to buy yen forward. Another would be to buy a yen call option, for say 7%. If you're shown an Average Price option by a dealer for 3%, it may seem very attractive, because it's so much cheaper. You may even run the inputs through your Average Price option model, and discover that 3% is a very fair value. But by doing some sensitivity analysis, you'll discover that as the yen gets stronger, the Average Price option doesn't rise nearly as much as the standard option. In fact, if the yen gets weaker for most of the year, and gets stronger at the end, the Average Price option will actually finish out of the money, and you won't be hedged at all.
It seems almost tautological to say this, but it needs to be said nonetheless: options software must use the appropriate pricing models. Surprisingly, they often don't. That's because too many people mistakenly think that Black-Scholes is the first and last word in option pricing. As groundbreaking as their formula is, it can't even handle exchange traded American options. There's a story that made the rounds a while back that when Fischer Black first joined Goldman Sachs, he was amazed at how prevalent the use of his formula was. Once he got over the initial shock, his first official order of business was to tell everyone to switch over to the binomial model so they could value American options.
The need to use the proper model is even greater when dealing with interest rate options. Again, the use of Black Scholes is prevalent, but even for European swaptions, the formula ignores the tug to par of a bond, or, if applied as an option on rates, it incorrectly converts the yield to an option price. Then again, merely applying the binomial model to bond options isn't enough, either, since that leads to put-call parity violations. Without an arbitrage free framework, like that of Ho-Lee, then whatever bond option formula you use, it will not be correct.
Twenty years ago, when option trading started taking off, anyone who needed a computer system to value and measure the risk of positions had to run their books on a mainframe. Fifteen years ago, people were switching over to Apple II's. Ten years ago they switched again, to the PC. And now they may run the system on a Sun, an HP, an RS 6000, or Next. Each time there was a switch, chances are the existing software (and database) had to be scrapped, and a new one written, with a new learning curve. Anyone who believes their current system will be their last system, is deluding themselves. The change may not come until next year, or in three years, but it will inevitably come. And when it does, you'll be much better off if your derivatives valuation models can be easily ported over from your old system to your new system. This results in faster and cheaper implementation of the new system, since you won't have to spend money rewriting large part of your derivatives models. And the models which use to work on your old system won't become broken on the new system. In other words, your derivatives software should be platform independent.
Platform independence means two things in the context of derivatives software. First, the option pricing models must be available as subroutines, callable from any programming language. Second, the subroutines must run on a variety of different machines and operating systems.
Beyond callable subroutines, derivatives software may come with a "front end" which is the user interface you use see to tell the program what type of structure to value. If there is a user interface, make sure it is easy and safe to use. This means that you can enter deals quickly, without a lot of pull down menus to go through. It also means that when you are entering your inputs, it should be clear what each input means, what type of data format the program is expecting (i.e., are interest rates expected as .07 or 7, are they annually or semi-annually compounded), if there's On-Line Help, and if it's easy to go back and correct any input errors.
The value of this feature is not just that of a shorter learning curve, but also quicker turnaround time in between when you are asked for a quote and when you are able to provide one. More importantly, the best user interface cuts down on input errors, which will cut down on misquoted deals. Making a wrong quote on a deal can cost dearly, and can cost much more than the price of the right software. Keep in mind, however, that even the best option pricing model will give the wrong quote, if it has been given the wrong inputs.
The derivatives software vendor you choose should have people on staff who have created option models for major investment houses. It may seem as if any programmer is capable of lifting a formula out of the latest issue of the Journal of Finance, but you trust an amateur at your own peril. For one thing, books and journals often have typos, and someone not familiar with the theory behind the model won't catch them. Also, the formula as stated may only be correct for certain types of options. For example, one widely published formula for barrier options can handle down and out calls, but not up and out calls. Even so, some well known derivatives software will blithely calculate (incorrect) values for these options.
Another reason you need a seasoned option modeler behind the software is so that new models will be added to the system as new structures are invented in the marketplace. Even someone who is knowledgeable enough to catch any typos in an academic paper, that person must still wait for the paper to get published before adding the model their software.
This paper has outlined some basic attributes that should be considered before purchasing derivatives software. You will find that althoug | | |