# 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-10-04
Reviewed: 2026-10-04
Summary: SWIFT, host-to-host, API and EBICS — how corporate treasury connects to banks. Host-to-host vs corporate SWIFT compared on reach, cost and who runs it.

**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. The comparison most corporates face is host-to-host versus corporate SWIFT: host-to-host is a private file link built bank by bank, corporate SWIFT is one network connection — your own or a service bureau's — that reaches all your banks. 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. SAP-centred landscapes have a managed variant of the one-connection idea: [SAP Multi-Bank Connectivity](https://gravam.com/blog/sap-multi-bank-connectivity) runs member-bank, host-to-host, EBICS and Swift connections behind a single connector in the ERP.

## 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.

## Host-to-host vs SWIFT for corporates

This is the comparison most corporates actually face, because it is the choice for the bulk flows — statements in, payment files out. Both carry the same files in the same formats. What differs is the shape of the cost: host-to-host is cheap per connection and multiplies with every bank; SWIFT has a fixed cost up front and adds banks at little extra connection effort.

|  | Host-to-host | SWIFT for corporates |
| --- | --- | --- |
| **What it is** | A private file connection to one bank, built to that bank's specification | One connection to a shared network, reaching every bank you have an agreement with |
| **Reach** | One bank per connection | Many banks through one connection |
| **Who operates it** | You and the bank, each maintaining your end | You (own Swift connection) or a service bureau on your behalf |
| **Fixed cost** | Low — no network membership | Higher — Swift membership, the connection or bureau fees, security obligations |
| **Cost per extra bank** | A new build each time: bank specification, keys, testing | Lower on the connection side; formats and bank onboarding still per bank |
| **Standardization** | Bank-proprietary channel; formats as the bank offers them | Standard channel and messaging services; formats still agreed per bank |
| **Makes sense with** | A few strategic, high-volume banks | Many banks across regions |

### How a corporate connects to SWIFT

"Corporate SWIFT" is not one product; it is a few decisions, and it helps to keep them apart.

- **The corporate-to-bank environment is SCORE.** Swift describes the Standardised Corporate Environment as a closed user group it administers, in which corporates interact with financial institutions. It offers three transfer mechanisms — FIN, FileAct real-time and FileAct store-and-forward — and a corporate subscribes to the ones its banks support. In treasury terms: FIN carries individual messages such as [MT940 statements](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2), and FileAct carries files, which is how ISO 20022 statements and bulk payment files usually travel. For a corporate that loses its SCORE eligibility, Swift names a member-administered closed user group (MA-CUG) — one run by an individual bank — as the alternative.
- **The connection is either yours or shared.** A corporate can connect directly, or use what Swift calls indirect or shared connectivity through a service bureau — a third party that runs the Swift infrastructure for several customers. Swift's Shared Infrastructure Programme sets the legal, financial and operational requirements those bureaux must meet, and Swift inspects against them; the bureau remains responsible for its own service.
- **Alliance Lite2 is no longer the entry route.** For years a common answer for a corporate wanting its own low-footprint connection was Alliance Lite2. Swift now states that Alliance Lite2 is available to existing clients only and points new customers to Alliance Cloud. If a proposal or an older article recommends Lite2 for a new connection, check it against Swift's current page.

What I can't give you from a primary source is a price or a bank-count threshold: Swift does not publish one on these pages, and bureau pricing is commercial. The rest of this section is general practice, not Swift's statement.

### How many banks before SWIFT makes sense

There is no official number. The reasoning is arithmetic: every host-to-host connection is a separate build and a separate thing to maintain — its own specification, its own keys and certificates to renew, its own testing whenever either side changes — so the effort grows in a straight line with the number of banks. SWIFT's cost is mostly fixed and shared across them.

- **A handful of banks carrying most of the volume:** host-to-host to each is usually simpler and cheaper, and nothing is gained by joining a network to reach them.
- **A growing or scattered bank landscape:** the point arrives where maintaining one more private connection costs more than adding one more bank to a network connection you already run. That is when SWIFT, directly or through a service bureau, earns its fixed cost.
- **Both at once** is common and reasonable: host-to-host to the two or three core banks, SWIFT for the long tail. Before building either for a bank with one small account, ask whether the account should exist — [rationalizing accounts](https://gravam.com/blog/bank-account-rationalization) removes connections that never have to be built.

One caveat applies to both: neither removes per-bank onboarding. SWIFT standardizes the channel, not the content, so each bank still has its own format variant, its own agreement and its own test cycle — which is why a [payment hub](https://gravam.com/blog/payment-hub-vs-payment-factory) or a TMS still sits between the ERP and either channel, and why every link needs [monitoring](https://gravam.com/blog/interface-monitoring-and-reconciliation) whichever route it takes.

## 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. The [EBICS explainer](https://gravam.com/blog/ebics-european-bank-connectivity) covers the channel, and the [order types reference](https://gravam.com/blog/ebics-order-types-and-btf) the codes a bank's parameter sheet is written in.

## 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](https://gravam.com/blog/mt940-format-tags-explained), 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-10-04 — https://www.swift.com/corporates
- EBICS — Electronic Banking Internet Communication Standard — accessed 2026-10-04 — https://www.ebics.org/en/home
- Nordea — Account Statement Service MT940 file description — accessed 2026-10-04 — https://www.nordea.com/en/doc/2010-05-31accountstatementservicemt940en.pdf
- Nordea — Corporate Access MIG camt.053.001.02 (BankToCustomerStatement) — accessed 2026-10-04 — https://www.nordea.com/en/doc/caar-camt-053-001-02-account-statement-standard.pdf
- Swift — SCORE (Standardised Corporate Environment): closed user group, services and eligibility — accessed 2026-10-04 — https://www.swift.com/myswift/ordering/order-products-services/score
- Swift — Shared Infrastructure Programme (service bureaux) — accessed 2026-10-04 — https://www.swift.com/about-us/swift-partner-programme/find-partner/shared-infrastructure-programme
- Swift — Alliance Lite2 (existing clients only; Alliance Cloud) — accessed 2026-10-04 — https://www.swift.com/products/lite-2

## 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: What is the difference between host-to-host and corporate SWIFT connectivity?**

Host-to-host is a private, direct file connection between a company's systems and one bank, built to that bank's specification and repeated for every bank. Corporate SWIFT connectivity is one connection to the Swift network that reaches every bank the company has an agreement with; corporates exchange FIN messages and FileAct files with banks through SCORE, the closed user group Swift administers for corporate-to-bank traffic. Host-to-host has no network membership and little fixed cost, but its effort multiplies with each bank. SWIFT has a fixed cost — membership, the connection or a service bureau, and security obligations — that is shared across all banks. Host-to-host therefore suits a few high-volume banks, and SWIFT suits a landscape of many banks. Either way, formats and onboarding are still agreed bank by bank.

**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.