SWIFT MTs / Learning brief
SWIFT message validation: mandatory and optional fields
Your notes
In simple terms / 01
What this means in plain language
How a SWIFT MT message is checked before and during sending: mandatory versus optional fields, tags and formats, the network's own cross-field rules, and what a rejection means.
A SWIFT (Society for Worldwide Interbank Financial Telecommunication) MT (Message Type) message is a structured form. Each piece of information sits in a numbered field marked by a tag, such as :20: for a reference or :32A: for a value date, currency, and amount. Some fields are mandatory and must always be present; others are optional and appear only when needed. Every field also has a defined format that limits its length and character set. Before sending, the originating bank checks its own message against these rules. When the message enters the network, SWIFT applies a second layer of network-validated rules, including cross-field checks that compare one field against another. A message that passes both is accepted; one that fails is returned to the sender.
Complete lesson / 02
Understand the full idea, step by step
A paper form has boxes marked required, boxes you fill only if they apply, and a clerk who hands it back the moment something is wrong — before it ever reaches the office that acts on it. A SWIFT MT message is checked the same way: some fields must be present, some are optional, some become required only under certain conditions, and a gatekeeper stops a malformed message at the door.
Mandatory, optional, and conditional fields
Every field in an MT type is marked. A mandatory field (M) must appear in every message of that type. An optional field (O) appears only when the payment needs it. A conditional field is required only when a stated condition is met — for example, a field that becomes mandatory if another field is present, or is forbidden if it is absent. Reading a message means checking, for each field: is it allowed here, and is it present when it must be?
| Internal (network-validated) | External (business) | |
|---|---|---|
| What it checks | Format of each field, mandatory fields present, and cross-field rules defined in the message standard | Whether the instruction makes business sense: real account, enough funds, sanctions, duplicate |
| Who enforces it | The message standard itself — checked by the sender's software and by the SWIFT network | The banks — sending, receiving, and any correspondent in between |
| When it fails | The message is refused up front and never delivered | The message may be delivered but then held, returned, or investigated |
| The signal | A negative acknowledgement (NAK) with a rule-specific error code | A return, a query, an exception in an operations queue |
Why the network can only check so much
The network's checks are powerful but narrow. A network-validated rule can confirm that :32A: holds a valid date-currency-amount, that a mandatory field is present, and that cross-field conditions hold — say, if one optional field appears, a related field must appear too. What the network cannot know is whether the beneficiary account in :59: really exists, whether Asha Traders has the funds, or whether a party is on a sanctions list. Those are business questions, answered by banks, not by the message format. A message can be structurally perfect and still be the wrong payment.
If Bank Alfa's own software already checked the message, why did the network still reject it?
Because the sender only ever sees its own copy passing its own checks. The bank's software confirms its house rules and the fields it knows to look at; the SWIFT network then applies the standard's network-validated rules centrally, so every institution is held to the identical bar. A rule your software did not implement — or implemented loosely — is still enforced at the network. That is the point of central validation: the same message is judged the same way no matter who sends it.
WHAT IF — The network's validation fails a submitted message
What happens: The message is not delivered. The sender receives a negative acknowledgement — a NAK — carrying an error code that names the broken rule (a missing mandatory field, a value outside its format, or a failed cross-field check). No message reaches the receiver, so no funds move and no duplicate is created.
How it is handled: Maya treats the NAK as a diagnostic: read the code, locate the field, correct the content, resubmit. Because the original was refused outright rather than half-processed, the corrected resend is one clean instruction with no risk of paying twice. A positive acknowledgement — an ACK — is the opposite signal: the network accepted the message for delivery.
COMMON CONFUSION
“An ACK means the payment succeeded and the beneficiary has been paid.”
An ACK means only that the network accepted the message for delivery — internal validation passed. The business questions come after: the receiving bank still has to accept the payment, credit the account, and clear its own controls. ACK is "the message is well-formed and on its way", not "the money has arrived".
STRICTLY SPEAKING
Strictly speaking, the full set of network-validated rules and error codes is extensive and differs by message type; a specific code maps to a specific rule in that type's specification. This lesson teaches the shape of validation, not a code list — for the actual rules and codes a bank consults SWIFT's message standards for that MT.
FOR NOW, REMEMBER
- Fields are marked mandatory (always), optional (when needed), or conditional (required only when a stated condition holds).
- Internal, network-validated checks cover format, presence of mandatory fields, and cross-field rules — and produce an ACK or a NAK.
- External, business validation — real account, funds, sanctions — is done by banks, not by the message format.
- A NAK stops a malformed message at the edge of the network: nothing is delivered, so no money moves and no duplicate is made.
TRY IT YOURSELF
An MT type says: if field :56A: (an intermediary institution) is present, then field :57A: (the account-with institution) must also be present. Bank Alfa sends a message with :56A: but no :57A:, and it is refused before delivery. What happened?
You know how a message is checked. Next, sit at Maya's desk and read an MT the way an operations person actually does — which fields matter for routing, amount, parties, charges, and references.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
Each MT field has a tag, a mandatory or optional status, and a fixed format.
- 02
The sender validates first, then the SWIFT network applies its own cross-field rules.
- 03
A rejected message is not delivered and must be corrected and resent.
Practical use cases / 04
Where you would use this
A payments operations analyst reads a rejection to find which field broke a rule.
A message-standards specialist maps required fields when building a new template.
A testing team crafts sample messages to confirm validation behaves as expected.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional bank, Meridian Trust, prepares an MT103 with field :32A: reading 260713EUR12500,00, meaning value date 13 July 2026, currency EUR, amount 12,500.00. Its internal check confirms the mandatory :20:, :23B:, :32A:, :50a:, and :59a: fields are present and formatted correctly. On sending, the network compares the EUR currency code in :32A: against the amount's decimal comma placement and accepts the message within 5 seconds.
Evidence & review / 07
Evidence & review
SWIFT FIN MT validation (network-validated rules and business validation).
What this brief simplifies: Describes the two validation layers and field status without listing specific error codes or per-type rules, which vary and live in the message standards.
Sources for this brief2
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · Network Validated Rules; field status M/O/C
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.