TubeSum

Why Computers Can't Count Money — Full Breakdown & Transcript

Why Computers Can't Count Money

0h 06m video Published Jun 18, 2026 Transcribed Aug 10, 2026 F freeCodeCamp.org
Intermediate 3 min read For: Software developers, financial technology professionals, and anyone curious about how computers handle money.
AI Trust Score 70/100
⚠️ Average / Some Fluff

"The title is catchy and the content delivers on the core promise, though it takes a while to get to the technical explanation."

AI 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.

[00:01]
The Mysterious Disappearing Money

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.

[00:29]
The Rise of Digital Payments

Online payments were booming, with startups like PayPal growing fast and banks digitalizing to keep up, leading to rushed financial software development.

[00:58]
The Challenge of Handling Money in Code

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.

[01:28]
The Accumulation of Rounding Errors

A large bank processing millions of transactions daily could accumulate minuscule errors (e.g., 0.0000001 per transaction) that become significant at scale.

[01:59]
The Exploit

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.

[03:22]
The Industry Response

Major institutions like Visa and MasterCard had to rethink how they handled numbers, moving away from floating-point arithmetic.

[03:36]
The 0.1 + 0.2 Problem

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.

[05:18]
The Solution: Integers

Modern financial systems store currency as integers (e.g., 1,023 cents instead of $10.23) to avoid rounding errors and drift.

[05:47]
The Ongoing Relevance

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.

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.

Mentioned in this Video

Study Flashcards (4)

What was the class of bugs that affected financial institutions in the early 2000s?

easy Click to reveal answer

Tiny rounding errors in floating-point arithmetic that accumulated at scale.

00:01

Why can't 0.1 + 0.2 equal exactly 0.3 in most programming languages?

medium Click to reveal answer

Because computers store numbers in binary (base 2), and some decimal numbers like 0.1 and 0.2 cannot be represented exactly, leading to approximations.

03:36

What is the modern solution to avoid rounding errors in financial systems?

easy Click to reveal answer

Store currency as integers (e.g., cents) instead of floating-point numbers.

05:18

How did users exploit rounding errors to generate money?

medium Click to reveal answer

By triggering sequences of transactions (splitting, recombining, converting, reversing) that amplified tiny rounding inconsistencies.

02:13

💡 Key Takeaways

📊

The Bug That Almost Broke Money

It sets up the entire narrative with a compelling historical mystery.

00:01
🔧

The 0.1 + 0.2 Demonstration

A concrete, relatable example that makes the abstract concept of floating-point error tangible.

03:36
⚖️

The Integer Solution

A clear, actionable principle that is still used in financial software today.

05:18

[00:01] 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

[00:15] 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

[00:29] 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

[00:44] 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.

[00:58] 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

[01:13] 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

[01:28] 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

[01:46] 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

[01:59] 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

[02:13] 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

[02:26] 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

[02:40] 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.

[02:55] 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

[03:07] 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

[03:22] 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

[03:36] 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.

[03:56] 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,

[04:08] 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

[04:22] 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

[04:37] of two. So, this number 101 actually means this, five in base 10. And some decimal numbers like 0.1 or 0.2

[04:49] 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,

[05:03] 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.

[05:18] 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

[05:31] 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

[05:47] 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

[05:59] doesn't, someone somewhere is getting paid. And that's the bug that almost paid. And that's the bug that almost broke money.

More from freeCodeCamp.org

View all

⚡ Saved you 0h 06m reading this? Transcribe any YouTube video for free — no signup needed.