The challenges companies face when building bank integrations

Companies building payment products or processing large volumes of payments as part of their operations often cannot rely on usual bank connectivity solutions. Their bank's web app or vendor's cash management system introduce technical, functional, and scalability limitations. The alternative is a direct integration with their banks that enables them to automate their payment operations from their in-house systems.

Although highly scalable and secure, banks’ direct connectivity solutions can be complex to understand and integrate, even for the most skilled product and engineering teams. They can also be a significant de-focus on a roadmap already filled.

At Numeral, we have built more than 10 bank integrations at Numeral over the last 12 months. This first-hand experience has enabled us to learn the specificities of every bank we have integrated with and refine our integration model over time. We now have a scalable process and a powerful bank integration engine that enables us to connect most banks to the platform in a fraction of the time it took to develop our first integration.

This article shares our learnings on the challenges of building direct bank integrations. We also outline how Numeral can help accelerate bank integration projects, prepare companies for the future, and transform high upfront investment costs into predictable variable costs.

The challenges of building a bank integration

Getting the right interlocutor and pace of communication

Accessing banks' direct connectivity solutions is more complex than creating a self-serve account and obtaining your API keys. If not already done, the first thing to do before even getting access to the bank's documentation is to open an account, and subscribe to the bank's connectivity solutions. The right stakeholders to do so is the cash manager.

Cash management is one of the many lines of products and services that banks offer to their corporate customers. It is also one of the most technical. As a result, banks have built teams of cash managers that are distinct from teams of account managers.

Because account managers have large customer portfolios and need to liaise with different teams from within the bank, response turnaround can sometimes be longer than what product or engineering teams working on a sprint need to reach their velocity goals. 

Choosing between all the bank connectivity options

Banks have strengthened their systems' reliability through years of iterations, keeping their customers’ funds secure and processing billions of payments yearly to power the economy. This iterative process created significant variability and complexity in those systems, reflected in the heterogeneity of their connectivity solutions for different use cases.

Connectivity

In Europe, connectivity channels include the below main channels

• EBICS servers are designed to automate payments securely but require payments to be manually approved

• SFTP servers enable end-to-end payment automation

• Messaging queues enable high throughput

• APIs are designed for companies looking for real-time payments but progressively expanding across other rails

• PeSIT and ETEBAC are bank connectivity protocols developed in France in the 1980s-1990s and used by certain banks

It is worth noting that different payment types might use distinct connectivity protocols and file formats for a given bank. SEPA instant credit transfer payments are an excellent example of API-based or messaging queue-based implementations, marking a departure from banks' historical file-based connectivity. If connectivity channels differ by payment method, each payment method requires distinct and incremental integration work. 

Security

Different connectivity solutions come with multiple security options. Depending on the protocol, banks will have varying requirements, including:

• Signature: eIDAS, SSL certificates, SWIFT’s 3SKey, etc.

• Encryption: PGP

• Authentication: RSA key, API key, OAuth2, JWT token, etc.

Features

Companies then must decide which features to subscribe to as part of their bank offering:

• Payment types (SEPA credit transfer, SEPA direct debit, SEPA instant credit transfer, treasury payments, SWIFT payments, etc.)

• Payment status report types (acknowledgements, executions, rejections, etc.)

• Account report types (prior-day, intraday, debit/credit notifications, etc.)

File formats

Finally, companies need to decide which file formats to use. Those file formats depend largely on the services requested and connectivity channels. Some common formats are:

• ISO 20022 XML files (PAIN, PACS, and CAMT)

• CFONB files

• SWIFT MT flat files

• CSV

• JSON payloads (for APIs)

Choosing the right bank connectivity can be a maze. And this complexity can be overwhelming for teams with no prior experience with cash management and bank integrations. Learning the intricacies of a bank's connectivity solutions can require multiple and lengthy back-and-forths between companies and their banks which can delay integration projects.

Going through the documentation to specify and develop the integration

Very few banks have online documentation. Bank documentation usually comes in PDF or Word documents, which can quickly be outdated.

Once they have received documentation from their account managers or cash managers, product & engineering teams need to specify their bank integrations. Bank integrations are complex pieces of software that leave no room for blind spots and approximations. Building a bank integration requires:

• Connecting and identifying to the bank server, API or messaging queues

• Defining payment batching logic, based on the bank’s processing times and payment file size limit, to batch individual payments into payment files

• Generating payment files in the right format

• Encrypting, signing, and sending payment files

• Retrieving payment status reports and account report files based on the bank’s processing times. Retrieving files is an asynchronous process, and bank connectivity solutions do not provide a synchronous response when receiving payment files. As a result, they do not have push notification capabilities, so companies need to periodically check for new payment status reports and account report files.

• Matching payment status report files with payment files to update the status of the individual payments

