Guide · Python · SDK · REST API

SWIFT MT Message Type Validation in Python — Categories & Lookup

Validate any SWIFT MT message type, retrieve its category and description, and list all types by category — using the IsValid API or SDK from Python.

1. What are SWIFT MT messages?

SWIFT (Society for Worldwide Interbank Financial Telecommunication) operates the global messaging network that financial institutions use to send and receive structured instructions about transactions. MT stands for Message Type — the legacy format that has been the backbone of international payments, securities, trade finance, and treasury operations for decades.

Each MT message is identified by a three-digit number (e.g. MT103, MT202, MT940). The first digit indicates the category — the broad functional area the message belongs to — while the remaining digits identify the specific message type within that category.

ℹ️SWIFT is gradually replacing MT messages with MX (ISO 20022) messages, but MT remains dominant in production systems worldwide. Many institutions run both formats in parallel during the migration period, making MT type validation critical for routing and compliance.

2. MT message categories

Every MT message type is assigned to one of ten categories (0–9). The first digit of the three-digit type number determines the category:

CategoryGroupExample
0System MessagesMT096
1Customer Payments & ChequesMT103
2Financial Institution TransfersMT202
3Treasury Markets — Foreign Exchange, Money Markets & DerivativesMT300
4Collection & Cash LettersMT400
5Securities MarketsMT540
6Treasury Markets — Precious Metals & SyndicationsMT600
7Documentary Credits & GuaranteesMT700
8Travellers ChequesMT800
9Cash Management & Customer StatusMT940

The most commonly encountered types in everyday banking are MT103 (single customer credit transfer), MT202 (general financial institution transfer), MT940 (customer statement), MT760 (guarantee / standby letter of credit), and MT700 (issue of a documentary credit).


3. Common MT message types

Below is a detailed look at the most frequently used message types across categories:

TypeCat.DescriptionUse case
MT1011Request for TransferCorporate-initiated multi-bank payment instructions
MT1031Single Customer Credit TransferStandard cross-border wire transfers
MT1991Free Format MessageAd-hoc communication between banks (payments)
MT2022General Financial Institution TransferInterbank transfers, cover payments
MT3003Foreign Exchange ConfirmationFX trade confirmations between counterparties
MT5405Receive FreeSecurities settlement (delivery without payment)
MT7007Issue of a Documentary CreditLetters of credit for international trade
MT7607Guarantee / Standby Letter of CreditBank guarantees and standby LCs
MT9409Customer Statement MessageEnd-of-day account statements, reconciliation
MT9509Statement MessageNostro/vostro account reconciliation

4. Why MT validation matters

Regulatory compliance

Payment and securities regulations often reference specific MT types. Compliance systems must verify that incoming messages match declared types, and that the correct message type is used for each transaction class. A customer payment routed via MT202 instead of MT103 can trigger regulatory flags.

Message routing

Middleware and message brokers use the MT type to route messages to the correct processing pipeline. An unknown or invalid type means the message cannot be dispatched and will end up in an exception queue.

Audit trails

Financial institutions maintain detailed logs of all SWIFT traffic. Valid, categorised message types make it possible to filter, aggregate, and report on traffic by category — a requirement for both internal audit and regulatory reporting.

MT to MX migration planning

As institutions migrate from MT to MX (ISO 20022), they need to map each MT type to its MX equivalent. Validating and categorising MT types is the first step in building a migration inventory — understanding which message types are in active use and what their ISO 20022 counterparts are.


5. The right solution: validate + list

The IsValid SWIFT MT API provides two endpoints: one to validate and look up a specific MT type, and another to list all known types — optionally filtered by category.

GET /v0/swift-mt — Validate a message type

Pass a message type (e.g. MT103, 202, mt940) and get back whether it's valid, along with its category, group name, and description.

GET /v0/swift-mt/list — List all message types

Returns all known MT types. Optionally pass a category parameter (0–9) to filter by category.

200+
Message types
all standard MT types covered
<30ms
Response time
local lookup, no external call
100/day
Free tier
no credit card required

Get your free API key at isvalid.dev — 100 calls per day, no credit card required.

Full parameter reference and response schema: SWIFT MT Validation API docs →


6. Python code examples

Using the isvalid Python SDK or the requests library.

Validate a message type

# swift_mt_validator.py
import os
from isvalid import create_client

iv = create_client(api_key=os.environ["ISVALID_API_KEY"])

# ── Validate a single MT message type ────────────────────────────────────────

result = iv.swift_mt("MT103")

if not result["valid"]:
    print("Unknown MT message type")
