Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to SWIFT message types.
Nothing was collected or created yet.
SWIFT message types
View on Wikipediafrom Wikipedia
SWIFT message types are the format or schema used to send messages to financial institutions on the SWIFT network. The original message types were developed by SWIFT and a subset was retrospectively made into an ISO standard, ISO 15022. In many instances, SWIFT message types between custodians follow the ISO standard.[1] This was later supplemented by a XML based version under ISO 20022.
Composition of MT number
[edit]SWIFT messages consist of five blocks of data including three headers, message content, and a trailer. Message types are crucial to identifying content.
All SWIFT messages include the literal "MT" (message type/text).[2] This is followed by a three-digit number that denotes the message category, group and type. Consider the following two examples.
Example 1
MT304
- The first digit (3) represents the category. A category denotes messages that relate to particular financial instruments or services such as precious metals (6), treasury (3), or traveller's cheques (8). The category denoted by 3 is treasury markets
- The second digit (0) represents a group of related parts in a transaction life cycle. The group indicated by 0 is a financial institution transfer.
- The third digit (4) is the type that denotes the specific message. There are several hundred message types across the categories. The type represented by 4 is a notification.
A MT304 message is considered an "Advice/Instruction of a Third Party Deal" and it used to advise of or instruct the settlement of a third party foreign exchange deal.[3] For example, an asset manager who executed a FX transaction with a broker would send a MT304 instruction to the custodian bank of the client.
Example 2
- The first digit (1) represents the category. The category denoted by 1 is customer payments and cheques.
- The second digit (0) represents a group of related parts in a transaction life cycle. The group indicated by 0 is a financial institution transfer.
- The third digit (3) is the type that denotes the specific message. There are several hundred message types across the categories. The type represented by 3 is a notification.
A MT103 message is considered a "Single Customer Credit Transfer" and is used to instruct a funds transfer.[3]
Overview of SWIFT MT categories
[edit]The table below shows the different categories and the message type descriptions.
| Category | Message type | Description | Number of message types |
|---|---|---|---|
| 0 | MT0.. | System messages | - |
| 1 | MT1.. | Customer payments and cheques | 19 |
| 2 | MT2.. | Financial institution transfers | 18 |
| 3 | MT3.. | Treasury markets | 27 |
| 4 | MT4.. | Collection and cash letters | 17 |
| 5 | MT5.. | Securities Markets | 60 |
| 6 | MT6.. | Treasury markets – metals and syndications | 22 |
| 7 | MT7.. | Documentary credits and guarantees | 29 |
| 8 | MT8.. | Traveller's cheques | 11 |
| 9 | MT9.. | Cash management and customer status | 21 |
ISO 15022 MT
[edit]Although ISO 15022 message types are different in their structure from the SWIFT MT, the naming convention remains the same.
Legal status
[edit]The Courts in England and Wales have held that the header of a SWIFT message amounts to a valid form of electronic signature.[4]
See also
[edit]- Delivery versus payment
- ISO 9362 (standard format for SWIFT IDs)
- MT202 COV
- MT940
External links
[edit]- Message standards supported by the SWIFT network: "Standards MT & MX Equivalence Table" (PDF). SWIFT. 28 July 2017.
- Message types defined in ISO15022 "ISO15022 Data Field Dictionary - Index of Messages". ISO.
References
[edit]- ^ McGill, R.; Patel, N. (2008). Global Custody and Clearing Services. Basingstoke, Hampshire: Springer. p. 27. ISBN 9781349282883.
- ^ swift.com [full citation needed]
- ^ a b "List of all SWIFT Messages Types". Paiementor. Retrieved 2020-01-07.
- ^ Gill, C., Law Commission report on electronic signatures, Walker Morris, published on 26 September 2019, accessed on 18 June 2025
SWIFT message types
View on Grokipediafrom Grokipedia
SWIFT message types, formally known as Standards MT, are a collection of standardized message formats established by the Society for Worldwide Interbank Financial Telecommunication (SWIFT) to enable the secure, structured, and automated transmission of financial instructions and information across its global network of over 11,500 financial institutions in more than 220 countries and territories.[1] These formats, identified by a three-digit code (e.g., MT 103 for a single customer credit transfer), ensure interoperability, reduce processing errors, and support straight-through processing in international finance.[2] Developed since SWIFT's founding in 1973, the MT standards have evolved through annual community-driven releases to address market needs, with the November 2025 version (effective 22 November 2025) incorporating updates for enhanced validation and compliance.[3]
The message types are organized into ten categories, each addressing specific financial domains: Category 1 covers customer payments and cheques, such as payment instructions (e.g., MT 103); Category 2 handles financial institution transfers (e.g., MT 202 for general financial institution transfers); Category 3 addresses foreign exchange, money markets, and derivatives (e.g., MT 300 for foreign exchange confirmation); Category 4 deals with collections and cash letters (e.g., MT 400 for advice of payment); Category 5 focuses on securities markets, including trade confirmations (e.g., MT 513 for client purchase and sale); Category 6 pertains to commodities and syndicates (e.g., MT 600 for precious metal trade confirmation); Category 7 manages documentary credits and guarantees (e.g., MT 700 for issue of a documentary credit); Category 8 handles travellers' cheques (e.g., MT 800 for travellers' cheque issue); Category 9 provides cash management and customer status updates (e.g., MT 900 for confirmation of debit); and Category n encompasses common group messages usable across categories.[2] Additionally, Category 0 includes system messages for network operations and acknowledgements.[4]
Structurally, each MT message consists of a basic header block (identifying priority and delivery monitoring), an application header block (specifying input/output and message type), an optional user header block, a text block with tagged fields (e.g., :20: for transaction reference number, using formats like 4!n for four numeric digits), and a trailer block for checksums and validation.[2] Fields adhere to strict rules, including character sets (X for letters/numbers, Y for letters only, Z for special characters), length limits (up to 10,000 characters), and mandatory elements like sender/receiver Business Identifier Codes (BICs) based on ISO 9362.[2][5] This rigid format promotes efficiency in high-volume transactions, such as the trillions of dollars processed daily via SWIFT, while the ongoing migration to ISO 20022-based MX messages, with the coexistence period ending on 22 November 2025, aims to enhance data richness and flexibility.[6]
This example demonstrates the block organization and tag-value pairs for a basic single customer credit transfer.[2]
Within Category 7, the MT799 free format message is commonly used for pre-advice in standby letters of credit (SBLC), serving as a non-binding notification from the issuing bank to the advising bank or beneficiary of its intention to issue an SBLC via a subsequent MT760 message. Field 79 of the MT799 contains the core narrative, detailing elements such as confirmation of fund availability, beneficiary information, currency and amount, and additional instructions. Although transmitted via the secure SWIFT network, MT799 messages require additional verification processes beyond the network's authentication to confirm their authenticity, as they do not constitute formal undertakings. Templates for MT799 vary by issuing bank but typically include statements affirming full bank responsibility for the intended issuance, references to International Chamber of Commerce (ICC) Uniform Customs and Practice for Documentary Credits (UCP 600) and International Standby Practices (ISP98), and explicit indications of no pre-payment requirements at the pre-advice stage. These messages are generally operative for a specified number of banking days, often 2 to 7, to allow for coordination before formal issuance. For actual transactions, it is recommended to accompany the MT799 with formal bank drafts incorporating specific contract references to ensure enforceability and compliance.[21]
Prior to the broader adoption of ISO 20022, these MT categories formed the backbone of SWIFT traffic, with Categories 1, 2, and 3 accounting for the majority of daily messages in payments and treasury operations in legacy systems as of 2023. Deprecations began in the early 2020s for low-volume or overlapping types, particularly in Categories 6 and 8, to streamline standards ahead of migration, though all remained supported under ISO 15022 until at least November 2025 for coexistence purposes.[22]
element for debtor information that includes sub-elements for name, address, and identifiers, whereas MT messages often use unstructured free-text fields like field 72 for additional instructions, leading to inconsistent and less machine-readable data.[26][27] This structured approach in MX supports greater granularity and standardization, reducing ambiguity in fields that MT handles narratively.[28]
MX messages accommodate significantly larger payloads, supporting up to 100,000 characters, while MT messages are constrained to a maximum of approximately 10,000 characters.[29][2] This limitation in MT often necessitates truncation or multiple messages for detailed instructions, whereas MX's flexibility enhances handling of intricate financial data without fragmentation.[26]
For error handling and validation, MT messages depend on basic syntax rules and category-specific checks enforced by SWIFT's network, which primarily verify format compliance but lack semantic depth.[30] In contrast, MX leverages XSD schemas for syntactic validation and the ISO 20022 repository for semantic rules, including business constraints like data integrity and interoperability guidelines, resulting in more robust error detection and higher straight-through processing (STP) rates.[31][26]
Specific MT messages have direct MX equivalents that preserve core functionality while enhancing data capabilities, such as MT103 mapping to pacs.008 for customer credit transfers and MT202 to pacs.009 for general financial institution transfers, enabling improved STP through richer remittance and party information.[32][33] However, backward compatibility during the transition poses challenges, as automated translations from MT to MX can result in data truncation or loss, particularly for unstructured elements, requiring careful mapping and testing to maintain interoperability.[34][35]
Introduction to SWIFT Messaging
History and Development
The Society for Worldwide Interbank Financial Telecommunication (SWIFT) was founded on May 3, 1973, as a cooperative society by 239 banks from 15 countries, primarily in Europe and North America, with the goal of standardizing and automating international telegraphic communications to replace the inefficient telex system used for cross-border payments.[7][8] This initiative addressed the growing volume of global financial transactions, which relied on error-prone manual telex messages that often required multiple transmissions and lacked standardization.[8] Early development focused on creating a secure, computerized network to facilitate reliable messaging, drawing on input from banking committees to define initial message formats known as Machine Readable Telegraphic (MT) standards.[9] The SWIFT network launched on January 10, 1977, connecting 518 institutions across 22 countries and enabling the transmission of the first electronic messages using the newly developed MT formats, which organized data into structured fields for automated processing.[7][9] These MT messages, conceived in the mid-1970s, were designed for brevity and compatibility with existing telex practices while supporting emerging computer systems, with initial categories defined for key operations like customer transfers (e.g., MT100).[8] By 1979, daily message volumes surpassed 120,000, demonstrating rapid adoption, though the network achieved financial break-even only in 1982 after repaying development costs.[8] Throughout the 1980s, SWIFT refined its MT standards amid challenges from varying national banking practices and proprietary systems, such as U.S. domestic networks like FEDWIRE, which initially resisted full integration.[8] Standardization efforts involved reconciling differences in message handling across countries, leading to the adoption of ISO 9362 in 1987 for Bank Identifier Codes (BICs), which provided a universal addressing system to enhance message routing accuracy.[10] That same year, SWIFT introduced its FIN messaging service and expanded into securities, while late-1980s category definitions further solidified MT usage, with annual messages reaching nearly 300 million by decade's end.[7][8] These developments, later formalized under ISO 15022 in 1999, marked the maturation of SWIFT's messaging framework despite ongoing efforts to balance global consensus with regional variations.[11]Role in Global Financial Transactions
SWIFT operates as a cooperative messaging network that connects more than 11,500 financial institutions across over 200 countries and territories, enabling the secure and standardized exchange of instructions that facilitate trillions of euros in global financial transactions each day.[12] The network's average daily value of payment messages exceeds €5 trillion (as of 2024).[1] These messages serve as precise directives for key operations, including cross-border payments, securities settlements, and treasury management, allowing institutions to coordinate actions efficiently across borders and currencies. By replacing error-prone manual processes like telex communications with automated, standardized formats, SWIFT has substantially lowered operational costs and reduced the incidence of processing errors, contributing to higher straight-through processing rates.[13] As of 2024, the network processed an average of over 53 million FIN messages daily, up from over 40 million in earlier years, with volumes continuing to grow in 2025.[14] SWIFT integrates with critical settlement infrastructures, such as the European Central Bank's TARGET2 for euro-denominated payments and The Clearing House's CHIPS for U.S. dollar clearings, while supporting correspondent banking relationships that bridge domestic and international flows.[15][16] To safeguard these exchanges, SWIFT has evolved its security protocols over time, incorporating end-to-end encryption using industry-standard algorithms and robust customer-to-customer authentication to prevent unauthorized access and ensure message integrity.[17][18]Traditional MT Messages (ISO 15022)
Structure and Composition
SWIFT MT messages, standardized under ISO 15022, are identified by a four-character code consisting of "MT" followed by a three-digit number, where the first digit denotes the category (1 through 9) and the second and third digits specify the particular message type within that category.[2] For instance, MT103 identifies a message for a single customer credit transfer in category 1.[2] The overall format of an MT message is organized into five distinct blocks, each enclosed in curly braces and separated by carriage return-line feed (CrLf) characters, as follows: {1: Basic Header Block}, {2: Application Header Block}, {3: User Header Block}, {4: Text Block}, and {5: Trailer Block}.[2] This block structure ensures standardized parsing and transmission across the SWIFT network.[2] The Basic Header Block ({1:}) includes essential routing and control information, such as the message input or output reference (a unique sequence number), the sender's Business Identifier Code (BIC), and the message priority (e.g., "N" for normal priority or "U" for urgent).[2] An example Basic Header might appear as {1:F01YOURBICXXXX1234567890}, where "F01" indicates a FIN message input reference, followed by the BIC and reference number.[2] The Application Header Block ({2:}) specifies the receiver's details, the message type, and processing dates, formatted to indicate input or output direction (e.g., "I" for input to SWIFT or "O" for output from SWIFT).[2] It includes the receiver's BIC, the three-digit message type (e.g., 103), and the input/output date and time.[2] A typical Application Header for an input message could be {2:I103YOURBICXXXXN}, where "I103" denotes an input MT103 message, followed by the receiver's BIC and a delivery monitoring flag ("N" for non-urgent).[2] The User Header Block ({3:}) is optional and accommodates additional sender- or receiver-specific information, such as urgency indicators or reference data, using predefined tags like {113:URGT} for urgent processing.[2] It allows flexibility for custom extensions without altering the core message content.[2] The Text Block ({4:}) forms the core of the message, comprising a sequence of up to 98 fields that convey the transactional details, each beginning with a colon, a two-digit tag (e.g., :20: for Transaction Reference Number), optional alphanumeric qualifiers (e.g., :50K: for a specific party type), and the corresponding value.[2] Field values adhere to ISO 15022 syntax rules, which define precise formats such as length limits (e.g., 16x for up to 16 alphanumeric characters), data types (alphabetic "a", numeric "n", or mixed "c"), and punctuation restrictions to ensure interoperability and validation.[19] For example, in an MT103 message, field :32A: specifies the value date, currency (3-letter ISO code), and amount (e.g., :32A:211223USD1000000,50), while :50K: details the ordering customer with a qualifier "K" indicating account information.[2] These fields must appear in a predefined sequence, with mandatory fields present and optional ones as needed per the message type.[2] The Trailer Block ({5:}) concludes the message with security and integrity elements, including a Message Authentication Code (MAC) for validation and a checksum block (e.g., {CHK:ABC123DEF456}).[2] It ends with a dash followed by "S" to signify the message's completion (e.g., -{S}).[2] Validation of MT messages under ISO 15022 involves syntax checks for field formatting, sequence adherence, mandatory field presence, and conditional logic (e.g., error code C81 for mismatched currency decimals), performed by SWIFT's network to prevent transmission errors.[2] This rigorous process supports reliable global financial messaging.[2] For illustration, a simplified MT103 structure might be represented as:{1:F01SENDERBICXXXX1234567890}
{2:I103RECEIVERBICXXXXN}
{4:
:20:REFERENCE123
:32A:211223USD1000000,00
:50K:/123456789
SENDERNAME
SENDERADDRESS
:52A:/987654321
INTERMEDIARYBIC
:59:/111222333
BENEFICIARYNAME
BENEFICIARYADDRESS
:71A:SHA
-}
{5:{MAC:ABCDEF123456} - }
{1:F01SENDERBICXXXX1234567890}
{2:I103RECEIVERBICXXXXN}
{4:
:20:REFERENCE123
:32A:211223USD1000000,00
:50K:/123456789
SENDERNAME
SENDERADDRESS
:52A:/987654321
INTERMEDIARYBIC
:59:/111222333
BENEFICIARYNAME
BENEFICIARYADDRESS
:71A:SHA
-}
{5:{MAC:ABCDEF123456} - }
Categories of MT Messages
MT messages under ISO 15022 are organized into nine primary categories, each designated by the first digit of the three-digit message type identifier (e.g., MT1xx for Category 1). These categories group messages by their functional purpose in facilitating various financial transactions between financial institutions and their customers. This structure ensures standardized communication for specific business domains, with over 200 distinct message types across the categories as of the November 2025 standards release.[20] The following table summarizes the main categories, their purposes, and representative message types:| Category | Purpose | Representative Message Types |
|---|---|---|
| 1 (MT1xx) | Handles customer payments and cheque-related instructions, including credit transfers and direct debits between banks and clients. | MT103 (Single Customer Credit Transfer), MT192 (Request for Cancellation).[2] |
| 2 (MT2xx) | Facilitates transfers of funds between financial institutions, often for interbank settlements without direct customer involvement. | MT202 (General Financial Institution Transfer), MT299 (Free Format Message).[2] |
| 3 (MT3xx) | Supports transactions in foreign exchange, money markets, and derivatives, including confirmations and settlements. | MT300 (Foreign Exchange Confirmation), MT399 (Free Format Message).[2] |
| 4 (MT4xx) | Manages collections, remittances, and cash letter processing for payment collections. | MT400 (Advice of Payment).[2] |
| 5 (MT5xx) | Covers securities markets activities, such as trade instructions, confirmations, and settlements for equities, bonds, and funds. | MT513 (Client Purchase and Sale Instruction).[2] |
| 6 (MT6xx) | Addresses commodities and precious metals trading, including confirmations and delivery orders; some types have been partially deprecated in favor of Category 3 equivalents. | MT607 (Precious Metal Trade Confirmation).[2] |
| 7 (MT7xx) | Deals with documentary credits, guarantees, and standby letters of credit for trade finance. | MT700 (Issue of a Documentary Credit), MT760 (Issue of a Demand Guarantee/Standby Letter of Credit), MT799 (Free Format Message).[2] |
| 8 (MT8xx) | Manages issuance, sales, and settlements of travellers cheques; usage is limited in modern contexts due to declining reliance on physical cheques. | MT800 (Travellers Cheque Issuance).[2] |
| 9 (MT9xx) | Provides cash management, account reporting, and customer status updates; free-format messages such as MT999 serve for communications to financial institutions. | MT940 (Customer Statement Message).[2] |
ISO 20022 MX Messages
Overview and Format
ISO 20022 serves as an international standard for electronic data interchange in financial services, developed to provide a common platform for messaging across the global financial industry. It employs XML syntax to enable structured and syntax-independent representation of financial business processes, incorporating reusable components such as messages and business components that can be assembled into comprehensive message sets. This methodology, including a central dictionary of business items, facilitates consistent data modeling and interoperability among financial institutions.[23] The MX format, specific to ISO 20022 implementations like those used in SWIFT, structures messages with distinct elements for clarity and processing efficiency. The message envelope includes a header containing identifiers such as message ID and creation date, ensuring traceability and routing. Following this are group headers for organizing multiple transactions, business application headers specifying the message's functional purpose, and the core payload comprising structured XML elements—for instance,for detailed payment information, allowing hierarchical data representation.[22]
Key message families within ISO 20022 encompass pacs for payments clearing and settlement, camt for account reports and cash management, pain for payment initiation, semt for securities management, and seev for corporate actions and securities events, each designed to address specific financial workflows. These families leverage the standard's advantages, including richer, structured data capabilities supporting larger payloads in a more organized manner than the unstructured formats of MT messages, which are limited to 10,000 characters, enhanced fields for straight-through processing and automation, and built-in extensibility for evolving requirements.[22] As of November 2025, following the end of the MT-MX coexistence period on November 22, 2025, MX messages have become the standard for cross-border payments and reporting on the SWIFT network.[6] Registration and ongoing maintenance of ISO 20022 are handled by the ISO Technical Committee 68 (TC68) for Financial Services, ensuring the standard's evolution through contributions from industry stakeholders and periodic updates to message definitions.[23]