For example, my bank lets me go negative and then if I don't settle by the end of the day, overdraft protection will kick in for a little more than that negative amount.
I don’t claim to be a banking expert, but I did work at a payment processor that handled real money, and we used “select for update” extensively.
We also (obviously) used a ledger, but “just let everyone overdraft whenever” wasn’t something that the executives of the company thought was a good idea. So we did try and prevent insufficient funds errors as much as possible.
I personally witnessed several scenarios where the company lost a notable amount of money, (not only rated to concurrency bugs of course) and it’s a pretty bad feeling.
Anyway, I’m legitimately curious to know from people who worked at larger banks perhaps. How is weak transaction isolation not a problem for banks?
My point is that these examples are bad ones because they don't match the real world, which is messy and complex and inconsistent.
There are many ways of solving the consistency problem, but understanding what consistency and serializability is means that you'll be better educated in coming up with solutions.
Also, I believe that all else being equal, you would want serializability. It simplifies everything. There's a new [financial database under development named TigerBeetle](https://docs.tigerbeetle.com/design/consistency). They chose to implement strict serializability by default because:
> Strict consistency guarantees (at the database level) simplify 1) application logic and 2) error handling farther up the stack.
So the banks of today may have to deal with inconsistency, but that doesn't mean the banks of tomorrow want to.