The beneficiary bank applies the exchange rate most often, usually only after an intermediary has already taken its cut, which is why unexpected deductions show up so frequently. The single most effective step to avoid surprises is to specify the payment currency explicitly in your instructions and, where possible, receive into a dedicated account that holds that same currency rather than letting any bank convert it for you.

TL;DR:

Ensuring the payment currency matches your invoice and requesting dedicated accounts can prevent automatic conversions and unexpected deductions.

The conversion rate is set by the bank performing the exchange, often the beneficiary bank or the originating bank if the currency isn’t supported early in the process.

Multiple conversions can occur at different banks in the chain, with each adding its own markup, making traceability essential for dispute resolution.

Choosing the correct charge instruction, especially OUR, minimizes the risk of deductions and ensures the full amount reaches the beneficiary.

Using ISO 20022 messaging and requesting GPI trace data helps verify where and when currency conversions and deductions happen during a SWIFT transfer.

Demivoltdemivolt.comKeep More Control Over SWIFT PaymentsDemivolt helps businesses manage SWIFT payments through dedicated IBAN accounts, multi-account structures, and compliant financial infrastructure.Visit Demivolt

How SWIFT payments travel and where currency conversion can happen
Who applies the exchange rate and how exchange rates are set on SWIFT transfers
Charge models and instruction choices: OUR, SHA, BEN, and how they change the received amount
Auto-conversion risks, PMPG best practices, and common dispute scenarios
Practical checklist: how to instruct your bank and steps to avoid unexpected conversions and fees
Regulatory and industry context that improves transparency
How a regulated fintech like Demivolt helps businesses manage SWIFT currency conversion
When to rely on SWIFT versus alternative settlement rails
How Demivolt supports SWIFT payment control
FAQ
Sources

How SWIFT payments travel and where currency conversion can happen

A SWIFT payment rarely moves in a straight line. Money typically passes from the ordering bank through one or more correspondent or intermediary banks before reaching the beneficiary bank, and each stop in that chain is a point where currency conversion, or a fee, can be applied without the payer necessarily seeing it happen in real time.

The payment message itself carries the instructions that determine currency handling. In the legacy MT format, fields such as 33B (currency and instructed amount) and 36 (exchange rate) tell every bank in the chain what currency the sender intended and what rate, if any, was used. The equivalent structured fields exist in ISO 20022 messages, which carry richer, more explicit data about the original ordered amount and any conversion applied along the way. Getting these fields right at the point of origin is what prevents an intermediary from assuming a conversion was wanted.

Whether a beneficiary needs any conversion at all often comes down to one factor:

A beneficiary with a multi-currency account can receive the original currency untouched.
A beneficiary with a single-currency account forces the receiving bank to convert automatically, usually at its own rate.

GPI tracking lets both sender and receiver see each leg of the payment as it moves, which makes it possible to reconcile exactly which bank applied a conversion and when, instead of guessing after the funds land short.

Who applies the exchange rate and how exchange rates are set on SWIFT transfers

Either side of the transaction can end up converting the funds, and the outcome depends on account setup more than on intent. When a sender’s instructed currency does not match what the beneficiary’s bank can hold, the beneficiary bank converts on arrival, usually at a rate it sets itself rather than a published market rate. When a sender’s own bank doesn’t support the destination currency, the conversion happens earlier, at the ordering bank, before the payment even enters the SWIFT network.

The real complication is that conversion can happen more than once in the same transaction. An intermediary bank in the chain may convert a currency it doesn’t support locally, and then the beneficiary bank may convert again on receipt, compounding the markup each time.

A single disputed transfer illustrates the stakes clearly: in one Lithuanian Bank case, intermediary fees combined with the beneficiary bank’s own exchange rate reduced the final credited amount, and resolving the complaint required pulling GPI trace data and the underlying message fields to show exactly where each deduction occurred.

Rate sources vary just as much. Some banks price conversions close to the interbank mid-market rate with a disclosed margin; others apply a proprietary rate with no visible markup breakdown at all. The only reliable way to check which rate was actually used is to request the GPI trace and the MT or ISO message details from your bank, since the credited amount alone tells you nothing about how it was calculated.

