Transactions in bank accounts are actually not realized through DB transactions. It's easily visible if you ever had a failing payment: the amount gets subtracted but added again right away after that. They have pretty strong auditing requirements.
Not the OP but I think it's essentially a event driven system as opposed to real time.
Think of a account with $0 in it.
1. A -$25 event comes in
2. A +$50 event comes in
3. A -$25 event comes in
The first event would fail in a transactional/real time system, but in my bank it doesn't. This tells me the balance is only calculated every once in a while. The balance you get in a app is only a estimate.
This makes sense when you think how slow bank transfers and using paper checks is. At some point it is decided to run the events "for real" and that's where overdrafts and the like are applied.
Don't think of them as transactions, instead it's a transaction request that can be rejected.
Related to this — Wells Fargo was sued[1] (and lost) around 2010 for the practice of ordering daily transaction to (indirectly) maximize fees and penalties.
In your example, a “good” bank would order the transactions: +$50, -$25, -$25 resulting in a zero balance with no penalties. What Wells Fargo did could result in the transactions being ordered as: -$25 (overdraft), -$25 (overdraft), +$50.
Each overdraft could charge a fee up to $35, leaving the account holder with a -$70 balance.
It depends on the country and currency but there is the SWIFT system, which works like messaging. There is also the SIC and EuroSIC. For SWIFT system as a bank you have an account on the other bank and sends an instruction to decrease your amount and book it to a receiver. If there are more than one bank between them it gets routed but always "own decrease and other bank increase". Only the receiver bank books to the client. This system works because every bank has an account on other banks and you can build up some paths.
Sure, it just means that the processing is done in a batch job at the end of the day. However, it doesn't mean that the batch jobs don't use a database. There's probably something like db2 on the mainframe, possibly even COBOL or RPG
Working in the fintech has opened my eyes to how many shortcomings there really are in banking/ACH. What you describe above is both my nightmare, and my reality. Pipe-delimited flat files being SFTPed via cronjobs overnight. Getting the emails at 5am that balances are off/not reconciled because somehow an errant '|' got into the mix.
Additionally, the number of folks that ask for spreadsheets (not encrypted) with your SSN... and then proceed to email that data around (sometimes via Gmail!)
I could be wrong but I think the following scenario is worth considering. Let's say a client wants to transact money from bank A to bank B. The following steps are taken:
1. Client initiates the transfer request.
2. Bank A decreases the client's balance.
3. Bank A sends the request to transfer money to bank B.
Now, I guess you would expect that steps 2 and 3 should form part of a DB transaction. This however does not really work because it is unclear what conclusion we should draw from step 3 failing. On one hand, it is possible that the request failed on its way to bank B, in which case step 2 should not be applied. On the other hand, it is possible that the request successfully reached bank B but the response got lost on its way back. In this case step 2 should be applied.
Therefore, not treating steps 2 and 3 as a single transaction makes sense if you want to take a conservative approach that does not allow for accidental transfer of infinite amounts of money to bank B in scenarios when the response fails to come back from an otherwise successful transfer.
We have exactly the same problem at work. One possible way to solve it is by ensuring that the receiving system treats the request as idempotent. One could also poll first at the receiver whether the transaction exists, and then send it if it doesn't. But both measures require that there is a way to uniquely identify a request. Also, idempotency can be annoying to implement correctly. Thus, implementors might try to wiggle their way out of it, technically or politically.
This is the only comment worth a thing here. Unless mongodb causes irrevocable data loss, eventual consistency is easily mitigated using an accounting service. I have seen one of them at work. Transaction amount comes in, it is compared with initial value and the session is kept open until the quantity is fulfilled. If there is a timeout, secondary systems try to recover or alert. Recovery can even deduct overfills or complete fills.
This seems ridiculously complicated and unnecessary for something that should be as easy as having a proper RDMS that is ACID compliant. I guess now we have one additional reason why banking has stagnated for so long.
Just in case you (or someone else) don't know why you are being downvoted, I'll give you a few reasons:
- Banks have to put these double-checking and reporting systems in place because the law mandates them to. No amount of ACID compliance in your database is freeing you from that.
- These requirements are not stupid either: assuming you had a perfect system with perfect ACID compliance and 0 bugs ever (which we all know is impossible), a random hardware failure (or cosmic ray) can flip a bit somewhere and you are screwed.
- Your comment reads as extremely condescending, which is never good to get your point across.
- Not only that, but you dismissed the work of some of the best people money can buy in two sentences with 0 rationale. Next time you think you know better than an entire extremely well funded industry, think again, and again, and again. If you are still convinced you know better, please open shop because if you are right you'll not just make yourself the next self-made billionaire, but also probably improve our lives in the process.
This comment gives me hope that there are at least some decent people on Hacker News.
Every time I read an article here I am put off from participating further because the comments are usually filled with toxic spew from peacock fan boys Who think they know better.
It is complicated, but necessary. You will get to the ridiculous part once you realize that executing brokers don't care about your acid guarantees or whatever.
