Last reviewed: · Curated by Ohmyfin Organisation editorial.
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 →
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.
| 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. |
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.
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.
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.
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, 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.
No card needed. Free for ordinary users — completely free for individuals — no daily limit, no card required. Track any international wire across 11,000+ banks.
Track a payment now — completely free Or try the tracker now →