A treasury team rarely has one connectivity requirement. It needs opening and intraday balances, prior-day statements, payment instructions, bank acknowledgements, rejection detail and a route for investigations. Those flows may involve different banks, message formats, cut-off times and control owners.
That is why “API versus SWIFT versus host-to-host” is the wrong unit of analysis when it is asked once for the whole company. The useful question is which connection should carry each flow, what evidence the bank can provide, and how the design behaves when a channel or credential fails.
Quick answer
The lowest-risk design usually preserves a standard file or SWIFT baseline for broad coverage while adding APIs only where they deliver verified operational value.
Decision: Assign each treasury flow to API, SWIFT, host-to-host or a mixed design only after confirming bank coverage, timing, controls, acknowledgements, fallback and lifecycle ownership.
Key takeaways
- Separate the connectivity channel from the message format, payment rail and treasury application before comparing options.
- Select a route for each flow: balances, statements, payment initiation, acknowledgements and exceptions may need different answers.
- An API is only as current, complete and available as the specific bank service behind its endpoint.
- SWIFT can reduce the number of corporate connection patterns, while direct host-to-host links preserve bank-specific capability at the cost of more bilateral maintenance.
- Do not approve a channel without defined status messages, duplicate protection, recovery, monitoring, access control and operating ownership.
API, SWIFT and host-to-host at a glance
| Decision dimension | API | SWIFT | Host-to-host |
|---|---|---|---|
| Connection model | A software interface to a named bank or network service. | A financial-messaging environment through which a corporate can exchange supported messages with participating banks. | A direct corporate-to-bank connection, commonly using scheduled or event-driven file exchange. |
| Coverage pattern | Broad only where the required banks, accounts and services expose suitable endpoints. | Strong multi-bank reach, subject to corporate eligibility, bank participation and supported services. | Deep coverage with the connected bank, but each additional bank normally needs a separate bilateral setup. |
| Typical timing | On demand or event-driven where the service and bank processing support it. | Depends on the selected messaging service, bank process and message flow; it is not automatically real time. | Usually scheduled batches, although frequency and triggering are bank-specific. |
| Strongest fit | Intraday data, status checks, pre-validation and time-sensitive actions with confirmed bank support. | Standardised multi-bank payment and reporting flows, especially across a broad bank estate. | High-volume or bank-specific file flows with predictable formats and established operating windows. |
| Control burden | Tokens, certificates, keys, scopes, signatures, versioning, rate limits and retry behaviour. | Swift security controls, user and service governance, message validation, access and operational monitoring. | Bank-specific keys, folders, file controls, cut-offs, acknowledgements, retention and replay procedures. |
| Change and maintenance | Endpoint, schema, authentication and bank-service changes. | Network, service, standards and bank-implementation changes. | Separate bank onboarding, format mapping, certificate or key renewal and file-schedule changes. |
| Main cost drivers | Development, testing, security operations, API or platform fees and support. | Onboarding, connectivity or service-bureau charges, messaging, security and support. | Per-bank implementation, mapping, testing, monitoring, support and future change work. |
| Avoid as the sole route when | Coverage is incomplete, data semantics are unclear, or the bank cannot evidence service and recovery behaviour. | The required bank or use case is unsupported, or the operating model cannot carry the governance overhead. | The bank estate is large and the team cannot own many bilateral connections and formats. |
The table is a starting point, not a verdict. A route that looks attractive at channel level can fail at account, country, message or acknowledgement level. The bank capability schedule and end-to-end test evidence should decide the production design.
First separate the channel from the message and payment rail
Bank connectivity is the controlled exchange of data and instructions between a corporate system and its banks. It is not the same as a payment rail, a message standard or a treasury application.
- SWIFT is a messaging environment. Swift explains that it carries payment instructions but does not move the money itself. Settlement still occurs through banks, market infrastructures and other institutions.
- Host-to-host is a direct connection pattern. It commonly carries files between a corporate and one bank. The categories can overlap: Swift’s comparison of FINplus and FileAct describes FileAct as a proprietary host-to-host channel between corporates and banks.
- An API is an interface to a defined capability. One endpoint may return balances, another may initiate a payment and another may report status. Buying “API connectivity” does not prove that every required function exists.
- ISO 20022 is a message standard. The ISO 20022 message catalogue includes payment-initiation and status families such as pain.001 and pain.002, and cash-reporting families such as camt.052, camt.053 and camt.054. Those messages can be carried through more than one channel.
This separation prevents a common architecture error: comparing an API transport with an ISO 20022 message or treating SWIFT as the payment rail. The selection record should name the channel, service, message or payload, bank, account scope, processing window and receiving system separately.
What each option gives treasury
APIs: approve a capability, not a label
APIs are strongest when treasury needs an on-demand request, an event notification or a rapid status check. They can remove the wait for the next file cycle, but only when the bank’s service, source system and endpoint all support the promised timing and data scope.
For example, Swift states that its Instant Cash Reporting API can return account balances, statements, debit and credit entries, pending and booked items, and date-time queries. The same product page says a corporate cannot obtain data from a bank that is not participating as a data provider. That limitation is the practical point: “real time” is a property of the complete bank service, not of the three letters API.
API coverage is also use-case specific. Swift’s API Channel overview, for example, lists tracking, pre-validation and case-resolution services. A treasury team should therefore build a capability inventory by endpoint rather than mark a bank simply “API available.”
The security model creates recurring operations. J.P. Morgan’s mTLS guidance shows that a bank API may require client certificates, private keys and digital signatures. Its OAuth documentation also separates test and production credentials and tells clients to renew certificates before expiry to prevent interruption. These are bank-specific examples, not universal rules, but they show why certificate ownership, key custody, renewal alerts and emergency replacement belong in the operating design.
Use an API when the named bank and service meet the required coverage, timing, data, status and recovery tests. Do not use it as the only route merely because the interface is newer or because a provider describes its platform as API-first.
SWIFT: one corporate access model, several services
SWIFT is attractive when a corporate wants a governed multi-bank access model rather than a separate technical pattern for every bank. Swift’s corporate page describes a single channel for communicating with banks and connecting back-office systems. Under the Standardised Corporate Environment, or SCORE, corporates and financial institutions operate in a closed user group, and Swift says participants can subscribe to one or more transfer mechanisms according to business needs and counterparty offerings.
That does not make every SWIFT flow identical. FINplus supports ISO 20022 messaging with network and message validation, while FileAct relies more heavily on bilateral agreements for the content carried in files. Timing, validation and acknowledgement behaviour must therefore be documented for the selected service and bank, not inferred from the SWIFT name.
SWIFT also brings a formal security environment. The Customer Security Controls Framework groups controls around securing the environment, limiting access, and detecting and responding to anomalous activity. A corporate must determine which controls apply to its setup and retain evidence that the operating model meets them.
Use SWIFT when multi-bank reach, common governance and standardised messaging justify the onboarding and control model. Do not assume that it removes bank-level testing, bilateral service agreements or the need to define how rejected and delayed messages are handled.
Host-to-host: direct, bank-specific and operationally explicit
Host-to-host is often implemented as file exchange between a corporate system and a bank gateway. It can support much more than payment uploads. As one official bank example, CitiConnect describes file transmission and translation for payments, receivables and information, with multiple formats, balance reporting, transaction repair, acknowledgements and reporting features.
The strength of H2H is that the parties can define a detailed bilateral process around a core banking relationship. The same strength creates its maintenance load. Each bank may use different endpoints, encryption or signing rules, file names, folders, cut-offs, status files, retention periods and support procedures. The treasury design must make those differences visible instead of hiding them behind a single “H2H” status.
Use host-to-host when a bank-specific file service meets a material volume or capability need and the organisation can own its lifecycle. Do not reject it merely as old technology if it has tested service levels, complete acknowledgements and a credible recovery process.
Select connectivity by treasury flow
The architecture decision should be made row by row. The following framework identifies a likely starting point, not a mandatory product choice.
| Treasury flow | Required outcome | Likely starting point | Evidence required before approval |
|---|---|---|---|
| Balances and intraday position data | Known freshness, available and ledger balances, booked and pending status, account coverage and timestamps. | API where participating banks support the required fields and response times; SWIFT or H2H reporting as the broad-coverage baseline. | Account-level coverage, source timestamp, refresh behaviour, pending-item treatment, pagination, history, outage response and reconciliation to the bank statement. |
| Prior-day and end-of-day statements | Complete, replayable records for reconciliation, posting, evidence and close processes. | SWIFT or H2H files where they provide stable scheduled delivery; API only when history, completeness and replay are proven. | Message or file version, sequence controls, opening and closing balance logic, duplicate handling, retention, re-delivery and control totals. |
| Payment initiation | Authorised instructions delivered before cut-off with duplicate protection and traceable bank acceptance. | SWIFT for broad multi-bank messaging; H2H for core-bank batch flows; API for supported time-sensitive or individual instructions. | Payment types and currencies, batch limits, cut-offs, approval boundary, signing, idempotency, validation, acceptance stages, reject reasons and fallback route. |
| Acknowledgements and payment status | A state model that distinguishes technical receipt, format validation, bank acceptance, execution, rejection and return. | The route that provides the most complete, timely and machine-readable status for the corresponding payment flow. | Every status code and timestamp, correlation identifiers, pain.002 or proprietary mapping, final-state definition, late updates and escalation ownership. |
| Exceptions and investigations | Enough structured detail to assign, correct, resubmit, cancel or investigate without losing the audit trail. | API case or tracking services where supported; SWIFT messages or H2H reject and repair files where those are the bank’s authoritative channel. | Reason-code detail, attachment or narrative limits, case identifiers, response deadlines, manual hand-off, resubmission controls and evidence retention. |
Do not infer message support from a standard alone. Swift’s corporate ISO 20022 guidance states that cash reporting can cover camt.052, camt.053 and camt.054, while its current roadmap still treats some corporate flows separately. The bank’s implementation guide and test pack remain the controlling evidence for the accounts and services in scope.
When those feeds supply a near-term liquidity process, the 13-week cash flow forecast control model defines how opening cash, cut-offs, forecast inputs and actual movements should be governed.
A six-step selection framework
Inventory the bank estate by flow. List every legal entity, account, bank, country, currency, current channel, source system and required service. Mark which flows are inbound data, outbound instructions or two-way status exchanges. The Revolut Bank S.A. migration shows why the register also needs effective dates and old-to-new entity and account mappings before cutover.
State the service requirement in measurable terms. Define freshness, delivery window, maximum recovery time, completeness, history, batch size, cut-off, availability window and support response. “Real time” is not measurable until the bank supplies a timestamp definition and target.
Verify message and status semantics. Obtain the bank’s implementation guide, message versions, required and optional fields, status codes, error examples and test cases. Map every acknowledgement to the treasury or payment state it changes.
Design access and approval controls. Assign credential custody, certificate renewal, user administration, segregation of duties, payment approval, signing, emergency access, logging and periodic access review. The channel should not weaken the authorisation model already approved for the payment process.
Test failure and recovery before volume. Simulate a timeout, duplicate request, delayed status, corrupted file, expired credential, bank outage and partial batch rejection. Confirm whether a retry is safe, how the transaction is correlated and which record is authoritative.
Model the full operating cost and assign an owner. Include implementation, bank onboarding, network or intermediary charges, message or service fees, format mapping, security operations, monitoring, support, testing, upgrades and exit work. Record who funds and owns each item after the project closes.
Score options only after these six records exist. A weighted score without bank-specific evidence produces a precise-looking answer to an unverified question.
When a mixed architecture is justified
A mixed architecture is justified when one route cannot meet the coverage, timing or service needs of all material flows. One example is API access for intraday balances at participating core banks, SWIFT for broad multi-bank reporting and payments, and H2H for a strategic bank’s high-volume or proprietary file service. That is an architecture pattern, not a default recommendation.
Adding channels also adds failure modes. Treasury needs one control model across them:
| Control | Minimum design requirement |
|---|---|
| Routing register | One approved primary route and any fallback for each bank, account, payment type and data flow, with effective dates and owners. |
| Canonical identifiers | Stable transaction, batch and message identifiers that survive channel changes and prevent the same instruction being sent twice. |
| Common status model | A controlled mapping from channel-specific responses into receipt, validation, acceptance, execution, rejection, return and investigation states. |
| Control totals and reconciliation | Counts and values compared at creation, transmission, bank acceptance and posting, with documented treatment of partial batches. |
| Fallback rule | Named authority to activate fallback, objective trigger, duplicate check, approval requirement and a controlled return to the primary route. |
| Monitoring and incident ownership | End-to-end alerts for missed files, failed calls, delayed statuses, expiring credentials and unreconciled items, routed to an accountable team. |
| Change calendar | Bank, network, message, certificate and system changes assessed together, with regression testing and rollback evidence. |
Do not configure two active payment routes as informal substitutes. Without a routing authority, idempotency control and a shared status model, “resilience” can become duplicate execution or an unresolved payment state.
Approval checklist for the treasurer
- Coverage is confirmed by legal entity, account, currency, bank service and environment, not by bank name alone.
- Every balance and transaction field has a defined source timestamp, status and completeness rule.
- Payment initiation has documented validation, authorisation, signing, cut-off, duplicate and fallback controls.
- Acknowledgements distinguish technical receipt from bank acceptance and final execution.
- Exceptions carry enough reason detail and identifiers for controlled repair, resubmission or investigation.
- Credentials, certificates, keys, user roles and emergency access have named owners and renewal procedures.
- Outage, retry, replay and partial-failure tests have passed with evidence retained.
- Monitoring covers the complete path from ERP or TMS through the channel to bank response and downstream posting.
- The cost model includes implementation and steady-state operations, not only the quoted connection fee.
- The exit plan explains how data, message history, credentials and bank mandates move if a provider or channel changes.
The architecture is ready for approval only when every material flow has an accountable owner, bank-supported capability, defined status path, recovery method and measurable service requirement.
Frequently asked questions
Does using a bank API make a treasury process real time?
An API does not make a treasury service real time by itself. On-demand data may still depend on bank participation, service coverage, upstream processing and downstream posting, so treasury should test the complete path for each balance, statement, payment status and exception flow rather than approve the API label.
When should treasury use a mixed connectivity architecture?
A mixed connectivity architecture is justified when different treasury flows require different bank-supported capabilities and the organisation can govern them through one routing register and status model. The design still needs common identifiers, reconciliation, fallback rules, monitoring and change ownership; multiple routes without that control layer can create duplicate execution or unresolved states.
What security controls can bank APIs require?
Bank API operations can require mutual authentication, certificates, private keys, digital signatures, tokens and environment-specific credentials. Treasury should assign owners for issuance, storage, access, renewal and emergency use, then test those controls alongside the payment and data flow. Secure transport alone does not prove authorised action or end-to-end recovery.
