SWIFT Wire Transfer: How It Works, What It Costs, and What You Need

A SWIFT wire transfer is a bank-to-bank payment carried over the SWIFT network (the Society for Worldwide Interbank Financial Telecommunication). What actually crosses the network is a secure, standardised instruction telling the banks in the chain how much to move, to whom, and in which currency. The money settles between banks behind that message.

That network connects more than 11,500 financial institutions across 200+ countries and territories, which is why it remains the default rail for cross-border payments. It also carries real costs, and if you are the one receiving the payment, every fee along the way comes out of your invoice. So it pays to know what a SWIFT wire transfer needs, what it costs, and how those fees get split.

Whether you are sending or receiving, a SWIFT wire transfer relies on five pieces of information. Get any of them wrong and the payment stalls or bounces.

• Recipient details - the beneficiary's full legal name and address exactly as held by their bank, plus the account number or IBAN.
• Bank details - the receiving bank's name, branch and country.
• SWIFT/BIC routing code - the code that identifies the beneficiary's bank on the network.
• Purpose of payment - why the money is being sent, which regulators in the receiving country often require on the record.
• Amount and currency - the exact figure and the currency it should arrive in.

Get those five right and the money will find you. What it costs to arrive is the part that catches most exporters out.

A SWIFT wire transfer rarely carries just one fee. The bill has a clear structure: the flat charges each bank in the chain adds, a percentage markup on the currency conversion, and a code on the payment that decides which side absorbs the lot. Here is where the money goes.

A payment usually passes through the sender's bank, one or more intermediary (correspondent) banks, and your receiving bank, so those flat fees can stack more than once on a longer routing chain. The receiving-side charge in India varies the most: some banks waive it for certain account types, while others apply an inward-remittance handling fee that, with 18% GST, can run past ₹1,000 on a larger receipt.

The layer most exporters miss is the FX markup, because no one bills it as a fee. The bank simply converts your dollars at a rate a percentage or two below the mid-market rate and keeps the difference. At a rate near ₹96 to the dollar, a 2% markup is about 192 paisa on every dollar, so on a $10,000 invoice that is roughly ₹19,200 you never see. For a fuller breakdown of every charge, see our guide to wire transfer fees.

