The compliance checklist for spreadsheets in financial services reads like a set of reasonable precautions: access controls, formula review, reconciliation to source data, documentation, backup, periodic review cycles. Read it instead as a record of what has already gone wrong, and each line resolves into a specific incident that somebody paid to learn.
Several of those incidents are in the public record, with the connection to the control traceable.
At Allfirst Bank in 2002, a trader fed fabricated transaction data from his personal computer into a risk-control spreadsheet. The risk officer calculated value at risk from those inputs without checking them against the bank's own trading system. That one comparison would have exposed the discrepancy. Losses reached $691 million. Three control categories that now appear in every serious end-user computing policy — restricting who can modify critical inputs, separating the person who prepares a calculation from the person who reviews it, and reconciling spreadsheet data against an authoritative source — sit directly on top of this failure.
In 2003, Fannie Mae disclosed that an incorrect formula had shifted reported shareholder equity by roughly $1.1 billion. The regulatory response is probably the clearest documented link between a spreadsheet error and a rule: Fannie Mae's regulator required a remediation plan covering every end-user application involved in financial reporting, including a full inventory, automation where feasible, and written justification for any application the company thought didn't need controls. Formula review, inventory, and documentation requirements all descend from that single response. We can trace this one because the paper trail survived. Most spreadsheet failures are absorbed quietly, and the controls that follow them are written without anyone recording why.
The Senate investigation into JPMorgan Chase's "London Whale" losses found a new value-at-risk model running on manual uploads and spreadsheet calculations, with frequent formula changes that nobody reviewed. Calculation errors likely halved reported volatility. An agreed plan to automate the process was never finished, which is the ordinary fate of infrastructure work whose benefit shows up only when something breaks. Requirements for reviewing formula changes and independently validating models trace to this pattern.
The same category of failure shows up outside finance. In 2020, Public Health England omitted 15,841 positive COVID-19 cases from its dashboards because incoming files exceeded the maximum size the data-load process could handle. Completeness checks and boundary testing are the kind of control that emerges from failures of exactly that shape.
The timeline is as informative as the incidents. Spreadsheets became standard business tools in the 1980s. Sarbanes-Oxley imposed a general internal-control obligation in 2003 without naming them. The PCAOB first addressed end-user computing explicitly in 2007. Basel's BCBS 239 named spreadsheets in 2013, citing the risk-data aggregation failures the financial crisis had exposed. Roughly two decades separated widespread adoption from specific governance, and the governance arrived only after the failures, often after several of them.
That lag isn't a story about slow regulators. Nobody's budget rewards inventorying spreadsheets, and no incentive inside a firm surfaces an uncontrolled calculation until it produces a number large enough to require an explanation. The controls are scar tissue, each one encoding a failure that already happened.