Friday, November 30, 2007

Financial Due Diligence

In my super-mega Investment Bank, we work with all kinds of vendors. In fact, in our old group, one of the things that we were charged with was investigating all kinds of esoteric technologies that could give us an edge in the trading world.

If you use a vendor for a "bet the farm"-type application, then you want to make sure that the vendor behind the product is rock solid. My boss, who is the Global Head of Equities Technology for the firm, asked me who the "800 lbs gorilla" is in the CEP space. He wanted to make sure that we were safe in our choice, and that no matter how good the technology is, we did not put all of our eggs into a guy working nights in his basement (although, those kinds of companies usually make the best software!).

There is really no 800-lbs gorilla is the "pure" CEP space. By "pure" CEP players, I am talking about guys like Aleri, Coral8, Streambase, Esper, Apama, Truviso, Kaskad, etc. In this space, most of these companies number their customers in the dozens rather than the thousands. These companies are all competing for that big reference customer, the one that companies can stand back and say "This investment bank doubled their trading revenues because of our product."

Compounding this fact is the whole credit crunch and subprime mess. The New York Times had an article yesterday that described the effects that the credit crunch is starting to have on all sorts of companies ... even softeware companies and web-design shops were mentioned. So, we need to make sure that the CEP vendor that we choose is not affected, nor will be affected by the credit crunch. Coincidentally, one ex-employee of a CEP vendor sent me private email that mentioned that his company was undergoing a round of layoffs.

No matter which CEP vendor you choose, you should always have one backup. This is standard practice when dealing with small vendors. You should have the vendor's source code in escrow. You should have your financial people do a deep dive on a vendor's financials. Is the vendor self-funded or are they VC funded? Does the VC have the appetite to wait 5 to 7 years for a good return on their investment? What is the past behavior of the VC firms with regards to startups? What happens if the chief architect of the product leaves the company? Is the product written in a mainstream language, in case you need to take possession of the source code that's in escrow?

These are all questions that you should ask before making the final selection of your vendor.

©2007 Marc Adler - All Rights Reserved

3 comments: said...

Hi Marc,

Excellent post. Please see my follow-up here:

Yours sincerely, Tim

Hans said...

I'll agree with all of this except to say that I am very skeptical about how much risk is mitigated by code escrow. Of course it is only wise to ask for code escrow given a major investment in the overall project.

But even if the EP product is written in a mainstream language, taking possession of and then actually using that code from escrow will be very expensive. By the time the escrow might realistically be used, the project will most likely be done with the main development phase and looking to lower its run rate for staff costs. Now let's say you fix an important bug in the code from escrow. You build yourself a new install of the EP software, but will deploying your big project under this build... increase or decrease stability?

Code escrow is pretty much standard but I suggest that its real impact on project risk is limited.

ken said...

Agree w Hans- Escrow is an incredible waste of time. Effectively a non fungible options which requires a great investment to contractualize and support, and yet is hardly ever exercised. And yet for many its just mandatory- period.

For that reason I'm a fan of the optionable escrow, whereby the beneficiary has a right to ask for Escrow at any time, but until that time the depositor doesnt have to actually do the deposits.