(from Derivatives Strategy, August 1998)

My customers are all geniuses. After all, they were smart enough to buy my product, TOPS, which allows them to price and hedge all manner of exotic options and derivatives. I'll even go so far as to admit there are some pretty smart people who have bought software from other vendors (though I wouldn't exactly call them geniuses…). But there are still people out there who don't buy from any of us. Over the years, they've given me a variety of reasons why they want to go it alone. Naturally, I don't think any of the reasons are any good. Despite the fact that they say "The customer is always right," until you've bought a third party analytics package, you're not a customer, and therefore, in my humble opinion, you can be wrong. In that spirit, I'm going to share some of the reasons potential customers have given me for not wanting to buy my product, along with some unassailable rebuttals. I call them "The Top Ten Reasons I Don't Need Derivatives Software."

10. I already have free software from _________.

Fill in the blank: it can be a dealer, like Goldman Sachs or Morgan Stanley, who will sometimes give their clients copies of some simple routines to price options. Or it could be something downloaded from the Internet as freeware, or something that was written by the guy's brother in law because he saw the formula in a magazine spreadsheet column. In any case, the old adage "You get what you pay for" certainly applies. For one thing, the product will almost certainly not be supported. For another, if it's freeware, it might have bugs in it. Even if it comes from a big dealer, it's probably not going to have the user interface features you're looking for to save time, or the ability to calculate needed sensitivities like delta and gamma. And if the program was put together by someone who lifted the formula from a magazine article or a book, it could have typos in it. All of which means the software isn't really free anyway, if it costs you time and aggravation in the end.

9. What if there's a derivatives blowup?

OK, what if? If the blowup occurred because a trader was sticking tickets in a drawer, it doesn't matter whose software was used. The same thing is true if bad volatilities are being used to mark options to market, or there are data entry errors, or a trader predicted the market was going to go up and it went down instead. On the other hand, if the blowup occurred because a model was misspecified, or because the coding of a good model was done poorly (isn't that nicer than saying "There's a bug?"), you'd have a legitimate gripe if it was a third party program that caused the blowup. But if you look around at the derivatives debacles of the last few years, I can't name a single one that was caused by an external software package. Every instance of model error came from an internal program. This doesn't mean every third party package is perfect. It just means that keeping your analytics in-house is no guarantee of safety. Besides, if there is a blowup in the future, and the cause was an outside package, wouldn't you want someone outside the organization to blame it on?

8. You guys can't be as good as us. After all, we work for a major bank.

So did we. That's not to say every software vendor has a team of people from major Wall Street firms. But those that are should be just as good at modeling derivatives, if not better. Speaking only for myself, I can say that the modeling I'm doing now for Savvysoft is better than what I did at Bankers Trust. It has to be, because I know more now than I did then. Which isn't to say I was stupid when I was at BT. After all, we never had a problem with our pricing models, well publicized or otherwise, while I was there. It's just that the models I sell now are even better.

7. The NIH syndrome.

NIH is Not Invented Here, and it is used to describe companies that want to be totally self-reliant. Like a hermit that builds his own log cabin, grows his own food, makes his own bombs, etc., those with NIH effectively worry about the day something vital in their world will no longer be available, and they'll die because of it. It's just as true for an organization as it is for an individual. The irony is, corporate NIH can actually lead to the event it is meant to avoid, as witnessed by Apple's near death experience these last few years. And as one of our client/geniuses pointed out to management while fighting NIH to buy our software, where do you draw the line? Do you build your own pricing models to run inside Excel, and then also build your own Excel compatible spreadsheet, and then build your own version of Windows, and then build your own BIOS, and then design and build your own C compiler and computer? At some point, you have to trust someone else to be a supplier. And there's no real reason why the line should be drawn at option modeling.

6. Our structures are too complex and proprietary to be handled by an off the shelf package.

