OUR vs SHA vs BEN
Charge-bearer options decide who pays the banks' fees on a cross-border payment: the sender pays everything (OUR), each side pays its own bank (SHA), or the beneficiary pays everything (BEN, covered in the notes).
| DIMENSION | OUR | SHA |
|---|---|---|
| Who pays which chargesUnder BEN, the beneficiary bears all charges, including the sending bank's — usually taken out of the payment amount itself. | The originator pays all charges — their own bank's, the intermediaries', and the beneficiary bank's. | The originator pays their own bank's charges; the beneficiary bears the charges on the receiving side, and intermediary deductions typically fall on the beneficiary side too. |
| Amount the beneficiary receivesUnder BEN the shrinkage is largest, because every bank in the chain may deduct from the principal. | In principle the full instructed amount: downstream banks claim their charges from the originator's bank instead of deducting them. | The instructed amount minus any receiving-side and intermediary deductions, so the credit can be slightly less than the invoice. |
| How it appears in the messageBEN maps to ISO code CRED. SEPA payments instead use SLEV — charges follow the scheme's rule rather than a per-payment choice. | MT103 field 71A code OUR; ISO 20022 ChargeBearer code DEBT. | MT103 field 71A code SHA; ISO 20022 ChargeBearer code SHAR. |
| Predictability | Best for the beneficiary (full amount) but worst for the sender, who may receive charge claims from downstream banks weeks later at amounts they could not see upfront. | Reasonably predictable for both: each side knows its own bank's tariff, though intermediary deductions can still surprise the beneficiary. |
| Operational side effectsBEN creates the most customer disputes, because the received amount visibly falls short of what the sender says they paid. | Generates separate charge-claim traffic between banks, plus reconciliation work matching claims to original payments. | Shows up as amount differences: reconciliation and accounts-receivable teams must tolerate small under-payments against invoices. |
| Scheme and regulatory constraintsEuropean payment services law generally requires shared charging for intra-EEA payments, which is why OUR and BEN have largely disappeared inside Europe. Verify the rules for your corridor rather than assuming the option is available. | Restricted in some contexts: many schemes and corridors do not support OUR, and some usage guidelines constrain when it may be used. | The default in many corridors, and effectively the rule inside SEPA, where each customer pays only their own PSP's charges. |
| Typical useBEN is rare and widely discouraged; it mostly appears in legacy corridors or when the sender explicitly refuses to bear any cost. | Invoice and contract payments where the beneficiary must receive an exact amount — salaries, legal settlements, supplier terms that say 'net of charges'. | The everyday default for cross-border payments where both parties accept standard banking costs. |
Sources for this comparison4
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · MT103 field 71A charge codes
Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login; content here relies on public summaries. Swift ended MT-to-ISO 20022 coexistence for in-scope cross-border payment instructions (for example MT103 and MT202) in November 2025; MT statement messages are being phased out on a separate timeline.
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · ChargeBearer element and code values
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Scheme-specific rule2025 version 1.1 (EPC125-05)
2025 SEPA Credit Transfer rulebook ↗ — European Payments Council · charging principles (each party pays its own PSP)
Version 1.1 replaced version 1.0 at publication on 5 October 2025 and is stated to remain in effect up to 21 November 2027. It moves the date from which the unstructured address format is no longer permitted to 15 November 2026.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: BEN is covered in notes because the schema compares two columns. Charge behaviour in practice varies by corridor, currency, and bank tariff; the cells describe the standard model, and the intra-EEA legal position is summarised without citing specific legislative provisions.
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.