Pretty much all banks use mainframes to do batch processing. "SFTP runs the world".
I got heavy into fintech a couple years ago, and at first I thought "This is all insane." I was coming from a SaaS world where it's easy to think about transactional guarantees with API calls.
I finally "got it" when I realized that pretty much all of our financial system in the US is based on the digitization of manual processes from the 50s and 60s. If you think of how banks worked before computers (e.g. large binders of ledgers that were manually reconciled), that's basically how it still works today, those big binders have just been turned into digital files that are processed by machines.
I'm no fan of crypto, but the one place where I can see real utility for blockchain is as a backend settlement service for banks.
So... what does the crypto provide there that a simple authenticated communication protocol with a few redundant centralized servers doesn't?
Seriously? You would trust billions of dollars to this?
https://web3isgoinggreat.com/?theme=hack
To be clear, the cryptographic underpinnings of blockchain seem solid, it's just that both implementations and actual usage are by fallible humans. And because everything is irreversible, even if you manage to guard against hackers, you still can straight up incinerate money by (say) mistyping a receiving account number (wallet).
This isn't an anachronism. Batched net settlement is inherently cheaper than real-time gross settlement.
Canonical example: if I send you $10, then you send me $5 and I send you $2, in net settlement, there is a single $7 transaction; with RTGS there are three transactions of $17. The first system not only has lower transaction costs, it also scales better on account of needing less capital. TL; DR If there is a real-time settlement system, it is always possible to build a net settlement system on top of it that's cheaper (albeit slower).
Every dollar that crosses a payments platform has a non-zero chance of creating some combination of legal, regulatory and customer-service costs. Frictionless transactions are as real world as their physics counterpart.
> would argue batch processing makes no sense
It does, from a deeply fundamental level. The only case where RTGS is equal to net settlement is if we make some Econ 101 assumptions (frictionless transactions, infinite borrowing and lending capacity) together with zero or negative rates. (Even then, one could be a stickler about the cost of computation.)
> you might have already been bankrupt
Clearinghouses.
My point isn't that net settlement or RTGS are inherently better. They're not. But they're fundamentally tied, and net settlement on top of an RTGS rail will always be cheaper in the real world than that same underlying rail. On the cost side, net settlement will win. On immediacy and counterparty risk, RTGS. A strong system offers both options.
Yes, but pretty much all of those costs are a factor of the originating individual transactions. In reality net settlement is just one additional transaction where things can go wrong.
Again, I'm no fan of crypto (WRT how it's currently used, scams, etc), but there is no reason a permissioned blockchain couldn't do millions of transactions a second, all with real-time settlement, at a cost lower than batch processing.
As long as operating a connection between two accounts has a non-zero cost and resolving consistency problems has a non-zero cost net settlement will be cheaper and easier.
Correct, to a degree. Hub-and-spoke systems (clearinghouse, with banks at the periphery) are cheaper and more efficient than an everything-connected topology. The clearinghouse can run cheap rails because it knows it has pushed those problems to the periphery. The main missing factor, however, is float.
Float makes RTGS more expensive than batched settlement. If you give me RTGS rails, I can batch on top of it and recycle the yield on float into savings, possibly rebates (or credit, e.g. how banks front credit against deposited cheques).
The batch mechanism will always be cheaper under real-world conditions. That's what I want to emphasize. This isn't an artefact. It's fundamentally inescapable.
The bank where you deposited a check would in fact be lending you the amount of the check until the settlement was complete - hence the daily deposit limits and such to limit the bank's exposure.
The Eurozone has been working on SEPA Instant Credit Transfer for a few years now. It allows transferring of money within 10 seconds, even to a different bank in a different country. The maximum time is 20 seconds in exceptional circumstances. How would this work with batch processing?
You want to have 100% uptime for authorize, but correctness isn't strictly required; if you allow too much in charges, you'll probably end up collecting user fees, which is not a negative for the bank. On the other hand, you want exactly once processing for capture, and you don't really need that to have 100% uptime, since the financial industry is built around batch processing.