Bank Connectivity: SWIFT, Host-to-Host and APIs

1. Why Bank Connectivity Matters to Treasury (and to the CTP Exam)

Every treasury process – cash positioning, payments, reconciliation, liquidity forecasting, fraud control – depends on moving information between the company and its banks. Bank connectivity is the set of technical channels through which a corporate's Treasury Management System (TMS), ERP or payment hub exchanges balance reports, transaction detail, payment instructions and acknowledgements with banks. Poor connectivity means late balance data, manual re-keying, higher error and fraud risk, and an inability to see global cash. Strong connectivity enables straight-through processing (STP), a single daily global cash position, centralized payment factories and real-time decision-making.

On the AFP CTP exam this topic sits inside the Technology in the Treasury Function domain (closely linked to the Treasury Management Systems and Payments chapters of Essentials of Treasury Management). Questions typically test whether you can (a) identify the four main connectivity channels, (b) match a channel to a business scenario, (c) recognize SWIFT message types and ISO 20022 terminology, and (d) understand the security, cost and control trade-offs. It is a high-yield area because it overlaps with payments, information reporting, fraud prevention and systems selection.

2. What Bank Connectivity Is – The Four Main Channels

a) Bank Proprietary Portals (web/online banking)
Browser-based access provided by each individual bank. Users log in, view balances, approve payments and download reports manually. Low cost and quick to implement, but each bank has its own portal, log-in, security token and file format. Manual, not scalable, weak audit trail across banks, and data must be downloaded and uploaded into the TMS/ERP. Appropriate for small companies or low-volume relationships.

b) Host-to-Host (H2H) / Direct File Transfer
A dedicated, automated machine-to-machine link between the corporate's system (ERP, TMS, payment hub) and a single bank's system. Files are pushed and pulled on a schedule using secure transport protocols such as SFTP, FTPS, AS2 or HTTPS, often across a VPN or leased line. Formats may be bank-proprietary, BAI2, EDI (ANSI X12 820/822, EDIFACT) or ISO 20022 XML. Key traits: highly automated, high volume, batch-oriented, excellent for a deep relationship with one bank. Weakness: it is bilateral – each bank requires its own build, testing and maintenance, so costs multiply as the number of banks grows, and changing banks means rebuilding the connection.

c) SWIFT (Society for Worldwide Interbank Financial Telecommunication)
A member-owned cooperative headquartered in Belgium (founded 1973) that operates a secure, standardized, global financial messaging network (SWIFTNet). Critical exam point: SWIFT does not hold accounts, clear or settle funds – it only transmits standardized, authenticated messages between financial institutions and, since the late 1990s/2000s, corporates. Settlement happens through correspondent banks and clearing systems (Fedwire, CHIPS, TARGET2, CHAPS, etc.). Participants are identified by a BIC (Bank Identifier Code, ISO 9362, 8 or 11 characters). SWIFT gives a corporate a single, bank-agnostic window to all of its banks worldwide.

d) Application Programming Interfaces (APIs)
Real-time, request/response (or event-driven) connections in which the corporate system calls a bank's published API (usually REST over HTTPS with JSON payloads, secured by OAuth 2.0, mutual TLS and API keys). Instead of waiting for a scheduled file, the TMS can query a balance on demand, initiate a payment and receive instant status, or receive a webhook notification when a transaction posts. APIs are the newest channel, accelerated by open banking regulation (PSD2 in the EU, UK Open Banking) and by instant payment schemes (RTP, FedNow, SEPA Instant). Weakness: limited cross-bank standardization (each bank's API differs, though ISO 20022 data models and industry groups are narrowing the gap), bank-by-bank implementation, and dependence on the bank's API maturity.

3. How SWIFT Works in Detail

Corporate access models. Corporates do not join SWIFT as banks do; they join through special programs:
• MA-CUG (Member Administered Closed User Group) – the original model; a bank sponsors the corporate and the corporate can communicate only with that bank. Multiple banks = multiple MA-CUGs.
• SCORE (Standardised Corporate Environment) – the dominant model today; a single membership lets a listed/qualifying corporate exchange messages with all SCORE-participating banks. This is what delivers true multi-bank connectivity.
• TRCO (Treasury Counterparty) – for FX/money market confirmation exchange with counterparties.

