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

  • 4
    Be careful how deeply you dig into this topic, what you find may horrify you.
    – Eric King
    May 6, 2020 at 14:44
  • Yet amazingly, bank errors are very unusual. I check my records carefully, and I have not found an error in a long time. I wonder why.
    – Joshua Fox
    May 6, 2020 at 14:46
  • Eventual consistency is one of the most feared concepts in banking. For a simple intra-bank transfer in the modern era, all operations which it potentially entails may not be a single database transaction, but the journal entry will definitely be guaranteed to be atomic and transactionally consistent. The system is never out of balance or subject to "inconsistencies" (those only occur between accounting systems, and that's where you have so-called clearing procedures and suchlike).
    – Steve
    May 6, 2020 at 19:16

2 Answers 2


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.

  • 1
    It also allows for transactions to be easily changed/reversed.
    – JimmyJames
    May 6, 2020 at 14:57
  • This doesn't accord with reality at all. Journal entries are not limited to two accounts - you can have one-to-many, and many-to-many entries. There is no "from" and "to" account - only credit lines and debit lines, which must balance for any entry. Database transactions are very much employed.
    – Steve
    May 6, 2020 at 18:53
  • 4
    @DanChase: that is exactly the thing that cannot happen with double-entry bookeeping, because the transaction is represented by a single record that contains debit and credit. May 6, 2020 at 21:40
  • 1
    How does this work for inter-bank transfers? I can see how a journal would allow one to maintain a consist ledger for intra-bank transfers as there's a single journal but not between banks? May 6, 2020 at 23:58
  • 1
    @DavidWaterworth, for interbank transfers which involve journal entries in more than one accounting system, there are clearing systems and suspense accounts (the exact details and timings of which differ for different schemes). In essence, the paying bank notifies the receiving bank of the intention to transfer, the receiving bank acknowledges, and if all is well then they each then make the necessary entries. In practice, the banks all hold accounts with each other, and those accounts form the counterparty accounts for the transfers within each system (so at least 4 accounts are involved).
    – Steve
    May 7, 2020 at 1:20

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

  • indeed, inter-bank operations are performed with a saga like approach (microservices.io/patterns/data/saga.html ) where some operations are rolled back if they cannot be completed (e.g. bank account unknown at the destination bank)
    – Christophe
    May 6, 2020 at 18:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.