What is Host-to-Host bank connectivity?

Host-to-Host is a direct, encrypted connection between your company's host system (typically an ERP, TMS, or middleware platform) and your bank's host system. Files move in both directions: payment instructions out, status messages and account statements back, on a schedule, without anyone logging into a bank portal.

The "host-to-host" name is literal. Two systems talk to each other directly, authenticated by cryptographic keys that the bank has on file, over a protocol the bank has formally agreed to support.

A typical H2H setup has three moving parts. First, a transport protocol, usually SFTP, EBICS, or AS2, that defines how files are pushed and pulled. Second, a set of permanent cryptographic keys (RSA or PGP) that identify your company to the bank and sign every message. Third, file formats, almost always ISO 20022, that describe what is in each file: payment instructions, status reports, account statements.

Your ERP generates a pain.001 payment file, the connectivity layer signs and uploads it to the bank, the bank returns a pain.002 status, and a camt.053 statement lands the next morning. The same loop runs every day, often unattended.

In most finance teams, H2H replaces three things at once: someone exporting a payment file from the ERP, someone logging into a bank portal to upload it, and someone downloading the statement the next day to import back. That entire chain becomes a single automated handoff.

It also replaces the patchwork of bank-specific tools that build up over time: one bank's desktop client, a second bank's web portal, a third bank's spreadsheet template. H2H gives you one connection per bank, all speaking the same file formats.

You need H2H when payment volume, frequency, or audit requirements have outgrown manual portal use. Daily payment runs, payroll, supplier batches, direct debit collections, and intercompany transfers all push teams past the point where a person uploading files is tenable.

You don't need H2H if you process a handful of payments per month and your bank's portal is fine. The ROI on H2H comes from removing repetitive work and eliminating manual errors at scale. If there is no scale, there is no payoff.

Open Banking APIs (PSD2) are sometimes pitched as a modern replacement for H2H. They are not. They were built for consumer apps and developer-facing fintechs, with a 90-day re-authentication requirement and no native four-eyes approval. For unattended corporate payment runs, those constraints are dealbreakers.

The detailed comparison sits here: Open Banking vs Host-to-Host.

H2H setup is a one-time effort, not a continuous one. The bank issues an agreement, you exchange public keys, the bank enables the channels you need (payments, statements, direct debits), and you run a test cycle. After that, the connection is permanent.

The complexity is mostly on the bank side: every bank has its own portal, its own key formats, its own quirks in how it interprets ISO 20022. A connectivity layer absorbs that so your ERP doesn't have to.

BankConnector is the H2H connectivity layer between your ERP and your bank. It manages the keys, the transport protocol, and the ISO 20022 file generation, and returns status confirmations and statements directly into your ERP. Supported banks span Denmark, Germany, the Netherlands, Sweden, Norway, and the UK.