7

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

Joshua Fox
  • 1,090
  • 10
  • 18
  • 4
    Be careful how deeply you dig into this topic, what you find may horrify you. – Eric King May 06 '20 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 06 '20 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 06 '20 at 19:16

2 Answers2

13

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.

Michael Borgwardt
  • 51,037
  • 13
  • 124
  • 176
  • 1
    It also allows for transactions to be easily changed/reversed. – JimmyJames May 06 '20 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 06 '20 at 18:53
  • @JimmyJames, transactions on a bank account are never changed once they have been applied, at least not beyond the end of a business day. They are reversed by a compensating transaction with opposite amounts - they are never just deleted from the account. – Steve May 06 '20 at 18:58
  • Michael, what about transfers between accounts, no database transaction, what happens if a debit occurs on one but doesn't credit the other? – Dan Chase May 06 '20 at 19:23
  • @Steve Sure, I'll buy that but you that would be difficult if you didn't have each original transaction. – JimmyJames May 06 '20 at 20:12
  • @JimmyJames, I didn't quite follow you; what is it you say would be difficult without the original transaction? – Steve May 06 '20 at 20:29
  • 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. – Michael Borgwardt May 06 '20 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? – David Waterworth May 06 '20 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 07 '20 at 01:20
6

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

Mike Robinson
  • 1,765
  • 4
  • 10
  • indeed, inter-bank operations are performed with a saga like approach (https://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 06 '20 at 18:09