The main reason it hasn't moved out of the 1960s is it works pretty damn well. It's a bit slow, but money goes where it needs to go, and there's a good audit trail to trace in cases of fraud.
It's crazy slow. Most ACH moves through a modern stack and then into COBOL that runs nightly batch jobs that then update the stuff in the modern stack and in on its way. Nevertheless, it takes the nightly batch job.
Honestly though, they processed 22 billion payments totaling 38.7 trillion dollars in 2013.[0] When you're dealing with numbers like that, there's an argument to made in favor of battle-hardened COBOL batch processing over some real-time rewrite.
One of my banks, every night between the hours of 12 am and 6 am America/Chicago (local), notes that they are processing the day's transactions or something, and my balance might not be correct. I presume they're handling ACH transfers during that time.
That said, during that time, my balance has read any of the previous day's balance, the next day's balance after processing all pending transactions, $0.00 (this one is particularly worrisome), and amounts that cannot be obtained by adding any combination or subset of the day's pending transactions. And that's not mentioning that the uptime for this is effectively 75%, assuming nothing is going wrong.
It could be faster. I could enjoy not having to worry that I might lose vast quantities of money because somebody got the number that I both must keep secret and give to everyone I do business with. I could wish for bank websites that understood how SSL works.
Yes, for what it does, perhaps it "works pretty damn well". But the requirements have changed since 1960.
