---
title: 'Why Computers Can''t Count Money'
source: 'https://youtube.com/watch?v=rQxPGqPq8wk'
video_id: 'rQxPGqPq8wk'
date: 2026-08-10
duration_sec: 365
---

# Why Computers Can't Count Money

> Source: [Why Computers Can't Count Money](https://youtube.com/watch?v=rQxPGqPq8wk)

## Summary

This video explores a historical bug in early digital payment systems where tiny rounding errors in floating-point arithmetic allowed users to generate money from nothing. It explains the technical root cause—binary representation of decimal numbers—and how the financial industry responded by switching to integer-based accounting.

### Key Points

- **The Mysterious Disappearing Money** [00:01] — In the early 2000s, people found unexpected money in their bank accounts due to a class of bugs affecting many financial institutions, not just one.
- **The Rise of Digital Payments** [00:29] — Online payments were booming, with startups like PayPal growing fast and banks digitalizing to keep up, leading to rushed financial software development.
- **The Challenge of Handling Money in Code** [00:58] — Money in software is hard: you can't lose a cent, create a cent, or be almost correct. Tiny rounding errors began to appear, initially unnoticed.
- **The Accumulation of Rounding Errors** [01:28] — A large bank processing millions of transactions daily could accumulate minuscule errors (e.g., 0.0000001 per transaction) that become significant at scale.
- **The Exploit** [01:59] — Users discovered that by triggering specific sequences of transactions (splitting, recombining, converting, reversing), they could amplify rounding inconsistencies to their benefit, generating real money from nothing.
- **The Industry Response** [03:22] — Major institutions like Visa and MasterCard had to rethink how they handled numbers, moving away from floating-point arithmetic.
- **The 0.1 + 0.2 Problem** [03:36] — In most programming languages, 0.1 + 0.2 equals 0.300000004, not 0.3, because computers store numbers in binary (base 2), and some decimals can't be represented exactly.
- **The Solution: Integers** [05:18] — Modern financial systems store currency as integers (e.g., 1,023 cents instead of $10.23) to avoid rounding errors and drift.
- **The Ongoing Relevance** [05:47] — Every online price and payment relies on engineering that ensures 0.1 + 0.2 equals 0.3, because if it doesn't, someone gets paid incorrectly.

### Conclusion

The bug that almost broke money was a class of floating-point rounding errors that, at scale, could be exploited. The industry's solution—using integers for currency—remains a fundamental principle in financial software today.

## Transcript

tech history that people checked their banking accounts to find money that didn't exist. Not a scam, not a hack, just a good old-fashioned bug. You'd probably assume someone got fired, but this wasn't just one bug. It was a class
financial institutions were affected by it. To tell my story, I need to go back to the early 2000s. For those of you who are too young to remember, I will set the scene with Motorola flip phones, iPods, Pokémon cards, and Britney and
Justin's matching denim outfits. Now, online payments are just starting to kick off, and companies like PayPal are growing super fast, and banks are digitalizing to try to keep up and not get left behind. Essentially, startups
are building financial systems and quickly. And when you're moving fast, handling money in software is actually way harder than it sounds. You'd think it's just numbers. You add a few dollars together, subtract some dollars, done.
But, money has rules. You can't lose a cent, you can't create a cent, and you definitely can't be almost correct. But, here's where things started happening. Small discrepancies started to creep in, and I'm not talking dollars, I'm not
even talking cents, I'm talking minuscule fractions of cents. Tiny rounding errors that no one noticed at first, until of course they do. So, going to work at a big big bank, and our big big bank processes millions of
transactions every single day. Now, let's say each of these transactions, each of these million transactions, has a tiny tiny minuscule rounding error. a tiny tiny minuscule rounding error. Let's say 0.0000001
meaningless, but at scale, it starts to accumulate. Now, here's where it gets accumulate. Now, here's where it gets messy. Some systems would round up, others would round down, and sometimes they wouldn't round at all. So, money
would start to, let's call it, drift, and reports from many different platforms started to come in about balances not quite adding up. By this, I mean transactions that left behind microscopic residues and accounts that
gained or lost fractions. And then, people started to notice something. If you trigger the right sequence of transactions, you could amplify this and to your benefit. I'm not sure if this is called hacking, as essentially you
aren't hacking or trying to enter the system. You're just using something that exists, but to your sneaky benefit, over and over again. In some early digital payment flows, including systems similar to what PayPal and banks were
experimenting with, users found ways to split transactions, recombine them, trigger conversions, and then reverse them. And each step introduced a tiny rounding inconsistency. And those inconsistencies, well, they stacked.
Now, to be clear, this didn't make everyone a millionaire overnight, especially because these transactions were minuscule. But, there were cases where people exploited random behaviors to generate real money from nothing. And
of course, that was a problem. Financial systems caught on quickly, because once you scale this across millions of users, it becomes a serious issue. Major institutions, from traditional banks to companies like Visa and MasterCard, had
to rethink how they handled numbers entirely and get rid of the assumption Don't get me wrong, they can be incredible, but not always. Let me show you something by simulating some numbers. A balance. So, here we have a
balance. We start over the balance being zero, and then we add 0.1, then we add 0.2 to that balance, and you'd expect 0.3, right? But, you get 0.300000004.
balance deeply equals 0.3, console log correct balance. Then, that condition would fail. In fact, it's the same for these. In most programming languages,
instead, you get this. Here's why. Computers don't store numbers in base 10 Computers don't store numbers in base 10 like we do. They use binary, base two. For those of you who don't know, base 10 means you have 10 digits. So, 0 1 2 3 4
means you have 10 digits. So, 0 1 2 3 4 5 6 7 8 9. Each position is a power of 10. So, this number 345 actually means this. Base two means you only have two digits, zero and one. Each position is a power
of two. So, this number 101 actually means this, five in base 10. And some decimal numbers like 0.1 or 0.2
And some decimal numbers like 0.1 or 0.2 can't be represented exactly in binary. So, instead of storing exactly 0.1, the computer stores the closest possible approximation. Same with 0.2. And when you add those approximations together,
you don't get exactly 0.3, you get something slightly off. Most of the time, it doesn't matter. But in financial systems, where millions of operations happen every second, that tiny difference becomes real money.
This is why modern systems don't use floating point numbers for currency, they use integers. Instead of storing $10.23 $10.23 like this, they store 1,023 cents. No
decimals, no rounding errors, no drift. So, because of that one bug, the one that made balances slowly shift, an entire industry was rattled and had to rethink how money works in code. And it's still relevant today. Every time
you see a price online, every time you make a payment, an entire layer of make a payment, an entire layer of engineering is making sure that 0.1 + 0.2 actually equals 0.3. Because if it
doesn't, someone somewhere is getting paid. And that's the bug that almost paid. And that's the bug that almost broke money.