Testing and validating the integration

Once product and engineering teams have developed a bank integration, they need to test and validate it to push it into production. The process can vary between banks:

• Some banks have acceptance environments where customers can safely test and validate their integrations

• Some banks might require customers to undergo multiple test scenarios to validate their integrations

• Other banks might not have acceptance environments. Customers’ only option is to test their integrations in production by sending actual payments, called “penny tests”

Factoring in the exponential complexity of building multiple bank integrations

As companies grow, they tend to work with an increasing number of banks for a variety of factors:

• Business relationships: Banks are much more to companies than processing payments. Building multiple strong partner relationships can help companies access the financing and support needed for their business to grow.

• Access to new payment products: Banks keep innovating and launching new payment products. For a given scheme, there also can be major differences in how efficient the bank technology can be. In the case of the SEPA instant credit transfer, for instance, the end-to-end execution of the payment can vary from a few seconds to 20 minutes, depending on the banking partners and their infrastructure. 

• Geographical coverage: When conducting business in a country, having a local bank account is critical for smooth payment operations and usually requires building a relationship with a bank.

• Regulatory requirements: Certain businesses have to hold accounts in different banks by law. For example, insurance companies have to keep safeguarded funds in the bank decided by their underwriters.

• Building redundancy: A partner bank can experience service interruption, change its commercial or compliance policy and decide to offboard specific customers, or in more rare occasions fail. For fintech companies relying on a unique partner bank, losing it means becoming instantly unable to deliver their services.

Each bank requires a new technical integration. Our experience shows significant differences in how banks implement connectivity and file messaging standards. 

Companies looking to integrate with multiple banks have limited options. They can copy and past bank integrations, and tweak them for each new bank and payment methods, adding code to integration developed specifically for other banks. This approach can work in the short term if banks’ connectivity channels are not too dissimilar but will ultimately prove not scalable. Or they can develop an abstraction layer to their bank integrations, which is challenging to design.

Considering the high upfront investment 

Bank integrations present a high upfront investment for companies. The learning curve can be steep, even for the best product & engineering teams. And it is not infrequent for a company to spend 3-6 months designing and developing a bank integration, even for the most payment-savvy teams. At Numeral, it took us three months to build our first bank integration and blueprint.

Bank integrations are also, unfortunately, mostly sunk costs. Since they rely on connectivity protocols and file formats that can be niche, the codebase created for the project usually has limited applicability to other parts of the company.

The hidden cost of bank integrations 

In addition to the visible complexity and direct costs of building bank integrations, several hidden costs derive from the decision to build a bank integration.

• Slower time-to-market: The back-and-forths required to identify and subscribe to the direct connectivity solutions and features to use and the time to receive the relevant documentation can delay the start of the integration specification. If not properly accounted for, those projects can result in delayed business initiatives and missed business opportunities.

• Maintenance and upgrades: Like any software, bank integrations require ongoing maintenance. Additionally, payment schemes and networks go through regular updates. For example, the European Payments Council, which governs SEPA, issues new rulebooks yearly. As a result, regular upgrades of bank integrations should be planned and budgeted to cope with these changes.

• Retaining teams and knowledge: Training teams on bank connectivity and payment file formats takes time and effort. There are very few domain experts in Europe and knowledge build and transfer needs to be a key consideration for the business.

The case for an API-first connectivity solution

At Numeral, we thought about how to step-change the experience of connecting with banks. And we believe a better path for a company with complex payment workflows is to lean on an API-first payment operations platform abstracting the complexity of the building. By relying on a well-documented API integrated with all banks, teams can

• Accelerate implementation projects: By abstracting away the diversity and complexity of bank integrations with a single RESTful API, companies can integrate with their banks in record time.

• Future-proof integrations: An abstraction layer continuously updates integrations as banks launch new payment methods and features, such as SEPA instant payments or virtual IBANs, or update their standards. This ensures no technical maintenance work is required.

• Enable their companies to focus on their core business and product: Companies can concentrate on their core business and product instead of becoming experts in bank connectivity and payment file formats while using a platform that enables them to be on the cutting edge of payment innovation.

• Turn high upfront costs into predictable variable costs: Companies can turn upfront investment costs and CapEx into variable costs and OpEx, making it easy to forecast costs and payment unit economics; benefiting from scale effects stemming from building multiple integrations also ensures economics make sense for the company.

In conclusion

This article has just covered the high-level concepts to consider when building bank integrations. Moving forward, we plan to share more content about specific payment schemes, banks connectivity solutions, and more. Subscribe to our newsletter to stay in the loop.

And if you are interested in learning more about Numeral and how our payments operations platform abstracts the complexity of building and maintaining direct bank integrations through a single API, do not hesitate to contact us.