What Is MT103? Meaning, Format & How to Get One

An MT103 is a standardised SWIFT message that confirms a single cross-border customer credit transfer was sent, and it’s the document banks and businesses treat as proof of payment.

Banks generate the MT103 SWIFT message themselves and send it across the SWIFT network. The receiving bank holds a copy on file. When a payment arrives short or late, that copy is usually what you end up asking for.

Key details inside an MT103:

• Who paid whom - the ordering customer (field 50a) and the beneficiary customer (field 59a), with account, name and address for each.
• Bank identifiers - the sending, receiving and any intermediary banks, by SWIFT/BIC code.
• Amount, currency and value date - field 32A holds the amount actually settled, field 33B what the sender instructed.
• Who paid the fees - field 71A carries one of three charge codes (OUR, SHA or BEN), and it’s the field that explains a short payment.
• A UETR - the 36-character Unique End-to-end Transaction Reference a bank uses to trace the payment through SWIFT gpi (Global Payments Innovation).

Why it matters:

• Proof of payment - evidence that the transfer left the sender’s account.
• Tracking - the UETR is how a bank locates a delayed payment.
• Reconciliation - the fields tie a received amount back to a specific invoice.

One thing worth knowing before you go looking for one: only the sender can request an MT103 from their bank. As the recipient, you generally can’t pull it yourself.

MT103 is the SWIFT message type banks use for a single customer credit transfer, which is the technical name for one payment moving from one customer to another across borders.

SWIFT stands for the Society for Worldwide Interbank Financial Telecommunication, the network banks use to exchange payment instructions.

Every message on that network carries an MT code, short for Message Type, and the first digit of the three-digit number tells you its category. MT103 sits in Category 1, customer payments and cheques, and the “103” denotes a single customer credit transfer specifically.

That’s the practical difference between an MT103 and a bare SWIFT message. SWIFT messaging covers everything from account statements to free-format queries, and MT103 is one specific type inside that family.

Customers don’t send MT103s. Banks do. You’ll also see the same message written as MT 103, with a space, and as SWIFT MT103. All three refer to the same thing.

Here’s what a real MT103 SWIFT message looks like once each line, called a field or a tag, is labelled with what it carries.

A few conventions in there catch people out. Amounts use a comma as the decimal separator, never a full stop, so USD12500,00 is twelve and a half thousand dollars.

The value date in 32A is YYMMDD, so 260715 is 15 July 2026. Name and address fields cap at 35 characters per line, which is why addresses look chopped up.

This example is clean on purpose, and the values are illustrative. Charge code OUR means the sender’s side absorbed every fee, so the beneficiary receives the full USD 12,500. Field 57A is absent because the beneficiary’s bank is also the receiver of the message.

If you came here looking for an MT103 SWIFT message format PDF, there isn’t an official downloadable one for customers. The format is a text structure, which is what’s shown above.

Below is closer to what a bank system actually produces, unformatted, and it deliberately shows a common real-world wrinkle.

The figures are illustrative and don’t reproduce a real payment. Read the two amount fields against each other. Field 33B says the sender instructed USD 18,000.00, and field 32A says USD 17,955.00 actually settled.

The USD 45.00 gap didn’t vanish. A correspondent bank in the middle took it out of the payment while the money was in transit.

Field 57A names the bank holding the beneficiary’s account. It appears when the beneficiary’s account sits at a bank other than the one receiving the message, which means the payment had to pass through at least one correspondent on the way.

The correspondent chain is where the USD 45 went.

The invoice and purchase-order references in field 70 are what let you match the credit to the right invoice in your books instead of guessing.

The field that explains the deduction is 71A, and it reads SHA. That’s the charge code that caused this USD 45 short payment. The other two codes would have produced a different outcome entirely.

Six fields are mandatory on every MT103: 20, 23B, 32A, 50a, 59a and 71A. The rest only appear when they’re needed.

Some tags are written with a lowercase “a” because they have letter options. You saw :50K: and :59: in the samples above, which are the ordinary options for a corporate payer and payee.

