Last reviewed: · Curated by Ohmyfin Organisation editorial.
Field 71F is the Sender's Charges — each correspondent bank's deducted fee, repeated per hop. Track a payment and see all fees per hop free →

Format: 3-letter ISO 4217 currency code + amount (comma as decimal separator, no thousands separators). Example: USD35,00 means the sending bank deducted USD 35.00 as its fee. Field 71F is mandatory whenever field 71A is SHA (shared) or BEN (beneficiary pays) — because in these cases the fees are deducted from the payment amount, and regulators and beneficiaries need a transparent record of exactly how much each bank took.
Field 71F is a repeatable field — it can appear multiple times in a single MT103, once for each correspondent bank in the chain that has deducted a fee. When the originating bank populates field 71F with its own fee, the next correspondent bank receives the message with that field 71F already present, then adds its own 71F entry to show its deduction, and so on. By the time the MT103 reaches the beneficiary bank, field 71F may contain multiple entries, one per correspondent, giving a complete audit trail of all fees deducted.
The relationship between field 71F and field 32A (Value Date/Currency/Amount): the amount in field 32A represents the original settlement amount. The sum of all field 71F entries represents the total correspondent fees deducted. The amount actually credited to the beneficiary is field 32A minus the sum of all field 71F entries (approximately — the actual calculation may vary slightly due to FX on fee amounts). This transparency was a significant innovation of the MT103 format, and was enhanced further by SWIFT GPI which provides real-time visibility of the fees at each hop.
Under the OUR charges code (field 71A = OUR), field 71F should not be present — because the sender is covering all fees and the payment amount should pass through untouched. However, in practice some correspondent banks still deduct their fee and add a 71F entry even under OUR, which is a violation of the MT103 rules and the bilateral correspondent agreement. The SWIFT GPI tracking trail and Ohmyfin make this visible — if you see a 71F entry under an OUR payment, your sending bank should dispute the deduction with the offending correspondent.
In ISO 20022 pacs.008, there is no direct equivalent of field 71F as a field within the payment message itself. Instead, the ISO 20022 approach to fee transparency is through the ChrgsInf (Charges Information) element at the payment level or through GPI status update messages (pacs.002) that carry the fee detail at each processing step. The SWIFT GPI Universal Confirmations framework specifically addresses end-to-end fee visibility for ISO 20022 payments.
| Example value | :71F:USD15,00 |
|---|---|
| Valid characters / format | 3!a + 15d |
| Required on MT103 | Optional |
| Required on MT202 | Not used |
| Required on pacs.008 | Optional |
| Notes | Charges deducted by sender (repeatable per correspondent). |
Track the payment by UETR on Ohmyfin. The SWIFT GPI status shows the fees deducted at each correspondent bank hop, equivalent to the cumulative field 71F entries in the MT103 message chain. This fee transparency is one of the key benefits of SWIFT GPI.
Field 71F is in the same currency as the interbank settlement (field 32A). All fees in the payment chain are expressed in the payment currency, regardless of the country of the bank deducting the fee. If a correspondent bank deducts a fee in a different currency, it must convert to the payment currency for reporting in field 71F.
Yes — field 71F is repeatable. Each correspondent bank that deducts a fee adds its own 71F entry to the message. By the time the message reaches the beneficiary bank, field 71F may contain multiple entries showing the fees deducted at each hop in the chain.
Under OUR, field 71F should not be present, because the sender is covering all fees and the payment amount should pass through each correspondent unchanged. If field 71F appears under OUR, the correspondent bank is in violation of the MT103 fee-code rules and the payment terms. Ohmyfin will show this as a discrepancy in the tracking trail.
The beneficiary receives approximately the field 32A amount minus the sum of all field 71F entries (under SHA or BEN). For example, if field 32A is USD 10,000 and two correspondents each deducted USD 25, the two 71F entries sum to USD 50, and the beneficiary receives approximately USD 9,950. The exact credited amount may differ slightly if FX is involved in the fee calculation.
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 →