SWIFT Payment Processing: MT103, ISO 20022, and gpi Explained

SWIFT connects over 11,000 financial institutions across 200+ countries — more than any other cross-border payment messaging network — but it is routinely misunderstood. SWIFT is not a bank. It does not hold funds. It does not move money. It is a messaging cooperative: a secure communication network that financial institutions use to send each other standardised payment instructions. The actual movement of funds happens through bilateral account relationships between those institutions.

This distinction matters operationally. When a SWIFT payment fails, stalls, or arrives short, the failure point is almost never SWIFT’s messaging infrastructure — it is a bank in the correspondent chain acting on that instruction, or not acting on it, in ways that SWIFT has no authority to override. Understanding the mechanics of how a SWIFT payment actually moves is the prerequisite for diagnosing problems, structuring payments correctly, and deciding when SWIFT is the right rail at all.

How a SWIFT Payment Moves

The architecture is a chain of bilateral account relationships. Bank A in Singapore and Bank B in Germany almost certainly do not hold accounts directly with each other. To move money between them, the payment travels through banks that do hold accounts with each other — correspondent banks.

A typical multi-hop SWIFT payment moves like this:

Step 1 — Instruction originates. The ordering customer (a Singapore company) instructs their bank (Bank A) to send €50,000 to a supplier’s account at Bank B in Germany. Bank A formats a payment message and sends it via SWIFT to its correspondent — Bank C, a large US or European bank with accounts in both SGD and EUR.

Step 2 — Correspondent processes. Bank C receives the SWIFT instruction, debits Bank A’s nostro account (the account Bank A maintains at Bank C), and forwards a new SWIFT instruction to Bank B or to another correspondent closer to Bank B.

Step 3 — Funds credit. Bank B receives the final instruction, credits the supplier’s account, and sends a confirmation message back through the chain.

Each hop takes time — not because the messaging is slow (SWIFT messages typically deliver in seconds) but because each bank has its own compliance screening, batch processing windows, and business-hours constraints. A payment submitted on a Friday afternoon Singapore time may arrive at a European bank on Monday. A payment routed through three correspondents on a corridor with infrequent processing windows can take four business days.

Nostro and vostro accounts are the balance sheet mechanism underlying this. Bank A’s nostro account at Bank C is the account Bank A maintains at Bank C (from Bank A’s perspective, “our money at your bank”). Bank C’s view of the same account is a vostro account (“your money at our bank”). Every correspondent hop requires the sending bank to hold sufficient balance in its nostro account at the next bank in the chain. Liquidity in the correspondent chain is what makes SWIFT payments work — and why corridors with thin correspondent coverage are slow and expensive.

MT103: What It Was, What Replaced It

MT103 was the SWIFT message format for single customer credit transfers for nearly three decades. An MT103 message carried the essential payment fields: sending bank BIC, receiving bank BIC, value date, currency and amount, ordering customer details, beneficiary account and name, and remittance information in a free-text field.

The free-text remittance field was MT103’s principal limitation. The field allowed approximately 140 characters across four unstructured lines — not enough to carry an invoice number, purchase order reference, tax identifier, and payment purpose in a format that receiving systems could automatically parse and match. The result was manual reconciliation on the receiving end: accounts payable teams keying data from bank statements into ERP systems, high rates of payment-detail mismatches, and slow accounts receivable close cycles.

SWIFT completed its cross-border payment migration to ISO 20022 in November 2025, when MT103 was retired from the cross-border network. The ISO 20022 equivalent for customer credit transfers is the pacs.008 message (Payment Clearing and Settlement, message 008). For financial institution-to-financial institution transfers — interbank settlements and correspondent-to-correspondent movements — the equivalent is pacs.009 (replacing MT202). Cover payment flows that previously used MT202COV — where the interbank leg carries underlying customer payment details — are handled within pacs.009 by embedding a linked pacs.008 reference.

ISO 20022 pacs.008 carries structured remittance data: machine-readable invoice references, multiple remittance items, tax identifiers, Legal Entity Identifiers (LEIs), and payment purpose codes in defined XML fields. For treasury and finance operations doing high-volume international payments, the ability to auto-reconcile against open invoices using structured data embedded in the payment message is a real operational improvement — provided the systems on both ends are updated to populate and consume structured fields, which is still an implementation challenge in practice.

What ISO 20022 does not fix: settlement speed and cost. The migration changes the data format; it does not change the correspondent banking network topology. Settlement timing is still determined by the number of hops, business-hours constraints, and processing windows of the banks in the chain. FX spreads are still determined by liquidity and commercial margin decisions. ISO 20022 is a multi-year operational efficiency gain, not a solution to correspondent banking economics.

SWIFT gpi and the UETR

Before SWIFT gpi (Global Payments Innovation), launched in 2017, a business that sent a SWIFT transfer had no way to know where the payment was in the correspondent chain. If funds had not arrived after two days, the only recourse was to ask your bank to send a tracer — an investigative message that could take 24–48 hours to return a status.

gpi changed this by requiring every bank in the gpi chain to update a shared tracking record at each processing step, and by assigning every gpi payment a Unique End-to-end Transaction Reference (UETR) — a 36-character UUID that persists unchanged through every bank in the chain from origination to credit. The UETR is embedded in the payment message and never modified by any correspondent. It enables end-to-end payment status lookup through SWIFT’s gpi Tracker.

The gpi service level includes:

• Same-day credit obligation: correspondent banks must credit the next bank in the chain on the value date (subject to cut-off times)
• Fee transparency: each bank must report fees deducted at its processing step, visible in the tracker
• Confirmation of credit: the receiving bank sends a confirmed credit notification back through the chain when funds are credited to the beneficiary account