That may in fact be true. But take a good look at a high end derivatives package, and see if it can't really price your trades. We've worked with lots of companies, and if Will Rogers never met a man he didn't like, I've never met an option I couldn't price. When we come across something new, we add it to our package. That's how we stay current, and keep our product up to date. But even if we can't handle the odd deal, or you don't want to tell us your secrets, that's OK too. Because you probably want your top research people working on the really hard problems, not doing date routines and valuing more common derivatives. So farm that work out to a third party vendor, and concentrate on the places where you can add value. But also consider the fact that we vendors often come across a wide spectrum of trades, as we are asked to handle new deals. What you may feel is proprietary may be something we've already come across, and it may be a problem we've already solved. It's worthwhile to at least ask the question "Can you price this thing?" The only cost is the time spent asking.

5. We're already making money.

If the amount of money you made last year is enough, then please do me a favor: If you make more money this year than you did last year, give me the excess. Or do yourself a favor, and stop working such long hours. However, if you would like to make even more money, then consider how you can improve your operations. And buying a third party package is a great place to start. It will allow you to increase revenues by getting into new markets, and save time and costs by getting into them faster and more cheaply. Besides, even if you're making money now, that's no guarantee of success in the future. Markets change, and you'll need to stay on top of change to stay on top. Don't be left behind by technological obsolescence. Think of a third party analytics supplier as your partner in a joint venture, but a partner that doesn't get their grubby hands on any of your equity.

4. We have an in-house quant group.

That's OK, because if you're doing enough business, you should have research people on staff. But let's say you have only one PhD doing modeling. Do you want to trust them with your whole business? Probably not. So for a second opinion, maybe you hire another doctor. But it would be much more efficient to buy a third party package for that. That would save you the expense and trouble of hiring a second person, or, if you want the second person anyway, it would let them model other products, so you'll get twice the work out of your staff. The argument holds no matter how big the research group is: You want a double check on people's work, and it will always be better to free up existing staff to do what they do best. Another less obvious reason you may prefer to go outside for much of your modeling is that a commercial package is commercial quality, which means it comes with a proven interface, documentation, is stable, and market tested by others in your mission critical situation. In house research groups often concentrate just on the math, without considering a host of other variables, all of which can lead to unnecessary operations risk.

3. I don't need a model. I just call around for quotes.

It seems like a Catch-22: An option model is no good if it can't give you prices that match the market, and if you have market prices, you don't need a model. This argument can be used to avoid both third party purchases, and also hiring in-house researchers. But the argument falls apart as soon as you need to hedge the trade, or measure its risk, or compare two different trades, or exploit a mispricing, or set target levels, or do any kind of what-if analysis. Of course, if you don't fall into any of these groups, why are you wasting your time reading this magazine?

2. I'll lose my job.

I know about this one, because it was the same argument I gave at BT whenever a vendor came in to show us a package. Hey, I was young and insecure. So I spent a disproportionate amount of time reinventing the wheel and not doing fun stuff like modeling even more esoteric options, or going home before midnight. After I left BT, and became a vendor myself, I went on a sales call to a major bank, and made a presentation to the head of the desk, and his chief quant. To my surprise, the quant admitted in front of his boss that he felt threatened by third party software, and wouldn't want to buy our package purely for that reason. Well, we didn't get the sale. And where is the quant now? He decided to become an analytics vendor himself!

1. It's too expensive.

It's a little embarrassing sometimes to be selling software that costs more than the computer. But it's really just because Microsoft can amortize their development costs over millions of customers, and those in our segment of the industry cannot. In fact, if you think about how much quantitative researchers, systems analysts and programmers earn, and how long it takes to derive option models, develop user interfaces, code them, test them and write documentation, and then support and upgrade the software, you'd realize it can cost millions of dollars and take years to build the same system you can buy off the shelf for a few thousand and get right away, saving you money and allowing you to exploit new markets before the window of opportunity closes. Granted, what you build in-house will be customized for your needs. But the right third party package can be used as a toolkit for a system that is just as customized, and can be delivered in a few months for a fraction of the cost. Ultimately, buying a third party package has to be cheaper than doing it yourself, because even though we're amortizing our development costs over fewer places than Microsoft, we're still amortizing them over more than in-house groups, who spread their costs over just one place. In summary, there is an eleventh reason I'm sometimes given, which is "Your package looks great, but we already have something built." To which I reply "There's always going to be new derivatives invented, and new models developed." So going forward, it's worthwhile considering third party analytics. Even if you haven't bought a package yet, it's never too late to become a genius.