The Evolving ACH Landscape

We’ve been tracking blockchain, distributed ledgers, etc for a number of years, and we’ve always been enthusiastic with the promise…but pointed out that it isn’t quite there yet, at least for payments. An announcement today caught our eyes:

"The Innovation Engineering team at Royal Bank of Scotland has built a Clearing and Settlement Mechanism (CSM) based on the Ethereum distributed ledger and smart contract platform."

In the Finextra article announcing it it says:

"The test results evidenced a throughput of 100 payments per second, with 6 simulated banks, and a single trip mean time of 3 seconds and maximum time of 8 seconds," states the bank. "This is the level appropriate for a national level domestic payments system."

So first the positives. That’s significantly higher throughput than any other test we’ve seen so far, by a fair margin. It’s also faster than many other systems.

But…

We’d perhaps take issue with “appropriate level” though. Not a criticism of the test or the technology, but more a reflection of the task.

100 payments per second sounds an awful lot to those not in payments. With 86,400 seconds in a day, that’s 8.4m transactions a day. UK Faster Payments in August was running at around 3.2m transactions a day. Yet of course payments don’t flow uniformly through out the day or even day by day. Anecdotally, we’ve been told that c.70% of Faster Payment transactions are sent between the last settlement of the day and the first one the next day, a window of c. 16 hours. But realistically few of those will be made at, say, 3am. The actual window is therefore closer to 8 hours or less for those 70%. That means, even if they are running evenly, it's approximately 110 transactions per second.

The system will be scalable, so it would seem feasible for Faster Payments to be replaced by what was tested. However, in fact it perhaps highlights the real issue. On an average day, it would cope. It’s planning for the unaverage day that’s the issue. The UK ACH system, BACS, highlights this well.

BACS processes on an average day roughly 15m transactions. Given the operating window for the actual processing (10pm to 4am), that’s actually c. 700 transactions a second, significantly higher that the test through-put. But systems have to be designed to cope with worst case scenarios, referred to as peak days. These occur when month ends meet quarter ends meet various other things such as Public Holidays. The BACS record peak day to date is 103.7m. That’s a staggering 4,800 transactions a second.

What do we learn from this?

The technology being tested has evolved rapidly, and is continuing to do so. The volumes now being processed are rising rapidly. Yet today the technology probably isn’t ready for a national payment system quite yet, with the exception of some smaller countries or for specific lower volume systems such as high value. Furthermore, it's important that the systems are tested from a peak day plus a comfortable amount of head room on top (nobody wants to operate at 99.99% capacity!)

But compared to as little as 18 months ago it, the conversation has shifted noticeably from could it replace to should it replace, signifying the very real possibility that it will happen in the near future. Coupled with APIs and PSD2, the payments industry could look radically different in less than a decade.