In this article
SWIFT is a member-owned cooperative, headquartered in Belgium, that runs a secure messaging network between financial institutions; a SWIFT payment is a payment instruction sent over that network from one bank to another, while the money itself moves separately, on accounts the banks hold with each other. SWIFT describes itself as a global cooperative owned by its members, in operation since 1973 and connecting more than 11,000 financial institutions. The name stands for the Society for Worldwide Interbank Financial Telecommunication.
That distinction between the message and the money explains what a business notices about an international transfer: why the amount received can differ from the amount sent, why a payment made on Thursday can land on Monday, and why "it has been sent" and "it has arrived" are two different statements. The rules of the network are the same everywhere, but fees and cut-off times are set by each bank, so the fees in the worked example below, computed on an invoice of $80,000, are illustrative.
BIC structure and reference length as published by SWIFT; the charge options are the codes of the payment message.
What is SWIFT?
SWIFT is a cooperative society under Belgian law, owned by the financial institutions that use it, whose business is to carry standardised messages between them securely. It is not a bank and it is not a government body.
The service has three parts. The first is the network itself, a private and secured channel over which a member can send a message to any other member. The second is the set of message standards: a shared format that says where the amount goes, where the beneficiary's account goes, and how each bank in the chain is named, so that a bank in one country can read an instruction written by a bank in another without a prior bilateral arrangement. The third is the directory of identifiers, the codes that tell the network which institution a message is for.
A business does not usually connect to SWIFT. It gives an instruction to its own bank, through online banking or a file, and the bank turns that instruction into a SWIFT message. "Pay me by SWIFT" means an international bank transfer whose instruction travels over this network, as opposed to a domestic transfer through a national clearing system.
What does SWIFT not do?
SWIFT does not hold money, does not keep accounts for customers and does not settle payments. In its own words, SWIFT "does not hold assets nor manage accounts on behalf of customers" and is "solely a carrier of messages between financial institutions". Its oversight description adds that it is neither a payment system nor a settlement system.
- No funds are ever "in SWIFT". At any moment the money sits on an account at a bank: the sender's bank, an intermediary, or the beneficiary's bank. A payment that seems lost is waiting at one of them, and the question to ask is which one.
- SWIFT sets no price for your transfer. The fees a business pays, and the amounts deducted along the route, are charged by the banks involved, each under its own tariff.
- SWIFT does not decide whether a payment is acceptable. Screening against sanctions lists, fraud checks and anti-money-laundering review are carried out by each bank that handles the payment, under the law that applies to that bank.
What is a BIC and how do you read one?
A BIC, or Business Identifier Code, is the 8-character code that identifies an institution on the SWIFT network, optionally followed by 3 characters that identify a branch, for 11 characters in total. It is defined by the international standard ISO 9362, and SWIFT is the registration authority that issues the codes under that standard. Banks and invoices often call it a "SWIFT code".
According to SWIFT's description of the standard, the code breaks down as follows. The example in the last column is invented to show the format and belongs to no institution.
| Part of the BIC | Length | What it tells you | Invented example |
|---|---|---|---|
| Business party prefix | 4 alphanumeric characters | The institution | ABCD |
| Country code | 2 letters, from ISO 3166-1 | The country where it is located | GB |
| Business party suffix | 2 alphanumeric characters | Completes the identification of the institution | 2L |
| Branch identifier (optional) | 3 characters | A specific branch or department | 4T7 |
Two details matter when you copy a BIC onto an invoice. First, the 8-character and the 11-character forms can both be valid for the same bank: the short one names the institution, the long one a branch of it. Use exactly the one your bank gives you for incoming international payments. Second, SWIFT distinguishes connected BICs, which have access to the network, from non-connected BICs, which exist for reference only and cannot receive messages. The code printed on your own bank's payment instructions is the safe source.
A BIC identifies a bank, never an account. The account is identified separately, by an IBAN in the countries that use that format or by a local account number elsewhere, and a payment needs both to be routed and credited without manual work.
How does a payment instruction travel over SWIFT?
A payment instruction travels as a chain of messages: the sender's bank debits its customer and sends an instruction to the next bank, each bank passes the instruction on to a bank with which it holds an account relationship, and the last bank credits the beneficiary.
- The payer instructs its bankThe buyer enters the beneficiary's name, account number, the BIC of the beneficiary's bank, the amount, the currency, a charge option and a payment reference. The bank checks the balance and runs its compliance controls.
- The sender's bank creates the messageThe bank debits the buyer's account, generates the unique reference that will follow the payment, and sends a customer credit transfer message over SWIFT to the next bank in the route.
- An intermediary bank passes it onThe intermediary, where both end banks hold accounts or have a route to one, runs its own controls, debits the account of the sending bank on its books, credits the account of the next bank and forwards the instruction with the same reference.
- The beneficiary's bank receives the instructionThe receiving bank checks that the account exists and matches the instruction, runs its own controls, and applies its conversion if the payment arrives in a currency other than the account's.
- The beneficiary is creditedThe bank credits the supplier's account and, on a tracked payment, confirms the credit back along the chain. The supplier sees the amount, the payer's name and the payment reference on its statement.
The message can cross the world in seconds. The time a payment takes is the time each bank needs to process it, and the hours during which each bank and each currency's settlement system are open.
Which messages carry a SWIFT payment?
Two messages carry almost every commercial payment over SWIFT: the customer credit transfer, which carries the full instruction with the names of the payer and the beneficiary, and the cover payment, which moves the funds between banks when the instruction has been sent directly to the beneficiary's bank. A third, the plain bank-to-bank transfer, moves a bank's own funds and involves no customer.
| Message, in plain words | Traditional name | What it carries | When it is used |
|---|---|---|---|
| Customer credit transfer | MT 103 | Payer, beneficiary, amount, currency, value date, charge option, remittance text | Every payment made for a customer |
| Cover payment | MT 202 COV | The funds for a customer transfer, with the underlying customer details copied in | When the instruction goes straight to the beneficiary's bank and the money follows through correspondents |
| Bank-to-bank transfer | MT 202 | An amount moved between two institutions for their own account | Interbank settlement, with no customer behind it |
With the customer credit transfer alone, the instruction and the funds follow the same path, bank after bank; this is called the serial method. With the cover method, the sender's bank sends the customer credit transfer directly to the beneficiary's bank, which therefore knows early that a payment is coming, and sends a cover payment through the correspondent banks to deliver the money. SWIFT requires the bank issuing a cover payment to copy the original unique reference into it, so that the two messages can be matched.
A business sometimes receives from its payer a copy of the customer credit transfer as proof of payment. That document shows the instruction as the sender's bank issued it: it proves that the payment was sent, with which details and under which reference, and it does not prove that the funds have been credited.
What changed with the move to ISO 20022?
Payment instructions on SWIFT now use ISO 20022, a richer and more structured message format, in place of the older MT format for cross-border payments. According to SWIFT, the migration started in March 2023 with the first release of the cross-border payment messages in the new format, and the period during which the old and the new formats coexisted ended on 22 November 2025.
The older customer credit transfer was a compact text message with numbered fields and tight limits: the remittance information, for instance, held four lines of 35 characters. Its ISO 20022 counterpart, known to banks as pacs.008, is built from labelled data elements, each with a defined meaning: the payer's name in one element, the street in another, the town and the country in others, the reference of the invoice in a dedicated place.
For a business, the change shows in three ways.
- Names and addresses are expected in structured form. A full legal name, a street, a postcode, a town and a country, each in its own field, pass automated screening more easily than a block of free text. SWIFT has announced that unstructured postal addresses will be retired from these messages and has adjusted the timetable for that step, so ask your bank what it requires today.
- More remittance detail can travel with the payment. Invoice numbers and references that used to be cut off can reach the beneficiary intact, when every bank in the route passes them on.
Where does the money settle?
The money settles on correspondent accounts: accounts that banks hold with each other, where a payment is a debit to one bank's account and a credit to another's on the books of the bank that holds both. For the major currencies, the last step usually runs through the settlement system of the country that issues the currency, which is why a dollar payment between two banks outside the United States still passes through a bank there.
How those accounts work, and how each bank on the route is paid for its part, is the subject of the articles on correspondent banks and on correspondent banking fees.
How is a SWIFT payment tracked?
A SWIFT payment is tracked through its unique end-to-end transaction reference, the UETR: a string of 36 characters that the sender's bank generates when it creates the payment and that every later bank must carry unchanged. SWIFT states that intermediary institutions must not generate a new reference when routing a payment, but copy the one they received and pass it on.
Because the reference stays the same from the first bank to the last, each bank can report the status of the payment against it, and the banks in the chain can see where the payment stands: in progress at a named institution, on hold, rejected with a reason, or credited to the beneficiary.
What a business can ask its bank:
- As the payer: the UETR of the payment, its current status, and, if it is on hold, which bank holds it and what information would release it.
- As the beneficiary: ask the payer for the UETR, then give it to your own bank, which can look for the incoming payment before it reaches your account.
- In both cases: the charges deducted on the way, to reconcile the receipt with the invoice.
The step-by-step method for following a payment and confirming its arrival is covered in the article on tracking an international payment. The UETR, not a bank's internal reference number, is the one identifier every bank in the chain recognises.
What do OUR, SHA and BEN mean, and what does the beneficiary receive?
OUR, SHA and BEN are the three codes that tell the banks who bears their charges: under OUR the payer bears all of them, under SHA the payer bears its own bank's charge and the beneficiary bears the rest, and under BEN the beneficiary bears all of them, deducted from the amount on the way. The code is a required field of the customer credit transfer, and the payer chooses it when giving the instruction.
Take a worked example with illustrative fees. A buyer owes a supplier $80,000 on an invoice. The buyer's bank charges $35 to send an international payment. The route has two intermediary banks, which deduct $20 and $15, or $35 together. The supplier's bank charges $12 to receive an international payment. For the OUR option, the buyer's bank adds a flat supplement of $55 to cover the other banks' charges. These fees are invented for the calculation; real tariffs vary by bank, currency and route.
| OUR | SHA | BEN | |
|---|---|---|---|
| Debited from the payer | $80,090 | $80,035 | $80,000 |
| Amount leaving the payer's bank | $80,000 | $80,000 | $79,965 |
| Deducted by the two intermediaries | $0 | $35 | $35 |
| Deducted by the beneficiary's bank | $0 | $12 | $12 |
| Credited to the beneficiary | $80,000 | $79,953 | $79,918 |
| Shortfall against the invoice | $0 | $47 | $82 |
Under SHA, a common choice on payment forms, the supplier receives $79,953 on an invoice of $80,000: a shortfall of $47 that neither party sees until the credit appears. Under BEN, the sender's own $35 comes out of the amount as well, and the supplier receives $79,918, which is $82 short. Under OUR, the buyer pays $90 on top of the invoice, the $35 sending charge plus the $55 supplement, and the supplier is credited the full $80,000.
Three remarks keep this table honest. The OUR supplement is a flat price set by the sender's bank, so the payer can pay more than the banks on the route would have deducted, as here, where $55 covers deductions of $47. OUR expresses an instruction to the other banks, which then claim their charges from the sender's bank; on some routes a deduction still occurs, and the payer's bank is the one to raise it with. And rules can limit the choice: for payments inside the European Union, the recitals of the second Payment Services Directive set out that charges are normally levied on the payer and the payee by their respective providers and that the full amount transferred should be credited to the payee, so the shared option is the rule there.
The charge option is a term of the deal: an invoice that says nothing leaves the choice to the payer's bank form. How the deductions add up across longer routes, and how conversion adds to them, is developed in the articles on correspondent banking fees and on currency conversion.
Why does a SWIFT payment stop or arrive a day later?
A SWIFT payment arrives later than expected when it misses a cut-off time at one of the banks, when the banks on the route work in time zones whose business hours barely overlap, or when one bank holds the payment to check something. The message is fast; the processing behind each message follows banking hours.
A cut-off time is the hour after which a bank treats an instruction as received on the next business day. Each bank sets its own, per currency, and each currency's settlement system has its own operating hours. Consider an illustration with invented hours. A buyer in Singapore instructs a dollar payment on Thursday at 17:00, after its bank's 15:00 cut-off for dollars. The bank processes the instruction on Friday morning, when New York, half a day behind, is still in its Thursday evening. The correspondent in New York handles the payment during its own Friday. The message reaches the supplier's bank in Europe on Friday evening, after that bank's cut-off for incoming payments, and the supplier is credited on Monday. Nothing went wrong: three banks each worked on their own business day. A public holiday in the country of the currency adds a day in the same way.
A payment stops, rather than waits, for a different set of reasons, and nearly all of them are a bank doing its job:
- A detail does not match. The account number does not exist, the beneficiary's name differs from the account holder's, or the BIC belongs to another institution. The receiving bank queries the sender or returns the funds.
- A screening control raises a question. A name, a country or a word in the remittance text resembles an entry on a sanctions list, and a compliance officer has to review it before the payment continues.
- Information is missing. The purpose of the payment, the address of a party, or a document required by the destination country's rules has not been supplied.
How to prepare a large transfer so that it does not stop is treated in the article on avoiding SWIFT delays on a large transfer, and the reasons behind the usual timescale in the article on why international wire transfers take so long. One rule is enough here: ask your bank for its cut-off time in the currency you are sending.
Who oversees SWIFT?
SWIFT is overseen by central banks, with the National Bank of Belgium acting as lead overseer because SWIFT is incorporated in Belgium. The European Central Bank states that the G10 central banks, itself included, perform cooperative oversight of SWIFT, and that this oversight focuses on the security, operational reliability, business continuity and resilience of its infrastructure.
The reason for this arrangement is the position SWIFT holds. The European Central Bank describes it as the messaging service provider for most of the systemically important payment and securities clearing systems, so a failure of the network would affect systems that central banks are responsible for. SWIFT's own account of the arrangement dates it to 1998, names the Federal Reserve System, the Bank of England and the Bank of Japan among the central banks involved, and mentions an Oversight Forum set up in 2012 to share information with a wider group of central banks.
Oversight of SWIFT is not supervision of your payment. The conduct of each bank, its fees, its handling of a complaint and its compliance controls fall under that bank's own supervisor, in its own country.
Can a bank be disconnected from SWIFT?
Yes: a bank can be disconnected from SWIFT when a law that binds SWIFT prohibits it from providing messaging services to that bank. SWIFT states that it is incorporated under Belgian law and must comply with European Union regulation, and that any decision to impose or lift sanctions rests solely with the competent government bodies and legislators.
SWIFT's published account gives the instances. In March 2012, under EU Regulation 267/2012, it disconnected the Iranian banks sanctioned by the European Union; many were reconnected after being de-listed in January 2016, and SWIFT suspended certain Iranian banks' access in November 2018. In 2022, in March and in June, it disconnected the Russian entities designated under EU Council Regulation 833/2014, and the Belarusian entities designated under EU Council Regulation 765/2006.
For a business, the operational meaning is narrow and concrete: a disconnected bank cannot send or receive messages over the network, so a payment to an account held there cannot be instructed through the usual route, and your own bank will refuse or return it.
What does an invoice need for a SWIFT payment?
An invoice paid by SWIFT needs the exact legal name of the account holder, the account number in the format of the beneficiary's country, the BIC of the beneficiary's bank, the currency, the charge option, and a short reference the payer must quote. Each item answers a question that a bank on the route will otherwise have to ask.
- Beneficiary name: the legal name exactly as it appears on the bank account, not a trading name or an abbreviation.
- Beneficiary address: street, postcode, town and country, written so that each part can be entered in its own field.
- Account number: the IBAN where the country uses it, otherwise the local account number with any national bank code the country requires.
- Bank name and BIC: the code your bank gives for incoming international payments, in the 8-character or 11-character form it specifies.
- Intermediary bank, if your bank names one: some banks publish the correspondent through which they receive a given currency; when yours does, copy it for that currency.
- Amount and currency: the currency in which the account is held, or a clear statement of which party bears the conversion.
- Charge option: written in words as well as in code, for instance "all bank charges for the payer's account (OUR)".
- Payment reference: the invoice number, short and without special characters, so that it survives in the remittance field.
On large amounts, state the purpose of the payment in plain words ("payment of invoice 2087 for machine parts"), because a clear purpose answers a screening question before it is asked. And ask the payer to send the UETR once the payment has left, so that your bank can find the payment on its way in.
