What Is SWIFT MT103? Meaning, Format, Fields and How to Get One

Depth standard for every core section: direct answer, then a list or table, then a worked example or scenario using real MT103 fields, then what to check or do (and the limits), then a close.

An MT103 SWIFT message is a standardised payment confirmation, often called a SWIFT confirmation, that a bank creates when it sends an international wire, recording who paid whom, how much and through which banks. Businesses use it as official proof that a cross-border payment was sent, and banks often call it a 'SWIFT copy' or 'SWIFT advice'.

Key facts

• What it is: the SWIFT record of one international customer payment
• Who creates it: the sender's bank, when it releases the wire
• Who can request it: usually only the sender
• Proves: the payment was sent, not that it was received
• Tracks with: the UETR, a 36-character reference
• Now replaced by: pacs.008 for bank-to-bank messages (since 22 November 2025)

The MT103 meaning breaks down simply. SWIFT (Society for Worldwide Interbank Financial Telecommunication) is the SWIFT network banks use to send payment instructions to each other. Every message on it has a type code. 'MT' means Message Type, the first digit 1 means the message is a customer payment, and 103 is the code for a single customer credit transfer: one payment, from one customer, to one beneficiary, across borders. You will also see it written as MT 103 or SWIFT MT103; all mean the same message.

Customers never send an MT103 themselves. You ask your bank to pay a supplier abroad, the bank turns that instruction into the SWIFT message, and the receiving bank keeps its copy. When something goes wrong, a late, missing or short payment, the MT103 is the document both sides go back to. If you are an Indian exporter or freelancer, the one you care about is the MT103 your overseas client's bank created when it paid you.

On 22 November 2025, banks stopped sending MT103 between each other for cross-border payments and switched to the ISO 20022 message pacs.008, which carries the same details in a richer format. The document your bank hands you is often still labelled MT103 or SWIFT copy, which is why the term is still in daily use.

An MT103 contains every detail needed to identify, settle and trace one payment: the two parties, their banks, the amount and date, who paid the fees, a tracking reference and the payer's note.

Say a US client pays your USD 18,000 invoice. The MT103 shows 33B USD18000,00 (instructed), 32A USD17955,00 (settled) and 71A SHA. Reading those three fields together tells you the full story: your client sent the full amount, a bank in the middle took USD 45, and the charge code allowed it. No one made a mistake; the deduction is within the rules of SHA.

An MT103 does not show the exchange rate your bank used to convert to rupees, your bank's own charges, or whether the money has been credited to you. Those sit on your bank's credit advice or statement, not the MT103.

An MT103 is useful because it gives the sender, the recipient and every bank in between one agreed record of a payment. That single record settles the four problems that come up most with international payments.

Proof of payment

It shows that the sender's bank released the money on a stated date, for a stated amount, to the account details you gave. A supplier chasing an overdue invoice, an auditor checking an expense or a counterparty in a contract dispute will usually accept it as evidence that the payment was made. It is proof the payment left, not proof it arrived (see the next section). As an exporter, ask for it when a client insists an invoice is paid but your account shows nothing: it turns 'we paid' into a date, an amount and a reference you can check.

Dispute resolution

When a payment arrives short, the MT103 shows why. Compare field 33B (instructed) with 32A (settled), then read 71A. With SHA, each side pays its own bank and intermediary fees come out of the payment in transit, so a USD 18,000 invoice can land as USD 17,955 with nobody at fault. With OUR, the sender pays everything and you should receive the full amount; if you did not, the MT103 is your evidence for a refund request.

Payment tracking

Every MT103 carries a UETR, a reference that stays the same through every bank. Give it to your bank and it can see in SWIFT gpi whether the payment is still with the sender's bank, held at a correspondent, or already credited, instead of guessing. For an Indian business waiting on a USD or GBP payment, quoting the UETR to your AD bank gets a faster answer than asking it to 'look for a payment from my client'.

Reconciliation

Field 70 carries the payer's note, usually your invoice or PO number. When one client pays several invoices, or a payment arrives without a clear name, field 70 is what lets your accounts team post the credit to the right invoice and match it to the right EDF entry.

In practice, if a payment arrives in full, on time and clearly labelled, you rarely need to ask for the MT103. Request it when a client says 'we paid' and nothing has arrived, when the amount is short, or when an auditor asks for the payment trail. For an Indian exporter, it is a tracing tool; the compliance documents are the FIRC or eFIRA from your bank.

Yes, but only proof that a payment was sent. An MT103 shows the sender's bank released the money; it does not prove the money reached your account, because an intermediary bank can still delay, deduct from or return it.

