MX Message

An MX message is a financial message written in XML according to the ISO 20022 standard. The name is used mainly in the SWIFT community to distinguish these messages from the older MT messages, which use a compact text format. MX messages carry payment instructions, status reports, account statements, securities instructions and many other kinds of financial information between banks, market infrastructures and corporate customers.

Strictly, "MX" is SWIFT's label for the ISO 20022 messages it carries, but in practice people use it as a general name for ISO 20022 formatted messages. The same message definitions are used by high-value payment systems, instant payment schemes and corporate banking channels, whether or not they run over SWIFT. The wider standard is described under ISO 20022.

Each MX message has an identifier made of four parts: a business area, a message number, a variant and a version. In pacs.008.001.08, for example, "pacs" is the business area for payments clearing and settlement, "008" is the message, "001" is the variant and "08" is the version. The main business areas used in payments are:

• pain (payments initiation). Messages between a customer and its bank, such as pain.001 for credit transfer initiation and pain.002 for the status report.
• pacs (payments clearing and settlement). Messages between banks, such as pacs.008 for customer credit transfers, pacs.009 for bank-to-bank transfers and pacs.002 for status reports.
• camt (cash management). Reporting and exception handling, such as camt.053 for account statements and camt.054 for debit and credit notifications.

Other business areas cover securities ("sese", "semt"), trade services and foreign exchange.

An MX message sent over a network usually has two parts. The business application header identifies the sender, receiver, message type and a unique business reference. The document contains the business content, organised in nested XML elements with defined names, data types and rules. A pacs.008, for instance, has a group header with information about the whole message and one or more credit transfer transaction elements, each with amounts, dates, debtor, creditor, agents and remittance information.

Because XML is self-describing, each piece of data sits in its own tagged element rather than in free text. Names and addresses can be broken into structured parts such as street, town and country, and purpose codes and invoice references have dedicated places. This structure is the main reason the industry is adopting MX.

Each message is defined by an XML schema, so a receiving system can check automatically that a message is well formed and that every mandatory element is present before processing it. Payment systems and SWIFT also publish usage guidelines that narrow the general standard, for example by making optional elements mandatory or restricting which codes may be used, so that all participants in a system complete the same message in the same way.

MX messages differ from MT messages in several ways:

• Richer data. Longer fields and more elements allow full names, structured addresses and detailed remittance information.
• Consistency. All messages are built from a shared data dictionary, so the same concept is represented the same way across payments, securities and reporting.
• Machine readability. Structured data supports automatic sanctions screening, reconciliation and analytics with fewer manual interventions.
• Size. XML messages are much larger than MT messages, which requires more storage and processing capacity.

SWIFT began moving cross-border payments and cash reporting from MT to MX in March 2023, using usage guidelines known as Cross-Border Payments and Reporting Plus (CBPR+) to define how each message should be completed. A coexistence period allowed both formats until November 2025. MX messages travel over SWIFT's FINplus messaging service. Many domestic high-value systems moved in the same period, including the euro area's T2, the UK's CHAPS and the US Fedwire Funds Service, while instant payment systems such as SEPA Instant and many newer real-time schemes were built on ISO 20022 from the start.

Migration has proved complex. Banks must upgrade payment engines, screening tools and reconciliation systems, and they must handle translation between MX and MT for counterparties or internal systems that have not yet moved, which can truncate data. Different market practices and versions mean that the same message may be completed slightly differently in different systems, so banks need strong payment message validation. The full benefit of MX depends on all banks in a payment chain passing on the richer data unchanged, rather than stripping it when converting formats.