Bank of New York 1985: The Software Failure That Created a $32 Billion Overnight Overdraft
Bank of New York's 1985 securities-processing failure let incoming Treasury deliveries pile up without matching redeliveries, producing a historic Fed overdraft and overnight emergency loan.
The famous $32 billion figure describes a rapidly changing intraday crisis
The Bank of New York incident is often summarized as a “$32 billion overdraft,” a figure reported contemporaneously as the bank’s cash-account deficit during the disruption.[5] The Federal Reserve’s own testimony gives a more precise timeline: the securities-account overdraft was almost $30 billion around 8:30 p.m., had fallen to $24.2 billion when the securities wire closed, and the New York Fed ultimately made a $22.6 billion overnight discount-window loan; an additional reserve-account overdraft brought total Fed credit to $23.6 billion.[1] The roadmap title preserves the famous shorthand, but the official record matters because different numbers describe different moments and different forms of exposure.
The failure was a settlement problem before it was a credit problem
The bank was receiving government securities through the Federal Reserve’s book-entry system but could not process and redeliver them normally. Money was debited to pay incoming sellers while the corresponding outgoing deliveries that would replenish the bank’s account were delayed.
Software failure damaged the transaction database needed to recover
Federal Reserve testimony said the settlement problem was caused by computer-system software failure and that Bank of New York’s account and individual-transaction data had been damaged.[1] That damage made recovery far harder than a simple machine restart. A clearing bank has to know which customer owns each security, which counterparty is due payment, and which transaction has already settled. Once that state becomes unreliable, operators cannot safely accelerate processing merely by adding hardware. Correctness has to be reconstructed before money and securities can move again.
Corrupted state can be more dangerous than unavailable state
A clean outage tells operators not to process. Corrupted records can tempt a system to continue with the wrong ownership or settlement information. Financial recovery therefore needs reconciliation controls that can prove state, not just restore server availability.
Fedwire’s delivery-against-payment mechanics magnified the liquidity effect
Later Federal Reserve analysis explains why the overdraft grew so quickly: the New York Fed debited Bank of New York as securities were delivered into its custodial accounts, while the software problem prevented the bank from redelivering those securities to buyers and receiving offsetting payments.[2] Under normal conditions, these intraday debits are temporary. During the incident, the normal recycling of securities and cash stopped on one side. The bank was effectively financing an enormous inventory it did not intend to hold.
Automation concentrated enormous values into a short operational window
Electronic settlement made the government-securities market faster and cheaper, but it also allowed operational faults to accumulate financial exposure at computer speed. Reliability controls therefore had to be designed for the value and velocity of automated settlement, not for paper-era assumptions.
The Federal Reserve kept the wires open and then supplied a fully secured overnight loan
The New York Fed extended operating hours into the early morning to give Bank of New York time to reduce the debit position. When recovery remained incomplete, the Fed provided the overnight advance, secured by domestic assets and customer securities the bank was permitted to pledge. The 1985 New York Fed annual report later described the loan as a record $22.6 billion advance and used the event to illustrate payment-system risk.[4]
Containment prevented an operational failure from becoming a solvency panic
The bank’s capital was not the immediate issue, and the Fed emphasized that the loan was well collateralized. The intervention bought time for settlement state to be repaired without forcing a disorderly shutdown of the government-securities market.
The incident changed how regulators thought about settlement and daylight credit
Federal Reserve work after the episode increasingly focused on the risks created by large intraday overdrafts, operational concentration, and the dependence of major markets on a handful of clearing institutions. Later Fedwire risk frameworks imposed controls, net-debit limits, collateral practices, and pricing around daylight credit.[3] The lesson was not that central-bank liquidity should disappear, but that routine settlement should not rely on emergency lending as its normal resilience mechanism.
Backup facilities must include recoverable data, not just spare computers
Corrigan’s testimony explicitly linked the episode to the cost of adequate computer backup facilities. A second processor is useful only if it can take over with current, trustworthy transaction state. Financial institutions therefore need replicated records, tested cutover procedures, reconciled journals, independent communication paths, and rehearsed operating roles. A hot standby without dependable data can reproduce the original failure or sit idle while staff manually reconstruct what happened.
The broader system proved resilient, but partly because the day was fortunate
The Fed later stressed that market disruption was contained, yet officials also noted favorable circumstances: the day was not an end-of-reserve-period settlement date and other major systems were functioning. Reliability history should not convert a contained incident into proof that the architecture was safe. The episode showed how close routine settlement plumbing could come to creating generalized disorder when operational failures, market volume, and interbank credit intersect.
Why Bank of New York 1985 belongs in software-failure history
The Bank of New York failure belongs in software history because an error in transaction-processing software propagated directly into the monetary plumbing of the U.S. government-securities market. The program did not merely inconvenience users; it prevented a major clearing bank from knowing and forwarding the state required to settle enormous flows. The Fed contained the event with extended processing hours and secured credit, but the incident exposed a permanent truth about financial software: when code represents ownership and payment obligations, database integrity, failover, reconciliation, and operational recovery are part of financial stability itself.
Works Cited
- 01Federal Reserve Bulletin, February 1986 — Statements on the Bank of New York Incident fraser.stlouisfed.org
- 02
- 03
- 04Federal Reserve Bank of New York — Annual Report 1985 fraser.stlouisfed.org
- 05The Washington Post — Computer Snarled N.Y. Bank washingtonpost.com
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.