SWIFT message types (MT) and ISO 20022 MX for developers

The Society for Worldwide Interbank Financial Telecommunication (SWIFT) network facilitates the sending and receiving of messages between financial institutions. SWIFT messages contain payment instructions and financial data, while the actual movement of funds happens elsewhere.

Until recently, the legacy SWIFT MT format defined the structure and content of these messages. Today, the more robust SWIFT MX message format, which follows the ISO 20022 international standard, has replaced MT for CBPR+ cross-border interbank payment instructions.

MT messages remain supported in other workflows, including corporate-to-bank and reporting. This guide covers the structure, mappings, and integration requirements of both SWIFT message types and the SWIFT MX format to help payment integration developers understand how to work with them. By grasping the core differences, developers can avoid the manual investigation work and downstream reconciliation issues that often come with using the wrong standard or formatting.

What is the SWIFT MT (message type) format?

Message types in SWIFT are the legacy standardized format for SWIFT messages. These were the default until the migration to the MX standard started in March 2023.

Like MX messages, message types carry payment instructions and financial data between financial institutions. In other words, SWIFT is the instruction layer, not the settlement layer.

Reading a SWIFT message code

Each SWIFT MT message comes with a label to identify its purpose. These labels contain a three-digit string. The first digit identifies the category, the second the group, and the third the specific function.

The categories each initial digit maps to are:

• 1xx: Customer Payments and Cheques

• 2xx: Financial Institution Transfers

• 3xx: Treasury Markets — FX, Money Markets, and Derivatives

• 4xx: Collections and Cash Letters

• 5xx: Securities Markets

• 6xx: Treasury Markets — Commodities — Reference Data

• 7xx: Documentary Credits and Guarantees/Standby Letters of Credit

• 8xx: Travellers Cheques

• 9xx: Cash Management and Customer Status

• nxx: Common Group Messages

The five-block structure

SWIFT message types are organized into five blocks:

• Block 1 (basic header) contains information about the financial institution’s identity and session control.

• Block 2 (application header) contains information about the message type, direction, and counterparty address.

• Block 3 (user header) contains metadata like tracking identifiers.

• Block 4 (text/body) contains the actual payment instructions or business data.

• Block 5 (trailer) contains information needed for integrity checks.

Field tags structure MT messages by labeling each piece of data. For instance, :32A: marks the field containing the transaction’s value date, currency, and amount.

MT messages also have to follow validation rules. For example, fields must appear in the correct sequence, use the correct character set and content type, and adhere to length restrictions.

To illustrate, take Field 70 (Remittance Information), which allows up to 4 lines of 35 characters each from the SWIFT X character set. In the following example, the first line hits the character limit, so the text wraps to the next line:

:70:/INV/abc/SDF-96//1234-234///ROC/98I
U87

In ISO 20022 MX messages for cross-border payments, structured remittance details in the corresponding RmtInf element have a limit of 9,000 characters of business information under CBPR+ usage guidelines, excluding XML tags.

While these validation rules are enforced by the SWIFT network, there may be other usage requirements depending on the services, market practices, or counterparties involved in a transaction.

What is the SWIFT MX (message XML) format? SWIFT MT vs. MX

SWIFT introduced the MX standard to let financial institutions send messages with more detailed and structured data. The critical distinction between these two SWIFT message formats is how they organize this data.

MT messages are plain text containing tagged fields with fixed formats and tight length limitations. MX messages follow the ISO 20022 standard and are written in XML. This keeps data organized as nested, labeled elements with meanings defined by the ISO 20022 central data dictionary.

Because MX messages allow for many more labeled, dedicated elements, they support more granular payment, remittance, and party data. This also facilitates downstream reconciliation in ERP and treasury systems.

It’s possible to convert an MX message to an MT message if necessary, but doing so can result in data truncation and loss of structured detail. This may drop information other parties need to process and reconcile payments.

Common SWIFT message types in payment integrations

Even after the end of CBPR+ coexistence in November 2025, developers may still come across SWIFT MT messages in specific areas like corporate-to-bank and reporting workflows. Here’s how some of the most common SWIFT MT messages map to their SWIFT MX equivalents and what each message means.

