Are bank transactions run with DB transactions?

Question

The classic example for a transaction is withdrawing money from a savings account and depositing it to a checking account in the same bank.

Yet I have the suspicion that DB transactions are actually not used for such examples, but rather that eventual consistency is achieved with a a journaling system that reconciles inconsistencies at the end of the day. I imagine that transactions are used for a single update (withdrawal/deposit).

What is the best practice? I realize that here is no single answer, but I wonder what is commonly done.

(This asks the same question, but about distributed systems. I am asking what is done within a single bank.)

Answer 1

Bank transactions are based on Double-entry bookkeeping.

That means that account balances are derived, not stored or manipulated directly.

Basically, every transaction is stored as a record saying "X dollars were moved from account A to account B", plus some additional fields. An account's balance is computed by adding up all its out- and inflows.

So transactions are indeed not necessary at this level, at least not for atomicity (the most commonly discussed feature of transactions). You still need mechanisms to ensure durability and prevent duplication.

The advantages of this system is that it not only prevents inconsistencies, like money getting "lost", it also ensures that you can always tell where all the money in a given account came from. That makes hiding embezzlement and fraud much harder.

Answer 2

"The real world of multi-business financial transaction processing" is always that there are many entirely-disconnected systems in place. "SQL transactions" therefore can never cover this.