Topic archive
Plain-language learning briefs that route you to the key ideas, operational questions, and practical context for this part of the payment ecosystem.
Latest first
A resident individual in India sends dollars to a friend's US account: Form A2 and the Liberalised Remittance Scheme, currency conversion at the sending bank, and a serial MT103 that carries both currencies through one US correspondent to the beneficiary's bank.
Every ISO 20022 payment carries two kinds of metadata: coded fields that declare what the payment is — service level, local instrument, category purpose, purpose — and an agent chain that names who moves it, bank by bank. This article reads a fictional pacs.008 field by field: what each code means, why there are four purpose-ish fields and not one, and how the instructing, previous-instructing, intermediary and reimbursement agents thread a payment across borders.
The move from MT to ISO 20022 is a dated schedule, not a single switch: CBPR+ coexistence from March 2023, CHIPS in 2024, Fedwire's cut-over on 14 July 2025, the end of cross-border MT coexistence in November 2025, mandatory structured or hybrid addresses from 15 November 2026, and later statement-message retirements through 2027-2028.
Directs readers to a detailed learning session about the SWIFT MT103 customer credit transfer message.
Explains how corporates and banks use MT101 transfer requests in practice and how those instructions can lead to customer credit transfers.
Contrasts serial and cover settlement methods by showing how payment instructions and funds travel through correspondent banking chains.
Breaks a SWIFT MT message into its five blocks and explains the identifying, application, content, trailer, and user information they carry.
Explains the MT naming convention, message categories, three-digit identifiers, and other structural details used across SWIFT FIN messages.
Narrows the broader MT catalog to the message categories most relevant to customer transfers, bank transfers, and cash management.
Traces the move from error-prone TELEX instructions to SWIFT's standardized, secure network for exchanging financial messages.
Explains how a cover payment funds the bank-to-bank leg with a SWIFT MT202 COV while the customer's MT103 travels separately to the beneficiary's bank, and why the cover message must carry the underlying customer details.
Describes the SWIFT Category 9 messages — the MT900 debit confirmation, MT910 credit confirmation, and MT940, MT942, and MT950 statements — and how they feed reconciliation of the accounts a bank holds at other banks.
The annual Standards Release is SWIFT's yearly update to its message standards. It keeps formats aligned with new business needs, regulation, and corrections, following a fixed announce-to-go-live cycle that ends on a November weekend.
SWIFT gpi (global payments innovation) is a set of standards that made cross-border correspondent payments faster and more transparent, adding fee visibility and end-to-end tracking through a unique reference and a central Tracker.
Correspondent banking lets one bank access another's market by holding an account with it. Establishing a relationship means exchanging authorisations, performing due diligence, and opening accounts; withdrawing from relationships, known as de-risking, can cut off access to payments.
When a payment must be questioned, cancelled, or corrected, banks use dedicated exception messages: free-format MT n99 notes, MT n92 cancellation requests, and the ISO 20022 camt.056 and camt.029 pair, supported by SWIFT gpi stop-and-recall.
How a SWIFT MT message is checked before and during sending: mandatory versus optional fields, tags and formats, the network's own cross-field rules, and what a rejection means.
The three SWIFT messaging services — FIN for store-and-forward MT messaging, InterAct for real-time ISO 20022 exchanges, and FileAct for secure bulk file transfer — and when banks use each.
Bank-to-bank funds transfers on SWIFT — the MT202 and MT205 and their ISO 20022 successor pacs.009 — used for cover payments, own-account moves, and market settlement, and how they differ from customer transfers.
The SWIFT Customer Security Programme: mandatory and advisory controls that connected institutions implement and attest to each year, why it exists, and how attestations inform counterparty risk.
SWIFTNet is the secure private network that carries every Swift service. This article explains how institutions connect to it and maps the four messaging services that ride on top.
The Alliance product family is how institutions actually send and receive Swift messages. This article explains the on-premises and cloud interfaces, the connectivity components, and how a firm chooses between them.
FINplus is the SWIFTNet service that carries ISO 20022 messages for cross-border payments and securities, alongside legacy FIN. This article explains FINplus, the interactive Browse service, and FileAct's two delivery modes.
SWIFTRef is Swift's reference-data utility, publishing authoritative directories of institutions, codes, and settlement details so payment systems can validate and route correctly. Its accuracy reduces repairs and delays before a message is sent.
The BIC Directory is the authoritative list of Business Identifier Codes, while Bank Directory Plus adds national clearing codes, hierarchy, and legal-entity data. Payment operations use both to route and validate cross-border transfers.
IBAN Plus derives the correct BIC from an account number, the SSI Directory records where and how to settle, the SEPA routing directory shows reachability, and RMA Plus governs granular messaging authorisations.
The gpi (global payments innovation) service family applies end-to-end tracking and service-level rules to cross-border payments, with distinct variants for customer transfers, cover payments, financial-institution transfers, and links to domestic instant rails.
Payment pre-validation checks beneficiary account details and other data before a cross-border payment is sent, so errors are caught at the start rather than becoming costly repairs and delays later in the chain.
SWIFT Go is a service for fast, predictable low-value cross-border payments for consumers and small businesses, using pre-agreed terms on speed, fees, and data quality built on tighter rules than a standard transfer.
The Transaction Manager is a central platform that orchestrates a payment as one shared transaction in ISO 20022, preserving data across parties and reducing truncation as part of the shift from point-to-point messaging to a central platform.
Swift MT (Message Type) messages are grouped into numbered categories by business area, from customer payments to securities and cash management, so each message carries a predictable purpose and structure across the network.
Category 7 Swift messages carry documentary credits and guarantees between banks in trade finance, supporting importers and exporters, while the Bank Payment Obligation offers an irrevocable interbank undertaking as an alternative structure.
Beyond payments, Swift carries category 3 treasury confirmations, category 5 securities settlement and reconciliation, and category 6 commodities messages, letting post-trade confirmation and settlement instructions travel over one network.
Corporates connect to Swift through models such as SCORE and MA-CUG, exchanging payment instructions and statements with their banks over a single channel instead of maintaining many separate proprietary connections.
SWIFT Financial Application (FIN) Category 1 covers customer payments, where a customer is a party to the transfer. This guide walks the MT101, MT102, MT103, and MT104 messages along two axes: single versus multiple, and push versus pull.
SWIFT Financial Application (FIN) Category 2 covers transfers where banks are the parties. This guide separates own-account from third-party transfers, single from multiple, and explains the notice nature of MT210 and the MT202 COV cover message.
SWIFT Category 0 system messages pass between a user and the network itself, not between banks. This guide covers acknowledgements, authentication responses, retrieval and delivery notifications, and why a valid payment can still fail at the network layer.
When a SWIFT MT payment goes wrong, banks use a small family of exception messages — MTn92, n95, n96, and n99 — to ask for cancellation, query, answer, and explain. ISO 20022 replaces this toolkit with camt.056, camt.029, and pacs.004.
Universal Confirmation asks every bank to confirm the fate of a payment — credited, returned, or rejected — feeding the gpi tracker. This piece walks through the gpi service variants and the Daily Validation Report as a detective control.