Who pays intermediary bank fees on a wire transfer?
It depends on two things: the charge code on the payment, and what kind of charge it is. The code decides who absorbs deductions taken from the money while it travels. It does not stop a bank billing its own customer separately, and that second category is outside its reach.
Where SHA applies, and it often does by default, those travelling deductions land on you.
If a wire arrived short and you cannot find a fee that explains the gap, this is usually why. The deduction was not made by your bank or by your client's bank. It was made in the middle, by an institution neither of you chose, under an instruction neither of you consciously set.
What is the charge code on a wire transfer?
It is a field on the payment saying who is expected to absorb the charges raised as the money moves.
For most of the last two decades that field was 71A, "Details of Charges", in the SWIFT MT103 message, carrying OUR, BEN or SHA. Those three labels are still what banks show customers, which is why they are the ones you will meet in practice. Underneath, the picture changed: for cross-border payments carried on the Swift network under the CBPR+ programme, the MT and ISO 20022 coexistence period ended in November 2025 and MT103 moved to legacy status in normal CBPR+ processing. Two qualifications matter. Domestic payment schemes migrated on their own timetables, so MT-era practice persists outside CBPR+ scope. Swift also introduced contingency processing for certain MT payment instructions as a short-term fallback. Eligible MT messages can still be converted to ISO 20022 after the migration deadline, subject to additional validation and charges. That means MT has not disappeared from every live processing path, even though ISO 20022 is now the normal CBPR+ format.
In the ISO 20022 message the equivalent field is Charge Bearer, and it has four codes rather than three.
| Legacy label | Charge Bearer | Who is expected to absorb charges |
|---|---|---|
| OUR | DEBT | The sender, including intermediary and beneficiary bank charges |
| SHA | SHAR | Each side pays its own bank; deductions in the middle fall to you |
| BEN | CRED | You, and every institution in the chain may deduct |
| none | SLEV | Charges follow the rules of the applicable scheme or service level |
The mapping is close but not exact, and SLEV is the reason. It means charges are determined by the rules of the applicable scheme or service level rather than allocated per payment by the sender. SEPA Credit Transfers are the case most people will meet: SLEV is the required code there, and the scheme's rules do not permit deductions from the transfer amount. The same code covers other bilateral arrangements that have nothing to do with SEPA.
SHA is widely used, and is a common default for international wires. It is not universal, and inside the EEA the choice is constrained by regulation rather than by the bank. In practice, the setting is often determined by the bank, payment scheme or default instruction rather than actively chosen by the sender.
One limit worth stating early. The code governs what may be deducted from money in transit. It does not stop a bank charging its own customer directly. That distinction explains most of the confusion in the sections below.
How much do intermediary banks actually take?
Enough to notice, and you cannot know in advance.
A wire between two banks with no direct relationship is routed through one or more correspondent banks. Each can deduct a handling charge from the amount in transit, and more than one institution in the chain is common. Published examples put the combined deduction in the tens of dollars: one business banking provider illustrates it with a $1,000 wire arriving as $950 after intermediary charges.
Separately, your own bank may charge for accepting an inbound international wire. One survey of US institutions puts the median incoming international wire fee at $15, and this charge is often taken out of the arriving amount rather than billed to you separately, which is why the two are easy to confuse. The incoming wire fee is one of four separate points where a cross-border payment loses money, and only one of those four is decided by the charge code.
None of these appear on the confirmation your client sends you. You discover them by subtracting what arrived from what you invoiced.
Does choosing OUR mean the money arrives in full?
From the payment, largely yes. From your account, not necessarily.
Under OUR, the sender is responsible for charges raised along the way, and the standard's own definition extends that to the beneficiary bank's charge as well. The instruction is intended to prevent charges being deducted from the money in transit, which is the behaviour you want.
What it does not stop is your own bank billing you directly for receiving an international payment. That charge is levied on you as its customer rather than deducted from the wire, so it sits outside the instruction entirely. A payment sent as OUR can still leave you out of pocket by that amount, and it is not a sign the instruction failed.
Implementation also varies between banks in ways you cannot audit from the receiving end. If the amount matters, the useful step is for your client to confirm with their own bank how it applies the instruction and whether it charges extra for it, rather than assuming the label guarantees an outcome. Treat OUR as a strong improvement rather than a guarantee.
Is OUR more expensive overall?
For your client, yes. For the two of you combined, usually not, and that is the argument worth making.
Sending as OUR typically costs the sender a fixed premium on top of their normal wire fee. One business banking provider charges a flat $15 for it. The premium is fixed and known in advance.
What it replaces is variable and unknown. Under SHA, the same payment might lose a handling charge to a single intermediary, more to two, or nothing at all if the routing happens to be direct.
So the comparison is not "who pays" but "which costs less in total". One provider publishes both halves of this: a flat $15 to send as OUR, and a worked example of a $1,000 wire arriving as $950 under SHA after intermediary charges. Set side by side, that is $15 spent against $50 lost.
Those two figures come from a single provider on a single route. They are not a benchmark, and the point is the shape rather than the amounts: a known cost on one side, an unknown one on the other.
Whether OUR wins depends on the route. If the payment happens to travel without intermediaries, SHA costs nothing and the OUR premium is money spent on a risk that did not materialise. If it passes through two, the premium was cheap. Neither you nor your client can tell in advance which route a given payment will take, which is what makes the fixed premium worth considering: it converts an unknown cost into a known one.
What keeps SHA in place is not economics. It is that the cost under SHA is invisible to the person making the choice, while the cost under OUR appears on their statement.
That asymmetry is the whole reason this conversation is difficult, and knowing it makes the request easier to phrase.
How do you ask a client to send it as OUR?
Briefly, in writing, before the first payment.
Most clients have no opinion about charge codes and will agree without much thought, because it is one dropdown to them and a real number to you. What causes friction is raising it after a payment has already arrived short, which reads as a complaint rather than a setup instruction.
Wording that works, in a contract or in the email confirming payment details:
Please send payment with charge code OUR, so that the full invoiced amount arrives. Your bank may charge a small fixed fee for this, typically less than the deductions it avoids.
Two things to expect in the reply.
Some clients will say the option is not there. They are often right, and there are two separate reasons. Retail and small-business banking interfaces frequently do not expose the field at all and send everything as SHA silently. Where it does exist, it tends to be buried under a label like "fee instructions" or "charges" rather than anything containing the word OUR.
The second reason is regulatory, and it is worth knowing before you ask. European payment rules restrict the charge options on certain transfers and apply a full-amount principle, and bank documentation reflects this: some institutions state that the sender-pays-everything code cannot be used for payments to and from EEA countries. Whether it applies to your payment depends on the currency and on where both banks sit, so it is not a blanket rule. If your client is in Europe and tells you the option is unavailable, this is a likely reason rather than an oversight on their part. The upside is that the same rules are designed to limit deductions from the transfer amount in the first place.
Others will ask you to absorb it, which is a reasonable commercial position. If so, price it in: the deduction is a cost of the engagement, and it belongs in your rate rather than in a surprise at the end of the month.
What if the money has already arrived short?
Work out which layer took it before doing anything else.
Compare the amount your client sent against the amount that arrived. Then ask your bank what it charged for the incoming payment. If that number explains the whole gap, nothing was deducted along the way and the charge code was not the problem.
If a gap remains, a deduction in the chain is one explanation, but not the only one. If a currency conversion happened between the two ends, it will produce a difference that no fee accounts for. Which of the two dominates depends on the amount and on the specific fee and spread involved, which is a calculation rather than a rule of thumb. Your client's own bank may also have deducted before sending. Before concluding anything, check whether the amount your client was debited matches the amount they intended to send, and whether a conversion happened at all.
Chasing a past deduction is rarely worth it. The useful output is the number itself: once you know what a route costs you all in, you can decide whether to change the charge code, change the rail, or raise your rate. If the gap turns out to be larger than any fee explains, the likely cause is the exchange rate spread rather than a charge.
Is there a way to avoid the question entirely?
Yes, by not using the correspondent chain.
Payments that settle on a domestic rail never enter it, so no intermediary exists to charge anything. Euro payments sent as SEPA Credit Transfers are the clearest example: there are no correspondent banks in the path, and the charge code question does not arise. The same logic applies to other local payment systems.
In practice this means asking one question before the charge code question: can my client pay into an account that is local to them? If the answer is yes, most of this article stops applying.
Sources: Swift for the end of the MT coexistence period; Federal Reserve Financial Services for Charge Bearer code definitions; Deutsche Bank, Payments Formatting Guide for legacy field 71A; Mercury for published OUR pricing and the worked example; NerdWallet for surveyed incoming wire fees.
Fee ranges cited are published figures at the time of writing and vary by bank, route and currency. Check current terms before deciding.