Professionals in banking or financial operations have likely heard of Swift messages. But some may still have questions about how they work, what they look like, how you’re supposed to read one, and why do they matter.

In this article, we’ll walk through the essentials that will give you a better understanding of Swift messages.

 

What Is a Swift Message

A Swift message is a secure, standardized way for banks and non-bank financial institutions (NBFI) to communicate about transactions. You use it to send payment instructions, confirmations, and account statements across borders or domestically.

But here’s the key: Just like any other financial message, Swift messages don’t move money. They carry the instructions that tell banks what to do with the transaction. The actual funds move through correspondent accounts or clearing systems.

 

Swift Message Categories: Legacy MT vs ISO 20022

Swift messages are categorized by their purpose. Historically, these were labeled as MT (Message Type) formats, but with the introduction and required transition to ISO 20022 XML-based formats (the new global messaging standard for financial transactions), they are being replaced. The chart below highlights key message categories in both legacy MT format and their ISO 20022 replacements.

Legacy MT Format	ISO 20022 Equivalent	Purpose
MT103	PACS.008	Customer Credit Transfer
MT202	PACS.009	Financial Institution Transfer
MT940/MT950	CAMT.053/CAMT.052	Account Statements
MT900/MT910	CAMT.054	Debit/Credit Advice

MT formats may still appear during the transition, especially in domestic or legacy systems. However, ISO 20022 is the future—bringing richer data and improved automation. Each message type has a defined structure and purpose, which we’ll explore through examples in the next section.

What Does a Swift Message Look Like?

We’ll start with a legacy MT103 — the format for customer credit transfers — to establish a baseline. Then, we’ll look at its ISO 20022 counterpart, the pacs.008 message, to show how richer, structured data enhances processing and compliance.

  {1:F01BANKBEBBAXXX0000000000}{2:I103BANKDEFFXXXXN}{4:
:20:REFERENCE12345
:32A:250903USD100000,
:50K:/123456789
JOHN DOE
1 MAIN STREET
NEW YORK, NY
:59:/987654321
ACME CORP
BERLIN
:71A:SHA
-}

Now, here’s how the same transaction might look in ISO 20022 format, using a PACS.008 message. This format is XML-based and far more structured:

< Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08" >
  < FIToFICstmrCdtTrf >
    < GrpHdr >
      < MsgId >REFERENCE12345< /MsgId >
      < CreDtTm >2025-09-03T10:00:00< /CreDtTm >
    < /GrpHdr >
    < CdtTrfTxInf >
      < PmtId >
        < EndToEndId >REFERENCE12345< /EndToEndId >
      < /PmtId >
      < Amt >
        < InstdAmt Ccy="USD" >100000.00< /InstdAmt >
      < /Amt >
      < Dbtr >
        < Nm >JOHN DOE< /Nm >
        < PstlAdr >
          < StrtNm >1 MAIN STREET< /StrtNm >
          < Ctry >US< /Ctry >
        < /PstlAdr >
      < /Dbtr >
      < Cdtr >
        < Nm >ACME CORP< /Nm >
        < PstlAdr >
          < Ctry >DE< /Ctry >
        < /PstlAdr >
      < /Cdtr >
    < /CdtTrfTxInf >
  < /FIToFICstmrCdtTrf >
< /Document >

Tip: If you’re used to MT103, PACS.008 might look overwhelming at first—but it’s designed to be machine-readable and easier to automate. We’ll help decode the message in a section further down in the article.

 

Anatomy of a ISO 20022 Swift Message: Field-by-Field Breakdown

ISO 20022 messages are built like structured code — similar to how a webpage or email is formatted. Each XML tag wraps a specific piece of data, clearly labeled and nested for easy parsing.

Group Header (GrpHdr) – Identifies the message and its origin

• MsgId: Transaction reference
• CreDtTm: Creation date and time
• InstgAgt: Initiating bank

Credit Transfer Transaction Info (CdtTrfTxInf) – Contains the actual payment details

• PmtId/EndToEndId: Unique transaction reference
• Amt/InstdAmt: Amount and currency
• Dbtr: Ordering customer
• DbtrAcct: Ordering customer’s account
• Cdtr: Beneficiary
• CdtrAcct: Beneficiary’s account
• ChrgBr: Charge bearer (e.g., SHA, DEBT, CRED)

Supplementary Data (optional) – Additional compliance or processing info

 

How to Read and Decode a Swift Format

To start, identify the message type—whether it’s a legacy MT format like MT103 or a modern format like PACS.008.

Here’s how to decode a PACS.008 message:

1. Identify the message type: Look for the root tag or schema reference indicating PACS.008.
2. Break down each XML element: Tags like , , and  carry key information.
3. Interpret the values: These include currency, amount, sender/receiver details, and transaction dates.

