SWIFT / Learning brief
SWIFT MT – Payments Perspective
Your notes
In simple terms / 01
What this means in plain language
Narrows the broader MT catalog to the message categories most relevant to customer transfers, bank transfers, and cash management.
The full MT catalog covers many financial activities, but payment teams can begin with a smaller working set. Category 1 messages commonly support customer payment instructions, category 2 messages support transfers between financial institutions, and category 9 messages support cash management and account reporting. Investigation and free-format messages may also matter when something goes wrong. Learning by business purpose is more useful than memorizing every type. The same transaction can produce several related messages, so teams should view them as a conversation around payment, funding, status, and reconciliation.
Complete lesson / 02
Understand the full idea, step by step
A nurse glancing at a chart does not read every line — the eyes go straight to the few numbers that decide the next action. A payments operations analyst reads an MT message the same way. There are dozens of possible fields, but only a handful answer the questions that matter right now: where is this going, how much, from whom, to whom, who pays the charges, and which reference ties it to everything else.
The questions come before the fields
A payments person does not read a message field by field; they arrive with questions and let the fields answer. Which reference is this? How much, in what currency, valued when? Who is the ordering party and who is the beneficiary? How does it route — any intermediary, which account-with bank? Who bears the charges? Learn which field answers each question and you can read any customer or interbank MT at working speed, skipping the rest until you need it.
The fields a payments analyst reads first
- Reference — :20: (and :21:)
- The sender's reference, and the related reference that links this message to the payment it belongs to.
- Amount — :32A:
- Value date, currency, and settlement amount in one field — the what and the when.
- Ordering party — :50a:
- Who the money is coming from (the debtor / ordering customer).
- Beneficiary — :59a: / :58a:
- Who is ultimately being paid — a customer (:59:) or an institution (:58A:) depending on the message.
- Routing — :56a: / :57a:
- The intermediary and the account-with institution: the path the payment takes to reach the beneficiary's bank.
- Charges — :71A:
- Who bears the fees: OUR, SHA, or BEN.
SWIFT MT — ILLUSTRATIVE, NON-PRODUCTION
Read it Maya's way. :20: and :21: give this cover its own reference and the reference of the customer payment it funds. :32A: is amount and value date. The routing fields :52A: (ordering institution), :56A: (intermediary), :57A: (account-with) and :58A: (beneficiary institution) trace the path. Then :50K: and :59: repeat the underlying customer and beneficiary — the same parties as the original MT103. Fictional data.
Why does a cover payment between banks repeat the underlying customer's name at all — isn't that the customer message's job?
It is repeated so that every bank in the chain can screen the same parties. The cover (MT202 COV) moves the money between institutions to fund a customer payment (the MT103) sent separately. If the cover named only the banks, a correspondent handling the funds would never see who the payment is really for or from, and could not run it against sanctions and controls. Sequence B of the COV carries the ordering customer and beneficiary precisely so the money leg and the announcement leg describe the same people. That is the difference between a plain MT202 and an MT202 COV.
| MT103 (customer transfer) | MT202 COV (cover) | |
|---|---|---|
| Its job | Instructs the beneficiary's bank to pay a named customer | Moves the funds between banks to cover an underlying MT103 |
| The beneficiary field | :59: — the end customer | :58A: — the beneficiary institution, with the underlying customer repeated in sequence B |
| Link to the other leg | Carries its own reference in :20: | Points back to the customer payment via :21: and repeats its parties |
| What Maya checks | Parties, amount, charges, routing | That it correctly funds the matching MT103 and repeats the same parties for screening |
WHAT IF — A cover payment arrives whose :21: does not match any customer payment Bank Alfa is expecting
What happens: Maya cannot pair the funds leg with its announcement. The money is covered but the underlying instruction is missing, contradictory, or not yet received — the transaction story is incomplete.
How it is handled: She does not invent a status to close the gap. She compares the stable references, amount, currency, value date, and parties across the two legs, identifies the last reliable event, and decides whether to wait for the customer message, request more information, or escalate to the correspondent — depending on which evidence is absent and who owns it.
STRICTLY SPEAKING
Strictly speaking, an MT202 and an MT202 COV share a message number but are not interchangeable: the COV is used only when the transfer covers an underlying customer payment, and it mandates the extra sequence carrying that customer's details. Using a plain MT202 to cover a customer payment hides exactly the party information downstream banks are required to see.
FOR NOW, REMEMBER
- A payments analyst reads an MT by question, not field by field: reference, amount and value date, parties, routing, and charges.
- References tie the legs together — :20: is a message's own reference, :21: points to the related payment.
- A cover payment (MT202 COV) repeats the underlying customer and beneficiary so every bank in the chain can screen the same parties.
- When a leg's story is incomplete, compare stable references and parties and find the last reliable event — never invent a status.
TRY IT YOURSELF
Maya opens an MT202 COV and the routing fields all look valid, but sequence B (the underlying customer and beneficiary) is blank. Why should she stop and query it rather than release the payment?
You have read the payment messages you meet most. Next, step back to the whole map: how MT numbers sort every message into categories by business area, from customer payments to cash management.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
Payment teams can focus first on categories 1, 2, and 9.
- 02
One payment may involve several related MT messages.
- 03
Business purpose is more useful than code memorization.
Practical use cases / 04
Where you would use this
A training lead builds a payments-focused MT curriculum for operations staff.
A solution analyst maps customer, interbank, and reporting messages across a flow.
An investigator groups related instructions, funding, and statements into one case.
Worked example / 05
Put the idea into a real situation
Illustrative example: a corporate payment begins with a customer-transfer message, is supported by an interbank funding message, and later appears in an account statement. When the beneficiary reports a delay, an investigation message joins the chain. Instead of treating each MT as a separate event, the operations analyst correlates references, amounts, dates, parties, and accounts to build one end-to-end transaction story.
Evidence & review / 07
Evidence & review
SWIFT FIN MT customer and financial-institution payments; serial vs cover method.
What this brief simplifies: Presents a working read-order over a subset of fields; a full message carries more fields and a real desk applies more controls than shown.
Sources for this brief2
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · MT103 / MT202 COV field usage; cover payment party requirements
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.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
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.