The complexity and CapEx of building a payment automation software

As companies with payments at the core of their product or operations scale, so do their volumes of payments. When this happens, they often decide to replace their payment service providers or bank connectivity software with direct bank integrations. 

Direct bank integrations enable them to connect directly to their banks and integrate payments right into their products or systems. They give them increased control over their payments as well as improved unit economics. To be functional, they require a number of payment automation features to send, receive, and reconcile payments with the appropriate level of visibility and controls.

In this article, we break down the different components of an in-house bank integration and payment automation software. We then look at the development, maintenance, and hidden costs associated.

The five components of a bank integration and payment automation software

1. Bank connectivity

The first step to building bank integrations is to connect to banks to send payment instructions and receive payment reports and account reports. 

Depending on the bank, this might mean integrating an API or connecting to an SFTP file server to send and receive payment and bank report files. Companies must follow the bank’s specifications, which might follow (strictly or loosely) a standard such as ISO 20022 or be an entirely proprietary format, resulting in a specific format implementation for every bank. Payment regulators or schemes regularly enforce new rules and update their standards. For instance, the European Payments Council publishes new SEPA rulebooks every other year.

Communications with the bank must be encrypted and signed (e.g., PGP for file transfers and TLS and eIDAS certificates for APIs). Some banks might accept self-generated certificates, while others might require going through a specific certification authority.

Finally, bank integrations must be monitored. Bank servers might occasionally be down due to maintenance. Payment reports and account reports might be duplicated too. Failing to build a monitoring system could result in payment reconciliation issues, payments not going through, or payments being duplicated.

2. Payment workflows

Multiple key features are needed to automate payments throughout their lifecycle. Payment operations start with initiating payments and ends with reconciling them with bank account statements. In between, payment operations teams need to manage approval workflows and track payment statuses.

Payment initiation – Initiating payments requires collecting and verifying the payment instructions, including amount and currency, counterparty details, communication to the counterparty, and any relevant documentation or metadata.

Approval workflows – The next step is to approve the payment. Serious payment operations teams will typically have approval workflows that match their internal policies and controls to make sure that payments are reviewed and approved by the right persons within the company. Rules might be based on payment amount, daily payment limit, or payment type, to name a few. Payments might require a single or multiple approvals.

Payment status update – Once a payment has been approved, it can be sent to the bank to be processed. The payment is then either executed, rejected, or put on hold (for instance, for compliance review). The bank updates the customer with status updates delivered through file (most of the time) or API / webhook (rarely). Payment status updates can be reconciled with the corresponding payments through a combination of unique IDs or payment attributes.

Bank reconciliation – The final step of a payment is reconciling it with the corresponding bank account statement. Because payments are typically processed within 24-48 hours, they might not be posted on the account on the day their instructions are sent. Reconciling payments requires matching them with the corresponding bank account debits and credits, based on their ID, amount, description, counterparty details, etc.

Cut-off management – Because clearing and settlement mechanisms and banks do not operate 24 / 7 / 365, payments can only be processed the same day if they are received by banks before the daily cut-off. The exact timing depends on the bank, payment method, and clearing and settlement mechanism. Similarly, banks will have different rules and timings to generate and send payment reports and account reports. If they are not properly managed, bank cut-offs and timings can result in delayed payments and reconciliations.

Idempotency – Idempotency ensures that, regardless of human errors, software bugs, or network failures, payments are processed once and only once. Idempotency can be enforced through a number of mechanisms, including state machines and state transition controls, database mutual exclusions, or idempotency keys in API requests. 

3. Dashboard

Direct bank connectivity and automated payment workflows are the right way to scale payment operations. But there are tasks and times when human, manual interventions are necessary. It can be a rejected payment, a payment that was not automatically reconciled, or a new report to run.

As a company, you do not want your payment operations teams to play with your production databases or internal APIs. You also do not want your engineering teams to touch bank accounts and payments. What you need is a dashboard that connects to your production databases and calls your internal APIs.

In its most basic form, a dashboard has:

• A user and access control level management system that enables users to securely log in and manages fine-grained user accesses and logs

• A user interface that can accommodate large volumes of data, with tables as well as filtering, sorting, and search features

• Payment approval workflows and audit trails 

• Data export capabilities 

4. Performance and reliability

A bank integration and payment automation software must be built for scale and combine low latency, high availability, and high throughput. 100 ms latency, 99.9% availability, and 100 requests per second are considered to be industry standards when it comes to bank integration and payment automation software. These can be achieved through a combination of experience, sound software architecture, horizontally and vertically scalable infrastructure, extensive load tests, and tweaking.

5. Security

Security is paramount to a bank integration and payment automation software. Such software will store sensible bank credentials as well as confidential bank account and counterparty data. It will also be used to send, receive, and reconcile payments. Any security breach could have catastrophic consequences, including confidential data leaks, payment fraud, and stolen funds. 

Non-trivial security good practices include:

• Data encrypted in transit and at rest using advanced cryptography (e.g., TLS 1.2 and AES-256) 

• Bank credentials and certificates stored in a secret manager (e.g., AWS KMS or Google Cloud Secret Manager)

• Zero trust policy

• Logging of application events

• Vulnerability automatically tested as part of the CI / CD process

• Regular external penetration tests

The costs of building

Initial investment

Now that we have broken down the five different components of an in-house bank integration and payment automation software, let’s look at the required team, estimated timeline, and resulting cost.

Notes
1. Timeline from first piece of specification to software being developed, tested, and deployed in production
2. Based on an average €100,000 fully charged cost per employee per year, or €8,333 per month
3. Some streams of work can be parallelised, which means that the total duration of the project might be shortened to 8-10 months 

Maintenance and hidden costs

In addition to the initial investment, there are a number of maintenance and hidden costs to build, run, maintain, and upgrade a bank integration and payment automation software.

Maintenance cost – As with any software, bugs, new features, or increased usage might require significantly rework the existing product, code, and infrastructure. Edge cases that had a limited impact when payment volumes were small can no longer be ignored when payment volumes increase. Performance and reliability are the most critical to support the business as it scales, but also the most difficult to scale. It is not uncommon for maintenance to represent 20% of the initial development cost, bringing the total cost to €573,333 over 3 years and €716,667 over 5 years.

The cost of the umpteenth bank integration – €573,333 to €716,667 is the cost to develop and maintain a single bank integration. Depending on the bank, adding a payment method (for instance, SEPA instant payment) might require developing another bank integration. Developing another bank integration, whether to an existing bank or to a new bank, might require significant rework and code refactoring to abstract the inevitable differences. As it is not rare for a fintech company to have 3-5 partner banks, complexity and cost can compound quickly.

Other costs not factored in – In addition to these direct costs, a number of hidden costs should not be underestimated and can actually be crippling. Such hidden costs include:

• Lack of bank connectivity and payments expertise, resulting in errors, rework, and high cost of learning

• Cost of context switching, as project might be stopped due to dependency on other teams and banks 

• Cost of opportunity, i.e. not working on other initiatives

Numeral, your turnkey payment operations platform

Numeral enables companies to send, receive, and reconcile payments with their banks with a single API and web app.

Numeral turns a risky software development project and high upfront investment (CapEx) into a risk-free implementation project and predictable variable cost (OpEx). By mutualising the development cost of our 10+ integrations, Numeral also generates economies of scale for our customers in their payment operations that can be reinvested into the core business.