else:
    print(f"Type: {result['type']}")            # MT103
    print(f"Category: {result['category']}")     # 1
    print(f"Group: {result['group']}")            # Customer Payments & Cheques
    print(f"Description: {result['description']}")
    # → Single Customer Credit Transfer

List message types by category

# swift_mt_list.py
import os
from isvalid import create_client

iv = create_client(api_key=os.environ["ISVALID_API_KEY"])

# ── List all message types ───────────────────────────────────────────────────

all_types = iv.swift_mt.list()
print(f"Total MT types: {len(all_types)}")

# ── Filter by category ──────────────────────────────────────────────────────

payment_types = iv.swift_mt.list(category=1)

for mt in payment_types:
    print(f"  {mt['type']:<8} {mt['description']}")
# → MT101    Request for Transfer
# → MT103    Single Customer Credit Transfer
# → ...

7. cURL examples

Validate a specific MT message type:

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://api.isvalid.dev/v0/swift-mt?value=MT103"

Validate using just the numeric part (without the MT prefix):

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://api.isvalid.dev/v0/swift-mt?value=202"

List all message types in category 1 (Customer Payments & Cheques):

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://api.isvalid.dev/v0/swift-mt/list?category=1"

List all known MT message types (no filter):

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://api.isvalid.dev/v0/swift-mt/list"

8. Understanding the response

Validate endpoint response

Response for MT103:

{
  "valid": true,
  "type": "MT103",
  "category": 1,
  "group": "Customer Payments & Cheques",
  "description": "Single Customer Credit Transfer"
}

Response for an invalid type:

{
  "valid": false,
  "type": "MT999",
  "category": null,
  "group": null,
  "description": null
}
FieldTypeDescription
validbooleanWhether the MT type is a known, valid SWIFT message type
typestringNormalised MT type with prefix (e.g. MT103)
categorynumber | nullCategory number (0–9), or null if invalid
groupstring | nullCategory group name (e.g. "Customer Payments & Cheques")
descriptionstring | nullHuman-readable description of the message type

List endpoint response

Response for GET /v0/swift-mt/list?category=1 (truncated):

[
  {
    "type": "MT101",
    "category": 1,
    "group": "Customer Payments & Cheques",
    "description": "Request for Transfer"
  },
  {
    "type": "MT103",
    "category": 1,
    "group": "Customer Payments & Cheques",
    "description": "Single Customer Credit Transfer"
  },
  {
    "type": "MT110",
    "category": 1,
    "group": "Customer Payments & Cheques",
    "description": "Advice of Cheque(s)"
  }
]
FieldTypeDescription
typestringMT type identifier (e.g. MT103)
categorynumberCategory number (0–9)
groupstringCategory group name
descriptionstringHuman-readable description of the message type

9. Edge cases to handle

Case insensitivity

The API accepts MT types in any case. mt103, MT103, and Mt103 all resolve to the same type. The response always returns the normalised uppercase form.

# All of these return the same result
iv.swift_mt("MT103")
iv.swift_mt("mt103")
iv.swift_mt("Mt103")
# → {"valid": True, "type": "MT103", ...}

With or without MT prefix

You can pass just the numeric part. The API normalises both forms:

# Both are equivalent
iv.swift_mt("MT202")
iv.swift_mt("202")
# → {"valid": True, "type": "MT202", ...}

Obsolete message types

Some MT types have been retired or replaced over the years. The API may still recognise them as valid historic types but will indicate their status. Always check the response for types that may have been superseded — particularly relevant when processing archived messages or legacy system data.

MT to MX migration mapping

When planning a migration from MT to MX (ISO 20022), use the list endpoint to build an inventory of all MT types in use, then map them to their ISO 20022 equivalents:

# Build a migration inventory from your MT traffic
all_types = iv.swift_mt.list()

# Common MT → MX mappings
mt_to_mx_map = {
    "MT103": "pacs.008",
    "MT202": "pacs.009",
    "MT940": "camt.053",
    "MT101": "pain.001",
    "MT900": "camt.054",
    "MT910": "camt.054",
}

for mt in all_types:
    mx = mt_to_mx_map.get(mt["type"], "no direct mapping")
    print(f"  {mt['type']} → {mx}")

Summary

Use the validate endpoint to check any MT type and get its category and description
Use the list endpoint to enumerate all types or filter by category (0-9)
Input is case-insensitive and works with or without the MT prefix
Cache list results — MT type definitions change infrequently
Use categories to group and route messages in your middleware
Plan MT→MX migration by mapping validated types to ISO 20022 equivalents

See also

Validate SWIFT MT types instantly

Free tier includes 100 API calls per day. No credit card required. Category, group, and description included in every response.