The migration plans below apply to FI-to-FI traffic within CBPR+. Corporate SCORE traffic follows separate requirements.

SWIFT MT message	ISO 20022 MX equivalent	Purpose	Typical payment workflow	Current status
MT103	pacs.008	Single Customer Credit Transfer	Customer payment sent from the customer’s bank to the recipient’s bank	Replaced by pacs.008 for cross-border interbank payments
MT202 MT202 COV	pacs.009 pacs.009 COV	General Financial Institution Transfer	Bank-to-bank transfers and settlement	Replaced by pacs.009 for cross-border interbank payments
MT101	pain.001	Request for Transfer	Requests relayed between banks	Still supported Single: Contingency conversion to pain.001 planned for SR 2026; timetable under review Multiple: Removal planned for SR 2026; timetable under review
MT900 MT910	camt.054	Confirmation of Debit/Credit	Notifying an account owner about a new debit or credit	Still supported Phase-out planned for SR 2028; timetable under review
MT940	camt.053	Customer Statement Message	Daily account reporting and reconciliation	Still supported Phase-out planned for SR 2028; timetable under review

Keep in mind that these aren’t always perfect one-to-one mappings. ISO 20022 MX messages can carry far richer and more structured data, which means some of that data may get lost in translation.

How developers format and validate MT and MX messages

The SWIFT guidelines for formatting MT messages require tagged text fields validated against SWIFT’s character limits, sequencing, and network rules, as outlined above.

MX messages are formatted as nested XML and validated against XML schemas from the ISO 20022 website. For cross-border payments and reporting, they’re also validated against the stricter rules of CBPR+, which are SWIFT’s own usage guidelines. Finally, messages must adhere to any service- or counterparty-specific requirements.

Why developers may still need to support both MT and MX

Developers can still run into MT messages in legacy corporate, tracking, or contingency workflows. Since converting richer MX messages to more rigid and limited MT messages risks losing information, this presents a challenge for integration teams.

Instead of trying to support every possible type of message, developers should design for the specific messages and counterparties they actually interact with. Note which MT messages the institution still sends and receives to understand which workflows and counterparties still rely on the legacy format, and build around those. If a counterparty is in the process of switching standards, supporting both in parallel helps verify the data’s accuracy and consistency.

The principle of keeping what works and only changing what doesn’t applies beyond messaging standards. Coastal is working with Tempo to build a cross-border payment corridor that leaves its proven compliance and messaging infrastructure intact while swapping out the settlement layer for stablecoin rails.

Pair SWIFT with stablecoin payment flows on Tempo

A blockchain built for stablecoin payments, Tempo is interoperable infrastructure that teams can connect with ACH, wires, SWIFT, and ISO 20022 workflows through payment providers and integrations. It doesn’t replace the existing infra you’re accustomed to. It makes it better. Here’s how:

• TIP-20 transfer memos carry reconciliation references instead of full ISO 20022 payloads to simplify downstream reconciliation.

• Tempo offers 24/7, near-instant onchain settlement and no re-orgs. Fintechs are no longer chained to banking windows but stay subject to issuer, custody, ramp, and jurisdiction constraints.

• Teams working with high-volume payout or treasury workflows can process them efficiently using batch and concurrent transactions, with fewer individually submitted transactions.

• Transaction fees can be covered using supported stablecoins, which cuts down on unnecessary gas-token steps for developers.

• Tokenized deposits truly blend traditional bank infrastructure and onchain settlement.

Try Tempo today to add stablecoins to your payment stack without rebuilding the rest of it.

FAQ

What is used for an intraday transaction report?

In the legacy SWIFT MT format, intraday reporting is covered by MT942 (Interim Transaction Report). The equivalent SWIFT MX ISO 20022 message is camt.052 (Bank To Customer Account Report).

Can one payment workflow use multiple SWIFT message types?

Yes, a single payment workflow often involves multiple messages to cover each stage, such as payment and funding instructions, confirmations, and statements.

Is MT103 only used for international payments?

No. MT103 (Single Customer Credit Transfer), replaced by pacs.008 in SWIFT MX ISO 20022 for cross-border payments between banks, is primarily associated with cross-border payments. Actual usage depends on the payment setup and counterparties.