The wire arrives and it is short. Not by a rounding error, by enough to notice. You check the invoice, the client confirms what they sent, and the two numbers do not agree.
Nothing went wrong. This is just what a SWIFT payment costs, spread across four charges of which one was quoted to you.
SWIFT is a message, not a rail
The first thing worth correcting: SWIFT does not move money. It is a secure messaging network banks use to instruct one another.
The money moves through correspondent banking. Your client’s bank holds an account with a bank that holds an account with another bank, and so on, until the chain reaches yours. The payment is a series of ledger entries along that chain, not a parcel in transit.
This matters because every hop is a bank doing work it expects to be paid for, and that is where the cost lives.
The four leaks
| Charge | Who takes it | How it scales | Quoted up front? |
|---|---|---|---|
| Outgoing fee | Sender’s bank | Flat | Yes |
| FX spread | The converting bank | Percentage of amount | No, inside the rate |
| Correspondent deduction | Each intermediary | Flat, per hop | No |
| Receiving fee | Your bank | Flat | Sometimes |
One of four is visible before the payment happens. The rest are discovered on your statement.
A worked example
Take a $3,000 invoice from a US client to a contractor in a corridor that needs one intermediary. Using mid-range assumptions, not a quote from any specific bank:
| Step | Effect | Running total |
|---|---|---|
| Client sends | $3,000 | $3,000 |
| Outgoing wire fee | Paid by client, does not reduce transfer | $3,000 |
| FX spread at 2.5% | Priced into the rate | $2,925 |
| One correspondent deduction | Flat, taken in transit | $2,905 |
| Receiving bank inbound fee | Charged by your bank | $2,890 |
The client believes they paid $3,000. You received roughly $2,890. The gap is about 3.7 percent, and the largest single component is the one that never appeared as a line item.
Change the assumptions and the total moves, but the shape does not: the spread dominates, the flat fees compound, and only the first is knowable in advance.
Treat these as illustrative ranges. Actual spreads and fees vary by bank, corridor and amount, so the only way to know yours is to compare the applied rate against the reference rate for that pair at the same timestamp.
Where the pain lands
Small invoices suffer from the flat fees. A $20 receiving fee on a $3,000 payment is noise. The same fee on a $300 payment is 6.7 percent before anything else is counted. If you invoice small amounts frequently, the fixed costs are the whole problem.
Large invoices suffer from the spread. The spread is proportional, so it grows with the payment. On $20,000, two and a half percent is $500, which dwarfs every flat fee in the chain.
There is no invoice size at which SWIFT is efficient. There is only a size at which one leak hurts more than the others.
The one change worth making today
Ask your client to send OUR rather than SHA.
Every wire instruction carries a charge code. SHA, the usual default, splits the cost: the sender pays their own bank, and you absorb the correspondent deductions and the receiving fee. OUR puts the whole chain on the sender, so the invoice amount reaches you intact.
This is a single field on the payment instruction. If your contract says you are paid $3,000, it is reasonable to ask that $3,000 is what arrives, and the charge code is how that happens.
Then put it in writing. A contract that specifies the amount is net of transfer charges gives you something to point at when the numbers disagree. See payment terms for contractor contracts.
When SWIFT is still right
For a large one-off payment into a corridor with no local alternative, SWIFT is fine. The flat fees shrink as a share of a big number, and the network genuinely reaches everywhere.
It is the recurring case that goes wrong. Twelve monthly invoices mean twelve outgoing fees, twelve receiving fees, twelve rounds of correspondent deductions, and twelve applications of the spread.
What the alternative looks like
The structural fix is to stop crossing borders on every payment. A platform receives domestically where your client is, then pays you out locally where you are, so the correspondent chain never enters the picture.
On Omnivoo Contract Management, the client pays a per-contractor subscription from $49 a month, the underlying rail cost passes through at cost with competitive FX. The fee is shown before you confirm, which is the difference that matters: you decide with the number in front of you instead of reconstructing it afterwards.
SWIFT remains available as a payout rail alongside bank transfer and ACH, and five more payout methods, because some corridors still need it.
The bottom line
SWIFT is not overpriced for what it does. Reaching any bank in the world through a chain of correspondents is genuinely hard, and the chain expects to be paid.
It is simply the wrong tool for a monthly invoice. If you are on it by default rather than by choice, ask for OUR charges this month, and look at what a domestic-in, local-out payout would cost you across a year rather than a single transfer.