GLOBAL PAYMENTS KNOWLEDGEISO 20022 / SWIFT / SEPA / MT / MX

SWIFT MTs / Learning brief

SWIFT MT103

Your notes

What this means in plain language

Directs readers to a detailed learning session about the SWIFT MT103 customer credit transfer message.

An MT103 is a SWIFT FIN message used to communicate a single customer credit transfer between financial institutions. It carries structured details about the ordering customer, beneficiary, banks, value, currency, charges, references, and remittance information. The message is an instruction and record; the associated funds may settle through accounts and correspondent relationships outside the message itself. Reading an MT103 well means understanding both its fields and the wider payment route. Validation, sanctions screening, account posting, and reconciliation still surround the message.

Understand the full idea, step by step

Think of a delivery note stapled to a parcel: it names the sender, the recipient, what is being sent, and any special handling. A SWIFT MT103 is that note for a single customer payment — except the parcel of money never rides along with it. Once you learn to read the note field by field, the whole message stops looking like code and starts reading like an instruction.

MT103SWIFT (Society for Worldwide Interbank Financial Telecommunication) Message Type 103, the single customer credit transfer

An MT103 carries one customer credit transfer between financial institutions over SWIFT's FIN messaging service. "MT" means Message Type; the number 103 is reserved for a single customer payment. It names the ordering customer, the beneficiary, the amount and value date, the banks in the route, and how charges are shared. It is an instruction that one bank sends another — not the money, and not a receipt that the money has arrived.

Read the MT103 as a set of fields

Field 20
Sender's Reference — the transaction reference every later message and query quotes to pair up with this one.
Field 23B
Bank Operation Code — CRED marks a normal credit transfer; it tells the receiver how to handle the item.
Field 32A
Value date, currency, and interbank settled amount — EUR 12,400.00 with the date the banks settle it between themselves.
Field 50a
Ordering Customer — who is paying. Here, Asha Traders.
Field 59a
Beneficiary Customer — who is being paid. Here, the supplier at Nordbank.
Field 71A
Details of Charges — OUR, SHA, or BEN, saying who bears the fees along the way.

SWIFT MT — ILLUSTRATIVE, NON-PRODUCTION

A compact FIN-style MT103. Notice the fields you just met: :20: the sender's reference, :23B:CRED the operation code, :32A: the value date, currency and settled amount, :50K: the ordering customer, :59: the beneficiary, and :71A: the charges. The values are synthetic. This message travels bank to bank; Asha Traders never sees it.

What happens around the message

  1. CUSTOMER

    Asha Traders instructs Bank Alfa to pay the supplier EUR 12,400.00, quoting the invoice.

  2. INSTRUCTION

    Bank Alfa composes the MT103, filling field 20 with a reference, field 32A with the amount and value date, and fields 50a and 59a with the two customers.

  3. VALIDATION

    Bank Alfa checks the field structure and business consistency, then screens the ordering and beneficiary customers against the lists it must check.

  4. LEDGER

    Bank Alfa debits Asha Traders and records what it now owes toward the beneficiary side. The money is squared up separately, not inside the message.

  5. MESSAGE

    The MT103 travels over SWIFT FIN toward Nordbank. It is information about a payment, never the value itself.

  6. NOTIFICATION

    Nordbank reads the fields, credits the supplier, and confirmations follow back along the route.

Bank Alfa's books (simplified)
AccountDrCr
Asha Traders' current accountEUR 12,400.00
Settlement position owed toward the beneficiary bankEUR 12,400.00

An illustrative two-entry view from Bank Alfa's side only. A real posting adds fee lines, control accounts, and a position against the settlement route, and the exact account names vary by bank.

You may be wondering: if the MT103 reaches Nordbank, has the money moved?

Not by itself. The MT103 is the announcement — it tells Nordbank what to pay and to whom. The value moves when accounts change: Bank Alfa debits Asha Traders, and the two banks settle what they now owe each other through the accounts they hold in the route. Read the message and the postings as two separate stories that must both be true before the supplier is genuinely paid.

COMMON CONFUSION

A SWIFT network acknowledgement for the MT103 means the beneficiary has been credited.

An acknowledgement only says the message was accepted at one point in the network. It proves nothing about the supplier's account. To know the payment truly landed, you follow field 20's reference through the receiving bank, the screening and repair queues, and the account entries — not the delivery receipt.

STRICTLY SPEAKING

Strictly speaking, the exact field options, which fields are mandatory, and the straight-through-processing rules for MT103 are defined in the SWIFT Standards documentation, and the same customer payment is increasingly carried as the ISO 20022 message pacs.008 under CBPR+. The two describe the same instruction with different structure. Check the standard in force before quoting a precise field layout.

