Faster...or fast enough?

My last post mentioned that I was on a panel at International Payments Summit talking about real time payments. The topic is one that has cropped up many times recently in analyst inquiry calls in the last few months. With all the activity in the market, such as the decision in Australia to implement such a system, it’s perhaps not that surprising. What is surprising though is the number of myths and misunderstandings surrounding the topic. I thought it worth highlighting - and straightening - just a few here. #1. Real time isn’t always really real-time The most frequent myth is that everything end-to-end is suddenly instant. In reality, most (though not all) real-time systems are real-time in notification and authorisation, not settlement. In fact, in some systems in certain situations, settlement can take place days later. The starting point should be what needs to happen, and at what speed. In deed, for many payments, its the certainty, not the speed that matters. #2 Real time isn’t p2p One belief is that there is a pent-up demand for real time to enable p2p (or perhaps, more accurately, a2a) transactions. The use case is often quoted to be that of splitting a dinner check – one person pays the restaurant, the rest then have to find a way to pay the payer. But in reality, how often does that happen? The default in the UK at least would be tell the restaurant how to split the check across multiple cards. Even if that weren’t the case, the numbers of times that this happens would not be large enough to justify the investment on its own. The starting point should be use case driven though: who would benefit from sending – or receiving – funds faster than the current method. In most systems so far, these have been typically b2c or c2b, or indeed, mandated so the business case isn't the issue. #3. Real time isn’t just payments In many instances around the world, real-time systems are often running 24/7. That poses, at the very least, 2 problems. Firstly, what other systems are required to run in real time, 24/7? Fraud checking, authorisation, notification and authentication systems are amongst the obvious, but banks have found dependencies on many others, and not just in the sending side. Secondly, maintaining systems becomes far more complicated if they have to always be available, and being “always on” means that maintenance becomes more important than ever.