Here is a common case: a client emails an MT103 dated Monday, but by Thursday nothing has arrived. The MT103 proves they paid, so the question becomes where the money is. Ask your bank to trace it with the UETR, and ask the client whether their bank shows the payment as completed. If a correspondent rejected it, perhaps because a name or account number did not match, it will come back to the sender, usually less fees.

Be careful with fake 'proof' too. 'MT103 one-way', 'MT103/23' and 'MT199 pre-advice' are not real payment guarantees. These terms appear in advance-fee scams where someone promises funds once you pay a fee. A genuine MT103 only exists after money has actually been sent, and only a credit in your account proves you have it.

An MT103 is a text message made of numbered fields, each starting with a tag such as :20: or :32A:. Six fields are mandatory on every MT103: 20, 23B, 32A, 50a, 59a and 71A; the rest appear only when needed.

Three conventions trip people up. Amounts use a comma as the decimal separator, so USD12500,00 is twelve and a half thousand dollars; the value date in 32A is written YYMMDD, so 260715 is 15 July 2026; and name and address lines are capped at 35 characters, which is why addresses look chopped.

In ISO 20022 the same codes are DEBT, SHAR and CRED. Do not confuse that CRED (beneficiary pays) with the CRED in field 23B (credit transfer).

A real-world MT103 example with a short payment

Read the two amount fields against each other: 33B says USD 18,000.00 was instructed and 32A says USD 17,955.00 settled. The USD 45 gap was taken by a correspondent bank in transit, which field 57A hints at by naming a different account-holding bank, identified by its SWIFT code. Field 71A reads SHA, which is what allowed the deduction; under OUR you would have received the full amount. Field 70 carries the invoice and PO numbers that let you post the short credit to the right invoice. For an exporter, this is the check that tells a bank charge apart from a client underpaying: if 71A is SHA and 33B shows the full invoice, the client paid in full.

If you are looking for an MT103 PDF or an MT103 format template, there is no official blank MT103 form or PDF for customers. When you request a copy, banks usually send a PDF titled SWIFT copy, SWIFT advice or MT103, laid out like the samples above. Since November 2025, some banks print the same details from the pacs.008 message instead, with field names such as 'Debtor' and 'Creditor' in place of tag numbers.

Ask the sender to request it from their bank. Only the sending bank creates the MT103 and releases the copy to its own customer, so as the recipient you usually cannot get it from your own bank.

1. Ask the sender with the payment date, amount and your invoice number, and ask for the UETR too.
2. The sender's bank issues the copy, sometimes the same day, sometimes in 1 to 2 business days through its trade or payments desk.
3. The sender forwards it to you, usually as a PDF.

Suppose a Singapore client says it paid SGD 8,000 on 2 October and nothing has arrived by 7 October. You send the request below; their bank issues the SWIFT copy the next day, showing value date 2 October and a UETR. Your bank traces that UETR and finds the payment held at a correspondent for a name check, which releases it once confirmed. Without the copy, you would have had no date, route or reference to chase.

You can send your client this request: '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 [number]. If possible, please include the UETR.'

If the sender is slow, in India you can ask your own AD bank whether it will share the inward SWIFT advice or credit advice it holds for the payment. Some banks do, some do not, and policies differ, so treat it as a back-up rather than the main route. If the money has not reached your bank at all, your bank will have nothing to share, which is itself a useful answer: the payment is still upstream.

Banks charge a small fee for a copy, which varies by bank, separate from the cost of the SWIFT wire transfer itself and from SWIFT transfer time, which depends on the banks in the chain. Many branches in India call it an MT103 SWIFT copy, or just 'SWIFT copy', rather than MT103; if you receive a document titled SWIFT advice, it is the right one.

Here is how to track MT103 payments. Track an MT103 with its UETR, a 36-character reference that SWIFT has made mandatory on payment messages since 18 November 2018. It stays the same through every bank in the chain, so your bank can look it up in SWIFT gpi and see exactly where the payment is.

1. Get the UETR from the MT103 or from the sender's bank.
2. Give it to your bank (or the sender gives it to theirs) and ask for a gpi status.
3. Read the status: in progress at a named bank, credited, or rejected and returning.

You cannot use the SWIFT gpi tracker yourself; it is a bank tool. If your bank cannot see a status, the sender's bank usually can, because it started the payment.

It helps to keep the two ideas apart. The MT103, or its pacs.008 successor, is the payment message itself and answers what was sent; you see it as a copy from your bank. SWIFT gpi is a tracking layer built on the UETR and answers where the payment is now; you see it as status updates through your bank, not as a document.

In India, a UTR is the reference for a domestic NEFT, RTGS or IMPS transfer; a UETR is the reference for an international SWIFT payment. Your bank's credit advice for an inward payment may carry its own reference for the rupee credit, but only the UETR traces the cross-border leg back through SWIFT. See our guide to the UTR number.

