In Germany, many of the smaller banks (for example Sparkasse banks) have opted to use payments as a service via a Technical Service Provider (TSP) in order to deliver Instant Payments.  This has been driven by factors such as time to market, costs and lack of internal capabilities. However, in the longer term, this route may not be the best option to offer value added services on top of Instant Payments.  So what other options do Banks have for meeting the demand for Instant Payments today whilst still being able to meet the payments demands of tomorrow and protecting their payments business from market disruptors such as Google, Amazon and Apple?  Here I share my views on the different approaches available and the benefits and downsides of each.

Some important considerations

Before going into detail about the options available, I think it is worth highlighting the impact Instant Payments will have in Germany alone.  This is not just another IT project; Instant Payments will become the new norm in Germany. Ovum research, commissioned by Icon Solutions, recently highlighted that by 2027, around 37% of all retail payment transactions in Germany will happen over Instant Payments.

As a result, a significant volume of payments will move away from cards and SEPA batch to Instant Payments. Additionally, this shift also predicts a gradual decline of batch payments.

You can hear more about the status of Instant Payments in Germany, and learn from early adopters of the SCT Inst scheme UniCredit and Raiffeisen International in a recent InstaPay webinar here.

Balancing the short and the long term – The options

Option 1 – Technical Service Provider (TSP): As already seen in Germany, the first and to some extent the simplest option for offering Instant Payments would be to join RT1 or TIPS through a technical service provider. As the physical connectivity to the scheme will be managed by the TSP, the banks can concentrate their resources on managing the payment orchestration and real-time processing requirements of the scheme. The funding requirements can be covered through a liquidity service provider thereby further reducing the stress of payment and liquidity managers.

This is a good option in terms of achieving low cost implementation and making instant payments available to customers quickly. However, the main limitation is that this reduces the bank’s flexibility to offer new value-added features in the future.  The bank is restricted to the payments services provided by the TSP and may be limited in terms of product and service innovation and meeting future consumer demands. In the end it limits innovation and also makes it difficult to bring payments capability in-house.

Option 2 – Upgrading the existing solution: This is perhaps the first option investigated by bigger banks that have a complex payments platform or a payments hub. This involves expanding the capabilities of the bank’s existing payments engine / hub to incorporate the functionalities associated with real-time payments processing. This upgrade typically involves implementation of a new module from the existing solution vendor or bespoke development centred around the bank’s specific challenges in achieving real-time processing. Funding requirements are typically managed as part of the upgrade or can also be addressed via a liquidity service provider.

This option allows the bank to maintain payments processing capability in-house and gives control around offering new products and services. Solution vendors will be able to provide plug-and-play modules to deliver new functionalities as per the bank’s / scheme’s requirements. However, the changes require significant regression testing efforts as they usually have a direct impact on existing payment services. Importantly, most of the hub solutions available were not built for real-time processing – their primary focus was daily, batch-based payments with very different SLAs. Retrofitting the hub to deliver instant payments has the risk of compromising the hub’s stability.  It also means that customisations require significant effort and more often than not, banks might have more than one hub to process payments, that may need change as well.

Option 3 – Moving to a framework approach: This approach is based on taking a strategic view of the payment processing platform/hub in the bank. By turning the single physical payments hub into a logical hub the bank can segregate the slow and fast payments processing in to different systems. This enables a dedicated solution for processing instant payments while the existing batch payments are processed through the eco system. The new engine for instant payments must be flexible to adapt to new payments products, based on a forward-looking technology stack that meets the requirements of API economy and encourages adoption of DevOps. This setup will effectively become the new ‘logical hub’ that can address the requirements of both legacy payments process as well as modern real-time payments using a common order management layer.

This third solution option of implementing a dedicated solution for Instant Payments prevents the bank from modifying the existing payments hub by isolating instant processing from batch processing. Instant Payments need a very high degree of automation for achieving complete straight-through-processing. Failures, both business and technical, must be handled within the short SLAs and therefore allow zero manual intervention. The new solution will allow banks to offer innovative payment services without affecting the existing payment services built on batch systems. Finally, to address the challenges of API economy banks need a modern API friendly solution, instead of evolving the existing solution and continue to carry the legacy technology issues plaguing the banks. By starting afresh, banks can slowly allow adoption of open source technologies, DevOps and eventually full agile development.

The importance of the right decision

Innovation is key to banks tackling the challenges from the new market disruptors.  To do this, banks have the opportunity to choose a solution for Instant Payments which supports rapid development and rapid integration via agile development processes, is flexible enough to meet changing business requirements and has a open, future proof technology stack with enough available resources to develop and maintain the platform. Instant Payments can enable banks to sow the seeds for future payments modernisation and innovation now and it is imperative that any chosen solutions provide longer-term advantages to the business and importantly, enables banks to future-proofing their payments architecture.

In the end, these are exactly the reasons why Icon Solutions developed IPF.  Find out more about the product here or contact me to find out more.