Are traditional hubs a good fit for instant payments?

Any mention of payments and multiple schemes, and the gurus are quick to respond with an “industry leader payments hub” as your go-to solution. These hubs are ‘centralized payments platforms’ which provide a unified view of payments activity and business. What they fail to mention is that these systems were built for handling bulk payments that are processed in batches wherein settlement is almost never in real-time. That’s a far cry from the needs of instant payment schemes planned in Europe (SEPA Instant Payments and Hungary Instant Payments) and the US (TCH Real-Time Payments).

As a sizeable number of European banks now have payments hubs (and the hub is where all payments must reside) the focus is skewed in the favour of expanding the services of the ‘existing’ hub to handle immediate payments as well. These hubs are, without a doubt, great in managing the current requirements i.e. bulking, de-bulking, warehousing, repair, re-route, retry, etc. They were in fact specifically designed to support these older functionalities.

A different world

However, with instant payments, the traditional requirements do not have the same relevance. Instant payments are, by nature, 100% straight-through-processed with absolutely no room for manual intervention. Hence, alternative payment paths and technical failures must be dealt in an automated fashion in real time and with full certainty. This fundamentally removes the need for a lot of technical overheads that come pre-packaged with the traditional hubs, and leaves room for automated recovery processes. Any change to the current architecture will not only be complex and costly but also removes the uniformity that payments hubs so ferociously advertise.

Now, do we really want to change the designs of payments hubs with every additional payments scheme even though the nature, priority and availability of these schemes do not match with each other? While traditional payments schemes only work for certain parts of the day, new schemes work 24×7. The end-of-day batch jobs are not required due to near-real availability of reconciliation information. Even the back-end systems – Accounting, Sanctions, AML, etc. – need a change in behaviour to support 24×7 payment processing.

Plug and play

What banks really need is a pluggable framework designed specifically to handle instant payments. Such a framework must club with the existing hub, allow banks to orchestrate separate flows created specifically for instant payments i.e. without affecting the existing payment flows. By definition, the framework would be light-weight, scalable and extensible to support addition of new instant payments schemes without disturbing the core engine. Payments data can be exposed via a list of RESTful APIs thus reusing the bank’s existing payments dashboards and maintaining a seamless user experience. Architecturally, the end state of such a design would look like a mini-hub (just for instant payments) within the traditional payments hub.

Finally, to speed-up the solution implementation and participation in these instant payment schemes, banks must focus on reducing ‘customization with cost’ i.e. a solution which does not require resource hungry bespoke development and an architecture flexible enough to respond to emerging customer, business and regulatory demands. This must be the primary driver to move away from massive, resource & customization hungry hubs to a lean and scalable instant payments framework.

First published on Bobsguide