OUR, SHA and BEN are the three charge codes in field 71A of a SWIFT MT103 wire, and they decide who pays the banks' fees. OUR bills the sender for every bank's charges, SHA splits them between sender and recipient, and BEN deducts all of them from the amount sent. Audit a quote by what lands.
A supplier paid less than the invoice does not see a fee. They see an unpaid invoice. The cause is usually printed on a message your bank can send you. This guide shows what each code does to the same invoice, the fees it does not touch, and seven checks for any wire quote. How a wire compares with a stablecoin route is a separate question, covered in stablecoins vs SWIFT for B2B payments.
What do OUR, SHA and BEN mean on a wire?
The three codes are the allowed values of field 71A, "Details of Charges", in the SWIFT MT103 customer payment message. The field is mandatory, so every SWIFT wire carries exactly one of them.
The wording below comes from the MT103+ field specification as reproduced in a bank's published manual (see the methodology section for the edition).
The three charge codes and what each one pays, per the MT103 field 71A definition.
Code | SWIFT definition | In practice | Fields 71F and 71G |
OUR | All transaction charges are to be borne by the ordering customer | The sender pays the banks' charges, usually through a surcharge, so the recipient should see the full invoice | 71F not allowed, 71G optional |
SHA | Charges on the sender's side are borne by the ordering customer, charges on the receiver's side by the beneficiary customer | The sender pays the sending bank, and what other banks take comes out of the payment | 71F optional, 71G not allowed |
BEN | All transaction charges are to be borne by the beneficiary customer | Every bank's fee, the sending bank's included, is deducted from the amount | At least one 71F required, 71G not allowed |
Field 71F lists sender's charges deducted along the way and field 71G lists receiver's charges the sender prepaid. The last column holds the message's validation rules for them.
Payments between two banks inside the European Union follow their own charge-sharing rules, so this audit targets wires outside them.
On Lumx, SWIFT payouts are in USD only, and every SWIFT payout carries UETR and MT103 confirmations. The customer does not choose OUR, SHA or BEN: Lumx deducts its wire fee from the sender. The minimum is 40 US dollars per SWIFT payout.
The same invoice under each code
Hold the invoice constant and move only the code. Let A be the invoice amount. Let S be the sending bank's fee, X the surcharge for choosing OUR, D the deductions by intermediary banks and R the receiving bank's incoming fee. The letters stand for the figures on your own quote and your bank's fee schedule; this guide prints no bank tariff or typical range. The numbers below are an illustration of the algebra, not a tariff and not a Lumx price: A = 10,000 USD, S = 5, X = 5, D = 5 and R = 5.
One invoice A sent as OUR, SHA or BEN, with the cost carried by each side. Illustrative figures in USD, not from any bank's tariff.
OUR | SHA | BEN | |
Sender pays in total | A + S + X = 10,010 | A + S = 10,005 | A = 10,000 |
Recipient receives | A = 10,000, less any receiving-bank fee the prepayment did not cover | A - D - R = 9,990 | A - S - D - R = 9,985 |
Fee visible on the sender's quote | S and X | S | None as an added line; S is deducted from the amount |
Short on the supplier's statement | 0 | 10 | 15 |
What the supplier can ask for | Nothing, if the amount matches | A copy of the MT103 | A copy of the MT103 |
Read the table by column. OUR moves the cost to the person who chose the wire and can budget for it. SHA and BEN move it to a person who was never shown the quote. Only OUR lets the payer promise a supplier a number.
Where fees escape the charge code
The code governs bank charges on the payment instruction. It does not govern four other places where an amount shrinks.
The first is the exchange rate. If the recipient's bank converts the dollars, a bank you never dealt with sets the markup, and it never appears as a fee line. Which reference rate to compare against is covered in PTAX or live quote for BRL, and the wider pricing structure in how stablecoin payout pricing works.
The second is the receiving bank. A bank may charge the recipient to credit an incoming foreign payment. The sender's quote does not show it, because another institution charges it.
The third is repair. A wire queried because of a wrong beneficiary name, a missing field or an address the bank cannot read can carry investigation and return fees, and a returned payment can come back at a different exchange rate. Before submitting a SWIFT address on Lumx, verify:
Address line 1 and line 2 together are at most 70 characters.
City is at most 35 characters.
State is exactly 2 letters.
Postal code is at most 16 alphanumeric characters.
Country is exactly 2 letters.
The whole address is at most 140 characters, with no unsupported symbols.
The fourth is the offer that says "no fee". Where a fee is not on a line, it is in the rate. A wire quote that says "intermediary fees may apply" is a price with a blank in it.
On Lumx, a conversion quote returns the base rate next to the final rate, so the conversion cost is one subtraction: the gap is Lumx's fee, any partner fee and any lock fee, with no FX margin inside the rate.
How do you audit a wire quote in 7 points?
A quote passes the audit when you can compute what the recipient receives, name every party who can still take money out of it, and check the result against the message after the first payment. The Financial Stability Board's G20 targets ask every payment service provider to show payers and payees, by end-2027, the total transaction cost (including intermediaries' fees, the FX rate and conversion charges), the expected delivery time, payment tracking and terms of service. The seven checks turn that list into questions for a bank or a provider.
Seven checks for any cross-border quote, each with the answer that passes and the answer that fails.
# | Check | Passes when | Fails when |
1 | Ask for the charge code in writing | The quote names OUR, SHA or BEN and says whether you can choose it | The code is set in a form you never see |
2 | List every fee line and the bank that charges it | Sending fee, OUR surcharge and FX fee each have their own line | One "total fee" with no breakdown |
3 | Ask who can still deduct after the code | The answer says whether intermediary and receiving banks can take anything | "May apply" |
4 | Pull the mid-market rate in the same minute and compute the spread | The spread is a percentage you can recompute from two numbers | One rate with no reference |
5 | Get the amount received, in the recipient's currency, in writing | A number, not "approximately" | The amount is shown only in the sender's currency |
6 | Check how long the price holds | An expiry time later than your approval step | "Indicative until execution" |
7 | After the first payment on a corridor, read 71A, 71F and 71G | What landed equals what was quoted, and the message explains any gap | No message to read, or a confirmation email in its place |
Teams usually skip the seventh, the only one that tests the bank rather than the quote.
On Lumx, check 1 has a plain answer: no choice of code, and the wire fee comes from the sender. Check 6 has a concrete one: a locked rate holds for 30 seconds with no fee, or for one or five minutes with a fee, and if the lock expires you request a new rate under a new exchangeRateId. The lock covers the conversion quote, not bank charges on a wire. For check 7, every SWIFT payout carries UETR and MT103 confirmations, per-rail references and webhooks. UETR is the end-to-end reference that lets you, or the recipient's bank, trace the payment by one identifier instead of by amount and date.
Which code to pick for a supplier invoice
If the supplier must be paid the invoice to the cent, choose OUR, pay the surcharge (X = 5 in the illustration above) and say so in the payment terms. Ask the sending bank for the MT103 copy on the day the payment goes out, and compare field 71A with what you chose. If the contract has the supplier absorbing bank charges, SHA is a fair default. BEN deducts even the sending bank's fee from the supplier, which few suppliers expect.
On a bank wire where I pick the code, I would send the first payment on any new corridor as OUR, ask the bank for the MT103 the same day, and read 71A, 71F and 71G against the quote before sending the second one. The surcharge is a known cost and a short-paid invoice is an unknown one, paid for in the supplier relationship. If the MT103 shows the supplier received the full amount, I would keep OUR for invoices where the supplier reconciles to the cent and consider SHA only where the contract already says the supplier bears the receiving side.
Choosing a code moves a cost. If a corridor is paid every week, ask whether the wire is the right instrument.
When a wire is not the right instrument
Chasing the charge code is the wrong exercise when the destination has a local rail. A payment over Pix (Brazil's instant payment system, run by the Central Bank) or SPEI (Mexico's interbank transfer system, run by Banxico) has no correspondent chain, so there is no intermediary to deduct. Payout limits and cut-offs by rail sets out the cut-offs, and the corridor logic is in what a stablecoin corridor is.
A stablecoin route is not free either. It carries a network cost, a conversion spread, rail fees and a partner fee if the platform adds one, but they are lines on a quote rather than deductions after it.
A wire stays the right instrument when the beneficiary's country has no local rail a provider reaches, or when the supplier's treasury accepts funds only from a bank.
Where USD by SWIFT is the remaining route, the audit above is the tool, and sending a SWIFT payout from USDC walks the payout. SWIFT on Lumx is USD only, so a supplier who is owed euros is paid by SEPA and one owed pounds by Faster Payments (the UK's real-time bank transfer network), not by a wire.
What the audit looks like on a Lumx payout
Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.
A payout to a supplier in Brazil or Mexico goes over Pix or SPEI, and Lumx does not deduct a fee from the amount that reaches the recipient on either; only the recipient's own bank can charge them. A payout to a country with no local rail goes out as a USD wire over SWIFT, and the settlement target is one to five business days with a 3:00 PM ET cut-off, subject to intermediary bank hours. The docs add that international wires may pass through correspondent banks, which can add hours or days and may deduct fees outside Lumx's control. Suppliers in Hong Kong or Singapore receive USD by SWIFT into a USD account, per the Lumx marketplaces guide.
On the SWIFT leg the sender shown to the beneficiary is the customer's own registered legal name, which is the sender-of-record rule for SWIFT in the Lumx docs. The migration prompt in the Lumx docs, migrate SWIFT wires to local rails, maps each wire corridor to a local rail where one exists and keeps the wire as the fallback.
Pricing follows the structure the audit asks for. The agreement is a monthly platform fee plus usage-based per-transaction fees, with transparent FX on locked quotes and no pre-funding. The trace after the payment runs on UETR and MT103. The coverage and rails per country are on global payments and the coverage page, and the difference between a bank API and a stablecoin API is in stablecoin API vs traditional banking API.
The conversion pairs are USDC to USD for a wire, USDC to BRL for Pix and USDC to MXN for SPEI.
Methodology and sources
The charge-code definitions and the 71F and 71G validation rules were read in the MT103+ section of the Millennium bcp MT103 manual, which reproduces the SWIFT Standards FIN Category 1 text from the Preliminary Standards Release Guide 2006 of November 2005. Read on November 1, 2026. That edition is old, so check current definitions in your bank's SWIFT Standards documentation.
The transparency list is from the Financial Stability Board's G20 targets for enhancing cross-border payments, read on November 1, 2026.
No bank tariff is printed on purpose, because figures differ per bank and per date. PSD2 (Directive (EU) 2015/2366) sets its own charge-sharing rules inside the Union and is not summarized here.
Lumx facts come from the Lumx docs pages on payment rail cut-off times, sender of record, exchange rates, coverage and the marketplaces guide, read on November 1, 2026.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Sung Jin Cho on Unsplash.
What are OUR, SHA and BEN wire fees, and who pays each?
They are the three charge codes in field 71A of a SWIFT MT103 wire. OUR means the sender pays all banks' charges, SHA splits them between sender and recipient, and BEN deducts all of them from the amount. On Lumx, SWIFT payouts are in USD only, each carries UETR and MT103 confirmations, and the customer does not choose the code.
Does choosing OUR make sure the supplier gets the full invoice?
It moves the banks' charges to the sender, but the wire still crosses banks you did not choose, and a receiving bank can have its own fee for crediting an incoming payment. Ask for the amount received in writing and check the MT103 after the first payment. On Lumx, a locked rate covers the conversion quote and not bank charges.
How do I find out which bank took a fee from my wire?
Ask the sending bank for the MT103 and read field 71A for the code, then 71F for sender's charges deducted along the way and 71G for receiver's charges prepaid. If the fields are empty and the amount is short, the gap is probably in the exchange rate or at the receiving bank. On Lumx, the UETR on a SWIFT payout traces the payment end to end.
Which charge code should a business use to pay a supplier invoice?
OUR when the supplier must receive the invoice amount, SHA when the contract says the supplier bears receiving-side charges, and BEN rarely. Write the code into the payment terms so the supplier is not surprised. On Lumx, a supplier in Brazil or Mexico is paid over Pix or SPEI, and one in a country with no local rail is paid by USD SWIFT.
How can I avoid wire charge codes altogether?
Pay over a local rail wherever the supplier's country has one, because a local rail has no correspondent chain to deduct from the amount. A wire remains the route where no local rail is reachable. On Lumx, payouts to Brazil and Mexico go over Pix and SPEI, and a USD wire over SWIFT is the fallback for corridors without a local rail.
