Think like a bank

When you send a friend 50 euros from your phone, the money doesn’t travel anywhere. What happens is that some records change in two banks and, later on, someone checks that both sides match. It happens millions of times a day, and it almost never goes wrong.

What does that have to do with a booking app or an online shop? More than it seems. Banking has spent centuries solving problems that every digital product runs into sooner or later. Here are five of its habits.

Numbers don’t float

Open a Python console and type 0.1 + 0.1 + 0.1 == 0.3. The answer is False. It isn’t a bug in the language: computers store decimals in binary, and 0.1 has no exact binary representation, just as 1/3 has no exact decimal one. The difference is tiny, but it’s there.

On a calculator it doesn’t matter. When you add up thousands of amounts, those differences pile up, and one day the total no longer matches the sum of its parts. That’s why banks never store money as floating point: they use whole cents (€19.99 is stored as 1999) or exact decimal types.

If your product handles prices, this applies to you too.

Nothing gets erased

In 1494, the friar Luca Pacioli published in Venice one of the first descriptions of double-entry bookkeeping, the method the city’s merchants were already using. Its golden rule still holds: every movement is recorded twice, as a debit in one account and a credit in another, and mistakes are never crossed out. They are corrected with an opposite entry.

The result is a complete history: you can rebuild what happened, when and why. In software, the same idea is called an append-only log. Instead of overwriting a customer’s balance, you store every movement and calculate the balance from them. When something goes wrong, you have the whole story to understand it.

One caveat: a history of movements isn’t a history of people. Keep everything that happened to the money, and only the personal data you genuinely need.

Balancing every night

Banks don’t trust that everything went well: they check. Every day they compare their records with those of card networks, other banks and payment processors. It’s called reconciliation, and any difference, however small, gets investigated.

A digital product can do the same with little effort. Your app saying “paid” doesn’t mean the money arrived. A nightly job that compares your orders with what the payment provider reports catches the double charge, the refund that never happened or the order shipped without payment, while there’s still time to fix them.

Four eyes

Many banks apply the two-person rule: to open a vault, each employee knows only part of the combination, and some cheques need two signatures. In day-to-day operations it’s known as the four-eyes principle: whoever prepares something sensitive isn’t the one who approves it.

It isn’t about distrust. It’s about accepting that anyone can make a mistake. In software its most common form is code review, and it makes sense to take it further: to permission changes, bulk deletions or production deployments.

Fraud starts small

Someone who steals card details rarely opens with a big purchase. First they test the card with charges of a few cents that the owner is unlikely to notice. It’s called card testing, and it’s often done with scripts that try hundreds of cards on any payment form they find open.

The lesson is that a product isn’t only used by its customers. Limiting attempts per person, watching for spikes in declined payments or asking for extra verification only when something looks off, without burdening everyone else, are simple measures, and you’ll be glad of them the day someone knocks on the wrong door.

If something went wrong tonight

You don’t need to be a bank to think like one. Storing money in cents, keeping the history of movements, checking instead of assuming, asking for a second pair of eyes and thinking about whoever wants to abuse the system are cheap habits. What they prevent, on the other hand, tends to be expensive.

Next time your app moves money, or simply data that matters, ask yourself a very banking question: if something went wrong tonight, how would I find out tomorrow?