Put together, a single receipt might carry $35 (client/sending bank) + $25 (intermediary) + ₹1,200 (the receiving bank's handling fee, incl. GST) + a 2% conversion markup. On a $10,000 invoice the fixed fees are the small part. The FX markup is where the real money goes, which is exactly the layer newer platforms price differently. Xflow, for example, converts at the live mid-market rate rather than a marked-up bank rate, and settles the rupees in your account the next business day (T+1).

One line on the payment instruction decides who absorbs all those fees, and most exporters never get to choose it. Field 71A of the MT103 message (the standard SWIFT format for a customer credit transfer) carries a three-letter charge code:

• OUR - the sender pays every charge, including the correspondent fees, so the beneficiary is meant to receive the full invoice amount.
• SHA (shared) - the sender covers only their own bank's outgoing fee; the beneficiary absorbs the intermediary and receiving-bank fees. This is the market default when nobody specifies.
• BEN - the beneficiary bears every fee layer, all deducted from the amount that arrives.

Take a $10,000 services export invoice, converted at an illustrative mid-market rate of ₹96 to the dollar (rounded from about ₹96.58 on 23 July 2026), with the same fees as above: $35 sending, $25 intermediary, ₹1,200 receiving-bank fee, and a 2% markup. The markup applies the same way in every case, because it is the bank's spread on the rate, not a Field 71A allocation, giving an effective rate of ₹94.08.

The gap between OUR and BEN is about ₹6,845 on this invoice, roughly 0.7% of its value, decided entirely by a code the exporter usually never sees. Where you can, ask your client to send under OUR. One caveat: even under OUR, some receiving banks still apply their own incoming-handling fee, because Field 71A binds the sender's bank and the correspondents not to deduct, not the beneficiary bank's own tariff.

Of the five details your client needs, the SWIFT/BIC code is the one most likely to be entered wrong, so it helps to know what a correct one looks like. Every bank on the network has a SWIFT code (Bank Identifier Code), an 8 or 11 character ID defined by the ISO 9362 standard. Here is how State Bank of India's code breaks down:

Read the first eight characters as the essentials (bank, country, location); the optional last three point to a specific branch, and XXX means the head office. A frequent and costly error is handing over an IFSC (Indian Financial System Code) such as SBIN0000001 instead. An IFSC routes domestic payments inside India; it is not a SWIFT code and will not work for an inbound wire. To find and verify a bank's SWIFT/BIC code, check with the beneficiary bank directly.

A SWIFT wire transfer usually clears in one to five business days. The reason it isn't instant is that the money rarely travels in a straight line. Few banks hold accounts with every other bank, so the payment hops through correspondent banks that do, and each hop adds a step. Here is how a typical USD payment from a US client to an exporter in India moves.

Day 1

The client instructs their bank, say Bank of America, to wire $10,000. Bank of America debits the account and sends an MT103 payment message into the network.

Day 2

Bank of America has no direct account with the beneficiary's bank, so it routes the funds through a correspondent, for example Deutsche Bank in Frankfurt, which holds the USD on its books.

Days 3 to 4

The correspondent forwards the payment to a bank with an Indian presence, such as Standard Chartered in Mumbai, which passes it on to the beneficiary bank.

Day 5

The beneficiary bank, say Punjab National Bank in Ludhiana, converts the dollars to rupees and credits the exporter's account.

Each hop rests on a nostro/vostro relationship (the account one bank holds with another). The more banks in the chain, the longer it takes: a wire between two well-connected banks can clear in a day, while a longer chain, a time-zone gap, a weekend, or an extra AML/KYC (anti-money-laundering and know-your-customer) check pushes it toward the five-day end. For a fuller breakdown of what slows a payment and how to track it, see our guide to SWIFT transfer time.

With several banks touching the money over several days, it is fair to ask how safe the whole thing is. The messaging layer itself is secure by design. SWIFT runs a private, encrypted network with customer authentication and continuous monitoring for suspicious activity, and it never holds your funds.

The bigger risk is human: sending money to the wrong or a fraudulent account, which is hard to undo once a wire is credited. A bank can attempt a recall with an MT192 (request for cancellation) message, but every bank in the chain has to agree, and the receiving bank is not obliged to return funds it has already paid out. So verify the beneficiary's details before the payment goes out.

Safety is not the only thing the receiving side adds. For an Indian exporter, a SWIFT wire transfer also carries a compliance layer the sender never sees. The RBI (Reserve Bank of India) requires every inbound export payment to be classified, documented, and reported, whether you are an IT-enabled services company, a services exporter, or a freelancer invoicing overseas clients.

Every inbound payment must be tagged with one of the RBI purpose codes, a short code describing why the money is coming in. Choose the one that reflects the actual nature of the work, not the closest-sounding approximation:

• Off-site software exports covered by SOFTEX - P0807.
• Software consultancy or implementation not covered by a SOFTEX filing - P0802.
• General professional services (consulting, design, marketing, PR) - P1006 or P1007, depending on the service.
• Physical goods exports - P0101, P0102 or P0105, depending on how your bank handled the bill.

If you export software or IT-enabled services, P0807 or P0802 will usually be the right pick.

Your bank needs paperwork to release and report the funds, and the set depends on what you export.

Services and software exporters

The export invoice, your service agreement or contract with the client, and a SOFTEX form (the software export declaration).

Goods exporters

The same invoice plus the shipping bill, the bill of lading or airway bill, and a packing list.

The SOFTEX form is being consolidated into a single Export Declaration Form (EDF) for all exporters from 1 October 2026, under the RBI's FEMA (Foreign Exchange Management Act) notification 23(R)/2026. It still applies today, so keep filing it until the switch.

Once the money lands, your AD Category-I (Authorised Dealer) bank issues a FIRC (Foreign Inward Remittance Certificate), your proof that you received foreign currency against an export. You need it to claim GST (Goods and Services Tax) refunds and export incentives, and the bank reports the same receipt to the EDPMS (Export Data Processing and Monitoring System). More on obtaining and using it in our guide to getting your FIRC.

• Using the wrong purpose code - a code that does not match the work invites RBI queries and holds up the credit. Match the code to the actual service, not the one that sounds closest.
• Missing or mismatched SOFTEX and invoice paperwork - if the SOFTEX filing, invoice and contract disagree on amounts or descriptions, the bank cannot close the entry in EDPMS, and your FIRC stalls.
• Mixing up your IFSC with your SWIFT/BIC code - giving a client your IFSC instead of your bank's SWIFT code is a frequent reason an inbound wire fails outright. The IFSC is for domestic transfers only.

All that fee, time and paperwork raises the real question: is SWIFT still the right way to get paid? Not always the wrong one. It reaches almost every bank in almost every country, which makes it the reliable option when your client's bank or currency corridor is not supported by a newer platform, when a payment is large and one-off, or when the counterparty simply insists on a bank wire.

Where it starts to cost you is on regular, mid-sized export receipts. The layered fees, the FX markup, the one-to-five-day wait, and the manual compliance follow-up add up when you are invoicing the same clients every month. SWIFT also does nothing to reconcile your RBI purpose code and export paperwork, so that follow-up lands on you with every payment. At that volume, the correspondent-bank model works against both your margins and your cash flow.

The practical test is frequency and predictability. For occasional or unusual payments, SWIFT's reach wins. For a steady stream of export earnings in major currencies, it is worth comparing it against purpose-built SWIFT payment alternatives that price transparently and handle the RBI paperwork for you.

If most of your income is regular export receipts, this is the case for a platform built around them. Xflow is a cross-border payments platform for Indian exporters receiving inbound SWIFT payments. A few things work differently from a bank wire:

• Live mid-market rate: where a bank converts at its own interbank rate and keeps the spread, Xflow prices off the live mid-market rate, so the markup you would normally lose stays with you.
• Next-business-day settlement: converted rupees reach your account on a T+1 basis.
• Compliance without extra work: every transaction gets an auto-issued eFIRA (electronic Foreign Inward Remittance Advice), while your FIRC is still issued by your own AD Category-I bank and your downstream EDPMS and GST steps stay exactly as they are.
• Regulated and certified: Xflow holds final PA-CB (Payment Aggregator - Cross Border) authorisation from the RBI for both exports and imports, as of February 2026, and is ISO 27001 and SOC 2 certified.