SWIFT is a financial messaging network, not a bank or settlement system. Learn how SWIFT payments, BICs, correspondents, tracking, fees, and controls work.
SWIFT is a cooperative and financial messaging network that institutions use to exchange standardized payment, securities, treasury, and trade-finance instructions. SWIFT transmits information; it is not a bank, does not hold customer accounts, and does not by itself clear or settle the money or securities described in a message.
SWIFT gives participating organizations a common channel for authenticated, standardized financial communication. Depending on the service and message type, institutions can exchange:
The message may identify parties, accounts, institutions, amount, currency, dates, charges, purpose, remittance information, and transaction references. The exact fields and rules depend on the message standard, version, market practice, and service.
SWIFT does not determine whether the customer has sufficient funds, whether the payment is authorized, whether an intermediary extends credit, or when settlement becomes final. Those decisions and records belong to the participating institutions and applicable payment or settlement systems.
| Layer | Main function | Typical evidence |
|---|---|---|
| Customer instruction | States who should pay whom, how much, and for what purpose | Payment order, invoice, approval, beneficiary instructions |
| Bank processing | Validates authority, data, balance, limits, fraud, and compliance conditions | Bank transaction record, screening result, exception log |
| SWIFT messaging | Transmits a standardized instruction or report between authorized endpoints | Message copy, reference, network acknowledgement, delivery record |
| Correspondent or payment route | Connects institutions and provides accounts or system access | Nostro/vostro entries, intermediary records, routing data |
| Clearing and settlement | Calculates and discharges obligations under system rules | Settlement-system record, participant-account debit or credit |
| Beneficiary posting | Applies the incoming payment to the recipient’s account | Beneficiary-bank posting, value date, hold or return status |
| Reconciliation | Compares messages, cash, settlement, and ledger records | Bank statement, general ledger, exception and resolution record |
Evidence at one layer does not prove completion at every later layer. For example, a SWIFT network acknowledgement can show technical acceptance of a message without proving that a correspondent had funds available or that the beneficiary bank credited its customer.
flowchart LR
A["Payer approves bank instruction"] --> B["Sending bank validates and creates message"]
B --> C["SWIFT transmits standardized instruction"]
C --> D["Correspondent or payment system processes route"]
D --> E["Settlement entries transfer value"]
E --> F["Beneficiary bank applies checks and posts credit"]
F --> G["Banks return status and reconcile records"]
C -. "message and tracking data" .-> G
A typical transaction can involve these steps:
Not every payment requires every step or intermediary. A direct relationship can produce a shorter path; another currency or destination can require several institutions and domestic payment systems.
Assume a Canadian importer owes a supplier a USD 84,000 invoice. The importer’s Bank A does not maintain a direct USD account relationship with the supplier’s Bank D, so Bank A uses correspondent Bank B.
84,000 payment and independently verifies Bank D’s BIC and the supplier’s account number.Suppose Bank A separately charges the importer a $35 sending fee and an intermediary deducts $15 from the payment amount:
| Measure | Amount |
|---|---|
| Payment instruction | USD 84,000 |
| Sending fee paid separately | USD 35 |
| Total payer outflow | USD 84,035 |
| Intermediary deduction | USD 15 |
| Amount credited to supplier | USD 83,985 |
The supplier remains short $15 against the invoice even though the original message requested USD 84,000. Fee allocation depends on the bank agreements, payment instruction, route, and applicable rules; this example is illustrative.
The transaction also shows why status language matters. “Message accepted” can be true at step 3, “settled between institutions” can be true at step 4, and “credited to the beneficiary” can remain false until step 6.
| Evidence or status | What it can support | What it does not prove alone |
|---|---|---|
| Customer confirmation | Bank received a customer instruction | Instruction was authentic, transmitted, or settled |
| Network acknowledgement | Message passed the applicable technical checks or was accepted for delivery | Receiving bank accepted the business instruction |
| Delivery record | Message reached the expected messaging endpoint | Funds settled or beneficiary account was credited |
| Payment tracker update | Reported progress associated with a transaction reference | Every underlying account entry is final and correct |
| Correspondent debit or credit | Value was posted to a particular interbank account | Recipient received the intended net amount |
| Settlement-system confirmation | Obligation settled under that system’s records and rules | Beneficiary bank completed customer posting |
| Beneficiary credit | Recipient account was credited | Funds are unrestricted, irreversible, or correctly applied to an invoice |
| Return or rejection | Participant did not complete the original instruction as submitted | All related fees and accounting entries have been reversed |
Operational teams should retain the message reference, timestamps, parties, amount, currency, status reason, settlement record, fees, and ledger entries. When a payment is delayed, the last verified stage is more informative than the broad label “sent.”
| Identifier | Identifies | Important limitation |
|---|---|---|
| BIC or SWIFT code | Financial or non-financial organization, and optionally an organizational unit | Does not identify the beneficiary’s customer account or guarantee direct SWIFT connectivity |
| IBAN | Account in jurisdictions and payment contexts using the IBAN standard | Is not used universally and does not replace the institution identifier in every route |
| Domestic account number | Customer account under the relevant domestic convention | May be insufficient for a cross-border instruction |
| UETR | Unique end-to-end transaction reference associated with a SWIFT payment instruction | Supports identification and tracking but does not make the payment valid or final |
SWIFT describes the UETR as a 36-character unique reference included in payment instruction messages carried over its network. A useful investigation begins with that reference, but still requires the underlying message, participating banks, route, and settlement records.
A syntactically valid BIC or account number is not proof that beneficiary instructions are genuine. Changed instructions should be verified through a trusted contact channel independent of the change request.
Correspondent payments can use different message and settlement paths.
In a serial route, the payment instruction moves from one bank to the next along the correspondent chain. Each institution receives the instruction, performs its processing, and passes it onward. The message route and account-entry route are closely aligned, although separate payment systems may support settlement between banks.
In a cover route, the customer payment instruction can be sent toward the beneficiary bank while a separate interbank instruction moves the cover funds through correspondent banks. The two flows must carry enough linked information for screening, processing, and reconciliation.
| Question | Serial route | Direct-plus-cover route |
|---|---|---|
| Customer instruction path | Passes through the bank chain | Can go more directly toward beneficiary bank |
| Interbank settlement path | Generally follows the correspondent sequence | Separate cover instruction funds the payment |
| Main control concern | Data, fees, and status across each handoff | Correct linkage and consistency between customer and cover messages |
| Investigation need | Trace each forwarding and account entry | Trace both message flows and match them to settlement |
Neither method guarantees a particular speed, fee, or legal result. The route depends on currencies, account relationships, market infrastructure, participant rules, and the precise message types in use.
SWIFT historically used its MT message standards extensively for cross-border banking. ISO 20022 provides a broader business-modelling method and structured message definitions often called MX messages in SWIFT contexts.
| Item | Meaning |
|---|---|
| MT | Established SWIFT message format organized into message categories and types |
| ISO 20022 message | Message derived from the ISO 20022 business models and repository |
| MX | Common SWIFT term for ISO 20022 XML messages |
| CBPR+ | SWIFT community usage guidelines for ISO 20022 cross-border payments and cash reporting |
SWIFT reports that the coexistence period for in-scope cross-border payment instruction messages ended on November 22, 2025. This statement should not be generalized to every historical MT message or every SWIFT service: reporting, exceptions, investigations, securities, and other message areas can have separate scopes and migration schedules.
Migration also does not eliminate translation risk. If an institution receives structured ISO 20022 data but converts it into a shorter internal record, the downstream process can lose the information needed for screening, reconciliation, or investigation.
Treasury teams use message, tracking, statement, and settlement data to monitor liquidity and investigate payments. They should distinguish bank-account value dates from customer-facing status and understand which institutions can deduct fees or delay processing.
Message references can connect invoices, payment batches, bank statements, correspondent entries, and general-ledger postings. The reference is useful only if systems preserve it and staff investigate unmatched amounts, duplicate entries, returns, and timing differences.
Standardized data can support straight-through processing, but automation depends on accurate source data, valid identifiers, compatible message rules, screening, settlement, and exception handling. A high message-delivery rate is not the same as a high end-to-end STP rate.
Messages can contain information used for fraud detection, sanctions screening, anti-money-laundering controls, and investigations. The participating institutions remain responsible for applying the laws and controls relevant to their roles. A secure channel cannot determine whether the underlying business purpose is legitimate.
SWIFT protects its messaging services, but each user must also secure the environment that creates, approves, sends, receives, and records messages. SWIFT’s Customer Security Controls Framework establishes mandatory and advisory controls for in-scope user environments.
Important institutional controls include:
A technically authentic message can still result from stolen credentials, compromised local systems, collusion, incorrect master data, or an authorized user’s mistake.
This article is general financial education, not payment-routing, cybersecurity, sanctions, legal, or compliance advice. Confirm actual payment instructions, message requirements, fees, and status with the participating institutions.