> Why should transaction "cost" anything? It is just running arithmetic instruction on a number in a computer.
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.
> 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.
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.
> all of those costs are a factor of the originating individual transactions
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.
Net settlement is a useful abstraction. Instead of a fully meshed network with every bank account in the country that was active that day having to be settled against each other, you can reduce the number of nodes to “just” the 14,000 banks and credit unions in the USA. Even that is simplified by running interbank settlement through a central clearinghouse at the Federal Reserve.
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.
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.