What SWIFT Is and What It Is Not

SWIFT is a member owned cooperative based in Belgium that provides secure messaging services to more than 11,000 financial institutions in over 200 countries and territories. Its full name is the Society for Worldwide Interbank Financial Telecommunication. Banks join SWIFT, connect to its network, and exchange standardised messages that instruct payments, confirm trades, and report account activity. SWIFT does not hold accounts, does not move money, and does not settle payments. It carries the instruction that tells a bank to move money, and that instruction is only as good as the accounts and the liquidity behind it. SWIFT is not a payment system, a clearing house, or a central bank. A payment system such as CHAPS in the United Kingdom, Fedwire in the United States, or T2 in Europe actually settles funds between banks, usually in central bank money. SWIFT does not settle anything. When BNP Paribas sends an MT103 to Banco Santander, SWIFT delivers the message securely, but the actual dollars move through correspondent bank accounts held in New York. If those accounts lack funds, the payment will fail even though the SWIFT message was delivered perfectly and on time. SWIFT is also not a bank, and it does not have a banking licence to take deposits or lend money. It does not decide whether a payment is lawful, and it does not approve or reject a customer transaction. Each member bank remains responsible for checking its own customers, screening against sanctions lists, and deciding whether to release a payment. SWIFT provides the secure channel and the standard message formats, and it validates the format of each message, but the business decision to pay always sits with the sending bank and the receiving bank. A simple example shows the split. Before the CBPR+ migration, a corporate treasurer in Paris instructed BNP Paribas to pay 250,000 euros to a supplier in Singapore. BNP Paribas created an MT103, sent it through SWIFT to DBS Bank in Singapore, and SWIFT delivered it in seconds. DBS then credits the supplier account, but only because BNP Paribas holds a euro account with a correspondent bank that can fund the payment, or because DBS is willing to credit the supplier against the incoming cover. If the correspondent account is empty, DBS will not credit the supplier, and the SWIFT message alone cannot create the money. The distinction matters in operations, in investigations, and in conversations with customers. When a customer asks where the money is, the answer is never simply in SWIFT, because SWIFT never held it. The money is either in a nostro account, in a clearing system queue, or credited to the beneficiary account, and the SWIFT message is the record that explains which of those places it should be. Analysts who understand this boundary can trace a delayed payment correctly, ask the right bank the right question, and avoid blaming the messaging network for a liquidity or compliance problem that belongs to a bank. Worked example with tracking: a corporate treasurer in Paris instructs BNP Paribas to pay USD 250,000 to a supplier in Singapore, and BNP Paribas creates an MT103 with a UETR, the unique end to end transaction reference that SWIFT gpi uses to track the payment. The treasurer watches the status move from ACCP, accepted, to ACSP, settlement in process, to ACSC, settled on the debtor account, and finally to ACCC, credited to the creditor account. Each status update arrives as a pacs.002 message from the bank that handled that leg. Failure and recovery: SWIFT is a messaging network, so when it is unavailable the payments do not disappear, they wait. A bank whose SWIFT connection fails stores its outgoing messages in a queue and sends them when the connection returns, and incoming messages wait at the SWIFT hub until the bank reconnects. The risk is delay, not loss, because no payment is settled until the message arrives and the bank acts on it. A bank that depends on a single connection point keeps a backup route, usually a second line or a service bureau, and switches to it when the primary fails. For a business analyst, product owner or subject matter expert, the SWIFT boundary is the first thing to get right in any requirement. The requirement must state that SWIFT delivers messages and never settles funds, so every test case must check the nostro account balance and the settlement leg, not just the message delivery. The requirement must name the message that carries the instruction, MT103 for a customer payment or pacs.008 after migration, and the message that reports the status, pacs.002. A payment is not complete until the beneficiary account is credited, which is the ACCC status. Source: SWIFT FIN service description; SWIFT gpi rulebook; last reviewed 7 November 2026.