Payment Modernization - an Engineering hurdle to overcome

Payment is no longer a protected territory of few large financial institutions (FI) and intermediaries. An evolving eco-system with technology players in the mix, and their rapid innovation, are continuously disrupting ways of making payments, ease of accepting cashless payments and the experience around it.

Regulatory moves from financial bodies are increasingly lowering entry barriers for Fintechs – be it democratization of customer data thru PSD2 directive in the UK or UPI (Unified Payment interface) based Payments in India. A regulation in the like of PSD2 shifts the control of customer data from FI to customer herself, and, necessitates building a new market place of API based Open Banking system; legacy players are not left with choices but to be part of the eco-system to stay relevant. UPI platform by NPCI (National Payments corporation of India) is enabling road-side tea-sellers or small vegetable vendors to accept digital payments and bringing banking service, like money transfer, to a wider audience. A low-cost UPI based payment with no MDR (merchant discount rate) imposed, that saw a hopping growth rate of 55% last year, questions existence of the costly 4-party payment system and challenges the legacy payment industry to revisit its revenue model.

As the digital payment market is set to grow ~18% over next 6 years, and current covid situation should only increase the adoption among small to medium business (SMB), need of a faster payment processing is quite evident as SMBs typically struggle with cash flow. While the UK, AUS and many others have made a move much early, one of the most conservatives in the block, the US have also seen the real-time payment (RTP) wave thru the new payment rail launched by TCH and Fed.

These examples of new normal in Speed (RTP), Cost (UPI) and Innovation (Open Banking) pose serious threat for large FIs to stay relevant with their payment business. Monolithic legacy platform and high cost of RTB (run the business) are primary hurdles for a bank or a payment network to change and/or innovate. However, to sustain, modernizing their payment platform is a not a choice they can afford to have.  

Here is a quick synopsis of key capability a modern payment platform should support:

• Processing real-time clearing which essentially means an ability to accept and process single-message transactions vs dual message in legacy system
• Adoption of ISO 20022 message; Real-time payment brings the challenge of building a more robust AML and fraud system, and, ISO 20022 acts as an enabler by providing additional data fields to enrich the model towards a better accuracy
• Positive customer experience through a highly available “always ON” platform; waiting time during authentication and authorization is a deal breaker for any PoS system
• Self-servicing capability in onboarding and certification for merchants (terminal certification) and network participants (host certification). Innovative payment players, like Square, are onboarding merchants in minutes; in this highly competitive acquisition space, acquiring new market/segment needs drive for speed and agility
• A frictionless experience for business in accepting newer form of payments, enabling digital channels (a growing need in Covid situation) or in handling a disputes case
• Faster adoption to different market based rules and geo specific compliance requirements (eg Data localization), which needs the new system to make a conscious departure from a tightly-coupled legacy architecture
• AI/ML capability, that equips a modern payment platform with advanced risk and fraud modeling, to build a continuously improved authorization engine and to avoid false positives. In addition, a payment system needs to be smart enough to identify abnormality or system failure in advance to prevent downtime.
• Integrate “outside-in” capability from eco-system players and expose “inside-out” features for them to integrate easily. As participation in Open banking is inevitable, a modernized payment platform is ought to act as an enabler to build new capability with consumer data from the ecosystem, or, expose APIs for partners to build on it.  

Modernizing age-old payments system is typically an intense, multi-year engineering modernization initiative for large industry players. In absence of a firm planning across some key dimensions, in the likes of architecture, data, infrastructure, environment, performance, quality assurance and DevOps, leads to a costlier affair for companies in terms of time and money. Not to forget continuous RTB investment towards maintenance of existing legacy platform that can’t take a back seat, during course of building and stabilizing the new system.

Let’s look at some of the key engineering dimensions FIs need to consider, at a very early stage of the affair, to avoid late rework and potential slippage of market commitment:

• Determining the technology stack is extremely important; there has to be a unified tech stack that can integrate all core functions, including real-time authorization/clearing and batch processes in clearing/settlement. Transaction processing thru payment messages should be facilitated through Microservices API. This service-based architecture has to be modular enough to minimize regression effort for future capability enhancement and speed up innovation.