Two of the optional fields are worth knowing by name. Field 57a identifies the bank holding the beneficiary’s account by its SWIFT code, and it’s the clearest signal that a correspondent bank sat in the chain.

Field 70 is where the payer’s remittance advice detail lives, and it’s usually the fastest route to matching a credit against an invoice.

Field 71A: OUR, SHA or BEN

The charge code in field 71A decides whether you receive the full amount or something less.

SHA is the code behind most inward payments that land short of the invoiced amount, and nobody has to have done anything wrong for it to happen. That is what happened in the sample above.

In ISO 20022 messages the same three codes appear as DEBT, SHAR and CRED.

Watch that last one. CRED as a charge code means the beneficiary pays, and it is not the CRED in field 23B, where the same four letters mark the message as a credit transfer.

An MT103 is the record that backs a SWIFT wire transfer for a customer payment, which is why you’ll also see it called an MT103 wire transfer or an MT103 cash transfer. Businesses reach for it for three reasons:

• Proof of payment - what you hand over when a statutory auditor, a counterparty in a contract dispute, or a third party running due diligence asks for the payment trace in writing.
• Tracking - give your bank the UETR and it can query SWIFT gpi for where the payment currently sits, which is where any escalation on a delayed credit starts.
• Reconciliation and disputes - when field 32A credits less than field 33B instructed, this is where your accounts team sees the size of the gap and which invoice to post the short credit against.

Mechanically, a cross-border customer payment moves in three steps, and the MT103 is the instruction travelling with it:

• The sender’s bank creates and releases the instruction - it debits the sender and puts the payment message onto the network.
• One or more correspondent banks may sit in the middle - each one passes the payment along, and each one can deduct a fee from it.
• The beneficiary’s bank credits the account - it holds the received message on file and posts the credit against it.

That middle step is where most of the friction lives. Our explainer on how SWIFT payment works goes deeper into the routing than this page needs to.

You’d need to see an MT103 in situations like these:

• The payment is late or hasn’t arrived - the copy confirms it was sent, and on what value date.
• You’re in a dispute with a customer - field 70 ties the payment to a specific invoice.
• A compliance or audit request lands - an auditor or a counterparty’s finance team wants the payment trace.
• You’re supporting an export-incentive or refund claim - the MT103 evidences the payment trail behind it.
• The payment is high-value - larger transfers tend to draw closer scrutiny on both sides.

You cannot request an MT103 directly from your own bank as the recipient. Only the sender can request one from their bank, because the sending bank generates the message and releases it to its own account holder.

Why you, as the recipient, usually can't request it directly

Indian banks routinely email the sender an MT103 copy for outward payments the moment they process them. There’s no confirmed equivalent automatic service for inward payments.

That rule has one soft edge in India: as the beneficiary, you can ask your AD bank (Authorised Dealer bank) whether they’ll share the inward SWIFT copy or credit advice they hold on file. This varies by bank and isn’t guaranteed.

The reliable route is still asking the sender to request it from their own bank.

Bank of Baroda’s public FAQ document illustrates the asymmetry. Its outward-remittance section promises an emailed copy of the MT103 plus a debit advice to the applicant. Its inward-payments section promises only a notification that money arrived.

The typical three-step request flow, and what it costs

Requesting an MT103 takes three steps, costs roughly $20-50 in bank fees, and takes anywhere from a few hours to 2 business days.

• You ask the sender - give them the payment date, the amount, and your own invoice or reference number.
• The sender's bank processes and issues the copy - some banks do it same day, others queue it with their trade-services desk.
• The sender forwards it to you - usually a PDF, sometimes labelled “SWIFT copy” rather than “MT103”.

That fee sits separately from what the transfer itself cost, which our breakdown of SWIFT wire transfer charges covers in full.

It is also separate from how long the payment takes to arrive, since SWIFT transfer time depends on the correspondent chain, not on when a copy gets issued.

A ready-to-use request-phrasing template

Ask the sender to request a SWIFT MT103, also called a SWIFT copy or SWIFT advice, quoting the payment date, the amount and your invoice reference.

