Bank connectivity is the set of technical channels through which a company, fintech or financial institution exchanges information with its banks: sending payment instructions, receiving confirmations and returns, and downloading statements and balances. The main channels are online banking portals, host-to-host file transfer, Swift messaging, the EBICS protocol used in parts of Europe, and bank APIs. Treasury teams, payment companies and finance-system vendors are the people who design and run it.
For a business with one bank account, connectivity is just a login. For a multinational with dozens of banks, or a payment company moving money for thousands of customers, it is a piece of banking infrastructure in its own right, usually managed through a treasury management system (TMS), an ERP system or specialist middleware. It is closely linked to corporate treasury work, because the quality of the connection decides how quickly treasury sees cash and moves it.
Bank connectivity in plain terms
There are many ways to talk to someone: visiting in person, phoning, posting a letter or using a private line installed just for the two of you. Each costs a different amount, takes a different time to set up and suits a different volume of conversation.
Companies face the same choice with their banks. A small firm logs into a website and clicks. A larger one sets up a dedicated pipe that sends hundreds of payments in one file every hour and receives statements automatically each morning. Bank connectivity is the choice and upkeep of those pipes.
Main connectivity channels
| Channel | How it works | Typical users |
|---|---|---|
| Online banking portal | Staff log in, key or upload payments and download reports | Small firms; backup for everyone |
| Host-to-host (H2H) | Files exchanged automatically, usually over SFTP, encrypted and signed | Companies with high volumes at a few banks |
| Swift | Standardised messages over the Swift network, directly or via a service bureau | Multinationals with many banks; financial institutions |
| EBICS | Standard file-transfer protocol with built-in signatures | Companies banking in Germany, France, Austria and Switzerland |
| Bank API | Real-time requests over HTTPS | Fintechs; companies needing instant data or payments |
Swift lets one connection reach many banks with the same message formats, which is its main attraction for groups banking across countries. Host-to-host links are bank-specific but cheap per transaction once built. A bank API gives the fastest feedback and supports instant rails, but each bank's API differs.
What flows over the connection
Outgoing traffic is mostly payment instructions: ISO 20022 pain.001 credit-transfer files, Nacha files for the ACH network, international wires and instant payments. Incoming traffic includes status reports (pain.002) that confirm or reject each instruction, return files, and statements and intraday updates through balance reporting in formats such as BAI2, MT940 or camt.053. The move to ISO 20022 gives richer, more consistent data across banks, which helps automatic bank reconciliation and cash positioning.
Choosing a connectivity model
The right mix depends on the number of banks and countries, payment volume, the need for real-time information, in-house technical skills and cost. A typical pattern is Swift or host-to-host for bulk payments and end-of-day statements, APIs for instant payments and live balances, and a portal kept as a fallback. Payment companies add direct links to their sponsor bank and to payout partners abroad. Some route everything through a payment orchestration or bank-agnostic hub so that adding a bank does not mean rebuilding every integration.
Security and operational resilience
Every channel is a route for moving money, so it attracts attackers. Standard controls include encryption in transit, digital signatures on payment files, dual approval of payments, strict access control and checks against changes to supplier bank details, the weak point exploited in payment diversion fraud. Payment instructions should carry unique references and idempotency protection so that a resent file is not paid twice.
Connectivity also carries operational risk: a broken certificate, an expired key or a bank outage can stop payroll. Firms keep a second channel ready and test failover. Banks and payment firms that rely on technology vendors for connectivity must manage third-party risk; in the EU, the Digital Operational Resilience Act has applied to financial entities since 17 January 2025 and sets rules for ICT risk management and oversight of technology providers, adding to the wider concern with cybersecurity risk.