• A payment platform is a collection of many applications like message switching, message parser, translator and validator, network participants set up, key management, addenda processor, fee calculator, risk/fraud and many more. In fact, every application/Microservice should be viewed as a separate product, with different workloads, that provides its own functionality. "Data strategy" for the modernized platform has to be curated to accommodate varied need of data processing and storage, which essentially means choice of an operational database vs a configuration/set up database might not be same; eg, operational DB for an RTP engine should support fast update to minimize latency, and, should be able to handle large volume of data (in terabytes and petabytes), and demands high scalability and fault tolerance, which is very different from DB requirement for storing disputes business rules or property related data (BIN, Pricing, hierarchy) for network participants. Another important aspect in data strategy is designing an effective and optimized "Data Caching" technique to avoid tightly coupled data sharing among processes, which adversely impacts peformace. 

• Building a high-throughput and low latency platform is absolute critical as it comes to real-time transaction processing. Having the right planning for performance validation during service integration, and a comprehensive tooling strategy to support it, is an engineering problem that IT needs to solve. Performance validation is usually an evolving process and has to have a drive for automation, as every deployment would need to ensure performance benchmark is met against predefined metrics; a heavily manual process would be costly to manage. A new payment platform must also be resilient enough to cater to anywhere, anytime payment across channels and across the globe. Assuring resiliency demands a well thought-through Chaos engineering strategy against infrastructure, network and application failure and having the right tool-set for each scenario.

• “TEST EARLY, TEST OFTEN” mindset is a key enabler to launch rapid MVPs. Shifting Quality Gating towards left in development cycle keeps cost of failure low, which essentially necessitates a departure from the traditional approach of quality assurance. Frequent testing can be achieved through tool chain automation, which triggers tests and executes automatically with every new build creation. There has to be a framework-driven testing mechanism to ensure all different payment messages in critical path of Authorization, Clearing, Settlement, Disputes, Reconciliation etc, with all possible combinations of ISO data fields, are tested; eg. During Auth testing, every supported POS entry modes (DE 22) like Mag stripe, Chip n PIN, contactless, PAN key-in, auto-entry etc needs to be validated and test framework should be capable enough to simulate generation of messages with required variability.   

• A robust automaton framework needs to be in place to enable continuous integration and continuous deployment for rapid development and release of MVPs (most viable product). Every stage of CI/CD pipeline should be looked through for automation and self-service enablement - from component level (to automate service level APIs) to end-to-end automation covering business flows for MVPs.

• Foundation of embracing resiliency, elastic scalability, availability or speed lies in adopting the right-fit cloud strategy for enterprise, which is also the key for reducing TCO (total cost of ownership) of the new system. A cloud native application, that has been designed and implemented to run on a Platform-as-a-Service model, reduces the development lifecycle and takes away the headache of scale-in, scale-out in a seasonal business like Payments. Determining the most optimized strategy in the choice of public vs private cloud is a bull’s eye FIs need to win over; a hybrid strategy, with mix of both, can potentially be the way to go. While public cloud is easier to scale as it comes to large data load or managing big-data driven analytics, for storing sensitive data, eg customer information, behind the firewall, private cloud should be the preferred option.

• In a move towards cloud-native, traditional monitoring approach, which is usually tactical, falls short. Microservice based architecture brings a series of complex dependency between services and with challenge of frequent code pushes in an automated CICD system, an end-to-end “observability” is must to have. It enables a cause and effect view of any system anomaly against meaningful metrics and traces the failure point in a series of events. Capturing right amount of application logs (logging), establishing a continuous view of application thru the lens of inter-service dependency (tracing) and aggregated measure of data in a time-series chart in an easy-to-understand dashboard (monitoring) are three primary tenets of observability to build a highly responsive alert generation and remediation system. Key essence of observability is solving a problem before it affects customers and damages brand, which the new payment platform must not be party to.

It would not be quite apt to say though, coming strong in all these engineering pillars are enough to achive the end-goal for FIs. Success of a large scale engineering modernization largely depends on adoption of a matured agile execution methodology, drafting a MVP strategy that delivers incremental and meaningful value to customer and clear ownership of functional components across application teams to avoid integration challenges and dependency issues. A tight cohesion between teams is a no brainer; API design best practices or automation tooling can’t be a federated decision. While IT should build the engineering guardrails, a closely-knit approach between business and IT in capability prioritization, MVP definition and release planning are mandatory for a seamless execution and rollout.

This engineering evolution is certainly a mountain to climb for large FIs, for whom technology was always an enabler and not a differentiator. However, further delays in making a move would only find them ending up losing forte to nimble foot competition from technology innovators. Staying relevant is not a choice they can afford to make in the age of payment innovation, and, modernizing their heavy-weight payment platforms build the foundation to win.