3 Spreadsheet Horror Stories from Banking

To misquote a phrase once used about advertising: “Spreadsheets are not necessarily a good or bad thing, it depends on the use to which they are put.” They are certainly a prominent feature of everyday life in banking. They do though need to be used carefully. This week’s post has a sample of the typical kind of mistakes in dealing with spreadsheets.

Wrong Formulae Risk: JP Morgan’s London Whale issue has another dimension to it. One of the problems they had, which we have covered in a previous post, was having the risk information in disparate systems and never reporting on the aggregate risk. On top of this it seems that a spreadsheet wrecked havoc on the CIO office where this was all going wrong too. The reporting to the regulator, in this case the OCC, the US Office of the Controller of the Currency, was wrong due to an unchecked formula, which added risks together rather than averaging them. To make matters worse, the OCC officials reviewing the changed number for VaR, Value at Risk, were apparently not alarmed when the number changed by 50%. That number is just “normal”. There is that expression again, “normal”. A change that big just has to be a cause for discussion.

For more on this, see: Bloomberg, Feb 4, 2013

Copy / Paste Risk: Spreadsheets often come into play when data needs to be aggregated from several sources. In previous posts we have discussed the perils of having too many systems do the same thing. As soon as you have to cut and paste data from one system to the other or, heaven forbid, re-enter it, there is a risk of getting it wrong. Exactly that once happened to Fidelity’s mighty Magellan Fund. A negative return was inadvertently entered the wrong way round, prompting Fidelity to announce a huge distribution. The happiness bubble of its investors was soon deflated when they found that a cut & paste error had inflated the returns. Now, I cannot help feeling that the returns were so much better than normal, that more questions should have been asked.

For more on this, see: CIO Magazine August 2007

Reconciliation Risk: In the earliest days of setting up Goldman Sachs’ Swiss Bank, we had a couple of clients who were more active than the others. In a private banking set-up, the private bankers route their orders via an execution desk. One of the bankers decided to ask the Execution Desk to more actively manage a particular client’s account, giving them a spreadsheet of positions and some instructions about what to do if prices moved. I can specifically remember the Ops manager at the time telling both the banker and the execution desk that this was a bad idea and it would come back to haunt them. Sure enough, the Execution desk used the spreadsheet and promptly sold shares the client no longer owned. The sheet had of course not been reconciled back to the actual account holdings and the bank then had to eat the losses. The Ops Manager walked up to the banker and went: “Boo.”

Lessons Learned: Normal. One more time. This is an important concept in monitoring.  How big of a change are you seeing? Proper systems for repetitive tasks. If you are to do something more than once, do it properly. If data has to be aggregated, then the processes around it need to run on proper systems with the usual level of IT support.

A personal request: Comments and feedback from regular readers are very welcome. Thank you for each and every one of them. If you find this Blog useful, please subscribe. There is an E-Mail tool and an RSS link on the right hand side of the main Blog page. If you like it enough to share, please share this with a friend or two and ask them to subscribe too. If the comments are wide of the mark and not offering anything of use, please comment or make contact directly via E-Mail

Share on: