Making your payment stack multi-bank

On average, companies work with more than three different banks. Those managing more than 10 million payments per year work with more than four different banks. A growing number of successful fintech companies go multi-bank for various reasons, such as expanding internationally or building redundancy into their payment infrastructure. But doing so can be challenging, from building and maintaining multiple bank integrations to managing payments and treasury across multiple banks.

In this article, we explore what it takes for a fintech company to go multi-bank.

Operating with a multi-bank payment infrastructure

To understand what is required from a multi-bank payment infrastructure, we first need to understand what operating with multiple banks actually means.

Sending and receiving payments through multiple banks

One of the benefits of working with multiple partner banks is sending and receiving payments through these multiple banks, whether it is to support more payment methods, build redundancy, or other reasons.

On top of simply sending and receiving payments through these multiple banks, companies going multi-bank need to be able to determine which payment to send from which bank, depending on the originator, the beneficiary, or the payment method.

In addition, regulated payment and electronic money institutions have regulatory obligations to safeguard customer funds. Most will do so by segregating customer funds in a dedicated bank safeguarding account. Sending and receiving payments through multiple banks therefore requires fintech companies to be able to move money between their multiple accounts held at multiple banks and their safeguarding accounts while respecting the safeguarding delay obligation. They also need to make sure they keep sufficient funds at all times on their multiple bank accounts to be able to actually extend payments.

Maintaining visibility across banks

Banks are the foundations of fintech companies’ operations. They hold their funds and process their payments. As such, fintech companies must have constant visibility on their bank accounts.

When working with multiple partner banks, fintech’s funds and their customer funds are spread in multiple accounts held at multiple banks. To ensure global liquidity levels are adequate at all times, fintech companies must have an aggregated view of all their bank accounts while monitoring each account balance to avoid fees and payment failures.

Payment and electronic money institutions also need a real-time view of the payments they send to their banks to ensure each payment is adequately executed or act accordingly when a payment fails. One main benefit of building a multi-bank payment infrastructure is redundancy. Being able to identify payment issues with one partner bank and automatically redirect payments to another bank is key.

Finally, in addition to account balances and payment statuses, fintechs should have a constantly up-to-date view of the transactions happening on their accounts across all their banks. They are critical for bank reconciliations but also for keeping customer balances up-to-date at all times.

As banks multiply, manual operations across various systems and interfaces become unsustainable. Automating tasks also become challenging, as the different data format across banks makes it difficult to normalise, centralise and act on this data.

Building and maintaining your multi-bank infrastructure

Now that we understand the tasks a multi-bank infrastructure must accomplish, let’s break down the required elements.

First, the foundation of such a layer is the ability to automatically exchange data with multiple banks: payment orders, account balances, payment statuses, etc. Doing it at scale across various banks is not realistic via web interfaces of manual file uploads and downloads.

Bank integrations that will automatically exchange data between fintechs’ core systems and banks’ cash management systems are mandatory. But building them is not an easy task. Companies must deal with heterogeneous connectivity channels, file formats, and even messages between banks. Building these integrations is just the first step, as regular payment schemes’ updates will require changes in message formats and upgrades to bank integrations.

Once integrations are built and data can automatically be exchanged between the fintechs’ core systems and the banks’ cash management systems, sending and receiving payments through multiple partner banks requires an orchestration layer on top of the bank integrations.

This orchestration layer includes several elements.

First, the ability to send payment orders to multiple banks, which means the ability to route each payment to the right bank based on the payment details (beneficiary, currency…) and the fintech company’s business logic.

Once a bank is designated, a payment order needs to be transformed into a specific message packaged into a file format, encrypted, signed, and uploaded on the bank’s servers.

As we covered above, operating with a multi-bank payment infrastructure does not stop at being able to send payments through multiple banks.

Once payments are sent, fintechs must monitor their correct execution, but also maintain visibility on account balances and transactions. Banks usually make this information available through files that customers can retrieve from their cash management systems.

Once these files are downloaded via bank integrations, they need to be parsed and processed by an orchestration layer that will normalise the data they contain. To be useful, this data needs to be consumed by other systems and acted on by finance and operations teams.

Such an orchestration layer should therefore make the processed data available through dedicated dashboards and APIs.

Finally, reconciling payments and transactions across multiple bank accounts requires a dedicated engine that will perform this task using data fetched from the banks through the bank integrations.

Adapting this multi-bank layer on top of an existing stack

Fintech companies’ existing core banking systems might not natively handle multi-bank operations due to limited coverage of their native bank integrations, lack of end-to-end integrations with the ability to automatically upload, download and process files from banks’ cash management systems, or other functional gaps.

But changing an entire core banking system to unlock multi-bank payment operations might not be a realistic solution. Luckily, a multi-bank orchestration layer can, most of the time, be plugged on top of an existing core banking system’s native payment engine.

This layer can receive payment orders from the core banking system, process them and send them to the correct partner banks, track and reconcile them, and send update notifications to the core banking system as the payments are validated, sent, executed, and reconciled.

Similarly, once the orchestration layer processes bank information, including balances and transactions, they can be fed back to the core banking system via API and webhooks.

Multi-bank orchestration: point of view and experience from payment companies' product and business leaders'

Establishing mutual confidence with the right banks and actually contracting with them might be the most uncertain step to becoming multi-bank. Or even starting your payment company with a single partner bank.

But building and operating a multi-bank payment infrastructure adds several orders of magnitude of complexity to your payment company.

We invited payment companies' product and business leaders to a webinar about building resilient payment operations. Our panellists – namely Nirav Patel, CEO of Andaria Financial Services, Dimitri Rodrigues, Chief Product Officer at iBanFirst, and Dan Wong, Senior PM Core Banking at TrueLayer – shared their learnings from their extensive experience.

Let’s explore how our panellists deal with this complexity.

Bank integrations are hard, and not very repeatable

SEPA rulebooks, ISO 20022, pain.002… You would think the technical part of payments is highly standardised throughout the industry. In theory, it is, with standards and rulebooks defining in extensive detail how things should work, how payment messages should look, and how files should be structured.

In reality, our panellists describe the process of integrating with multiple banks as a complete nightmare. For a single currency and a single payment scheme, each bank adds its individual nuances in the payment messages, uses different cut-off times, generates different types of payment reports, or even uses different UTC offsets, a tiny detail that has major implications on the automatisation of operations with banks.

And obviously, the process of building integrations with multiple banks for different currencies and payment schemes is almost like going back to 0.

Managing the flows of funds

Working with multiple banks means that you can collect funds via one bank, safeguard them in a second one, and settle payments with a third one. To operate correctly and in a compliant way, you need to maintain a certain level of funds in each of these banks, which means continuously moving money between these three banks, tracking these movements and reconciling them.

To achieve this internal orchestration, iBanFirst built its own internal messaging system for payments, which is agnostic of specific bank integrations and allows them to move money across their bank accounts.

Routing payments: the perfect orchestration layer

Working with multiple banks means having multiple possible banks to send a payment from, and for each bank, potentially several different bank accounts, currencies, and payment methods.

Whereas on the customer side, you want to abstract as many things as possible and obviously won’t require customers to choose which one of your payment company’s bank accounts to send the payment from.

So how do payment companies manage that? They use an orchestration layer that will route each customer payment to a given bank, bank account and payment method based on various criteria.

First, there is the purpose of the payment. The purpose of the payment is driven by what the customer wants to make this payment for: is it a priority payment? Is it a payment for an e-commerce purchase or for paying for a house? Does the customer want the payment to be low CO2 emission? Is it for a local or cross-border payment?

Then, there is the technical routing: is the counterparty bank available for instant payment? Is the primary bank down? Am I risking to overload the local bank’s systems by sending them too many payments at once?

Finally, there is economical routing. Your payment company might have better terms with a specific bank for a specific payment method, currency or counterparty location, or you might want to balance your payment volumes across your different partner banks.

All these criteria need to be fed into an orchestration layer that will route each payment to the best bank based on the said criteria and the current state of the broad payment systems.

Building the team to support multi-bank payment operations

As automated as the system can be, there are people working behind the scenes to build these systems, monitor them, make sure everything is compliant, and correct potential errors.

For our panellists, typical organisations at these stages are made of:

• Squads of five engineers and two product managers to build and maintain each bank integration

• A dedicated team to manage settlements across banks

• 15 to 20 people to operate and optimise the orchestration layer

How many banks to work with: always be one and a half a bank ahead

Depending on your payment company’s specific business, the ideal number of banks to work with will change. From 2 for Andaria to 15 for iBanFirst, which focuses on cross-border payments.

Again, the more partner banks, the more complex it is to build, maintain and operate your payment infrastructure, but the more resilient your payment operations are. The right number is a trade-off between functional coverage requirements, complexity and resilience.

The rule of thumb is to always have at least half a bank in advance in your infrastructure. Ideally, one and a half. What does it mean? It means that in addition to your existing banking coverage in production, you should have:

• One additional banking partner ready to go live almost immediately. This means having an integration developed with that bank, already tested and connected to your systems, a contract already signed or ready to sign and, therefore, a KYC process already done with the bank.

• Half a bank in the pipeline. By half a bank, our panellists mean a bank you have already engaged with, that already knows your business and with which you can start the onboarding process overnight. Concretely, it is a matter of keeping the conversation with the bank warm and sustaining the relationship live with the right people at this bank.

Why this one-and-a-half rule? Because as we’ve seen, many things can go wrong with your current banking coverage, and your one bank in advance can also decide not to work with you. This one-and-a-half rule is insurance on your access to payment rails and capacity to safeguard customer deposits. It is insurance for your payment company.

How Numeral supports fintech companies going multi-bank

Going multi-bank, with all the benefits it unlocks, can be challenging for fintech companies, whether at their early stages or once they already have a significant payment infrastructure in place.

Numeral is a bank orchestration platform designed for fintechs and financial institutions building advanced payment flows on top of their multiple partner banks. Do not hesitate to contact us if you are interested in building robust multi-bank operations.