Charge models and instruction choices: OUR, SHA, BEN, and how they change the received amount

Every SWIFT payment carries a charge instruction that decides who absorbs bank fees along the way, and the choice directly affects how much currency conversion risk lands on the receiver.

OUR means the sender pays all fees, including intermediary charges, so the beneficiary is meant to receive the full invoiced amount.
SHA (shared) splits fees: the sender pays their own bank’s charges, and the beneficiary absorbs any intermediary or receiving-bank fees.
BEN means the beneficiary pays all fees, including the sender’s bank charges, deducted directly from the transferred amount.

Even with OUR selected, residual deductions can still occur. As the Lithuanian Bank dispute example shows, intermediaries or the beneficiary bank can apply their own charges or conversion unless the payment is explicitly routed through a cover arrangement or a bilateral agreement that commits every bank in the chain to honor the OUR instruction.

For recurring cross-border invoicing, matching the charge model to the contract terms matters more than defaulting to whatever a bank’s payment form pre-selects. A supplier expecting the full invoiced amount should be paid under OUR with a documented cover arrangement, not SHA.

Auto-conversion risks, PMPG best practices, and common dispute scenarios

Auto-conversion happens when a receiving bank, lacking a matching currency account for the beneficiary, converts incoming funds automatically rather than holding them in the original currency. It is a default behavior at many banks, not a service the beneficiary explicitly requested, and it is one of the most common sources of unexpected deductions on cross-border invoices.

The PMPG white paper on Auto Foreign Currency Conversion addresses this directly, warning that automatic conversion can produce unintended consequences for both payers and payees. It recommends transparency around the rate applied, opt-out mechanisms for customers who want to receive the original currency, conversion thresholds below which auto-conversion is skipped, and consistent use of supporting message fields so banks downstream know the sender’s true intent.

Intermediary bank fees and the beneficiary bank’s exchange rate reduced the final credited amount, and the investigation relied on GPI tracking and message fields to establish where the deductions occurred.

That pattern, drawn from the Lithuanian Bank dispute decision, is a useful template for what to gather if you ever need to challenge a deduction: the GPI trace showing each leg of the payment, the original MT or ISO message with its currency and rate fields, and your bank’s own terms on charge handling and auto-conversion.

Pro Tip: Ask your bank in writing whether auto-conversion applies to your account type before you send or receive a large cross-border payment, not after the funds arrive short.

Practical checklist: how to instruct your bank and steps to avoid unexpected conversions and fees

Preventing conversion surprises comes down to giving precise instructions before the payment leaves, not reconciling after it arrives.

State the exact currency and amount you intend to send or receive, matching the invoice currency precisely.
Confirm the beneficiary account can hold that currency, or open a dedicated account in it if it can’t.
Populate the currency and rate fields correctly (field 33B/36 in MT, or their ISO 20022 equivalents) so no bank in the chain assumes a conversion is wanted.
Choose the charge code deliberately: OUR when the invoice requires the full amount received, SHA or BEN only when the contract allows for shared or beneficiary-side fees.
Request a cover payment or bilateral fee agreement for high-value or recurring transfers where OUR needs to hold through every intermediary.
Track the payment via GPI and confirm the credited currency and amount with the beneficiary before closing the invoice in your books.

A dedicated multi-currency IBAN removes most of this friction by letting a business hold and receive several currencies without forcing a conversion at all, which is often the simplest fix for recurring invoices in the same currency.

Pro Tip: Build a standard payment template for repeat suppliers or clients so the currency fields, charge code, and account details never have to be re-entered from memory.

Regulatory and industry context that improves transparency

Several regulatory and standards shifts are making SWIFT conversions easier to trace, even if none of them eliminates conversion risk outright.

Initiative	What changed
ISO 20022 migration	Replaces MT messages with structured data carrying richer currency and conversion detail, reducing exceptions
MT contingency processing	SWIFT converts in-flight MT messages to ISO 20022 for delivery, but converted messages lack full ISO richness and charges apply from January 1, 2026
PSD2	Strengthens consumer and business protections, introduces strong customer authentication, and clarifies liability for unauthorized transactions
Instant Payments Regulation (VoP)	Requires payee verification for euro credit transfers, reducing fraud and misdirected payments