Connectivity options (how the corporate physically reaches SWIFTNet).
• Direct connection – the corporate installs SWIFT Alliance Access/Gateway hardware and software on-site. Most control, highest cost and IT burden.
• SWIFT Service Bureau – an outsourced, SWIFT-certified third party hosts the infrastructure and connects many corporates; the corporate pays a fee and avoids in-house expertise. Must comply with SWIFT's Shared Infrastructure Programme.
• Alliance Lite2 – SWIFT's own cloud-based, lighter-weight connection for lower-volume users, typically using a USB security token.
• Lite2 for Business Applications (L2BA) – Alliance Lite2 embedded inside a TMS or ERP vendor's offering, so connectivity comes bundled with the application.

Messaging services on SWIFTNet.
• FIN – store-and-forward, individual structured MT (Message Type) messages; the classic SWIFT service.
• FileAct – secure transfer of bulk files (any format: ISO 20022 XML, BAI2, EDI, PDF, proprietary). Used by corporates for high-volume payment files and statement files.
• InterAct – real-time or store-and-forward exchange of XML (MX) messages.
• Browse – secure browser access to bank services over SWIFTNet.

Key MT message types to memorize (FIN). The first digit indicates the category: Category 1 = customer payments; Category 2 = financial institution transfers; Category 3 = treasury (FX, MM); Category 5 = securities; Category 9 = cash management/status.
• MT101 – Request for Transfer (corporate-initiated payment instruction to its bank).
• MT103 – Single Customer Credit Transfer (bank-to-bank message carrying a customer payment).
• MT202 – General Financial Institution Transfer (bank-to-bank/cover payment).
• MT300 – FX Confirmation; MT320 – Fixed Loan/Deposit Confirmation.
• MT900/MT910 – Confirmation of Debit/Credit.
• MT940 – Customer Statement (end-of-day/prior-day statement).
• MT941 – Balance Report; MT942 – Interim Transaction Report (intraday).
• MT199/MT999 – Free-format messages.

ISO 20022 and MX messages. ISO 20022 is the open, XML-based global financial messaging standard with richer, structured data (e.g., full remittance detail, structured addresses, purpose codes). SWIFT has migrated cross-border payments and reporting from MT to MX (CBPR+), with a coexistence period that began March 2023 and ended November 2025. Corporate-relevant MX families:
• pain (Payment Initiation): pain.001 Customer Credit Transfer Initiation (replaces MT101 function), pain.002 Payment Status Report, pain.008 Direct Debit Initiation.
• camt (Cash Management): camt.052 Intraday Account Report (MT942 equivalent), camt.053 End-of-Day Statement (MT940 equivalent), camt.054 Debit/Credit Notification (MT900/910 equivalent), camt.056/029 cancellation request/resolution.
• pacs (Payments Clearing and Settlement): pacs.008 FI-to-FI Customer Credit Transfer (MT103 equivalent), pacs.009 FI Credit Transfer (MT202 equivalent).
Many domestic systems (SEPA, Fedwire, CHIPS, CHAPS) have adopted ISO 20022, which is why treasurers care: one data standard across banks and countries enables automated reconciliation and better analytics.

Other SWIFT concepts that appear on exams.
• SWIFT gpi (global payments innovation) – tracking of cross-border payments end-to-end via a Unique End-to-end Transaction Reference (UETR), same-day use of funds, fee and FX transparency, and payment confirmation.
• 3SKey – SWIFT's multi-bank personal digital identity token used by corporate users to sign payment files for multiple banks.
• Customer Security Programme (CSP) – mandatory security controls and annual attestation for all SWIFT users, introduced after high-profile network-connected frauds (e.g., Bangladesh Bank 2016).
• RMA (Relationship Management Application) – controls which counterparties may send you messages.
• Non-repudiation – SWIFT authenticates and logs every message so senders cannot deny having sent it; this is a core control benefit.

4. How Host-to-Host Works in Detail

1. The bank and corporate agree formats (e.g., pain.001 for payments, camt.053/BAI2 for statements), file naming, schedules and cut-off times.
2. A secure transport channel is established – SFTP (SSH), FTPS (TLS), AS2 (HTTPS with signed/encrypted MIME) or Connect:Direct – frequently with IP whitelisting and a VPN.
3. Files are encrypted (PGP/GPG or built into AS2) and digitally signed for integrity and authentication; some banks require Hardware Security Modules (HSMs) for key storage.
4. The corporate's payment hub/TMS pushes payment files at scheduled times; the bank returns acknowledgement/status files (pain.002 or proprietary ACK/NAK).
5. The bank pushes prior-day and intraday reports which the TMS auto-imports for cash positioning and reconciliation.
Strengths: full automation, high throughput, bank-level security, good for a primary cash management bank. Weaknesses: one build per bank (N banks = N projects), proprietary variations, reliance on the bank's IT change cycle, and no real-time visibility between scheduled runs.

