How SWIFT works: messaging, settlement, and where the time goes

SWIFT is a messaging network, not a settlement system. It carries standardized payment instructions between more than 11,500 financial institutions in over 200 countries; the money itself moves separately, across the web of accounts banks hold with one another. Understanding that distinction explains almost everything about how international payments behave: why they can be fast, why they are often slow, and why nobody in the chain can always say where a payment is.

What SWIFT actually is

SWIFT, the Society for Worldwide Interbank Financial Telecommunication, is a member-owned cooperative headquartered in Belgium. Since 1977 it has done one job exceptionally well: deliver financial messages between institutions securely, reliably, and in a format every participant understands. It averages more than 50 million FIN messages a day.

A SWIFT “payment” is therefore an instruction. When a bank in Singapore pays a supplier’s bank in Brazil, no value crosses the SWIFT network. What crosses is a message that says, in effect: debit my account with you, credit this beneficiary, here is the reference data. The moving of money is the job of the banks in the chain, and of the correspondent banking arrangements between them.

From MT to ISO 20022: what the message contains

For most of SWIFT’s history, payment instructions traveled as MT messages, a compact fixed-field format designed in the era of telex. The MT103, the classic customer credit transfer, is still the best-known message type in banking.

That era has now formally ended for cross-border payments. On 22 November 2025 the coexistence period between MT and ISO 20022 closed, and the MT categories used for cross-border payments and reporting no longer meet SWIFT’s CBPR+ requirements. Their ISO 20022 equivalents, such as pacs.008 for a customer credit transfer, carry far richer structured data: full party details in dedicated fields, purpose codes, and remittance information that survives the journey intact.

The upgrade matters because bad data is a hidden tax on the old system. Truncated names and unstructured addresses forced manual repairs and triggered false positives in sanctions screening, each one parking a payment in a queue until a human cleared it. Structured data removes a share of those stops. It does not change what happens after the message arrives.

What a message sets in motion

Consider a dollar payment from a mid-sized bank in Nairobi to a beneficiary at a regional bank in Vietnam. Neither bank holds an account with the other, so the payment travels through correspondents:

1. The Nairobi bank sends a pacs.008 to its US dollar correspondent in New York, instructing it to pay onward.
2. The New York correspondent debits the Nairobi bank’s nostro account, runs its own sanctions and AML checks, and passes the instruction to the Vietnamese bank’s dollar correspondent.
3. That second correspondent settles with the first across their mutual accounts or a domestic system such as CHIPS or Fedwire, then credits the Vietnamese bank’s account.
4. The Vietnamese bank converts and credits the end beneficiary through local rails.

Each institution in the chain moves value only on its own books. Settlement is the accumulation of those bilateral debits and credits, and the payment is only final for the beneficiary when the last bank credits the customer’s account. Interestingly, the chains are shorter than their reputation suggests: BIS analysis of SWIFT gpi data found cross-border payments involve just over one intermediary on average. The delay comes less from the number of hops than from what happens within each one.

Where the time and the fees go

The same BIS study, covering around 20 million transactions across 141 countries, located the biggest single block of time at the end of the journey: the beneficiary leg, from the moment the last intermediary pays the beneficiary bank to the moment the customer is credited, absorbs almost eight hours on average. Business hours, batch cycles in domestic systems, capital controls, and currency conversion all live in that leg.

The rest of the delay is distributed along the chain: cut-off times that close a correspondent’s books for the day, time zones that mean one bank’s afternoon is another’s night, compliance checks that repeat at every institution because each carries its own regulatory obligations, and funding, since a correspondent will not pay out against an account that has not been pre-funded.

Fees follow the same path. Each intermediary charges for its work, and deducting charges from the principal as it passes is common practice, which is why beneficiaries often receive less than was sent and why the sender frequently cannot say in advance what the payment will cost. The buyer pain is familiar to anyone who operates these flows: days, dictated by the correspondent network; stacked intermediary and FX fees you can’t see.

What gpi fixed, honestly

SWIFT gpi deserves a fair reading. It gave every payment a unique end-to-end reference, the UETR, so a payment can be tracked across the chain the way a parcel can. It brought service-level commitments and fee transparency between member banks. The results are real: by SWIFT’s figures, nearly 60% of gpi payments reach the end beneficiary within 30 minutes, almost 100% within 24 hours, and members send over $300 billion a day through it.

What gpi did not do is change the model. Value still moves bank by bank across pre-funded nostro accounts. Compliance still runs separately at every hop. Settlement finality still arrives at different moments for different parties, and a payment that fails screening at hop three still sits until someone releases it. Visibility improved; the machine underneath is the machine the BIS has described as struggling to adapt, with active correspondent relationships down about 22% between 2011 and 2019.

Where Frame fits

Frame is the settlement layer for global finance: one integration to orchestrate payments at scale across fiat rails, stablecoins, and tokenized deposits, with compliance enforced on every transaction and settlement in seconds instead of days.

Where SWIFT standardized the message and left settlement to the chain, Frame treats settlement itself as the product. A payment entering Frame is routed across whichever rail fits the corridor, the counterparty, and the policy that governs it. Frame’s Rules Engine evaluates every transaction against those policies inside settlement, so a transfer that cannot satisfy them does not settle, and every settled transaction produces verifiable evidence that its conditions were met without exposing the underlying business data. The checking that today repeats at every hop becomes a property of the settlement itself.

See how a rail-neutral settlement layer works: The Frame Blueprint.