Payments - Introduction / Learning brief

Payment Messages

13 July 2026Plain-language lessonContributor: Shubham Mathure

Your notes

In simple terms / 01

What this means in plain language

Explains how customer and interbank messages carry payment instructions and status information across an end-to-end transfer.

Payment messages carry structured information needed to request, process, report, or investigate a transfer. A customer instruction tells a bank what should be paid. Interbank instructions coordinate institutions. Status messages report acceptance, rejection, or progress, while account reports and investigation messages support reconciliation and exception handling. The message is not the same as the money: it describes an event or instruction, and separate account or settlement processes complete the value movement. Consistent identifiers, parties, amounts, dates, and reasons allow systems to connect all messages in one payment story.

Complete lesson / 02

Understand the full idea, step by step

Until now you have watched payments as journeys — instructions, ledgers, clearing, settlement. Every hop of those journeys was carried by something you have not yet looked in the eye: a payment message, a small block of rigidly structured text that one bank's machine writes and another bank's machine reads. Time to meet one.

What a message actually is

A payment message is a structured record with agreed field meanings: who pays, who receives, how much, in which currency, on what date, with which reference. The structure is the point — a machine at any bank in the world must extract the amount, screen the names, and route the payment without a human reading it. And one thing a message never carries is the money. It is the instruction and the information; value moves separately, when accounts are debited and credited. The message asks; the ledgers answer.

SWIFT MT — ILLUSTRATIVE, NON-PRODUCTION

:20:ALFA-2607-00421
:23B:CRED
:32A:260713EUR12400,00
:50K:/00218890
ASHA TRADERS
:59:/DE44NORD0000123456
ARJUN
:70:INV-2214
:71A:SHA

An MT103 — the classic customer credit transfer between banks. Each :nn: tag has a fixed meaning: :20: is the sender's reference, :32A: packs value date, currency, and amount into one line (date as YYMMDD, and note the comma as decimal separator — 12400,00), :50K: and :59: are the ordering customer and beneficiary, :70: carries the invoice reference for Arjun, and :71A:SHA says the banks share the charges.

READ THE MESSAGE REFERENCE →

You may be wondering: why so rigid? Why not just write "please pay Arjun EUR 12,400" in a secure email?

Because no human reads this. The message will be parsed, validated, screened against sanctions lists, routed, and booked by software at two or more banks — possibly in different countries, built by different vendors, decades apart. Only a format where the amount is always in the same place, written the same way, lets all of them agree on what was instructed. Rigidity is not bureaucracy; it is how thousands of independent machines stay in agreement.

MT — Message Type — the SWIFT tag-based message family

The established format, carried over the SWIFT network for decades: compact lines of :tag:value pairs, with numbered types grouped by purpose. MT1xx messages carry customer payments (the MT103 above), MT2xx carry bank-to-bank transfers, MT9xx carry statements and confirmations. Terse, proven, and limited — the fields hold little structured detail about parties and remittance.

MX / ISO 20022 — the XML-based message family defined under the ISO 20022 standard