5. How Bank APIs Work in Detail

1. The corporate registers with the bank's developer portal, obtains credentials (client ID/secret, certificates) and agrees scopes (balances, transactions, payment initiation, FX, account validation).
2. The TMS/ERP authenticates (OAuth 2.0 token, mutual TLS) and calls endpoints, e.g., GET /accounts/{id}/balances or POST /payments, sending and receiving JSON (often mapped to ISO 20022 fields).
3. The bank responds in seconds with data or a payment status; alternatively the bank pushes event notifications (webhooks) when a credit arrives or a payment fails.
4. Use cases: real-time cash positioning, on-demand balance inquiry before releasing a large payment, instant payment initiation (RTP/FedNow), beneficiary account validation to fight payment fraud, real-time FX rates, virtual account management, and embedded finance.
Strengths: real-time, granular, event-driven, lower infrastructure than SWIFT direct, supports instant payments. Weaknesses: each bank's API differs (standardization is improving via ISO 20022, BIAN, Swift's API catalog and regulatory open-banking standards), coverage varies by bank/country, rate limits, and change management when banks version their APIs. Many corporates adopt a hybrid approach: SWIFT or a connectivity-as-a-service aggregator for broad multi-bank reach, H2H with the primary bank, and APIs for real-time needs.

6. Comparing the Channels – The Decision Framework

Think of six evaluation criteria the exam likes:
• Number of banks – many banks across countries → SWIFT (SCORE) or a multi-bank aggregator; one or two banks → H2H or portal.
• Volume and automation – high volume batch → H2H or SWIFT FileAct; low volume → portal or Lite2.
• Timeliness – real-time/intraday on demand → APIs (or MT942/camt.052 intraday reports via SWIFT/H2H on a schedule).
• Standardization and bank independence – want to switch banks without rebuilding → SWIFT + ISO 20022; proprietary H2H and APIs create lock-in.
• Cost and IT resources – direct SWIFT is most expensive to run in-house; service bureau or L2BA shifts cost to a fee; H2H costs scale per bank; portals are cheapest but labor-intensive.
• Control and security – all automated channels improve segregation of duties and audit trails versus portals; SWIFT adds non-repudiation and CSP; APIs add real-time fraud checks like account validation.

7. Security and Control Themes Across All Channels

• Confidentiality – encryption in transit (TLS, SFTP) and at rest (PGP).
• Integrity – hashing and digital signatures so files cannot be altered.
• Authentication – certificates, tokens (3SKey, bank tokens), multi-factor authentication, IP whitelisting.
• Non-repudiation – signed messages and immutable logs.
• Authorization – dual approval/segregation of duties inside the TMS or payment hub before transmission; bank-side limits and mandates.
• Resilience – redundant connections, service bureau SLAs, disaster recovery, SWIFT CSP attestation.
• Fraud risk – business email compromise is mitigated by removing manual portal entry, enforcing STP from ERP master data, and using account validation APIs and payment confirmations.

8. Worked Scenario Examples

Scenario A: A multinational with 40 banks in 25 countries wants one standardized channel for balances and payments, and the ability to change banks without re-engineering. Answer: SWIFT via SCORE, probably through a service bureau or L2BA, using FileAct with ISO 20022 (pain.001/camt.053).

Scenario B: A U.S. company with one primary cash management bank sends 50,000 ACH and wire items weekly from its ERP and needs fully automated acknowledgements. Answer: Host-to-Host (SFTP/AS2) with NACHA/pain.001 payment files and BAI2/camt.053 reporting.

Scenario C: Treasury wants to check the exact available balance seconds before releasing a large wire and to receive instant notice when a customer's RTP payment lands. Answer: Bank APIs (real-time balance inquiry and webhook notifications).

Scenario D: A small company with two banks, 20 payments a month and no IT staff. Answer: Bank portals (possibly a TMS with embedded connectivity later).

Scenario E: Which message gives intraday transaction detail? MT942 / camt.052. Prior-day statement? MT940 / camt.053. Corporate-to-bank payment instruction? MT101 / pain.001. Bank-to-bank customer payment? MT103 / pacs.008. Payment status back to the corporate? pain.002.

9. Exam Tips: Answering Questions on Bank Connectivity: SWIFT, Host-to-Host and APIs