Banks don’t all use the word MT103. “SWIFT advice”, “SWIFT copy” and “MT103” are used interchangeably, and in India the first two are more common at a branch counter.

There’s also no blank, fillable MT103 form a customer downloads and completes. Some banks keep their own internal request form, but the message itself is generated bank-side, so the practical equivalent is knowing exactly what to ask for.

Send your sender something close to this:

Please ask your bank for a SWIFT MT103, also called a SWIFT copy or SWIFT advice, for the payment dated [date] for [amount]. My invoice reference is [reference]. If your bank can also share the UETR for the payment, please include that.

The date, the amount and the sender’s own reference number (SWIFT field 20, sometimes called the transaction reference) are what a bank needs to locate the payment.

If the sender already has the UETR, ask for that too, since it’s the one reference that doesn’t change as the payment moves between banks.

The process is the same at any bank, Citibank included. Only the channel differs, whether that’s a branch, a relationship manager or an online banking request.

An MT103 works as a SWIFT confirmation of payment, and auditors, banks and counterparties accept it as proof of payment.

It has one specific limit. An MT103 evidences that the sending bank released the payment, but it doesn’t confirm the funds cleared into your account, and it doesn’t make the payment irreversible.

A payment can still be recalled or returned over a wrong beneficiary detail long after an MT103 exists for it. Treat the MT103 as evidence of dispatch and your own bank statement or credit advice as evidence of receipt.

That’s also why it works as a receipt for a third party who needs to see a payment was made. Fraudsters work the same gap between sent and settled, which is where the next three warnings come in.

Three MT103 red flags that mean fraud

• “One-way” or “leased” MT103 offers - a genuine MT103 only exists as part of a payment that has already been sent. It’s never sold, leased, or issued in advance of funds moving, so any offer of one is advance-fee fraud.
• A request for payment before funds move - the classic advance-fee pattern, usually dressed up as a fee to “activate” or “release” the transfer.
• Unofficial labels like “MT103/23” or “two-way” - these aren’t real SWIFT message types. A SWIFT message can’t carry conditions, and anything typed in as a condition is ignored by the beneficiary’s bank. The terms circulate almost entirely in scam material.

MT202 was a genuine SWIFT message type in its own right, replaced by pacs.009 in November 2025, which is worth separating from the fabricated “MT103/202 two-way” label. The difference between MT103 and MT202 is covered further down.

If you do hold a genuine MT103 and the money still hasn’t arrived, the useful next move is tracing it.

Track an MT103 using its UETR (Unique End-to-end Transaction Reference) through SWIFT gpi tracking.

The UETR is a 36-character identifier, mandatory on SWIFT payment messages since November 2018. It’s generated once, at initiation, and stays the same through every bank in the chain.

That’s what makes it more reliable than field 20’s sender reference, since intermediary banks can assign their own references in transit.

One practical limitation: you can’t query the SWIFT gpi Tracker yourself. Tracker access is a bank-side tool. You track through your own bank’s portal, or by giving your bank the UETR and asking them to trace it.

MT103 and gpi get confused because they travel together, so here’s what each one actually is.

If your bank can’t see a status, the sender’s bank often can, because the sending side initiated the payment and holds the originating record.

For an Indian services exporter receiving payment, an MT103 is useful for diagnosis rather than for compliance. Your obligations as the beneficiary of an inward remittance run through your AD bank, and they’re a different rule set from the one that applies to somebody sending money out of India.

EDPMS closure

EDPMS (the Export Data Processing and Monitoring System) is RBI’s system for monitoring whether export proceeds actually get realised against each shipping bill or invoice.

Your AD bank reports the inward remittance and closes the entry once the proceeds land. An open entry is a conversation with your bank, and an MT103 isn’t what closes it.

Purpose codes P0802 and P0807

Every inward remittance gets classified against an RBI purpose code, and software and IT services have their own. P0802 covers software implementation and consultancy not covered by SOFTEX. P0807 covers off-site software exports, which are SOFTEX-reportable.

