When a bank sends an international payment, two things happen in parallel. A message travels over SWIFT telling each bank what to do. And value moves across a chain of accounts that banks hold with each other â debited here, credited there â until it reaches the beneficiary's bank. This second layer, called correspondent banking, is centuries older than SWIFT, and it's the part that determines how many banks touch your payment, how many fees get taken, and how long it takes.
The short version
- Banks hold accounts with each other. To pay in US dollars, a Thai or Hong Kong bank needs a USD account at a bank that can settle dollars â typically one with access to the US payment systems.
- SWIFT carries the instructions between those banks in a standard format (today, ISO 20022 messages such as pacs.008 and pacs.009).
- If the sending and receiving banks don't have a direct relationship, one or more intermediary banks relay the payment.
- Final settlement of each currency ultimately happens in that currency's home system â Fedwire or CHIPS for USD, T2 for EUR, CHATS for HKD, BAHTNET for THB.
Nostro and vostro â the accounts behind every transfer
The vocabulary comes from Latin, and it's all about perspective:
- Nostro ("ours"): an account our bank holds at another bank, in that bank's currency. A Bangkok bank's USD account in New York is its nostro.
- Vostro ("yours"): the same account seen from the other side â the New York bank holds your money for you.
When the Bangkok bank sends USD 10,000 on a customer's behalf, it's really instructing its New York correspondent: "debit our account with you, and credit this other bank." No physical money crosses the ocean. Balances shift on ledgers.
- Settlement type: Book transfers between correspondent accounts, with final settlement in the currency's domestic RTGS or clearing system
- Speed: Near-instant on the books once each bank releases the payment; business hours of each bank and settlement system apply
- Value tier: All values, from small invoices to very large corporate transfers
- What it's used for: Any cross-currency or cross-border payment where the two banks don't share a faster direct link
A payment, step by step
Take a small design studio in Chiang Mai paying a USD invoice to a software vendor in Germany whose account is held in USD.
- Instruction: The studio submits the payment in its banking app or dashboard â beneficiary name, account/IBAN, bank BIC, amount, purpose.
- Checks at the sending bank: The bank verifies funds, screens names against sanctions lists, runs fraud and anti-money-laundering checks, then debits the studio's account (converting THB to USD if needed).
- Message out: The bank creates a customer credit transfer message (pacs.008, the successor to the MT103) with a unique tracking reference (UETR), and sends it to its USD correspondent.
- Intermediary processing: The correspondent â often a large US or global bank â screens the payment again, debits the Thai bank's account, and credits the German bank's USD correspondent (or the German bank directly, if it holds an account there). Settlement between those two may happen in CHIPS or Fedwire.
- Receiving bank: The German bank receives the message, runs its own checks, and credits the vendor.
- Confirmation: Each bank updates the payment's status against the UETR, so the sender's bank can see when the funds were credited.
Every step is fast when automated. Every step can also pause â for a compliance query, a cut-off time, a public holiday, or a missing piece of information.
Serial vs cover â two ways to route the same payment
- Serial method: The customer payment message hops bank to bank along with the money. Every bank in the chain sees full payment details. Simple, transparent, but each hop adds processing time.
- Cover method: The sending bank sends the customer payment message directly to the beneficiary's bank, while a separate bank-to-bank message (pacs.009 COV, formerly MT202 COV) moves the funding through the correspondents. The beneficiary bank knows a payment is coming before the money arrives â but can't credit the customer until the "cover" lands.
Regulators require cover messages to carry the underlying customer details, so intermediary banks can screen who is really paying whom.
Comparison at a glance
| Role | Who it is | What it does | Can it deduct a fee? |
|---|
| Ordering (sending) bank | Your bank | Checks, debits you, sends the message | Yes â sending fee |
| Correspondent bank | A bank holding an account for another bank in a given currency | Settles the currency on the sending bank's behalf | Yes |
| Intermediary bank | Any bank in the chain between sender and receiver (often a correspondent) | Relays and screens the payment | Yes â "lifting" fees |
| Beneficiary bank | Recipient's bank | Final checks, credits the recipient | Yes â receiving fee |
| Settlement system | Fedwire, CHIPS, T2, CHATS, BAHTNET etc. | Final, irrevocable settlement of each currency | Built into bank pricing |
What this means for your payments
The number of banks between you and your payee is the single biggest driver of cost and delay in a SWIFT payment â and it's usually invisible to you. Two practical takeaways: send in the currency your payee's account is actually held in (so the receiving bank doesn't convert at its own rate), and ask your provider which route and charge option it will use before you send. Where both ends have strong local payment rails, a provider that collects and pays out locally can avoid the correspondent chain entirely.
Sources
- SWIFT â FIN traffic figures â www.swift.com
- SWIFT â ISO 20022 end of coexistence: 10 days to go (Nov 2025) â www.swift.com
