Over time, banks’ payment orchestration platforms have evolved as a collection of isolated systems to serve the specific requirements of different payment rails.
As a result, aggregating front-end channel access, integrating with the bank stack, billing, and performing analytics across these systems can be difficult. It is time and resource-consuming when changes are needed to comply with new regulatory requirements or to add new features to enhance customer experience. Supporting new payment rails or use cases often entails significant investment and business disruption. The need to operate multiple systems also comes with cost considerations, including licensing and operations support.
Why do banks need a new payment engine?
Banks face the challenge of handling multiple and diverse payment methods, including traditional methods such as cash, cheques and wire transfers, and newer methods such as digital payments, mobile payments, and e-commerce payments. Each payment method has its unique characteristics and requires different systems and processes to support it, and consequently, a common payments stack consists of multiple payment platforms.
It stands to reason that banks want to consolidate payment processes into a single platform. By doing so, banks gain operational and cost efficiency, have less exposure to cybersecurity and regulatory compliance risk, and can offer a frictionless customer experience.
However, consolidating multiple and disparate payment methods, schemes, and types into a single platform presents challenges.
Different payment methods may have varying business requirements, compliance standards and procedures — leading to additional technical considerations. For example, a credit card processor must be able to respond to authorisation requests within a matter of a few hundred milliseconds. A credit card processor must also be aware of the card scheme’s guarantees.
In contrast, the processing of direct debit batches is not time sensitive, but the processor must be able to schedule sending payments and settle them over multiple days. Modern instant payment systems such as RT1 and FedNow use single ISO 20022 messages, while older systems such as BACS and ACH use files with proprietary formats.
Banks won’t find a payment system with connectivity to all payment methods because they cannot anticipate enough of the new payment methods that may arise in today’s fast-evolving and complex financial world. A simple look at the payment methods that came onto the scene over the last two years makes the case.
And so here is the key point of this paper: Banks need a single payment orchestration system to simplify their stack and lower the cost of ownership and change, while gaining full control over the behaviour of their payments and the flexibility to future proof the solution, add new payment methods, and innovate.
To read this piece in full, visit here.