FIRC/eFIRA vs the MT103 itself

What RBI actually requires from you as an inward-remittance recipient is EDPMS closure and a FIRC (Foreign Inward Remittance Certificate) or eFIRA via your AD bank, not an MT103.

An MT103 (or its SWIFT copy) is useful as payment-trace evidence for a dispute or a third-party audit request, but it’s not itself an RBI-mandated document.

If your CA is asking for support on a FIRC for GST refund, the certificate is the document that carries the weight.

If you’re comparing collection platforms on paperwork rather than price, four traits are worth checking:

• A payment document you can hand an auditor - a dashboard line item won’t satisfy one.
• The fee deducted, visible before you accept the payment - rather than reconstructed afterwards.
• Live status on an incoming payment - so chasing a delay doesn’t start with a phone call.
• ISO 20022 readiness - the message formats banks moved to in November 2025.

Xflow automatically issues an eFIRA (electronic Foreign Inward Remittance Advice) and payment advice for every incoming payment. The FIRC itself still comes from the Indian bank, and the downstream EDPMS and GST-refund workflow is unchanged.

The message types nearest to MT103 are MT202, its bank-to-bank counterpart, and pacs.008, its ISO 20022 replacement. Several others came through the 2025 cutover untouched.

MT103 vs MT202: what's the difference

MT103 and MT202 both move money across SWIFT, but for different legs of a payment. An MT103 carries a customer’s payment with full ordering and beneficiary detail. An MT202 moves funds between financial institutions, with no customer detail in the base message.

The wider SWIFT and ISO 20022 message family

MT103 and MT202 aren’t the only message types affected by the 2025 cutover, and not all of their relatives were retired. Here’s the wider set of messages on the SWIFT network that an exporter is likely to hear named.

That distinction has practical consequences. If your finance team pulls MT940 statements into an ERP for reconciliation, or your bank sends an MT910 when your account is credited, none of that changed on 22 November 2025.

SWIFT replaced MT103 with pacs.008 under ISO 20022 for interbank flows on 22 November 2025.

That needs one qualification, and it’s the part that trips people up. The MT103 message itself has been retired from bank-to-bank SWIFT traffic since 22 November 2025 and replaced by pacs.008, but banks still issue MT103-format documents or copies to customers as proof of payment.

So the wire your bank sends today is a pacs.008. The document it hands you can still be labelled MT103 or SWIFT copy, and businesses still request it in 2026.

What actually changed on 22 November 2025:

• MT103 - retired for bank-to-bank flows, replaced by pacs.008.
• MT202 - retired the same day, replaced by pacs.009.
• MT103 REMIT - withdrawn outright, with no ISO 20022 substitute.
• Unmigrated senders - auto-conversion to pacs.008 at initiation, chargeable since January 2026 and capped by volume.

Institutions that hadn’t migrated weren’t stranded. SWIFT auto-converts an MT103 to pacs.008 at initiation under a contingency service, chargeable since January 2026 and capped by volume. It’s a temporary bridge rather than a long-term option.

The rulebook behind all of this is CBPR+ (Cross-Border Payments and Reporting Plus), SWIFT’s guidelines for how the ISO 20022 messages must be built and read, so every bank interprets them the same way.

Some exporters route receivables around the correspondent chain rather than manage it, and our guide to SWIFT payment alternatives covers those routes.

An MT103 proves a cross-border payment was sent. It doesn’t prove the money cleared, and you can’t pull one from your own bank as the recipient. The sender’s bank issues it, typically for $20-50 and within a few hours to 2 business days.

Six fields are mandatory, and 71A is the one that explains a payment arriving short. For an Indian exporter, the documents RBI actually wants are a closed EDPMS entry and a FIRC or eFIRA from your AD bank, not the MT103.

Xflow issues an eFIRA and payment advice on every incoming payment, so the payment-advice side of that paperwork does not start with a request to a bank. The FIRC and the EDPMS entry still run through your AD bank.

Keep the MT103 for what it’s genuinely good at, which is tracing one specific payment when something goes wrong.