Over 4,000 financial institutions were live on gpi by 2025. SWIFT reports that approximately 50% of gpi payments settle within 30 minutes, with most of the remainder settling within 24 hours. The tail — payments that take multiple days — is concentrated on corridors with less gpi coverage, currency pairs requiring manual processing, and transactions that trigger compliance holds.

Fee Structure: What a SWIFT Payment Actually Costs

SWIFT payment cost is the sum of four components, most of which are not disclosed by the sending bank at the time of payment:

Sending bank fee — charged by your own bank for executing the outgoing SWIFT transfer. Ranges from $15–50 for consumer/SMB accounts, often tiered or flat-fee for corporate banking relationships.

Correspondent transit fees — charged by each intermediary bank for processing the payment through its account. Typically $10–30 per correspondent hop, deducted from the payment principal unless the sender instructs otherwise. A payment routed through two correspondents loses $20–60 before reaching the recipient bank.

FX spread — the difference between the interbank (mid-market) exchange rate and the rate the sending bank or correspondent applies. Standard bank FX spreads: 1.5–3% on major currency pairs (EUR/USD, GBP/USD, USD/JPY), 3–5% on less liquid corridors. This is typically the largest single cost component.

Receiving bank fee — charged by the beneficiary’s bank for crediting the account. Ranges from zero to $20+ depending on the bank and account type.

Charge instructions determine who pays correspondent transit fees:

• SHA (shared charges): sender pays sending bank fee; recipient pays all transit and receiving bank fees via deduction from principal. This is the default.
• OUR (all charges to sender): sender pays all fees, including correspondent transit fees. Recipient receives the full instructed amount.
• BEN (all charges to beneficiary): all fees deducted from principal, including sending bank fee.

For B2B payments where the recipient needs to receive a specific net amount — invoice settlement where short receipt creates reconciliation problems — OUR is the correct charge instruction. SHA is cheaper for the sender but transfers cost uncertainty to the recipient.

When to Use SWIFT vs Alternatives

SWIFT is the default rail for international payments because of its near-universal coverage — 11,000 institutions, 200+ countries. But near-universal coverage does not mean it is the right rail for every payment. The operator decision matrix:

Use SWIFT when:

• No real-time alternative exists for the corridor (many emerging market currencies)
• Payment is high-value (above the limits of faster payment systems)
• The correspondent chain is short (two well-connected major banks) and the corridor is liquid
• Regulatory or bank policy requires SWIFT rails (some institutional treasury workflows)
• The recipient’s bank only accepts SWIFT-routed incoming transfers

Consider alternatives when:

• Both sender and recipient are in markets with real-time domestic rails that are interconnected (SEPA, FedNow, PayNow, etc.)
• Payment volume justifies the integration cost of a payment-on-behalf-of platform (Airwallex, Wise Business, Currencycloud) that pre-positions liquidity and bypasses correspondent chains
• FX cost is material — interbank-proximate platforms offer 0.2–0.5% spreads vs 1.5–3% bank FX
• Settlement certainty is required in minutes, not days

For a detailed comparison of SWIFT against faster local rails across specific corridors, the SWIFT gpi vs local rails analysis covers decision criteria by corridor and payment type. For the structural argument on why correspondent banking persists and where platform models are gaining ground, see cross-border B2B payments: what’s still broken.

Operator Pitfalls

Sending SHA when you need OUR. The most common SWIFT complaint from recipients is arriving short. If your supplier has invoiced €10,000 and receives €9,960 because correspondent transit fees were deducted, you have a reconciliation dispute. Use OUR for B2B invoice settlement unless you have explicitly agreed with the counterparty that they bear the transit fees.

Not capturing the UETR. If a gpi payment is used, the UETR should be recorded at payment initiation and linked to the underlying transaction in your ERP or treasury system. When a payment goes missing or is delayed, the UETR is the fastest path to status — asking your bank to trace a payment without a UETR forces them to search by amount and date, which is slower and error-prone.

Misunderstanding cut-off times. SWIFT messages route through banks that operate in specific time zones with processing cut-offs. A payment initiated at 4 PM Singapore time on a Thursday may not be processed by the correspondent until the following Monday if it misses the Thursday cut-off. For time-sensitive payments, check the cut-off chain — not just your own bank’s outgoing cut-off, but the processing windows of the correspondents your bank uses for the target corridor.

Assuming ISO 20022 fields will be populated. The migration to ISO 20022 enables structured remittance data but does not guarantee it. Banks and corporates are at different stages of updating their systems to populate structured fields. If you are relying on structured invoice references in incoming pacs.008 messages for auto-reconciliation, verify your banking partner’s actual implementation — many are still populating structured fields with legacy free-text content transcribed from MT103 formats.

Using SWIFT for small-value, frequent payments. The fixed costs of SWIFT (sending bank fee, transit fees) make it economically inefficient for payments under $500–1,000. A recurring $200 supplier payment via SWIFT could lose 10–15% to fees. For frequent small-value cross-border payments, specialist platforms are almost always more cost-effective.

---

SWIFT’s role in payments infrastructure is narrowing rather than expanding. For high-value, low-frequency institutional transfers in corridors without better alternatives, it remains the only viable option. For the large and growing volume of commercial cross-border payments where speed, cost, and transparency matter — B2B SaaS subscriptions, marketplace payouts, SME supplier payments — the combination of real-time domestic rails, regional payment networks, and platform-based liquidity positioning is replacing correspondent banking chains in the corridors where coverage exists. The operator challenge is understanding which category each payment falls into, and routing accordingly.