The modern counterpart. ISO 20022 is more than a format — it is a methodology and a repository of business definitions, from which XML messages are generated. Names describe purpose: pacs.008 is the interbank customer credit transfer (the MT103's counterpart), pain.001 the customer's initiation, camt.053 the statement. The same payment fills far richer, labelled structures — separate elements for names, addresses, identifiers, and remittance — which is why screening and reconciliation teams prefer it.

MT vs MX at a glance
	MT	MX (ISO 20022)
Syntax	Colon-tagged lines — `:32A:`	XML elements — `<IntrBkSttlmAmt>`
Names	MT103, MT202, MT940	pacs.008, pacs.009, camt.053
Party & remittance detail	Compact, loosely structured	Rich, fully labelled structures
Where you meet it	Established correspondent traffic	Modern rails and cross-border migration

COMMON CONFUSION

“When Nordbank receives the MT103, the EUR 12,400.00 has arrived with it.”

The message delivers the instruction and the details — never the value. Nordbank credits Arjun only after its own checks pass and it is satisfied the funding is in place, through whatever settlement arrangement the banks use. If the message were lost in transit, not a cent would be lost with it; the instruction would be re-sent or investigated.

Where to explore them on this site

This brief is an introduction, and the site is built for the next step. The Message Lab lets you open annotated samples of each family and decode them field by field — the link under the snippet above leads to the full MT103 reference. The flow player shows the other half of the picture: which message moves at which hop of a payment, and what each party does when it arrives. Read a message, then watch it travel.

FOR NOW, REMEMBER

A payment message is a structured, machine-readable record of an instruction or a status — rigid on purpose, so every bank's software reads it identically.
Messages carry information, never value: money moves only when accounts are debited and credited.
Two families cover most of what you will meet: tag-based MT (MT103, MT202, MT940) and XML-based MX under ISO 20022 (pacs.008, pain.001, camt.053).
ISO 20022 is a methodology and repository, not just XML — its richer structure is why the industry is moving toward it.

TRY IT YOURSELF

Nordbank's systems have just received the MT103 for Asha Traders' EUR 12,400.00 payment. Which statement is accurate at this moment?

Nordbank now holds an instruction and its details; Arjun's credit follows only after Nordbank's checks pass and the interbank funding is in place.

Correct — Right. The message's arrival starts Nordbank's work — validation, screening, confirming cover — and the credit to Arjun is a separate, later event on Nordbank's own books.

The EUR 12,400.00 arrived inside the message, so Arjun's account is already credited.

Not this one — Messages never carry value. The MT103 is text — parties, amount, date, references. The money moves only through debits, credits, and settlement between the banks.

Receiving the MT103 obliges Nordbank to credit Arjun immediately, before any checks.

Not this one — A receiving bank always applies its own validation and screening first, and credits when it is satisfied — including that funding is in place. An instruction is a request to act, not an accomplished fact.

You have now seen the artifact that travels. The payment lifecycle topic places it in time — exactly when in a payment's journey each message is created, sent, answered, and reconciled.

KEEP GOING

Key takeaways / 03

Three things to remember

01
Messages describe payment events; accounts record value changes.
02
Different business stages need different message purposes.
03
Stable references connect instructions, statuses, reports, and exceptions.

Practical use cases / 04

Where you would use this

USE CASE 01

A gateway maps a customer instruction into the bank-to-bank format required by a payment rail.

USE CASE 02

An operations analyst links a negative status to the exact transaction in a bulk file.

USE CASE 03

A corporate treasurer uses account reporting to reconcile invoices with completed transfers.

Worked example / 05

Put the idea into a real situation

A company sends a file containing several supplier instructions. Its bank acknowledges the file, validates each transaction, and creates interbank messages for accepted items. One item receives a negative status because required data is invalid; the others continue. Later, account reporting shows the resulting debits. Shared references let the company connect the original file, individual statuses, and ledger entries. This example is illustrative and not tied to one particular message standard.

Evidence & review / 07

Evidence & review

AWAITING SME REVIEWNo qualified human domain reviewer has signed off on this yet — how review works.

REVIEWED 2026-07-13

SWIFT MT and ISO 20022 message families in general; specific field rules follow the standards release in force

What this brief simplifies: The MT103 snippet is a shortened synthetic illustration — headers, trailers, and several mandatory fields are omitted; charge-bearer and routing options are not covered here.

Sources for this brief3

Market practice
Swift Standards MT (annual standards releases) ↗ — Swift · MT103 structure and field meanings
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.
Market practice
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · ISO 20022 methodology, repository, and message families (pacs, pain, camt)
Defines the current versions of all ISO 20022 message definitions, including the pain, pacs, and camt messages taught on this site. · Checked 2026-07-12
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal · Synthetic MT103 teaching snippet
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.