When you send money across borders, you may be asked who should pay the processing charges that banks apply along the way. That choice is usually expressed with one of three short codes: OUR, SHA or BEN. They are not three fixed fee amounts. They are instructions about which party bears the charges, and getting the choice wrong is a common reason a recipient receives less than expected. This explainer covers what each code means, where it appears, when it matters and how charges are handled when you send money with Coinepay.
What OUR, SHA and BEN actually mean
These codes travel inside the payment message that banks exchange. Each tells the banks in the chain who should absorb the transaction charges.
- OUR \u2014 the sender pays everything. The payer is instructed to bear all transaction charges, including those added by banks along the route and by the recipient\u2019s bank. The goal is that the beneficiary receives the full amount.
- SHA \u2014 charges are shared. The payer covers charges on the sending side and the payee covers charges on the receiving side. \u201cShared\u201d does not mean a neat 50\u201350 split; each side simply pays its own part.
- BEN \u2014 the beneficiary pays. The payee is instructed to bear all transaction charges, potentially including the sending bank\u2019s charge. The amount credited can therefore be less than the amount sent.
SHA is the most common default for ordinary international transfers. OUR is often chosen when the sender has promised to deliver a precise amount \u2014 for example settling an invoice in full.
What the code looks like and where to find it
In a legacy SWIFT MT103 payment message, the charge instruction sits in field 71A and reads simply OUR, SHA or BEN. Under the newer ISO 20022 standard the equivalent charge-bearer codes are DEBT (debtor/sender pays), SHAR (shared) and CRED (creditor/beneficiary pays). SWIFT\u2019s coexistence period for legacy MT and ISO 20022 cross-border payment instructions ended on 22 November 2025, so the older 71A wording may still appear in bank records and interfaces even as the ISO codes become standard.
A made-up example of how it might look in a transfer record:
71A: OUR \u2014 Beneficiary: Jordan Rivera \u2014 Reference: INV-2026-0042 (fictional, for illustration only)
You will usually see the choice presented in plain language when you set up a transfer \u2014 something like \u201cWho pays the fees?\u201d \u2014 rather than as a raw code. In bank statements or remittance advice, the code itself may appear next to the payment details.
A quick comparison of the related codes
| MT 71A | ISO 20022 | Who bears charges | Typical use |
|---|---|---|---|
| OUR | DEBT | Sender pays all charges | Paying an invoice in full; delivering an exact amount |
| SHA | SHAR | Each side pays its own | General-purpose default on many wires |
| BEN | CRED | Beneficiary pays all charges | When the recipient agrees to absorb costs |
| \u2014 | SLEV | Follows the scheme/service-level rules | Scheme-governed payments such as SEPA |
Note that SLEV is not another spelling of OUR, SHA or BEN. It means charges follow the applicable service-level or scheme rules. For SEPA Credit Transfers, the European Payments Council\u2019s customer-to-bank guidelines allow only SLEV when a charge-bearer element is supplied, so a SEPA transfer should not be presented as a free choice among the three codes.
When the choice matters \u2014 and when it does not
The charge code matters most on traditional SWIFT wires that may pass through one or more correspondent banks. When the sending and receiving banks have no direct relationship, intermediaries handle the payment, and each of them \u2014 plus the receiving bank \u2014 can apply a separate charge. The code tells those banks whose account the charges should land against.
In several regions the choice is constrained by law:
- Within the EU, where both payment-service providers are located there, Payment Services Directive 2 (Article 62(2)) requires each side to pay charges levied by its own provider \u2014 OUR or BEN cannot simply override that. Article 81 also generally requires the full amount to be transferred without deductions, though the payee and its provider may agree a clearly identified deduction before crediting.
- In the UK, where both providers are in the UK, regulation 66(2) of the Payment Services Regulations 2017 similarly allocates each provider\u2019s charges to its own customer. This is not a blanket rule for every UK-to-overseas wire.
- For covered US-to-foreign remittances, the provider must disclose the fees, the exchange rate and the expected amount delivered, and may have to warn that foreign taxes or fees can still be deducted. That disclosure duty does not force every provider to offer all three codes.
So the practical lesson is: the code is relevant mainly for conventional correspondent-bank wires, and even then the local scheme or regulation may decide the outcome for you.
Common mistakes and what happens if it is wrong
- Assuming OUR guarantees the full amount. OUR is an instruction, not an unconditional guarantee. An intermediary or receiving bank may not support or follow it, and the instruction can be lost when a payment crosses into a local scheme.
- Being surprised by a short credit under SHA or BEN. Charges taken from the proceeds along the route, plus a receiving-bank fee, can reduce the final credit. Under BEN this is expected; under SHA a receiving-side fee is normal.
- Forgetting returns can also be short. If a payment is returned, processing and correspondent charges may already have been deducted before the funds come back.
- Confusing charges with currency conversion. An exchange rate or conversion charge affects the recipient\u2019s amount independently of the charge-bearer choice. A \u201cmissing\u201d amount is not always a fee.
One honest limitation: the exact correspondent route, each third-party charge, whether every bank honours OUR, and the final credited amount cannot be known from the code alone. For a specific route, rely on the sending provider\u2019s quote and the receiving bank\u2019s terms.
How charges work when you send with Coinepay
Coinepay Global Remittance is designed to keep this simpler than a raw bank wire. Rather than leaving you to guess about correspondent charges, Coinepay shows the exchange rate and fees clearly before you confirm a transfer, and every transfer has status tracking so you can follow it to payout. You can send to every country and region except jurisdictions under comprehensive sanctions, with payout by bank account deposit, mobile wallet (for example UPI, GCash, Maya, M-Pesa, bKash, JazzCash or GoPay) or cash pickup.
To send money:
- Register and complete identity verification (KYC) in the Coinepay app or dashboard. Download it from the App Store or Google Play.
- Choose the destination country, payout method and currency.
- Review the rate, fees and the amount the recipient will receive, shown before you confirm.
- Confirm and track the transfer\u2019s status to completion.
Because the cost is presented up front, you are not left reconstructing an OUR, SHA or BEN outcome after the fact. Transfers are subject to identity verification, sanctions screening and local regulations, and Coinepay may ask for documents such as the purpose or source of funds. If you are unsure which charge arrangement a particular payout involves, contact Coinepay support or reach the team on Telegram before you send.
If you also need to settle with overseas suppliers, Coinepay supports international trade payments in partners\u2019 local currencies with compliant transaction records. Learn more on the Coinepay home page.
Get your Coinepay virtual card: Sign up · App Store · Google Play · Customer support
FAQ
Does OUR guarantee my recipient gets the full amount?
No. OUR instructs the sender to bear all charges, but it is not an unconditional guarantee. An intermediary or receiving bank may not support or follow the instruction, and it can be lost when a payment enters a local scheme. Check the route\u2019s specific terms.
Does SHA mean the fees are split 50-50?
No. Under SHA the sender pays charges on the sending side and the recipient pays charges on the receiving side. Each side simply covers its own part, which is rarely an even split.
What are DEBT, CRED and SHAR?
They are the ISO 20022 charge-bearer codes that correspond to the older MT 71A values: DEBT equals OUR, CRED equals BEN and SHAR equals SHA. SLEV is a separate code meaning charges follow the scheme or service-level rules.
Can I choose OUR, SHA or BEN when sending with Coinepay?
Coinepay shows the exchange rate and fees clearly before you confirm a transfer, so you see the cost up front rather than selecting a bank charge code. If you have a question about charges for a specific payout, contact Coinepay support before sending.
Why did my recipient receive less than I sent?
Under SHA or BEN, charges taken along the route and a receiving-bank fee can reduce the credit. A currency conversion charge can also lower the amount independently of the charge code. With Coinepay, the fees and recipient amount are shown before you confirm.
Related guides
- Bank Account Number Formats by Country: What They Are and How to Use Them
- Beneficiary Name Mismatch on International Transfers: What to Do
- MT103 Payment Confirmation: What It Is and How to Use It
- Purpose of Remittance Codes in India: What They Are and How to Use Them
- SEPA Transfers: What It Is and How to Use It for Transfers
- Intermediary and Correspondent Banks: A Transfer Guide
