Bank integration

We work with the ISO 20022 messages banks use for corporate payments and reporting: pain.001 for payments, pain.002 for status, and camt.052, camt.053 and camt.054 for account reports. We also handle the SWIFT MT940 and MT942 statements many banks still send. For transport we use host-to-host SFTP, EBICS where banks offer it, and bank APIs. Each bank has its own variant of each format, so we build from the bank’s implementation guide, not from the standard alone.

We connect banks to SAP S/4HANA, Oracle NetSuite, Oracle Fusion Cloud ERP, Microsoft Dynamics 365, Odoo and Sage, and to treasury and custom systems. Some ERPs have their own bank communication modules. Where they do, we configure and extend them rather than build around them. Naming a product here does not mean a partnership with its vendor.

It depends mostly on the bank, not on the code. Each bank sets its own onboarding steps, test windows and approvals, and some need contracts or key exchanges before testing can start. The number of banks, payment types and countries matters too. After the mapping step we give you a plan per bank, and we start testing with whichever bank is ready first.

The number of banks and channels, the payment types and countries in scope, how much your ERP already supports, and how complex your matching rules are. Signing and encryption requirements and each bank’s test process add effort. We estimate per bank and per flow after discovery, so you can phase the work and its cost.

Payment files are signed and encrypted as each bank requires, for example with OpenPGP, and travel only over the agreed channel. Keys and certificates are kept in your key vault or hardware security module, never in code, and only named people can reach them. Files are validated before they are sent, and every transfer is logged, so you can trace who approved and sent each payment.

It goes to a review list with the likely candidates and the reason it did not match, such as a difference in amount or a missing reference. Your team clears it there, and the rules can be adjusted so the same case matches next time. Nothing is posted to the ledger without a match that you approved.

Banks announce format changes in advance, as many did when moving from SWIFT MT to ISO 20022 messages. We follow those notices for the banks we connect, assess the impact, and schedule the change and its tests with the bank before its deadline. This can be part of a support agreement.

Intellectual property in the work we build for you is yours from the first commit — no assignment step at the end. That covers the custom code, documentation and other deliverables made for you. Anything we bring that existed before, such as internal tools or libraries, stays ours, and you receive a licence to use it in your systems. Open-source components keep their own licences, and we list them for you.