The SWIFT message format is a rigid, block-based structure that lets banks exchange payment instructions in a way automated systems can parse without human intervention. Every FIN message is built from five numbered blocks, data inside the main block sits under two-digit field tags, and each field is restricted to a defined character set and line length. As of November 22, 2025, cross-border payment instructions on the SWIFT network must use the ISO 20022 XML format rather than the legacy MT syntax, so the formatting rules that govern a payment today look different from those that applied a year ago.1Swift. ISO 20022 – Implementation
The Five Blocks of a SWIFT Message
Every SWIFT FIN message is assembled from five blocks, each with a fixed job. Automated systems read them by position, so a missing delimiter or a malformed header stops the whole message from being processed.
- Block 1, the Basic Header, identifies the sending institution by its BIC and includes a logical terminal code, session number, and sequence number. It looks the same regardless of message type.
- Block 2, the Application Header, carries the message type, the recipient’s BIC, and the priority flag (urgent, normal, or system).
- Block 3, the User Header, is optional. It holds extra routing information, authentication codes, or a Message User Reference the sender uses to track the transaction internally.
- Block 4, the Text block, is the body of the message. Amounts, dates, account numbers, beneficiary names, and special instructions all live here, each under a specific field tag.
- Block 5, the Trailer, closes the message with integrity and error-detection codes so the receiver can confirm nothing was altered in transit.
When a message fails validation, the network returns a negative acknowledgement with an error code identifying whether the problem was in a header, in the text block, or in the broader syntax.2SWIFT. FIN Error Codes
Field Tags Inside the Text Block
Inside Block 4, every data element is prefixed by a field tag: a colon, a two-digit number, and sometimes a letter qualifier. The tag tells the receiving system what kind of data follows and how to interpret it. The ones that appear in nearly every payment:
- :20: Transaction reference number, used by both banks to track the payment. Required on every message.
- :32A: Value date, currency, and amount, in that order. The date uses YYMMDD, the currency uses the three-letter ISO 4217 code, and the amount uses a comma as the decimal separator. A payment of fifty thousand US dollars with a value date of March 15, 2026 reads 260315USD50000,00.
- :50K: Ordering customer. The name and address of the party sending the funds.
- :56A: Intermediary institution, identified by BIC. Used only when the payment needs to route through a third bank.
- :59: Beneficiary. The name and account of the party receiving the funds.
Fields are either mandatory or optional. Omitting a mandatory field causes immediate rejection, and omitting an optional field such as :56A: when an intermediary actually is needed can stall the payment or push it onto a slower, more expensive route. Qualifiers inside tags matter too: a date field may distinguish between the value date (when funds become available) and the entry date (when the transaction posts), and the two are not interchangeable for interest or reporting purposes.
Character Sets and Line Rules
Each field in a SWIFT message is bound to one of three defined character sets, and using a character outside the permitted set is one of the most common reasons messages bounce.3SWIFT. Standards MT General Information
- The X set is the standard. It allows A–Z, a–z, 0–9, and a limited punctuation group: slash, hyphen, question mark, colon, parentheses, period, comma, apostrophe, plus sign, space, and the CrLf line break. Fields marked “x” accept only these.
- The Y set (EDIFACT Level A) is used in specialized fields like the MT105. It allows uppercase letters and digits only, no lowercase, but adds punctuation such as exclamation marks, percent signs, ampersands, and angle brackets.
- The Z set is the broadest. It covers everything in the X set and adds symbols like @, #, underscore, and the opening curly bracket.
An emoji, a non-ISO currency symbol, or a closing curly bracket inside a Z-set field will fail validation. Line length is capped at 35 or 65 characters depending on the field, and overrunning the cap produces a text validation error. The Cr and Lf characters cannot appear alone; they must be used together as CrLf.
Common Message Types You’ll See
SWIFT groups messages into numbered categories. For cross-border payments, three categories do most of the work, and although the ISO 20022 transition has replaced the MT formats for payment instructions, bank operations teams still reference the MT numbering internally and the underlying data requirements carry forward.
Category 1: Customer Payments
The MT103 was the standard single customer credit transfer for decades, carrying ordering customer details, beneficiary account, amount, currency, and charges. Its ISO 20022 replacement is the pacs.008, which carries the same core data in a structured XML form.
Category 2: Bank-to-Bank Transfers
The MT202 handled transfers between financial institutions, including FX settlement and interbank lending. The MT202COV variant was created specifically for cover payments that accompany an underlying customer transfer. The COV version includes the originating and destination customer details so intermediary banks can perform sanctions screening on the real parties behind the funds flow. The ISO 20022 equivalent is the pacs.009.
Category 9: Reporting
The MT940 delivers end-of-day account statements and the MT942 provides intraday interim reports. These remain in heavy use for cash management and reconciliation.
What Changed with ISO 20022 in November 2025
The CBPR+ coexistence period, during which banks could send either legacy MT or ISO 20022 messages for cross-border payments, ended on November 22, 2025. Payment instructions including MT103, MT200, and MT202COV have been replaced by their XML equivalents (pacs.008, pacs.009) on SWIFT’s FINplus service.1Swift. ISO 20022 – Implementation
The practical difference is granularity. Where an MT103 packed a beneficiary’s name, street, city, and country into a few 35-character lines under :59:, the ISO 20022 version breaks each of those into its own structured XML element. Less truncation, fewer misrouted payments, and screening systems that can match against discrete name and address fields instead of free-text blobs.4Swift. ISO 20022 – Standards
Two cost and compliance deadlines follow. Since January 1, 2026, SWIFT charges extra fees for contingency processing (converting outbound MT messages to ISO 20022) and for the in-flow translation service that converts incoming ISO 20022 messages back to MT for banks whose systems still can’t read XML natively. These charges are not covered by the standard fixed fee or Essentials packages, and SWIFT has signaled they may rise over time.5Swift. ISO 20022 – Translation Services Then in November 2026, unstructured postal addresses will be forbidden across CBPR+ messages: all agent and party addresses must use structured or hybrid formats, with separate fields for street name, building number, postal code, city, and country. Messages still carrying a free-text address line after that date will be rejected outright.6Swift. ISO 20022 for Financial Institutions
Why Formatting Errors Trigger Compliance Problems
Formatting isn’t only a technical concern. The data in each message feeds directly into the compliance systems banks are legally required to run. Names in :50K: and :59: are screened against the Office of Foreign Assets Control sanctions lists before a payment is executed, and incomplete or garbled name data undermines that screening.7Federal Financial Institutions Examination Council. BSA/AML Manual – Office of Foreign Assets Control
Separately, under the Bank Secrecy Act, payment orders of $3,000 or more require banks to obtain and retain specific originator and beneficiary information, including names, addresses, and account numbers.8Federal Financial Institutions Examination Council. BSA/AML Manual – Funds Transfers Recordkeeping A message with a truncated beneficiary name or a mangled address doesn’t just fail a syntax check; it leaves a gap in the recordkeeping the bank is required to maintain. The MT202COV format exists for exactly this reason: the original MT202 didn’t carry enough customer data for intermediary banks to screen the underlying transaction.
Canceling a Wire You Sent
If you’re a consumer who sent an international wire rather than a bank formatting one, federal law gives you a short cancellation window. Under Regulation E, you can cancel a remittance transfer within 30 minutes of authorizing the payment, as long as the recipient hasn’t already received the funds. The request can be oral or in writing, and the provider must refund the full amount, including fees and taxes, within three business days.9Consumer Financial Protection Bureau. 12 CFR 1005.34 – Procedures for Cancellation and Refund of Remittance Transfers The clock starts when you authorize, not when the bank processes, so act quickly if you spot an error. After the 30 minutes expire or the funds are picked up, your options depend on the provider’s own policies.