Payments - Introduction / Learning brief
Charges and FOREX (FX)
Your notes
In simple terms / 01
What this means in plain language
Explains common payment charge allocations and how foreign-exchange conversion and margins affect cross-currency transfers.
A cross-border payment can change value through both fees and foreign-exchange conversion. Charge instructions indicate how sender, receiver, and intermediary costs are allocated, often using familiar labels such as shared, sender-paid, or beneficiary-paid. The exact treatment depends on the route and applicable rules. When currencies differ, a provider converts at an exchange rate and may include a margin or separate fee. Customers therefore need more than the sent amount: useful disclosure shows the conversion basis, charges, expected received amount when available, and which party could deduct further costs.
Complete lesson / 02
Understand the full idea, step by step
Every cross-currency payment screen quietly asks two questions that most payers never notice: who will pay the fees along the way, and at what rate will one currency become another? Answer both carelessly and the beneficiary receives less than the invoice says — with nobody having made an error.
The payment at a glance
- Payer
- Asha Traders — EUR account at Bank Alfa
- Payee
- Supplier — USD account at Nordbank
- Invoice amount
- USD 25,000.00
- Conversion
- EUR debited, USD delivered
- Route
- Bank Alfa → Meridian Bank (correspondent) → Nordbank
- Two open questions
- Who bears the charges? At what exchange rate?
Two separate questions, often confused
Charges and foreign exchange (FX) are different things that happen to meet on the same screen. Charges are fees: what Bank Alfa charges Asha Traders, what Meridian Bank charges for the correspondent leg, what Nordbank may charge the supplier. FX is conversion: turning euros into dollars at a rate. A shortfall at the supplier's end can come from either — or both — so a practitioner always separates them before explaining a difference.
Charge bearer — the instruction that says who pays the transaction charges
In the SWIFT MT world, field 71A of the MT 103 customer payment carries one of three codes. OUR: the payer bears all transaction charges, so the beneficiary should receive the full amount. SHA (shared): the payer pays the charges on the sending side, and charges on the receiving side may be taken from the amount or billed to the beneficiary. BEN: the beneficiary bears all transaction charges, which are deducted along the way. ISO 20022 messages such as pain.001 and pacs.008 carry the same idea in the ChrgBr (charge bearer) element with the codes DEBT (debtor bears), SHAR (shared), CRED (creditor bears), and one code MT has no equivalent for: SLEV, meaning charges follow the rules of the scheme's service level rather than a per-payment choice.
| Who bears the charges | MT (field 71A) | ISO 20022 (ChrgBr) |
|---|---|---|
| Payer bears all | OUR | DEBT |
| Shared: each side bears its own | SHA | SHAR |
| Beneficiary bears all | BEN | CRED |
| Whatever the scheme's service level says | no equivalent | SLEV |
SWIFT MT — ILLUSTRATIVE, NON-PRODUCTION
:32A:260715USD25000,00
:71A:SHATwo lines from the MT 103 Bank Alfa sends: field 32A carries the value date, currency, and interbank amount; field 71A carries the charge option. With SHA, Asha Traders pays Bank Alfa's charges, while a receiving-side bank may still deduct its own — which is why the supplier can legitimately receive slightly less than USD 25,000.00.
| Invoice amount (what the supplier must receive) | USD 25,000.00 |
|---|---|
| Currency pair, as quoted | EUR/USD — base EUR, quote USD |
| Meaning of the pair | one euro buys this many dollars |
| Reference (mid-market) rate at quote time | 1.0800 |
| Customer rate Bank Alfa quotes Asha Traders | 1.0700 |
| EUR debited at the customer rate (25,000.00 ÷ 1.0700) | EUR 23,364.49 |
| EUR the reference rate would imply (25,000.00 ÷ 1.0800) | EUR 23,148.15 |
| Difference attributable to the FX spread | EUR 216.34 |
Read the quote from Asha Traders' perspective: it is buying dollars with euros, so a customer rate below the reference rate means each euro buys fewer dollars, and the EUR debit grows. Naming the base currency (EUR), the quote currency (USD), whose side of the deal you are on, and which rate you are looking at — reference or customer — is the only way to check a conversion. The rates and amounts here are illustrative.
You may be wondering: is that EUR 216.34 spread simply the bank's profit? And does a rate of 1.0800 mean one economy is stronger than the other?
Neither follows. The spread covers real things before profit: the bank's own cost of sourcing dollars, the risk that the market moves between quote and execution, and the cost of running an FX desk — some of it is margin, but a spread is not automatically pure profit. And a rate is just a price between two units; a rate number by itself proves nothing about economic strength. One currency can be worth many units of another and belong to a struggling economy, or a thriving one. What matters to a payment is the rate applied, not what the number seems to say about countries.
COMMON CONFUSION
“The rate on the news is the rate my payment will get.”
The rate on the news is a reference rate — a mid-market snapshot at which no customer actually deals. A payment converts at the customer rate: the reference adjusted by the provider's spread, fixed at the moment the deal is booked. Comparing the two, as the calculation above does, is exactly how a practitioner measures the cost of a conversion.
WHAT IF — The supplier reports receiving USD 24,982.00 instead of USD 25,000.00
What happens: With charge option SHA, a receiving-side institution — here a USD 18.00 deduction on the correspondent leg through Meridian Bank — may lawfully take its charge from the amount. Nothing failed; the chosen option allows it.
How it is handled: Maya at Bank Alfa traces the value path: the booked customer rate, the 71A code, and each bank's charge. If the deduction matches the SHA arrangement, the answer is disclosure, not refund — and for invoices that must arrive whole, quoting OUR next time. If it does not match, Bank Alfa raises an inquiry with the deducting bank.
STRICTLY SPEAKING
Strictly speaking, customers cannot always choose the charge option. Schemes and market-practice guidelines restrict which codes are allowed: SEPA credit transfers effectively fix a shared arrangement (ISO SLEV — each party pays its own bank's charges, with no deduction from the principal), and usage guidelines on other corridors limit the permitted codes. The menu on a payment screen reflects what the route allows, not a free choice — check the scheme rulebook for the corridor in question.
FOR NOW, REMEMBER
- Charges and FX are separate questions: fees along the route, and the rate at which one currency becomes another.
- OUR/SHA/BEN live in MT field 71A; DEBT/SHAR/CRED/SLEV live in the ISO 20022 ChrgBr element — same idea, different code sets, and SLEV defers to the scheme.
- A useful FX quote names the base currency, the quote currency, whose perspective applies, and whether a rate is the reference or the customer rate.
- A spread is not automatically pure profit, a rate number proves nothing about economic strength, and the charge menu is set by the route, not the payer.
TRY IT YOURSELF
Asha Traders sent USD 25,000.00 with charge option SHA. The supplier confirms USD 24,982.00 arrived. Which explanation should Maya test first?
Fees and FX are the costs a payer can see. The next lesson adds the ones nobody prints on a receipt — liquidity, operations, and exceptions — and totals what one payment really costs.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
Fees and foreign-exchange effects are separate value components.
- 02
Charge labels do not guarantee the final received amount in every route.
- 03
Transparent pricing should explain rate, margin, fees, and deductions.
Practical use cases / 04
Where you would use this
A treasury user compares two routes by expected beneficiary amount rather than headline transfer fee.
A service agent explains why an overseas recipient received less than the original instructed amount.
A product tester verifies that a quote displays currency rate, bank fee, and charge allocation consistently.
Worked example / 05
Put the idea into a real situation
A customer wants to send 1,000 units of Currency A to an account in Currency B. The bank presents an illustrative exchange rate, its conversion margin, a transfer fee, and the selected charge arrangement. The screen estimates what the beneficiary should receive but warns that another participant may apply an allowed deduction. Before confirmation, the customer can compare the total cost and outcome with another route. Actual calculations depend on provider terms and market conditions.
Evidence & review / 07
Evidence & review
Cross-border customer credit transfers in MT (MT 103) and ISO 20022 (pain.001/pacs.008); SEPA charging noted as a scheme-specific case
What this brief simplifies: Rates, spread, and charge amounts are illustrative. The route shows a single correspondent; real chains may add legs and further charges. Bid/offer mechanics are reduced to a single customer rate versus a single reference rate.
Sources for this brief5
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · MT 103 field 71A (Details of Charges)
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 · ChargeBearerType code set (DEBT/SHAR/CRED/SLEV) in pain.001 / pacs.008
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 · SCT charging principles (shared charges, no deduction from principal)
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.
- Market practice
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · Charge bearer usage in cross-border payments
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal · Asha Traders scenario, illustrative rates and amounts
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.