Instant Payments and the Reactive Manifesto

Over the last year, we’ve been talking with many banks and payment service providers about the challenges of instant payments.  The most progressive organisations are looking to instant payments as an opportunity to embrace open-source frameworks as an alternative to traditional vendor technology solutions.  As a large organisation put it to me recently, “unless we are using the same technology as the fintech’s and the GAFA’s how are we going to compete or stay current?” There are a number of challenges that banks and payment service providers face in delivering instant payments that make it a great use case for open-source frameworks, in particular Akka and its embodiment of the reactive manifesto.  This post looks at some of the challenges of instant payments, why the concepts embodied in the reactive manifesto are suited to solving these challenges and what this means for the client/vendor conversation. Instant Payments As the world continues to become more and more real-time, customers and regulators expect instant payments around the clock, no exceptions. The challenges include:

• Flexibility: Competition and regulation mean the ways in which payments services are offered and consumed are changing all the time. This means payments flows need to be deployed independently – allowing the bank to explore new service offerings, service improvements and to join new payment schemes without having to force user visible changes or risk a full outage. Solutions need to enable the client organisation to easily make change using skill sets that are widely available, not rely on the vendor for development or require skills that are difficult and expensive to hire

• Roundtrip time: Instant Payments need to guarantee a timely response to the payment scheme for every payment and this requires that tight control is maintained over how long a payment spends being processed by each of the bank’s supporting systems (such as sanctions checking or the accounting platform). Many legacy payment systems struggle here – they were designed in a world of bulk/batch payments and are not easily bent to the task of ensuring timely delivery, every time.

• Uptime: Be it for scheduled maintenance or an unexpected outage, most IT systems have downtime. Instant payment requires 100% resilience to failure and to allow individual nodes to be upgraded or maintained without any impact to live service.  Solutions therefore need to be distributed, elastic and resilient.

• Scale: Instant payments will become the new normal.  New use cases will create new payment transactions, including taking volumes from the existing card scheme infrastructures, and solutions need to be able to scale to meet this as-yet uncertain demand. To achieve scale, solutions need to be designed for concurrency, and do this in a manner that is simple, keeping support and maintenance costs lower than traditional multi-threaded solutions.

The Reactive Manifesto These challenges lend themselves well to the reactive manifesto.  The reactive manifesto is focused around four areas:

• Responsive: The system responds in a timely manner if at all possible. Problems may be detected quickly and dealt with effectively.
• Resilient: The system stays responsive in the face of failure. Resilience is achieved by replication, containment, isolation and delegation. Failures are contained within each component.
• Message Driven: Reactive Systems rely on asynchronous message-passing. Location transparency makes it possible to work within a single host or across a cluster.
• Elastic: The system stays responsive under varying workload. Reacts to changes in the input rate by increasing or decreasing the resources allocated to service these inputs.

Akka, an open-source toolkit, embodies the reactive manifesto.  Importantly, for applications such as instant payments, Akka simplifies the construction of highly concurrent and distributed applications on the JVM (Java Virtual Machine).  It emphasises a technique called actor-based concurrency, developing on earlier toolkits such as Erlang but avoiding many of the problems, such as niche skills requirement and the lack of a vibrant community providing “battle hardened” open source libraries and tools. Each payment is independently taken through the defined payment flow by a dedicated actor (lightweight “process”) whose job it is to orchestrate the processing required and ensure the scheme SLA is met. If there is a risk that a deadline will be missed due to a slow running external system, the actor is ready to step in. The actor also handles any business exceptions such as closed account or sanctions hit. Akka provides many of the core non-functional requirements for payments processing “out of the box”.  By comparison, many traditional payments products handle these mission critical challenges, such as concurrency and resilience, using their own proprietary applications.  This restricts the support base and expertise to that of the single product, making it more expensive to support and maintain for customers and vendors alike.  Over time an increasing proportion of vendor R&D spend is used on simply maintaining the proprietary technology rather than enhancing business functionality and enabling new product development.  This limits organisations in exploring the capabilities opened up by instant payments as maintenance dollars are spent on functionality that’s freely available in open-source frameworks. Changing the client conversation Fundamentally, incorporating open-source frameworks within the payments systems, also changes the client conversation.  Discussions are much more open, focussing on resolving challenges through the most appropriate toolset, within flexible commercial models.  This is in marked contrast to the traditional hard selling of a proprietary technology stack. Collaboration pays a much greater role in this world as does intellectual curiosity about building solutions.  In the market many organisations have already adopted Akka for processing at scale, for example PayPal.  At Icon we’d love to hear from organisations using Akka in financial services and share experiences. Written by Richard Dear For more information click here.