The support ticket arrives in the same shape every time. A trader wires a round figure to fund an account, the confirmation from their bank shows the full amount debited, and the firm's statement shows a smaller credit. The trader wants to know who took the difference. Usually nobody can name them, because the deduction happened at a bank neither side chose.
Understanding that gap starts with a correction: SWIFT does not move money. It is a secure messaging cooperative that carries payment instructions between member institutions. The money itself moves through accounts that banks hold with each other, and each bank in that chain is a business that charges for the work.
The correspondent chain is where the deductions happen
A bank in Almaty does not hold an account at a bank in Limassol. So when a payment has to travel between them, it hops through institutions that do hold accounts with each other, typically a large bank in the currency's home country. A dollar payment settles through a US correspondent, a euro payment through a euro clearing bank, a sterling payment through a UK institution.
Every hop is a real posting on a real balance sheet, and the intermediary bank has no relationship with either the sender or the beneficiary. It has no way to invoice them. So it takes its fee out of the payment as it passes, a practice the industry calls a lifting fee. Two intermediaries means two deductions. The sender sees none of this on their outbound confirmation, because at the moment they pressed send the routing had not been decided yet.
This is also why a payment can take three or four working days without anything being wrong. Each institution applies its own cut-off time, and a message that lands after cut-off waits for the next value date. Add a weekend and a public holiday that is observed in the correspondent's country but not the sender's, and a Thursday instruction credits on Tuesday.
OUR, SHA and BEN decide who absorbs the cost
Every SWIFT payment carries a charge code in field 71A. It is a small field with a large effect on what actually lands.
| Code | Who pays | Effect on the credited amount |
|---|---|---|
| OUR | Sender pays every fee in the chain | Beneficiary should receive the full instructed amount |
| SHA | Sender pays their own bank, beneficiary absorbs the rest | Credited amount is reduced by intermediary and receiving fees |
| BEN | Beneficiary pays everything | Credited amount is reduced by all fees including the outbound one |
SHA is the default in most retail banking apps, and most senders never see the choice. It is also the code that produces the surprise, because the sender's receipt is accurate about what they paid and silent about what the beneficiary will get. OUR costs more at the counter and removes the ambiguity, which is why firms paying suppliers on fixed invoices generally insist on it.
If a broker or prop firm credits client accounts by the amount that actually arrives, a SHA wire creates a permanent reconciliation gap. Decide the policy in writing before the first ticket: either credit the received amount and say so in the deposit terms, or absorb the deduction as a cost of acquisition.
The exchange rate is usually the bigger charge
Flat handling fees are visible and annoying. The conversion margin is invisible and larger. If a client's bank converts euro into dollars before sending, it applies a retail rate that includes a spread over the interbank mid, and no line item on the statement calls that a fee. On a five-figure transfer, that margin can dwarf every flat charge in the chain combined.
Worse, the conversion can happen twice. A client sends euro, an intermediary converts to dollars, and the receiving bank converts back because the account is denominated in euro. Each leg carries its own spread. The defence is boring and effective: send in the currency of the destination account, so the payment never needs converting in transit. That is one of the practical arguments for holding balances in more than one currency rather than converting on every movement, and the same logic sits behind how conversion fees are actually priced.
When SWIFT is the wrong rail entirely
Plenty of payments go through SWIFT out of habit rather than necessity. A euro payment between two accounts in the SEPA area does not need a correspondent chain at all: SEPA credit transfers are priced as domestic within the EU, settle in a business day, and SEPA Instant settles in seconds with no intermediary taking a slice. We wrote out the full split in SEPA versus SWIFT.
Local rails do the same job in other regions, and modern payment institutions exploit that. When a provider offers a cheap international transfer, it is often not sending a wire at all. It is collecting locally at one end, paying out locally at the other, and netting the positions internally. The trade-off is coverage and account limits, plus the risk of an account being closed with balances inside it.
What a trading firm should build around this
Firms that take client deposits by bank transfer end up with three recurring problems: amounts that do not match the requested deposit, references that get stripped in transit, and payments arriving from a name that does not match the account holder. The first is fee deduction, the second is a field-length issue in the chain, and the third is a compliance stop that has nothing to do with fees.
The operational answers are unglamorous. Issue a unique reference per deposit and match on amount plus sender name when the reference vanishes. Publish an expected settlement window rather than a promise. Give clients a named contact for tracing, because a SWIFT payment can be traced through the unique end-to-end reference, and a bank will usually produce the deduction history when asked. Firms running deposits at volume put this reconciliation logic inside the back office where the client ledger lives, so a partial credit raises a flag instead of a support ticket.
And expect the rejections that have nothing to do with money. Some institutions refuse accounts whose IBAN is issued in a country other than the one the client lives in, a practice covered in IBAN discrimination. That one is a policy problem, not a pricing problem, and no charge code will fix it.
"Nobody argues about the fee. They argue about the surprise. Tell a client up front that a wire may arrive light and roughly why, and the same deduction that would have cost you an hour of support costs you nothing."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- SWIFT carries instructions, not funds. The deductions come from correspondent banks that settle the payment and bill by taking a slice of it.
- The charge code decides the outcome: OUR delivers the full amount at higher cost to the sender, while the default SHA lets every intermediary reduce the credit.
- Conversion spreads usually cost more than the flat fees, and sending in the destination account's currency removes the conversion entirely.
- A firm taking deposits needs a written policy on short credits, a unique reference per payment, and a matching rule that survives a stripped reference.
Frequently Asked Questions
Why did my broker receive less than I sent by SWIFT?
Under the SHA charge code, which most banks apply by default, any intermediary bank in the settlement chain may deduct its own handling fee from the payment before passing it on. The sender pays their own bank's outbound fee, and every bank after that takes its slice from the principal, so the amount credited is smaller than the amount instructed.
What is the difference between OUR, SHA and BEN?
OUR means the sender pays all charges and the beneficiary should receive the full amount. SHA splits them: the sender covers the outbound fee and the beneficiary absorbs the rest. BEN means the beneficiary pays everything, including the sender's own outbound fee. OUR usually costs the sender more up front but makes the credited amount predictable.
Is SEPA cheaper than SWIFT for euro payments?
For euro payments between accounts inside the SEPA area, yes. SEPA credit transfers are domestic-priced by regulation in the EU, settle in one business day or in seconds under SEPA Instant, and have no intermediary bank chain deducting fees. SWIFT is the right rail only when the currency or the country sits outside SEPA.