This article was originally posted on the equensWorldline blog. The original can be found here: https://equensworldline.com/en/home/blog/2017/August-17/20170831-the-challenges-of-processing-instant-payments.html
Low latency, 24/7 availability, connectivity and scalability. When it comes to processing Instant Payments, these are the four main challenges for banks and processors. This new and faster way to make payments has a lot of market potential, but the underlying infrastructures and processes need to be upgraded to facilitate the Instant Payments. I wrote an article for the German magazine IT Finanzmagazin to explain the technical aspects of processing Instant Payments. What are the technical challenges that come with the processing of Instant Payments and what are the potential solutions?
As written before on this blog by the equensWorldline CEO Michael Steinbach, the implementation of Instant Payments will have a bigger impact than the introduction of the euro or even SEPA. Let us take a deeper look into four of the non-functional requirements of Instant Payments.
Low latency
Instant Payments need to be instant. The current specifications from the EPC SCT Inst scheme rulebook list a 10 second target, while several communities (most notably The Netherlands and Belgium) aim for an even faster 5 second roundtrip. Because this is an end-to-end target, the allotted time is divided between the participants, the clearing house and the network, meaning each party should aim for sub-second processing. For a typical participant, this includes validating the payment message from the customer, checking the account balance, debiting the account in the ledger, checking for reach and availability of the beneficiary bank, fraud checking, sending out the message to the clearing house and correlating the return message.
Sub-second processing times can only be met if participants make sure the process is optimized for processing single messages instead of files and batches. They need to make use of parallel processing steps (validating the message and checking the reach and availability can be done in parallel to the fraud check for instance) and most importantly, they need to optimize the database I/O as this typically is the biggest bottleneck. This can be done with various methods; by loading static tables in memory, by optimizing indexes or even switching to different database technology, such as MongoDB or Cassandra.
24/7 availability
Instant Payments not only need to be instant, they need to be available. This requirement may have the biggest impact from a technical and operational perspective. And although running high available systems is not complex from a technical viewpoint (we have been running 24/7 available payment processing systems in cards for decades), it does come with its own challenges. The high availability requirements can only be met by running an active-active setup, where two datacenters are processing in parallel and one datacenter can process the full load when another datacenter goes down and there are no delays in switching traffic from one datacenter to the next.
This setup can be made even more robust by running multiple nodes per datacenter. The location of the datacenters need to be placed sufficiently apart in order to have different risk profiles (i.e. a grid power outage in one datacenter does not affect the second site), but close enough to maintain a low latency. The multiple datacenter setup can also be used to do upgrades and maintenance without downtime.
Connectivity
This brings us to connectivity, as both the requirements of (guaranteed) low latency and high availability apply here. Banks need to connect their payments processing to their Clearing and Settlement Mechanism (CSM) using a network that is available and fast enough and banks have several options here. The current “go-to” network for financial messaging, SWIFT, will offer a full managed network with the required latency and availability figures necessary for Instant Payments. Alternatively, to SWIFT, banks can also opt for solutions from SIANet and EBICS, where the latter is a self-managed network.
Banks can also choose to manage the network fully independent of the major suppliers and connect directly into their CSM of choice, using a dedicated physical connection through a leased line. As availability remains key, using a dual leased line strategy from two different vendors or using a backup via an MPLS connection is advisable.
Scalability
Looking at implementations in the UK (growth from 20 million transactions per month half year after launch to 100 million transactions per month 6 years later), Sweden (Swish on boarded 5 million users in 3 years) and Denmark (28 transactions per capita in 2 years with 4% monthly growth), any Instant Payments system needs to be scalable from the start. It is critical that the Instant Payments processing is designed to be scalable (up and out) without impacting the latency of the service, for instance by using components designed with parallelism and asynchronism in mind.
By using a load balancer/dispatcher model, horizontal scalability can be obtained, which is crucial in order to keep the TCO under control, as costs rise exponentially when scaling vertically, while costs rise linearly when scaling horizontally. Additionally, methods such as caching, asynchronous processing and striving for statelessness are crucial in obtaining cost efficient performance and scalability.
These four challenges need to be addresses before Instant Payments will become a reality. The processing of Instant Payments may come with technical challenges and as account based payments processing traditionally has been batch based, the resulting impact may be significant. However, the solutions are available and have been tried and tested in other applications already. Card based payments have dealt with 24/7 availability for decades already, and companies such as Facebook, Google and Amazon have paved the way in scalability. It is now up to payments to follow suit.