SWIFT ended MT and ISO 20022 coexistence for many cross-border FI-to-FI payment instructions on November 22, 2025, and contingency conversion for senders still using MT format will carry a charge starting January 1, 2026. Finance teams relying on legacy formats should treat this as a deadline, not a future consideration: insisting on ISO 20022-native messaging now avoids both the fee and the loss of structured currency detail that makes conversions easier to trace.

How a regulated fintech like Demivolt helps businesses manage SWIFT currency conversion

Our account structure addresses the problems this guide describes. Business accounts provide dedicated IBANs, and the payments infrastructure supports both SEPA and SWIFT with GPI-aligned tracking, so a finance team can see exactly where a transfer sits and which bank touched it. Role-based user management lets a company separate who can initiate a payment from who approves the charge code and currency instructions, which cuts down on the kind of mismatched field entry that triggers unwanted conversion. For businesses invoicing internationally, this operational layer maps directly onto the checklist above.

When to rely on SWIFT versus alternative settlement rails

SWIFT’s reach is its real advantage: almost any bank in the world can be reached through it, which closed-loop or regional rails can’t match. That reach comes at the cost of predictable pricing, since every intermediary in a cross-border chain can add its own fee or conversion step. For a business with recurring flows into one region, a rail like SEPA offers the business the currency and scale of cross-border invoicing with the predictability each rail can offer. A CFO handling occasional large international invoices benefits most from a regulated platform that gives visibility into SWIFT’s chain, rather than trying to avoid SWIFT altogether.

— dd

How Demivolt supports SWIFT payment control

The account structure aims to stop currency conversion surprises before they start. Dedicated IBANs let you receive and hold funds in the currency your invoices are actually denominated in, while payment tools let you track a SWIFT transfer leg by leg instead of waiting to see what lands.

Open a business account with a dedicated IBAN suited to cross-border invoicing.
Send and receive through our payments infrastructure with SWIFT and SEPA support in one place.
Fixed SWIFT fees apply per transfer, with SWIFT In priced at €25.00 and SWIFT Out at €30.00, so you know the cost before you send.

Get in touch to open an account and put your SWIFT payments on a platform built for cross-border control.

FAQ

Who decides the exchange rate on a SWIFT transfer?

Whichever bank performs the conversion, often the beneficiary bank when the receiving account can’t hold the original currency, sets the rate it applies. GPI tracking and the underlying message fields are the most reliable way to confirm which bank actually applied the rate.

What does OUR, SHA, or BEN mean on a payment instruction?

These are charge codes that decide who pays bank fees: OUR puts all fees on the sender, SHA splits fees between sender and receiver, and BEN puts all fees on the receiver. The code chosen affects how much of the invoiced amount the beneficiary actually receives, even before any currency conversion is applied.

How can I avoid unexpected currency conversion on an incoming SWIFT payment?

Hold a dedicated account in the currency you expect to receive, and make sure the sender’s instructions specify that currency in the correct message fields. The PMPG white paper on auto foreign currency conversion recommends opt-out options for exactly this reason, since many receiving banks default to converting automatically.

Does ISO 20022 change how SWIFT currency conversion works?

ISO 20022 doesn’t change who converts currency, but it carries more structured data about the original amount and any conversion applied, making it easier to trace. SWIFT ended MT and ISO 20022 coexistence for many cross-border FI-to-FI payments on November 22, 2025, with MT contingency conversion becoming chargeable from January 1, 2026.

What should I collect if I need to dispute a SWIFT conversion or fee?

Request the GPI trace showing each leg of the payment, the original MT or ISO 20022 message with its currency and rate fields, and your bank’s written terms on fees and auto-conversion. A Lithuanian Bank dispute decision shows how this evidence was used to establish exactly where fees and conversion were applied in a contested transfer.

Stop SWIFT Currency Conversion Losses for Finance Teams with GPI

Table of Contents