FOR NOW, REMEMBER

  • An MT103 is one customer credit transfer, sent as a structured instruction between banks over SWIFT FIN.
  • Its fields map to plain questions: 20 the reference, 23B the operation code, 32A the amount and value date, 50a the payer, 59a the payee, 71A the charges.
  • The message announces the payment; the money moves separately through account entries and settlement.
  • A network acknowledgement confirms delivery of the message, not credit to the beneficiary.

TRY IT YOURSELF

Maya sees a positive SWIFT acknowledgement for an MT103 Bank Alfa sent to Nordbank. A day later the supplier says it has not been paid. What is the most accurate reading?

The acknowledgement proves the supplier was credited, so the complaint must be a mistake at the supplier's end.

Not this one — A network acknowledgement only confirms the message was accepted in transit. It says nothing about whether Nordbank has credited the supplier's account.

The message was delivered, but credit is a separate step; Maya should trace field 20's reference through Nordbank's screening, repair, and posting before assuming anything.

Correct — Correct. Delivery of the instruction and credit to the beneficiary are distinct. The reference is the thread that lets her follow the payment through the receiving bank rather than trusting the acknowledgement.

The MT103 was carrying the EUR 12,400.00 and it must have been lost with the message.

Not this one — Messages carry information, not value. If a message were lost, no money is lost — the banks still hold every euro and the instruction is re-sent or investigated.

The MT103 was the bank-to-bank instruction. But who asked the bank to send it? Often a corporate treasury, using a different message — the MT101 request for transfer, which we read next.

KEEP GOING

Three things to remember

  1. 01

    MT103 communicates one customer credit-transfer instruction.

  2. 02

    The message and movement of funds are related but distinct.

  3. 03

    Field interpretation depends on the complete payment route.

Where you would use this

USE CASE 01

An investigator reads references and parties to trace a delayed cross-border payment.

USE CASE 02

A developer maps MT103 fields into an internal canonical payment model.

USE CASE 03

A tester creates cases for charges, intermediary banks, and missing mandatory data.

Put the idea into a real situation

Illustrative example: Bank A sends an MT103 instructing Bank B to credit a customer with USD 2,000. The message names the ordering party, beneficiary, amount, date, charge option, and transaction references. Operations sees that an intermediary bank is involved, so it checks both the FIN acknowledgement and correspondent account entries. The beneficiary is considered paid only after the receiving bank completes its checks and posts the credit.

Evidence & review

REVIEWED 2026-07-13

SWIFT FIN MT103 single customer credit transfer; cross-border correspondent context. Field numbering per the SWIFT MT standard; ISO 20022 pacs.008 is the CBPR+ successor.

What this brief simplifies: The ledger shows only Bank Alfa's side as a two-entry pair and omits fee, control, and settlement-position postings. Field descriptions are taught at concept level; exact options and network-validated rules live in the SWIFT Standards documentation.

Sources for this brief3
  1. Official requirement

    Swift Standards MT (annual standards releases)Swift · MT Category 1 — MT103 single customer credit transfer

    Defines the MT message standards (including MT101, MT103, MT202/202 COV, and the MT9xx statement messages) exchanged over the Swift FIN network, maintained through annual standards releases. · Checked 2026-07-12

    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.

  2. Scheme-specific rule

    Cross-Border Payments and Reporting Plus (CBPR+) usage guidelinesSwift (CBPR+ working group) · pacs.008 as the ISO 20022 equivalent of MT103

    Defines how ISO 20022 messages (including pacs.008, pacs.009, pacs.002, pacs.004, and camt investigation messages) are used and validated for cross-border payments on the Swift network. · Checked 2026-07-12

    Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.

  3. Simplified educational illustration

    Payments Signal editorial teaching modelsPayments Signal · Asha Traders scenario and simplified ledger view

    This site's own simplified teaching models. · Checked 2026-07-12

    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.

Learn this properly

Related briefs

View SWIFT MTs archive

SWIFT MT101

Explains how corporates and banks use MT101 transfer requests in practice and how those instructions can lead to customer credit transfers.

READ BRIEF

SWIFT MT9xx: statements and confirmations

Describes the SWIFT Category 9 messages — the MT900 debit confirmation, MT910 credit confirmation, and MT940, MT942, and MT950 statements — and how they feed reconciliation of the accounts a bank holds at other banks.

READ BRIEF

SWIFT investigation and exception messages

When a payment must be questioned, cancelled, or corrected, banks use dedicated exception messages: free-format MT n99 notes, MT n92 cancellation requests, and the ISO 20022 camt.056 and camt.029 pair, supported by SWIFT gpi stop-and-recall.

READ BRIEF