Let’s look at a sample field:

< InstdAmt Ccy="USD" >100000.00< /InstdAmt >

This tells you:

• Currency: USD
• Amount: $100,000

Other common fields include:

• < Dbtr > → Who’s sending the money
• < Cdtr > → Who’s receiving it
• < ReqdExctnDt > → Requested execution date
• < EndToEndId > → Unique transaction reference

Note: PACS.008 replaces MT103 under ISO 20022, but many of the same data elements still apply—just with more clarity and structure.

 

How You Send Swift Messages

Swift messages are more complicated than sending an email, for example. You don’t just type it out and hit send. Here’s how it works:

1. Your banking or payment system generates a message based on transaction data.
2. It validates the format against Swift standards to ensure accuracy.
3. It sends the message securely either through your direct SwiftNet connection or via a Swift service bureau or third-party platform.

You’ll use BICs (Bank Identifier Codes) to route the message to the correct recipient. If you’re working with a third-party provider, they handle the transmission and compliance checks on your behalf.

Whether you’re a bank or NBFI, you don’t need a direct Swift connection to send Swift messages. Many of your peers rely on trusted intermediaries to manage access and infrastructure.

​​​​​​

Myths vs Facts About Financial Messages

If you’ve worked with financial messages including Swift messages—or even just heard about them—you’ve probably come across some confusing or outdated assumptions.

Below are some of the most common myths we hear, along with the facts that set the record straight. Understanding these will help you avoid miscommunication and improve compliance. Let’s take a look.

Myth	Fact
Swift messages move money.	Swift messages don’t transfer funds. Rather, they carry instructions between institutions. The actual money moves through correspondent accounts or clearing systems.
MT103 is a receipt.	MT103 is a payment instruction. It shows what was requested, not what was completed. You’ll need settlement confirmation to verify completion.
All Swift messages are the same.	Each message type (MT101, MT103, MT202, etc.) serves a specific purpose and follows a unique format.
Only large banks use Swift.	Thousands of mid-sized banks and non-banking financial institutions (NBFIs) use Swift—often through third-party providers or service bureaus.
Swift is only used in Europe.	Swift is a global network used in over 200 countries, including the U.S., Canada, India, and across Asia and Africa.
Swift and ISO 20022 are the same.	Swift is the messaging network. ISO 20022 is a newer, richer data standard that Swift is adopting to replace older MT formats.

Download the Myth Vs Facts: Financial Messaging infographic to dispel even more common misconceptions.

Tip: If you’re ever unsure whether a Swift message confirms payment, check whether it’s an instruction (like PACS.008) or a confirmation (like MT910 or CAMT.054 under ISO 20022).

 

ISO 20022 and the Future of Financial Messaging

You’ve seen ISO 20022 mentioned throughout this article—and for good reason. It’s at the heart of a major shift in how banks and NBFIs communicate. Let’s take a moment to unpack what it means and why it matters.

Starting November 2025, banks and NBFIs must use ISO 20022 formats for cross-border payment instructions. This means legacy Swift messages like MT103 and MT202 will be replaced by their ISO equivalents:

• MT103 → PACS.008 (Customer Credit Transfer)
• MT202 → PACS.009 (FI to FI Transfer)
• MT900/910 → CAMT.054 (Debit/Credit Advice)

So why does this matter to you?

• You’ll work with richer, more structured data that improves automation and reconciliation.
• You’ll see new field names like “Debtor” and “Creditor” instead of “Originator” and “Beneficiary.”
• You’ll need to include structured addresses for all parties involved.
• You’ll benefit from better compliance screening and fewer manual interventions.

Even if your bank uses a third-party provider or in-flow translation, understanding the structure of MT messages like MT103 helps you interpret PACS.008 and troubleshoot issues during the transition.

Tip: Think of MT103 as the foundation. PACS.008 builds on it—with more data, more structure, and more clarity.

With a better understanding of the ISO 20022 impacts, you’re better equipped to navigate the changes. Let’s recap what you’ve learned.

 

Final Takeaway: What You Now Know About Swift Messages

You’ve just unpacked the essentials of Swift messaging—from understanding message types and decoding fields to navigating third-party connections and understanding the impacts of ISO 20022.

Here’s what you’re walking away with:

• A clear view of how Swift messages work and what they look like
• The ability to read and interpret key fields like those in MT103 and PACS.008
• Awareness of common myths—and the facts that replace them
• Insight into how financial messaging is evolving with ISO 20022

Whether you’re working directly with Swift or through a service provider, this knowledge helps you communicate more clearly, operate more efficiently, and stay ahead of industry changes.