Is Excel the most dangerous piece of software in the world? Baseline Scenario‘s James Kwak reports on a little-mentioned aspect of the notorious “London Whale” debacle at JPMorgan, where Bruno Iksil headed a proprietary trading team which made losses of up to $9bn.
To summarize: JPMorgan’s Chief Investment Office needed a new value-at-risk (VaR) model for the synthetic credit portfolio (the one that blew up)… The new model “operated through a series of Excel spreadsheets, which had to be completed manually, by a process of copying and pasting data from one spreadsheet to another”… After the London Whale trade blew up, the Model Review Group discovered that the model had not been automated and found several other errors. Most spectacularly,
“After subtracting the old rate from the new rate, the spreadsheet divided by their sum instead of their average, as the modeler had intended. This error likely had the effect of muting volatility by a factor of two and of lowering the VaR…”
Kwak wonders if the very ease of use that Excel offers — allowing people with no programming experience to knock together what are, in effect, relatively advanced applets — also makes it dangerous to use in most sensitive situations. There’s no debug, no audit trail, and no way to test why a spreadsheet returns the value it does. Similarly, training for Excel, where it exists, tends to ignore the importance of elegant and well-designed code, leading to legacy spreadsheets being used with internal workings which are opaque to all but their original creator, who may have left the company 20 years earlier.
The problem is, though, that Excel is the worst way to run a company’s software other than all the other ways. The fact that it’s capable of being programmed by the people who will end up using it means that it might enable hacked-together code, but it also prevents exactly the sort of corporate bloat which leads to people circumventing their company’s software in the first place.