This week, I read an interesting paper from Newgen Software about the application of “low-code thinking” to their business process automation domain. The paper highlighted the critical need for speed in a modern enterprise in order to respond to strategic and competitive threats. It suggests that the speed with which an organisation gets from a strategic decision to execution determines competitive advantage.  It’s hard to disagree with this assertion.

The key question is how to convert the specialist knowledge of an organisation’s domain experts into operating services for customers as quickly as possible.  Traditional development approaches, even those utilising agile methods in a DevOps model, still encounter an IT bottleneck.  Organisations need to do more, faster and with less risk – the only solution is to shift from coding to delivering using low-code techniques. 

I think that this conundrum also impacts the payments domain.  Many new products and services introduce a requirement for a payment.  An organisation does not want to build new payments support for every new service. Instead they need to be able to rapidly extend their existing payments infrastructure to support the new business service.

Most of today’s existing payments infrastructures in what we could describe as the “cards payments domain” are characterised by coding-intensive, monolithic architectures.  These are slow and risky to change and rarely lend themselves to easy extensibility.

In its recent paper “The Benefits Of Moving To Open APIs”, Finastra addressed this problem for the bank-to-bank payments domain.  They highlighted that most new services require the collaboration between multiple systems that can’t be tightly integrated – at least not without long, expensive and risky change projects.

This same quandary exists for organisations that want to add new value-added services into their retail payments and self-service channels.  How to integrate those new service platforms into the payment processing chain without complex changes to the existing payment switch infrastructure?  My view is that the answer is similar to the Finastra approach to corporate payments – opening up services in the payment infrastructure using APIs published to the value-added services platforms.

Of course, opening up payments switches to non-traditional transaction sources and value-added services through APIs, along with delivering strategic speed through low-code techniques, requires a flexible and modern IT architecture for the payments engine.