How a SWIFT Payment Works

Every day SWIFT carries more than 53 million messages between banks across 200+ countries.

It doesn't move a single pound of anyone's money.

To understand international transfers, it helps to look at the two pieces of information you're always asked for: your IBAN and your SWIFT code.

The difference between IBAN vs SWIFT code

IBAN: Think of this as your full address down to the specific room. It's your account number, written out the long way. It starts with the country, then the bank, then the account number itself. No two are alike.

SWIFT code: This is just the front door of the building. It doesn't know who you are or what your account balance is; it only identifies the financial institution holding the funds.

Whether you need both depends on where the money is coming from.

A UK client paying you in sterling won't ask for a SWIFT code or an IBAN at all, just your sort code and account number, because that payment never leaves the domestic system. Payments moving between euro-area banks can usually route on the IBAN alone.

But the second a transfer comes from further afield - say, a client in the US or a supplier in Singapore - the sending bank needs that SWIFT code to figure out which institution to route through.

How funds travel behind the scenes

Since SWIFT is just a secure messaging network, the actual cash moves separately through direct banking relationships. When two banks have no direct relationship, the payment passes through one or two intermediary banks first.

Each handoff adds time (usually a day), and often a processing fee.

There's no faster SWIFT payment to shop for, since speed isn't really the part that's negotiable. What helps is not needing SWIFT in the first place, at least for currencies you already hold.

A euro invoice clears via SEPA, and a sterling invoice runs on Faster Payments - fast, direct, and without intermediate fees. You can open an account with Ampere - accounts can be issued in GBP, EUR, USD and CHF, each with its own IBAN, so which rail a payment takes comes down to the currency.

SWIFT's been around since 1973, which in tech years makes it roughly the same generation as the fax machine, and just as stubbornly still in daily use. Every few years someone declares it about to be replaced. It's still here because pulling out isn't really an option when upwards of eleven thousand banks worldwide are already plugged into it.

Why your invoice arrived short

You invoiced £5,000, but only £4,950 landed. Nobody's done anything wrong, and nobody's going to send an email explaining where the missing £50 went.

Every international transfer carries a three-letter code deciding who absorbs the handling charges on the way. Your client picks it when they send the payment, usually without thinking about it, because the default is already selected.

SHA is that default, which is why this happens as often as it does. One company paying a $12,000 invoice picked it to save on fees. The supplier received $11,940, flagged the invoice as unpaid over the missing $60, and paused delivery while everyone worked out what happened. The saving was smaller than the disruption.

If exact amounts matter, the fix is a line in your payment terms asking clients to send with charge code OUR. It costs them a few pounds more and saves you an afternoon of reconciliation.

When a payment goes missing

Every SWIFT payment gets a unique tracking reference, a UETR, generated when it's sent. It works like a parcel tracking number, and you can ask whoever sent the payment for it.

The other useful document is the MT103, the formal record of a completed transfer, showing the amount, the date, and everywhere the payment passed through. If a client insists they've paid and nothing has landed, asking for the MT103 settles it quickly.