Earlier quoted context omitted.
>It enables faster transactions and reactions to the transaction states than regular currency. This is only true in the US, where the inter-bank financial system runs on mainframes and 40 year old code. The British banking system decided a while ago that they were going to update their bank communication system, and now they can send sums between bank accounts at different banks within 10 seconds.
10 seconds is still an two orders of magnitude too slow given many use cases and the technology which is currently available. I should be able to tap my card on a subway turnstile and have it open immediately such that the subway faces zero fraud risk. A centralized system should be limited only by RTT and there are ways to overcome even that via caching layers or cryptographic techniques. You want something sub 250m…
'Zero fraud risk': you cannot prevent people from finding loopholes. Every system breaks. Instead, you use the same techniques that have been used for centuries in finance: keep audit logs, make it possible to fix things later, and maybe try to catch the majority of possible attacks by adding more rules.
If you're processing tens of millions of transactions a second, you do not have a single point of truth. You have at least a cluster, ie. a distributed system. Fortunately finance grew up before automatic computing and telecoms even existed, so its algorithms and systems run just fine (FSpecificVO) at less than 1 FLOP/S with communication latencies measured in weeks.
So you might as well just collect transactions locally, then sort them out as a batch job in the evening, with a percent or two price hike to cover liabilities due to fraud.
Last time I went anywhere near London, they had the instant payment system working down there in the Tube.
It's not centralised and none of the important stuff is necessarily low-latency, but it seems to work fine anyway.