Tip 1 – Remember SWIFT is messaging, not money movement. Any answer choice that says SWIFT settles, clears or holds funds is wrong. Settlement occurs via correspondent accounts and clearing systems; SWIFT carries the instructions.

Tip 2 – Match keywords to channels. 'Multi-bank', 'standardized', 'bank-agnostic', 'global', 'reduce number of connections' → SWIFT (SCORE). 'Single bank', 'high-volume batch', 'direct file transfer', 'SFTP/AS2' → Host-to-Host. 'Real-time', 'on demand', 'instant', 'event notification', 'open banking' → APIs. 'Low cost', 'manual', 'small company', 'log-in' → bank portal.

Tip 3 – Know SCORE vs MA-CUG. SCORE = one membership, many banks (preferred, standardized). MA-CUG = bank-sponsored closed group, one bank per group. If a question stresses simplicity across many banks, pick SCORE.

Tip 4 – Know the access options and their trade-offs. Direct connection = most control/most cost; service bureau = outsourced infrastructure and expertise; Alliance Lite2 = cloud, low volume; L2BA = embedded in TMS. Questions often ask which option minimizes in-house IT burden (service bureau/L2BA) or which gives maximum control (direct).

Tip 5 – Memorize the core message pairs. MT101↔pain.001 (payment initiation), MT103↔pacs.008 (customer credit transfer), MT202↔pacs.009 (FI transfer), MT940↔camt.053 (end-of-day), MT942↔camt.052 (intraday), MT900/910↔camt.054 (debit/credit advice), pain.002 (status). Category digit: 1 = customer payments, 2 = FI transfers, 3 = treasury confirmations, 9 = cash management.

Tip 6 – Understand ISO 20022's value proposition. The exam frames it as richer structured data, global harmonization across SWIFT and domestic systems, better STP and reconciliation, improved sanctions screening and analytics – not merely 'a new file format'.

Tip 7 – Distinguish FIN, FileAct and InterAct. FIN = individual MT messages; FileAct = bulk files of any format (what corporates mostly use for payment and statement files); InterAct = XML/MX exchange. If a question mentions sending a large payment file over SWIFT, the answer is FileAct.

Tip 8 – Think in trade-offs, not absolutes. Scenario questions reward the choice that best fits the stated constraints: number of banks, volume, timeliness, cost, IT capability, bank independence. Eliminate choices that overbuild (direct SWIFT for a two-bank company) or underbuild (portals for 40 banks).

Tip 9 – Link connectivity to controls and fraud. Expect answers framed around STP, elimination of manual re-keying, segregation of duties, dual approval, encryption, digital signatures, non-repudiation and SWIFT CSP. Automated connectivity is presented as a control enhancement, not just an efficiency gain.

Tip 10 – Remember SWIFT gpi and account validation as modern enhancements. gpi = end-to-end tracking (UETR), speed and fee transparency for cross-border payments; API-based account validation = pre-payment fraud check. Also remember BIC identifies institutions while IBAN identifies accounts.

Tip 11 – Watch for 'best' and 'most' wording. When asked for the 'most standardized' channel, choose SWIFT/ISO 20022; 'most timely' → APIs; 'most bilateral/proprietary' → H2H; 'least scalable' → portals.

Tip 12 – Use process of elimination with definitions. Many distractors swap definitions (e.g., calling a service bureau a clearing house, or saying H2H provides multi-bank reach through one connection). Check each option against the one-line definitions above before selecting.

10. Quick-Reference Summary

• Bank portal – manual, per bank, low cost, low scalability.
• Host-to-Host – automated secure file transfer to one bank; SFTP/FTPS/AS2; batch; BAI2/EDI/ISO 20022; cost grows per bank.
• SWIFT – cooperative messaging network (not settlement); BIC; corporates join via SCORE (multi-bank) or MA-CUG; connect directly, via service bureau, Alliance Lite2 or L2BA; services FIN/FileAct/InterAct; MT (MT101, MT103, MT940, MT942) migrating to MX ISO 20022 (pain, camt, pacs); gpi, 3SKey, CSP.
• APIs – real-time REST/JSON, OAuth, webhooks; open banking; instant payments; account validation; less standardized, bank-by-bank.
• Selection drivers – number of banks, volume, timeliness, standardization/bank independence, cost/IT capacity, control and security.
• Trend – hybrid architectures combining SWIFT or aggregators for reach, H2H for the primary bank, and APIs for real-time treasury, all underpinned by ISO 20022 data.