5 ms·
> There really is no reason transactions need to take as long as they do other than that money disappears from one account and re-appears two days later in anot
by vanderZwan 7y ago
> There really is no reason transactions need to take as long as they do other than that money disappears from one account and re-appears two days later in another account.
Well, that and legacy systems that run batch jobs in COBOL at midnight to do the bank-to-bank transfers:
> Roughly 80% of their systems are batch jobs. These are jobs that runs at a certain time or interval, doing some processing on their data or sends data to other banks/agencies/etc. For example when I buy a can of Coke, the money is withdrawn from my account balance, however the money is not actually transferred anywhere until one of their batch jobs does so. These jobs are usually executed during the night, which is usually why it takes a day before transactions between banks are completed. Transactions to the same bank are usually instant because it executes immediately.
https://hackerfall.com/story/interviewing-my-mother-a-mainframe-cobol-programme https://hackerfall.com/story/interviewing-my-mother-a-mainfr...
Also, that interview convinced me that the busfactor of the entire Swedish economy is a handful of old Cobol programmers.
- spookthesunset 7y agoIf US banks wanted free, instant inter-bank transfers, it would exist already. Moving out of legacy systems is an engineering problem that can easily be solved with enough willpower. Don't let banks blame their legacy systems -- that is an excuse.
- hodgesrm 7y agoBank user here. Free is fine but instant inter-bank transfers are bad. That means somebody can just empty the account with limited ability for the owner/bank to intercept the transaction. I'm quite happy with the current semantics, so far as I understand them.
- raverbashing 7y agoLiability and reversibility have nothing to do with how quickly or slowly the operation happens.
- perl4ever 7y agoI've had cognitive dissonance for years, because in every basic database programming class, they tell you about transactions, and use the example of transferring money from one account to another, where you don't want the system to be in an inconsistent state. Yet nothing in the real world works like that! I've particularly noticed how money being transferred between two different financial firms can either disappear for a few days, or be in both places at once. Not sure if it's happening more or I'm noticing it more.
- manigandham 7y agoYes, banking is always mis-used as an example for transactions and ACID but in reality it's eventually consistent, often spanning hours, days, and sometimes weeks. The real-world needs to account for laws, geographies, timezones, physical movement of goods and cash, risk management, etc. that is not modeled in a simplistic database class. I do wish they would pick a different domain to avoid this confusion.
- Chyzwar 7y agoThese batch jobs are not necessary COBOL. It can be anything from modern Python, Scala, Java to more esoteric choices like Smalltalk, K and bash. I know because I worked in large investment bank writing Smalltalk for risk management. Banks need to follow regulatory regime. Batch jobs are very convenient, they usually produce flat files that can archived, easy readable by humans and can be consumed in downstream systems regardless of programming languages. My biggest beef with CSV format is multiple specification and poor tooling. Transaction can completed instantly but risk, reporting, regulatory and reconciliation would be performed later as batch job.
- vanderZwan 7y agoThanks for sharing! Given its debugging capabilities Smalltalk sounds like it could be a surprisingly sane option for banks actually, all things considered. Was it like that in real life too?
- Chyzwar 7y agoSmalltalk is amazing to work with, shame it did not get wider adoption.