Payment and electronic money institutions all share one promise they build upon: facilitating payments for their customers. Fulfilling that promise requires the utmost reliability. All software and services buyers will demand reliability from their vendors.
But some software and services are more critical than others for their customers. When it comes to facilitating payments, sometimes being the single means of payment for your customers, any downtime can have a critical impact on people’s real life and the trust they have in their business partners.
To cover how regulated fintech companies apprehended that challenge and ensured resilience in their payment operations, we’ve invited payment companies' product and business leaders to a webinar about building resilient payment operations.
This article sums up what Nirav Patel, CEO of Andaria, Dimitri Rodrigues, Chief Product Officer at iBanFirst, and Dan Wong, Senior PM Core Banking at TrueLayer’s shared and how their companies embraced multi-banking for more resilient payment operations.
Payments should be invisible
Our guests all build payment products, for which any operational issue can have severe reputational repercussions and real-life consequences for businesses and individuals, as discussed above.
Nirav leads Andaria, a UK and EU-regulated fintech company providing non-financial businesses with payment accounts augmented with multi-currency capabilities, virtual IBANs and more, with the aim of increasing business banking inclusivity.
Dimitri is Chief Product Office for iBanFirst. Based in Brussels, Belgium but operating in more than 10 countries across Europe, iBanFirst enables SMEs to go global by facilitating cross-border payments and FX for use cases such as goods import and export and international retail.
Dan oversees the core banking system of TrueLayer, a company that started with open banking and quickly expanded to provide merchants with online accounts-powered payment services.
As we can see, it is in these companies’ mission to make payments just work, so their customers can focus on their core products and services. For any non-financial business, while being critical to the lifeline of the companies, payments should remain in the background, almost invisible, embedded.
And to remain invisible, payments should not break.
What is payment resilience?
Preventing payments from breaking requires building resilience in payments. But how to define payment resilience? Which metrics to track?
Again, the goal is to make payments invisible. So what makes payments invisible?
First, they should obviously work, meaning that whenever a customer sends a payment, this payment should arrive to the bank of its beneficiary. Many steps of payment, internal or external to the payment company, can go wrong. But payment companies keep an overall view of payment success rate, with a specific threshold they aim at maintaining.
When incidents affecting the platform's overall capacity to send and receive payments happen, again, whether internal or external, recovery should happen as fast as possible. Payment companies' infrastructures are built in that sense, and the overall uptime of these platforms is a key indicator.
To be invisible, a payment should also be fast. There are two aspects to consider here. Depending on the payment rail and method, a specific payment will take more or less time to be executed. Think about your classic bank transfers compared to instant bank transfers. Payment companies ensure that any payment initiated through their services respects the promised payment speed. An “instant” payment shouldn’t take more than a few seconds, a classic one more than a few days.
Independently from the payment rail and methods, customers want to know as fast as possible if their payment has been accepted, processed and sent by the payment company, so they can know they can peacefully wait for the payment to be received by their counterpart – or see that their instant payment has been instantly executed.
Payment and electronic money institutions, therefore, monitor the processing speed of their payments.
These metrics sound very backend oriented, linked to processes happening under the hood of payment products. They do, but they also directly affect the end users of these services and their experience. As such, companies consider them as critical factors of their customer experience, and build their entire product and infrastructure around them, with the goal of maintaining the best customer experience, even if major incidents happen in the background.
What can break in payment systems?
The short and scary answer is everything. As mentioned above, many steps, internal and external to the payment company, are involved in successfully executing a payment. In our webinar, our panellists broke down those steps into three main categories.
The case of counterparty availability
The first breaking point mentioned by our panellists was, surprisingly, the counterparty banks. When sending an account-to-account bank payment, this payment has to be received by the counterparty (the beneficiary of the payment, the “payee”)’s bank. Most payment schemes, such as SEPA instant credit transfer, require the receiving bank to acknowledge the incoming payment and accept (or refuse) it within a defined timeframe.
And these counterparty banks actually happen to be unavailable frequently enough that this counterparty availability challenge is top of mind for payment companies. The frequency of this issue depends on the geography and type of counterparty banks, with smaller banks or local branches of larger banks being more often impacted than tier 1 banks.
A specific unavailability issue comes from SEPA instant credit transfers, which aren’t mandatory for banks to support as of today, both as senders and receivers, but will soon be. As a result, even if the payment company does support instant payments, they might not be able to successfully execute such payments for their customers if the counterparty banks don’t support it.
Some counterparty banks are also known to be reachable for instant payments at some times of the day but unavailable at certain hours. Finally, even when both the sending and receiving banks support instant payments, these instant payments can fail due to the fact that they are connected to two different clearing and settlement mechanisms (namely TIPS and RT1).
In such cases, instant payments can fail because messages have to be forwarded between TIPS and RT1, leading to timeouts.
It leads payment companies to implement strategies to overcome these challenges and, once again, abstract them from their customers. Such strategies include:
Delaying the send of the instant payment to an hour when it is more likely to be accepted by the counterparty bank.
Automatically falling back to a classic credit transfer.
Sending the payment from a bank in the same country as the counterparty bank. Hello multi-banking.
Another part of the payment lifecycle that can break is the payment company’s partner bank. The thing to understand is that all banks aren’t operating at the same level of reliability. While relying on legacy systems and connectivity, large banks' payment systems are extremely robust and rarely encounter issues.
But for the reasons mentioned above, and many others, payment companies are led to work with smaller, local banks, offering not that more modern connectivity options, often less documentation, and, more critically, lesser availability. Required formats can change without prior warnings, payment errors can go unnotified or be shared without any explanation, or payment systems can simply be unavailable. It makes building payment automation with these partner banks very difficult, if not impossible, leaving companies' payment teams with no choice but to spend significant time manually investigating and resolving issues.
In addition to technical issues, payment companies are also subject to partner banks’ changing risk appetite. Payments with specific characteristics, such as cross-border payments – even within SEPA – can one day be considered more risky by a partner bank, therefore going through stricter compliance workflows and generating more payment rejections. It makes predicting which payments will be successful with specific banks more difficult for payment companies.
Lastly, a large part of payment companies’ systems are their own payment systems, which will process payment orders from their customers, run compliance and technical checks on them, route them to the best payment rail based on payment characteristics, business rules and counterparties’ availability, package payment orders in the right message format and files for the selected counterparty, and deliver these files to the partner banks.
As highlighted by our panellists, there are nuances in every bank integration. Every integration is different and has its own specific elements payment companies need to play around with.
Making sure all the steps of this workflow work at all times with each partner bank, and in case of issues, solving the issues as fast as possible with minimal impact on customers is a true challenge for payment companies, which dedicate significant engineering and operational resources to this task.