Host-to-Host (H2H)

Host-to-host (H2H) is a direct, automated connection between a company's own systems and the systems of its bank. Payment instructions are generated in the company's accounting or treasury software and delivered to the bank's server without anyone logging in to an online banking portal, and the bank sends back acknowledgements, status reports and account statements over the same link. The word host refers to the server on each side.

The arrangement is used by companies that make payments in volume: payroll runs, supplier payments, insurance claims, refunds and payouts. It sits between manual online banking, which suits small numbers of payments, and a full connection to a network such as Swift, which suits groups dealing with many banks. Payment service providers also use host-to-host links to their settlement banks to submit outgoing transfers and collect incoming credit reports.

A typical flow begins in the company's enterprise resource planning system or treasury management system, where approved payments are collected into a file. The file is encrypted, digitally signed and placed on a secure channel to the bank. The bank's gateway checks the signature, validates the format, and passes each instruction to its payment engine, which routes it to the right scheme, for example ACH, SEPA Credit Transfer, a domestic instant scheme or a wire transfer.

Information then flows back. The bank returns a file-level acknowledgement, a status report for each payment showing whether it was accepted or rejected, and end-of-day or intraday statements. The company's system reads these files and updates its ledger, which is the basis of automated reconciliation.

The transport is usually SFTP, with files additionally encrypted and signed using PGP keys exchanged during setup. Some banks offer AS2 or HTTPS-based file transfer, and banks in Germany, France, Austria and Switzerland commonly use the EBICS protocol for the same purpose. Access is restricted to agreed network addresses, and keys are rotated on a schedule.

The content of the files follows agreed formats:

• ISO 20022 XML. The pain.001 message carries payment instructions, pain.002 carries status reports, and camt.053 carries end-of-day statements. These are the most widely supported formats for new connections.
• National formats. A United States bank may accept a Nacha-formatted ACH file, and other countries have their own legacy layouts.
• Legacy statement formats. MT940 and BAI2 statements remain in use for balance and transaction reporting.
• Bank-specific formats. Some banks define their own delimited or fixed-width layouts, which increases the mapping work.

A host-to-host project is run jointly by the company and the bank and typically takes several weeks to several months. The parties agree the services in scope, sign a connectivity agreement, exchange encryption keys and network details, and map the company's data to the bank's format. Test files are sent to the bank's test environment until every payment type, error case and return file behaves as expected, followed by a small live test, sometimes called a penny test, before full volumes are switched over.

Approval controls need attention because the bank acts on the file as received. Companies normally enforce payment approval inside the source system, restrict who can change the file after approval, and may ask the bank to hold files above a set value until a second person releases them through the bank's portal.

Host-to-host is a batch, file-based method. It handles thousands of payments in one file efficiently, but status information arrives only when the bank generates the next report. A bank API works one payment at a time and returns an immediate answer, which suits instant payments and balance checks, though not every bank offers one and coverage of payment types varies. Many companies run both: files for payroll and supplier runs, treasury API calls for urgent payments and real-time balances.

A company with many banking relationships faces a different problem: each host-to-host link is built separately, with its own format rules and security setup. Corporate access to Swift, or a service bureau that connects to many banks on the company's behalf, replaces multiple bilateral links with a single channel. Groups that centralise payments in a payment factory often choose this route.

The main costs are setup effort and maintenance. Formats change, keys and certificates expire, and a bank migration to a new platform can require retesting. A broken connection or a rejected file can delay a payroll, so companies keep a fallback, usually manual upload through the bank's portal. Because a file can carry very large total values, a compromised source system is a serious fraud risk, which is why segregation of duties, file-level digital signatures and bank-side limits are standard controls. Duplicate submission of the same file is another known failure, addressed through unique file identifiers that the bank checks before processing.