Ask IEEE 754 to add 0.1 and 0.2 and it answers 0.30000000000000004. Every engineer has seen it; almost none have been harmed by it. The error sits seventeen digits out, the UI rounds it away, and the program moves on. Lending does not get to move on.
A loan is a promise about numbers that stays enforceable for years. The schedule tells a borrower what is due on the fifteenth of every month. The market’s cap says what the product may cost, to the basis point. An auditor recomputes a balance three years after origination and expects the same centavo. Floating point cannot carry that promise. The problem is not that its errors are large; it is that they are unaccountable. They come and go with the order of operations, the compiler, the platform. A ledger where “equal” means “within tolerance” is not a ledger.
// pesos as IEEE 754 doubles 0.10 + 0.20 = 0.30000000000000004 // pesos as integer centavos 10 + 20 = 30
Money is a count, not a measure
The engine underneath Workspace and the Engine stores every amount as an integer count of minor units. MXN 1,404.90 is not a decimal; it is 140490 centavos. Counting is what integers do perfectly: addition and subtraction are exact by construction, and there is no representation error because the representation is the quantity. The smallest unit that legally exists is the smallest unit the system can express. Nothing below it exists at all.
Rates get the same treatment. An annual rate of 68.00% is 6,800 basis points, an integer. An origination fee of 2.5% is 250 basis points. IVA at 16.00% is 1,600. A credit product’s whole definition fits in integers: amounts, rates, fees, caps, allowed term ranges. Nothing is left over for a float to approximate.
Round once, by the market’s rule
Integers keep addition honest, but a schedule needs multiplication and division: a period’s interest on a declining balance, a fee proportional to principal, tax on interest. Those operations leave integer space, and this is where most money code goes quietly wrong. It rounds at every intermediate step, in whatever direction the language defaults to, and the bias compounds across twelve installments.
The engine does the opposite. Intermediate steps run in arbitrary-precision arithmetic: no truncation, no drift. The result is rounded exactly once, at the boundary, by the market’s rule. Where to round and which way to round is not a programming preference; it is regulation. The rounding rule lives in the market’s signed rule set, next to the rate cap and the official cost formula, and every product is computed under the rules of the market it points at. A different market means different rounding. That is configuration, not a new code path.
Determinism is a test, not a promise
Exactness buys something bigger than clean centavos: reproducibility. The same inputs, under the same product version and the same market-rule version, produce the same result this year, next year, and on whatever machine the audit runs. Floats make equality a question of tolerance. Integers make it a question of fact.
We do not treat that as a design intention; we enforce it. A test suite pinned to the regulator’s own worked examples runs on every build. If a refactor moves the last centavo of a published example, the build fails. Determinism you do not test is optimism.
What it is all for
Everything downstream leans on this property. On a live book, every accrual, allocation, and penalty is appended to a calculation ledger and never mutated; a correction is a reversing entry, not an edit. Reversing entries only work when the amounts being reversed are exact. You cannot cleanly reverse a number you cannot exactly reproduce. And when a borrower, a regulator, or a court asks how a balance came to be, the answer is a replay: same version, same rules, same result, to the centavo.