MT103 vs MT202 comes down to whose money moves: an MT103 carries a customer's payment with full sender and beneficiary details, while an MT202 moves money between banks, with no customer details. One international payment can involve both.

Here is how they work together. Say a German client pays your Indian account EUR 10,000, but their bank has no account with your bank. Their bank sends the payment message with your details towards your bank, and moves the actual euros through a correspondent bank using an MT202 COV, the cover version that repeats the customer details so every bank can screen them. Your bank matches the two and credits you. Since November 2025 these are a pacs.008 and a pacs.009 COV. For the full routing, see how SWIFT payment works.

In practice you only ever see the MT103 side. If your bank says it has the message but not the funds, the cover payment is still moving through the correspondent chain; ask the sender's bank to check the cover leg using the UETR. An MT202 is never what a client should send you as proof of payment.

In MT103 vs MT199, the key difference is that an MT103 moves a customer's money while an MT199 moves no money at all. MT199 is a free-format text message banks send each other for queries, investigations and cancellation requests about a payment.

Put side by side, the two could hardly be more different. An MT103 is a single customer credit transfer with fixed, mandatory fields, used to pay a supplier abroad, and it is proof that a payment was sent. An MT199 is free text between banks, used to ask about a delayed, wrong or duplicate payment, and it proves nothing about money moving.

You are most likely to meet a real MT199 when a payment is stuck. Say your client's payment is five days late. Their bank sends an MT199 to the next bank in the chain quoting the UETR and asking where the funds are. The reply might say the payment is held because the beneficiary name does not match the account. Your client's bank then sends a correction or a cancellation request. None of those MT199 messages moves money; they only move the investigation forward.

On the other hand, an 'MT199 pre-advice' saying funds are coming, sent before any payment, is not a payment and not proof of anything; it often appears in advance-fee scams. Treat any deal that asks you to pay a fee to 'release' funds after an MT199 as fraud until your bank confirms a credit.

MT199 is still in use today. Its ISO 20022 replacements (camt.110 and camt.111) were due in November 2026, but SWIFT has postponed that release to the first quarter of 2027, so expect MT199 to stay around for a while.

For bank-to-bank messages, no: since 22 November 2025, cross-border payments on SWIFT use the ISO 20022 pacs.008 message instead of MT103. For customers, the proof document is often still called MT103.

• MT103: replaced by pacs.008 for cross-border bank-to-bank payments.
• MT202: replaced by pacs.009 the same day.
• MT103 REMIT: withdrawn, with no ISO 20022 equivalent.
• Banks not yet migrated: SWIFT converts their MT messages to pacs.008 under a temporary contingency service, chargeable since 1 January 2026.

For you, nothing changes in how you receive money or ask for proof. If your bank sends a 'pacs.008' or a copy with 'Debtor' and 'Creditor' instead of tag numbers, it is the same proof. The new format carries separate address fields and longer payment notes, which gives banks more complete data to screen and match. If you receive USD from a US client into an Indian account, your bank's inward advice may now quote pacs.008 details, but your FIRC, eFIRA and EDF steps stay exactly the same. For routes that avoid the correspondent chain, see SWIFT payment alternatives.

For an Indian exporter, an MT103 helps you trace a payment, but it is not the document RBI or GST asks for: that is the FIRC or eFIRA from your bank.

• EDPMS: your AD bank reports the inward payment and closes the export entry once proceeds arrive; an MT103 does not close it.
• Purpose code: each inward payment is tagged with an RBI purpose code, for example P0802 for software consultancy and implementation.
• EDF: from 1 October 2026, service exporters report their invoices to the bank on a monthly Export Declaration Form, which replaced SOFTEX for software exports.
• FIRC or eFIRA: the proof of receipt your CA uses for GST refunds and records (see FIRC for GST refund).

Picture a Bengaluru agency that invoices a UK client GBP 6,000. The client pays, but only GBP 5,975 arrives. The agency asks the client for the MT103, sees 71A SHA and 32A lower than 33B, and so records a GBP 25 bank charge instead of chasing an underpayment. For its GST and FEMA records, it uses the eFIRA for GBP 5,975 and lists the invoice in that month's EDF. The MT103 explained the gap; the eFIRA and EDF are the compliance trail.

When comparing collection platforms, look for a payment document you can hand an auditor (a dashboard line will not satisfy one); the fee shown before you accept the payment; live status on incoming payments; and readiness for ISO 20022 messages.

Xflow issues an eFIRA within 24 hours for every international transaction, along with payment advice; the FIRC and EDPMS steps still run through your bank.

Delete; points now covered in 5.1, 5.4, 5.6 and 5.11.