The Payment Engine Problem

The Payment Engine

Also known as the payment hub or simply the back office application, these IT solutions help banks process hundreds of thousands of payments a day like clockwork. Most human beings with bank accounts must thank payment engines that process their salaries, help them pay rent, and make buying guitar strings on Amazon possible. It simply makes digital account-to-account (A2A) payments scalable and affordable for banks to provide the service free of cost (or for a small teeny tiny fee).

In this article, I will discuss the real pain points banks face in choosing the right payment engine, getting it up and running, and operating it over the long term.

Choice:

There are more than a few payment engines that you (as a bank) can choose from. My opinion is that not all payment engines are created equal. Some payment engines are objectively better than others. There are several factors that banks need to consider in order to choose the right one. Here are the key ones.

1. Volume of payments being processed
2. Payment Engine Vendor’s business
3. CSM(s) that the banks need to connect
4. The amount of customized workflow required
5. Support and maintenance
6. Other banks using the same product
7. Architecture
8. Costs
9. The suite of related offerings related to the payment engine
10. ISO20022 nativity
11. Documentation
12. Product Vision

Often, I see banks not having the ideal payment engine for their needs, and that becomes a roadblock for banks to innovate and adapt to changing customer demand. Banks generally start with their payment engine transformation journey with a single payment scheme, like a classic credit transfer or direct debit, but when they want to add instant payments, they end up realizing that the instant payment product of the same company is not as good as the other offerings.

A bank’s business and current market sentiment are key factors in deciding which payment engine to go for. Banks must think about everything in their pipeline for the next 5 to 7 years. Request to pay or same-day cross-border payments will become the new norm soon, and banks should take these into account.

Operating cost is another very obvious consideration. In addition to the product license, maintenance is a major factor.

Banks feel frustrated when they don’t receive the level of support from the payment engine vendors (PEV) that was promised during the sales pitch. The defect fixes and product upgrades are not delivered on time or are not of the expected quality. A good background check on the vendor and their track record is a must.

PEVs sometimes make Significant changes to the product on the back of a request from their largest client. This directly or indirectly affects their other client, and the other clients would be forced to adapt to the new changes. There are some advantages here where other clients’ bug fixes help the banks, but in my opinion, the largest client always has the advantage of choice.

ISO20022 nativity in their code and database is also a key point to consider. This will help banks with analytics, increased STP, and easy adoption of new schemes with ISO20022.

If I start talking about documentation, the entire article will turn into a rant. Forget clients, even within the PEV organisation, new joiners can’t get to the bottom of what the product actually does. That remains securely in the minds of a few select product gurus. Every question has to go to the product guru. Sometimes resolutions of queries take too long.Ask me how I know this. There are exceptions to this, where some payment engines have spectacular documentation.

Another key aspect that banks must evaluate is how much of a PEV’s business is the Payment Engine part. If the percentage is too small, then PEVs will simply not care as much as we want.

Here is an Excel sheet that you can use to evaluate payment engines. Even for your own amusement, try to objectively score two payment engines you know.

Operation and Maintenance:

Operating a payment engine is not an easy task. The scale with which banks operate is an important factor in the maintenance. If you are a corporate bank that processes a few hundred payments, then maintenance might not be too difficult when compared to a global bank that processes millions of payments a day across multiple countries.

Payment engines need to be continuously monitored to ensure performance and reliability. It should not lose a single payment. Most modern payment engines do not perform too badly in these aspects for non-time-critical payments like NEFT, SEPA Classic, ACH etc. For Instant payments, the demands are completely different. Only well-designed payment engines offer banks a bang for their buck especially with instant payments.

Multiple times a year, banks have to install a new version of their code. In an era of 24* 7 availability for customers, zero-downtime upgrades are now becoming a “must-have” feature for payment engines. This again is a clear marker to differentiate the better-designed ones.

Payment engines need TLC too.

Another area where PEVs struggle is defect prioritization and delivery. 100s of defects pour in from all clients across geographies for multiple CSMs. PEVs should prioritize and solve them. With the volume of defects pouring in, in my experience, PEVs prioritize only P1a. Forget the P3s, even P2s are not fixed, at least not on time. This leads to a situation where banks give up and learn to live with them. An extremely strong engineering and delivery framework is a must-have for PEVs.

PEVs generally have multiple layers in their product. Any changes to their CORE product can take years to prioritize and deliver. If it cuts across their other offerings like CORE banking, then I would say forget about it.

Crisis management is yet another aspect where PEVs find themselves in a tough spot. Suddenly, out of the blue, something breaks banks mobilize their resources to solve the issue. Supporting banks during the time of crisis is really critical, and not all PEVs offer such support.

Innovation:

In the current regulation-driven era in payments, PEVs do not prioritize innovation. The process of continuous improvement takes a back seat. Both from a technological and functional perspective. Payments are evolving at an ever-increasing speed, and to keep up with the trend, PEVs must innovate. It is no longer just about increasing the STP rate.

SEPA instant in Europe is a case where banks are required to process payments end-to-end within 7 seconds. Banks will now look at processing times closely. Banks are also expected to be available 24*7*365. Once customers get used to instant payments can’t be down for hours together for upgrades and maintenance. Error margins for payment engines are razor-thin.

Here are some areas where PEVs can innovate

• Sanctions and fraud integration
• Auto repair rules
• Tight integration across products
• Auto Healing
• intelligent routing
• predictive analytics
• dynamic fees/fx rates
• Reducing invalid rejections
• Operator suggestions
• AI integration

I am sure there are really smart people working in PEVs who can come up with better ideas. The point is, Innovation must be given appropriate priority.

Conclusion:

Many working in payments might feel “Tell me something I don’t know” but as a community, we have to keep highlighting the problems often and loudly so that we don’t forget this and eventually learn to live with them. I don’t discount the limitations within which PEVs operate. I have firsthand experience working on a payment engine development, but changes are required now.

I really hope there is fierce competition and innovation battles that lead to more innovative products in the market.