Blog: Payments Modernization: From Legacy Monoliths to Agile Microservices

Scaling for the Future

The movement of money, especially electronically, must be quick and seamless, at least from the account holder perspective.  In a manner of sub-seconds – literally, hundreds of lines of code are being executed as the transaction flows across the system to authenticate, verify and authorize money to change hands every second.

To handle these transactions, most FIs are still using legacy monolithic systems  built in the early 1980s when servers were large and costly, code was written in a language that required specialized resources and the ease and efficiency of the tools and technology of the digital age was still off in the horizon.

Fast forward 40 years…24/7/365 cost-effective availability is now a must-have, and lag-time is not acceptable in this on-demand world. Unfortunately, with legacy systems’ traditional ‘bulky’ architecture, they are hard coded around the business model of the time. For example, for consumer authentication that means legacy systems are built around card and PIN as the solitaire form of authentication. In this example, to authenticate the consumer’s card, it’s not just one piece of code running. Rather, it’s typically a bundle of many executables that do not lend itself to efficient and easy scaling.  If there is one single point of entry or exit, a bottleneck will occur. This is why most FIs have large pre-paid and pre-configured servers sitting idle and, ready to handle what happens on a quiet Tuesday night, as well as a super busy Black Friday, when millions of transactions are increasing queue lengths.

To put this demand in perspective, here are some startling figures: In 2022, U.S. credit card transactions totaled 1,739 per second¹. Additionally, Visa handled an average of 757 million transactions a day in its fiscal year 2023, up from 707 million in fiscal 2022². And, as more electronic payment methods become available, the trend moves ever upward…

To handle today’s volume fluctuations and diversity of transactions, FIs need to modernize their systems to process payments in the most cost-effective and efficient way while enabling new features and compliance seamlessly without any disruption of service.

Easy to Scale Up, but More Importantly Down

Modern payments systems that are cloud-native and built utilizing a microservice architecture eliminate these concerns. Rather than use multiple, large single-use servers, these systems run in modern dynamic public, private or hybrid environments using containers built to run scalable applications. These applications can automatically start up new copies and spread the load so that the service is always optimized for the current demand. They also provide the resilience required to run these mission-critical applications in the multi-active redundancy required. Once the load reduces, servers can be reconfigured to perform other tasks or simply released. Utilizing this reserved processing capacity for other processing needs while ensuring the additional capacity is always instantly available to be dedicated to the payment engine is a benefit of the cloud.

But scalability is just one of the benefits. Microservice architectures utilize low-code modeling, enabling the removal of utilities that are no longer needed or used, or to add the capability of new services, such as new forms of consumer authentication from digital channels using tokens or biometrics. When more modern, service-based architecture is used, new services can be introduced, tested, and deployed with low risk via a blue/green deployment model with no operational downtime. If this function proves to be unsuccessful, it can be quickly removed, and then the next iteration can be tried. This removes cost and complexity and the burden of keeping obsolete code maintained, plus it ensures the code can perform optimally as the system scales up and down.

With a microservice based architecture, big blocks of functionality can start to be disassembled into more resilient and individually scalable services. For example, the security elements, which are typically a replicated element of a payment system, as well as at the ATM and branch terminal handling capabilities, can be pulled out and made available as central services.  This lightens the operational load as the system that needs it can access the central service via an API. Common services (such as security, authentication, etc.) can now be available as configurable facets – no monolithic code needs to be maintained. Additionally, they can be used in different places across the enterprise or distributed as needed, independent of the channel or back-end service that needs to utilize it. For example, if a security policy changes, new regulations demand change or the business wants to change customer limits, this can be consistently applied across the enterprise with specific variations clearly identified and limited to a small configuration change or a small set of specific code. This approach allows the enterprise to introduce change securely at speed and scale.

As financial institutions strive to evolve their infrastructure and systems to support the ever-increasing growth of and innovation in payment transactions, Diebold Nixdorf has the solutions to provide a highly configurable, scalable, and reliable set of business service components that tie the ATM and other channels together and integrate the front end, back office, and core banking services, without limitations.

Is your organization ready to future-proof your banking ecosystem? Let’s discuss how Vynamic Transaction Middleware can help you evolve your payments system.


¹ Source: Number of Credit Card Transactions per Second & Year: 2024 Data (capitaloneshopping.com)
² Source: https://www.wallstreetzen.com/stocks/us/nyse/v/statistics#link-0-1-0