SWIFT MT103 Field 71A — Details of Charges
Field 71A is the Details of Charges — one of three codes that determines who pays correspondent-bank fees. Draft an MT103 with the right charges code →
Details
The three valid codes in field 71A: OUR (all charges borne by the ordering customer — the sender pays every correspondent bank's fee along the chain; the beneficiary receives the full amount stated in field 32A); SHA (shared — the sender pays their own bank's charges, the beneficiary pays any foreign correspondent bank charges; this is the most common code globally and the SEPA regulatory default); BEN (all charges borne by the beneficiary — every correspondent bank's fee is deducted from the payment amount before the beneficiary receives the remainder). Field 71A is mandatory — every MT103 must have one of these three values.
The financial impact of the charges code is significant for the beneficiary. Under SHA, each correspondent bank in the chain deducts its own fee (typically $10–$35 per hop) from the payment before forwarding it. If the payment passes through two correspondents, the beneficiary may receive $20–$70 less than the sender instructed. Under OUR, the sender's bank typically charges an additional fee upfront to cover the expected correspondent fees, but the beneficiary receives the full amount. Under BEN, the beneficiary bears all fees — they may receive substantially less than the sender instructed, with no advance notice of exactly how much will be deducted.
For business payments where the beneficiary needs to receive a specific exact amount (e.g. paying a supplier invoice exactly), OUR is the most appropriate choice. For routine remittances where a small shortfall is tolerable, SHA is cheaper for the sender. BEN is generally inappropriate for business payments because the shortfall is unpredictable and can disrupt supplier relationships. Under SEPA rules, SHA is effectively mandatory (SEPA scheme rules do not permit OUR on SEPA Credit Transfers sent between banks in the SEPA zone).
In ISO 20022 pacs.008, field 71A is replaced by the ChrgBr (Charge Bearer) element with four values: DEBT (equivalent to OUR — debtor/sender pays all), CRED (equivalent to BEN — creditor/beneficiary pays all), SHAR (equivalent to SHA — shared), and SLEV (service level — defers to the scheme agreement, used in SEPA Credit Transfer where the EPC scheme defines the charges allocation as SHAR but uses SLEV as the standardised value to avoid the explicit SHAR vs SHA ambiguity in multi-scheme environments).
The Ohmyfin payment tracker shows the fees deducted at each correspondent hop in the SWIFT GPI tracking data. This fee transparency was a key innovation of SWIFT GPI — before GPI, beneficiaries and senders had no way to see exactly which bank took what fee. With GPI and Ohmyfin, you can audit the complete fee trail and confirm whether the charges code was applied as instructed. If the beneficiary received less than expected under OUR, the Ohmyfin fee trail will show which correspondent deducted a fee that should not have been deducted under OUR.
Quick facts
| Example value | :71A:SHA |
|---|---|
| Valid characters / format | OUR / SHA / BEN |
| Required on MT103 | Mandatory |
| Required on MT202 | Not used |
| Required on pacs.008 | Mandatory |
| Notes | Charges bearer. |
Key facts
- Mandatory MT103 field — OUR, SHA, or BEN
- OUR: sender pays all correspondent fees; beneficiary gets the full field 32A amount
- SHA: each side pays its own bank — globally the most common code; SEPA default
- BEN: beneficiary pays all fees; amount received is unpredictable — avoid for business payments
- pacs.008 equivalent: ChrgBr element (DEBT/CRED/SHAR/SLEV)
- Ohmyfin shows fees per correspondent hop so you can audit the charges code outcome
Frequently asked questions
Why did the beneficiary receive less than I sent?
Most likely SHA or BEN was specified in field 71A, and correspondent banks deducted their fees from the payment amount. The Ohmyfin payment tracker shows fees deducted at each hop — track the UETR on Ohmyfin to see exactly which bank took what amount.
Which charges code should I use for paying an exact invoice amount?
Use OUR — it instructs all correspondent banks that the sender will cover their fees, so the beneficiary receives the full amount stated in field 32A. SHA may cause the beneficiary to receive a few dollars or euros less than the invoice amount, depending on the number of correspondent hops and their fee schedules.
What is SLEV in pacs.008 and when is it used?
SLEV (Service Level) in pacs.008 ChrgBr means the charges allocation is governed by the applicable payment scheme's rules rather than being explicitly set to DEBT, CRED, or SHAR. SEPA Credit Transfer uses SLEV because the EPC scheme rulebook defines the charges as shared (equivalent to SHA) and SLEV delegates that decision to the scheme rather than repeating SHAR explicitly.
Can I change the charges code after the payment is sent?
No — field 71A is set at the time the SWIFT message is created and cannot be changed once the message has entered the payment chain. If the wrong charges code was used, you cannot fix it in transit. You can only send a top-up payment if the beneficiary received less than expected, or request a recall if the payment has not yet been credited.
Under OUR, who deducts what?
Under OUR, the sending bank charges the sender an additional fee to cover the expected correspondent charges, then sends the full payment amount in field 32A. Each correspondent is supposed to pass the full amount through without deduction (the sender's bank will have agreed to cover their fees bilaterally). In practice, some correspondents still deduct their fee — this is visible on the Ohmyfin tracker and can be disputed with your sending bank.
Related guides
Related — more from swift field reference and beyond
Get 100 free credits — track unlimited SWIFT payments
No card needed. Free for ordinary users — 10 free trackings per day per IP, no signup required. Track any international wire across 11,000+ banks.
Track a payment now — completely free Or try the tracker now →