# Treasury Bank Connectivity: SWIFT, Host-to-Host, API, EBICS

Source: https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-29
Reviewed: 2026-07-29
Summary: SWIFT, host-to-host, API and EBICS — how corporate treasury connects to banks, compared on reach, cost, real-time capability and setup effort.

**Corporate treasury connects to banks through four main channels — SWIFT, host-to-host, API and EBICS.** SWIFT gives multi-bank reach through one standardized connection; host-to-host is a direct, efficient link to a single bank; APIs bring real-time balances and payment status; and [EBICS is a regional standard](https://gravam.com/blog/ebics-european-bank-connectivity) used mainly in parts of Europe. There's no single best choice — you pick per bank and per need, and most treasuries run a mix. The important thing is not to confuse the _channel_ (how the message travels) with the _format_ (what it says).

## What bank connectivity does

Whatever the channel, connectivity does two jobs: bring **bank statements in** (so you can build the cash position and reconcile) and send **payment instructions out** (and get their status back). Everything below is a different way to move those two flows.

## SWIFT

SWIFT is the global bank-messaging network. For a corporate, connecting to SWIFT (directly or, often, through a service bureau or a bank's channel) means **one standardized connection that reaches many banks**. That's its strength: instead of a separate integration per bank, you speak one network. The trade-offs are cost and complexity — it's an investment that pays off when you have many bank relationships across regions, and is often overkill for a handful.

## Host-to-host (H2H)

Host-to-host is a **direct, secure file exchange between your systems and one specific bank** — typically automated file transfer (SFTP and similar). It's efficient and reliable for a small number of **strategic, high-volume** relationships: once set up, statements and payment files flow automatically. The catch is that it's **per bank** — every host-to-host link is its own setup, so it scales poorly across many banks.

## API

Bank APIs bring **real-time, request-response connectivity** — fetch a balance now, submit a payment and get its status immediately, rather than waiting for a batch file. They're the modern direction of travel and shine where **immediacy** matters: [intraday positioning](https://gravam.com/blog/real-time-treasury), instant payments, real-time status. Maturity and coverage still vary by bank, and like host-to-host, they're **bank-by-bank**, so breadth takes effort.

## EBICS

EBICS (Electronic Banking Internet Communication Standard) is a **bank-connectivity standard used mainly in parts of Europe** (notably Germany, France and neighbours). Where your banks support it, it's a standardized way to exchange statements and payments. Its relevance is largely regional — essential in some European landscapes, not applicable elsewhere.

## Comparison

|  | SWIFT | Host-to-host | API | EBICS |
| --- | --- | --- | --- | --- |
| **Reach** | Many banks, one connection | One bank per link | One bank per API | Banks supporting EBICS |
| **Mode** | Messaging / files | File exchange | Real-time request-response | Files / messaging |
| **Real-time** | Generally batch | Batch | Yes | Generally batch |
| **Best for** | Multi-bank, multi-region | Few high-volume banks | Immediacy: intraday, instant | European landscapes |
| **Effort / cost** | Higher setup; scales across banks | Per-bank setup | Per-bank; maturity varies | Regional standard |

## How to choose

Work from your bank landscape and needs, not a preference for one technology:

- **Many banks, many regions?** SWIFT's single multi-bank connection avoids integrating each bank separately.
- **A few strategic, high-volume banks?** Host-to-host is efficient and robust for those relationships.
- **Need real-time balances or payment status?** APIs, where your banks support them.
- **European banks that use EBICS?** Use it where it applies.
- **Reality:** most treasuries **combine** channels — SWIFT or a bank portal for breadth, host-to-host for a few core banks, APIs where immediacy pays.

## Where connectivity projects get stuck

- **Underestimating onboarding.** Every channel and bank is a setup with agreements, formats and testing; connectivity is [almost always the critical path](https://gravam.com/blog/why-tms-implementations-fail), not the software.
- **One channel for every bank.** Forcing all relationships through a single channel when a mix fits better — SWIFT for reach, H2H for the core few.
- **Confusing channel and format.** Agreeing "we'll use SWIFT" without settling the statement and payment formats (MT940, camt.053, pain.001) — you need both, per bank.
- **No monitoring.** A feed failing silently until a position is wrong or a payment is missed.

Pick channels per bank and need, agree the formats alongside them, start early, and monitor every link — and connectivity stops being the thing that holds go-live. It is also the clearest illustration of why capability is never the hard part: the difficulty lives in the joins between systems that were not designed to talk to each other, which is [equally true of enterprise AI](https://gravam.com/blog/why-enterprise-ai-is-an-architecture-problem). The security layer under all of it — certificates, keys, mTLS, OAuth and SWIFT CSP — is its own discipline: see [bank connectivity security](https://gravam.com/blog/bank-connectivity-security).

***

_See also the [reference architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury)._

## Primary sources

- Swift — Corporates (single channel to all your banks) — accessed 2026-07-29 — https://www.swift.com/corporates
- EBICS — Electronic Banking Internet Communication Standard — accessed 2026-07-29 — https://www.ebics.org/en/home
- Nordea — Account Statement Service MT940 file description — accessed 2026-07-29 — https://www.nordea.com/en/doc/2010-05-31accountstatementservicemt940en.pdf
- Nordea — Corporate Access MIG camt.053.001.02 (BankToCustomerStatement) — accessed 2026-07-29 — https://www.nordea.com/en/doc/caar-camt-053-001-02-account-statement-standard.pdf

## Questions this article answers

**Q: What is the difference between SWIFT, host-to-host and API bank connectivity?**

SWIFT is a shared network that reaches many banks through one standardized connection — good for multi-bank reach, higher in cost and complexity. Host-to-host is a direct, secure file exchange between your systems and one specific bank — efficient for a few high-volume relationships. API connectivity is real-time and modern, bank-by-bank, best where you need instant balances or payment status. EBICS is a standard used mainly in parts of Europe. Most corporates use a mix, chosen by bank and need.

**Q: Which bank connectivity method is best for corporate treasury?**

The best bank connectivity method depends on your bank landscape. If you deal with many banks across regions, SWIFT's single multi-bank connection is attractive. If you have a few strategic banks with high volumes, host-to-host is efficient. Where real-time balances or instant payment status matter, APIs are the direction of travel. In Europe, EBICS is common. There is no single best answer — most treasuries combine channels.

**Q: Is connectivity the same as file format?**

No — connectivity and file format are different things, and confusing them causes trouble. Connectivity is the channel — how the message travels (SWIFT, host-to-host, API, EBICS). The format is the content — what the message says (MT940 or camt.053 for statements, pain.001 for payments). You choose a channel and a format per bank, and both have to be agreed and tested.