The optimal solution to payment system architecture

Developing payment capabilities directly within the core banking system makes immediate sense, given that payments are debited from or credited to customer accounts. Processing payments within the core means direct and seamless access between payment services and accounts.

However, this approach has a significant downside. As payment processing requirements and the bank’s stack evolve and change, the payment service must also adapt, often requiring extensive modifications to accommodate new message types, rules, processes, and integrations.

‍
‍

‍

All these changes must be implemented in the core banking system, arguably the bank's most crucial and sensitive system. Furthermore, should the bank decide to introduce a new core system, it would face the daunting task of replicating all these capabilities in the new system. These difficulties in introducing changes can lead to stagnation in payment capabilities, thereby reducing the bank’s control over them.

As new payment processing requirements emerged, it was not always feasible to implement them directly into the core banking systems. Consequently, banks increasingly opted to implement these requirements through gateway connectors instead. These connectors provide banks with access to the payment system's network and, due to their close association with the payment system, have become ideal candidates for handling payment processing rules and processes. Many gateway connectors have evolved into complex payment processors that do much more than merely facilitate connectivity to the payment system.

‍

‍

Shifting payment processing from the core system to gateway connectors offers advantages but introduces similar challenges. The bank must implement a unique connector for every payment system it wishes to integrate with. Each connector needs to integrate with a variety of bank services and support its own user interface, adding complexity to the technology stack and reducing the potential for interoperability.

Additionally, gateway connectors are directly exposed to changes in messaging protocols, connectivity technology, and new regulatory requirements. Presently, payment transactions are largely facilitated through file-based messaging. However, as the transition to cloud computing gains momentum, a significant shift towards modern APIs is anticipated. Such evolution will substantially impact a large portion of the bank’s payment processing infrastructure.

Finally, gateway connectors are considered critical systems; in certain instances, banks must establish redundancy for them. Keeping these gateways as streamlined as possible and centralising orchestration can reduce both the burden and the risk for the bank. 

‍

Since neither the core system nor the gateway is an optimal solution for managing payment processing, an intermediary, dedicated layer is called for. This layer, positioned between the core and the gateway, would be specifically designed to handle the rules and requirements of various payment systems. This solution effectively shields the core system from frequent changes and keeps the gateway connectors focused on connectivity. 

Focusing this solution on orchestrating payment instructions allows it to become an expert system, generalising payment processing patterns and capabilities and reducing the amount of payment system-specific code. In this scenario, a bank will have a single payment orchestration layer—a payments hub—to handle all its payment needs. 

‍

‍

It would seem then that a payment hub is an optimal solution for managing a variety of payment rails: it consolidates payment operations within a single system, simplifies the bank's technology stack and externalises scheme connectivity issues away from the core payment processing tasks. The adoption of payment hubs has become widespread, with various software vendors providing offerings of varying complexity, scope, and features.

Despite the perceived benefits, legacy payment hubs present significant challenges as they often consist of multiple systems stitched together rather than a unified platform. This fragmented architecture complicates the management of diverse payment types within what appears to be a single system. This patchwork setup increases the overall complexity and can hinder efficient operation.

Payment processing requirements are highly varied. High-value transactions demand sophisticated processing and occasional manual intervention, file-based methods require managing vast numbers of transactions across several days, and instant and card payments necessitate rigorous adherence to SLAs while coordinating with fraud detection and anti-money laundering (AML) systems. Even when comparing similar systems (e.g., Bacs, STEP2, FedACH, and any other mass file-based system), while there are many similarities, there are also distinct differences.

Finally, banks' payment processing methods vary greatly, reflecting the diverse needs of their customers, local regulations, and the limitations imposed by their technology stacks. 

The payment engine must simultaneously accommodate all these variations, presenting a significant challenge for vendors trying to offer a one-size-fits-all solution. Older, legacy solutions typically require complex parameterisation and involve expensive, vendor-specific customisations. Over time, these systems can become inflexible and brittle, with modifications becoming time-consuming, costly, and sometimes impossible to implement. Consequently, banks often find their control over payment orchestration diminished, forcing them to resort to compromises and workarounds.

This situation places banks in a predicament. They frequently find themselves either compromising their payment processing capabilities or resorting to costly stopgap measures. Some larger banks have undertaken the daunting task of developing their own in-house payment hubs. However, these projects are expensive and risky, saddling the bank with the ongoing challenge of maintaining and operating these intricate systems. They also risk being overly tailored to the bank's current needs, potentially resulting in less extensible systems as requirements evolve. In contrast, a well-designed payment hub built by a product company should take these considerations into account and create a solution that generalises better over time. 

‍

Consolidating payment rails into a single solution is the optimal strategy for banks. However, achieving this effectively goes beyond merely modernising old systems with new technology. Banks need the capability to control the critical components of their payment system. This means designing their payment orchestration processes—determining the steps, the sequence, the number of external integrations, and the specific business rules for each payment type -without needing extensive technical expertise and expending valuable resources and time.

Traditional UI-based rules and flow orchestration tools are a start, but they have limitations. Ideally, banks would benefit from access to a straightforward, high-level programming language. This language should be supported by a comprehensive SDK that is payment-domain aware and integrates seamlessly with services essential for payment operations such as warehousing, mandate management, and routing directories.

Another key principle is that each payment journey should be implemented as an independent flow, separate from the platform's core and other payment journeys. Such an architecture allows updating individual journeys without affecting others or being tied to the core platform's upgrade cycles. Banks should be free to independently adjust or develop new payment journeys without relying on their vendor.

Choosing the right platform to modernise a bank's payment infrastructure is challenging. In assessing options, banks should look beyond basic requirements and the simple replication of existing capabilities. Today, banks must have far greater control over their payment stack than ever before. With the right systems in place, banks can transition to adaptable, responsive, and robust payment processing that meets both their current and future needs.

‍