SWIFT MTs / Learning brief
SWIFT MT103
Your notes
In simple terms / 01
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.
Complete lesson / 02
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.
MT103 — SWIFT (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.
What happens around the message
- CUSTOMER
Asha Traders instructs Bank Alfa to pay the supplier EUR 12,400.00, quoting the invoice.
- 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.
- VALIDATION
Bank Alfa checks the field structure and business consistency, then screens the ordering and beneficiary customers against the lists it must check.
- 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.
The MT103 travels over SWIFT FIN toward Nordbank. It is information about a payment, never the value itself.
- NOTIFICATION
Nordbank reads the fields, credits the supplier, and confirmations follow back along the route.
| Account | Dr | Cr |
|---|---|---|
| Asha Traders' current account | EUR 12,400.00 | |
| Settlement position owed toward the beneficiary bank | EUR 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 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 GOINGKey takeaways / 03
Three things to remember
- 01
MT103 communicates one customer credit-transfer instruction.
- 02
The message and movement of funds are related but distinct.
- 03
Field interpretation depends on the complete payment route.
Practical use cases / 04
Where you would use this
An investigator reads references and parties to trace a delayed cross-border payment.
A developer maps MT103 fields into an internal canonical payment model.
A tester creates cases for charges, intermediary banks, and missing mandatory data.
Worked example / 05
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 / 07
Evidence & review
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
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · MT Category 1 — MT103 single customer credit transfer
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.
- Scheme-specific rule
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · pacs.008 as the ISO 20022 equivalent of MT103
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal · Asha Traders scenario and simplified ledger view
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.