The business case for RTP – moving past the hub

While the conversations we have had with payments business leaders point to a willingness to participate in the Clearing House’s RTP scheme, many of them are struggling with the business case to justify the costly adoption of RTP, which they expect due to the need to enhance existing systems and adopt new core payments processing functionalities.

Across the US and Canada, Icon have held multiple discussions with banks around their RTP strategies, priorities, challenges and, most importantly, solution options. Many banks are still in the RTP “education” and market scan phase and, at this point, believe that their best options are either:

1. Buy solutions from the leading payments ISVs to extend their existing payment hub infrastructure to support the new rail or to adopt a new hub as a first step in multi-rail HUB strategy.
2. Outsource processing to the 3^rd party processor – either commercial bank or one of the same leading payment ISVs mentioned above.
3. Build their own custom RTP solution.

As a result, the RTP enablement topic has been largely dominated by the hub vs. non-hub debate, which keeps the discussions centred around the generalised view that the adoption of RTP is a cost issue, especially when one considers that, although the cost-savings from reducing the use of cash and check are clear, the new products to grow top line revenue are yet to be defined.

Because of the assumed large cost of implementing RTP, many banks have adopted a strategy of addressing RTP requirements within the context of an existing larger, well-funded and already cost-justified HUB program. This makes the RTP project easier to justify as part of the already approved comprehensive initiative.

Meanwhile, other FIs cannot see business justification for additional major spend to accommodate RTP processing. They do not want to adopt a full payments hub to supplement/compliment their Payments and Core systems (DDA, AML, OFAC, etc) that are unavailable around the clock. Instead, they look to either option 2 (outsourcing to 3^rd party service providers) or option 3 (custom development). What results is a hybrid near-RTP/Batch processing design. Additionally, when there is a significant custom development component (possible/probable under both option 2 and option 3), costs can easily spiral out of control and even exceed those of a “small” payments hub.

There is another way

Let’s step back a minute and imagine what this conversation would look like if it weren’t limited to a cost driven hub vs non-hub debate. Because there is a third option. Doesn’t it make more sense for banks to consider a solution designed solely for RTP that seamlessly fits into the surrounding legacy environment, cutting through the huge cost implications of implementing RTP, and making the business case a much easier sell.

Understanding and repeatedly helping to solve client pain points from the implementation of over complicated (expensive to install and to run) hub solutions, lead Icon to create a dedicated purpose-built solution that is aligned with the streamlined and agile nature of RTP. We codified our years of global payments experience into IPF, a solution designed to do one thing – expedite instant payments – expertly well in terms of speed of implementation, cost-effectiveness and sustainability.

IPF is a lightweight solution which is cloud native (although also available on premises) and which provides TCH, as well as other RTP scheme packs, certified compliant out of the box – saving valuable time, budget and unnecessary configuration headaches.

IPF’s technology layer is dedicated to serving all RTP integration plus the orchestration of inbound and outbound RTP flows – throughout any bank’s existing payments and core processing environment.

Flows can be reused for new RTP schemes as an accelerator for future development and the core IPF engine is architected for scalability, throughput and redundancy.

So, now, because of the comparatively low cost of IPF, it presents a more cost justified approach available to banks implementing RTP.

Banks really have 3 options as described above. The business case need not be dominated by the cost. And, crucially, implementing RTP doesn’t mean undertaking an extensive change in existing infrastructure or giving up control and initiative to the correspondent.

Instead, banks can choose a solution that has been designed specifically for RTP and fits easily within existing systems to provide a quick time to market, low cost of entry and superior long-term economics. By taking away the considerations of cost and timeline, Icon frees banks to bring the benefits of RTP to their customers.

This blog is part of series exploring the key considerations for banks planning to implement RTP. Our next post will look more closely at the architectural needs of RTP.

Don’t miss a thing! To receive future blogs and insight updates from Icon Solutions, simply register your details below:

You can unsubscribe at any point by clicking the link in our emails. Read our Privacy Policy.