back About SWIFT

This information is provided as a quick introduction to the SWIFT standard and the MT format

For detail information please check out

The acronym stands for Society for Worldwide Interbank Financial Telecommunications. SWIFT is a cooperative society under Belgian law and it is owned by its member financial institutions. It has offices around the world, and SWIFT headquarters are in La Hulpe, Belgium, near Brussels.

It mainly provides a network that enables financial institutions worldwide to send and receive information about financial transactions in a secure, standardized and reliable environment.

The term SWIFT is normally used indistinctly to reference the society, the network, the system, and the message protocol.

Each financial institution, to exchange banking transactions, must have a banking relationship by either being a bank or affiliating itself with one (or more).

The organizations types that can access the service are: Banks, Trading Institutions, Money Brokers, Securities Broker Dealers, Investment Management Institutions, Clearing Systems and Central Depositories, Recognised Exchanges, Trust and Fiduciary Service Companies, Subsidiary Providers of Custody and Nominees, Treasury Counterparties, Treasury ETC Service Providers and Corporates.

SWIFT has become the industry standard for syntax in financial messages. Messages formatted to SWIFT standards can be read by, and processed by, many well-known financial processing systems, whether or not the message traveled over the SWIFT network.

The SWIFT network support two message standards:

  • MT (ISO 15022): based on a proprietary format, composed by boundary delimited blocks.
  • MX (ISO 20022): the new SWIFT standard based on XML syntax.


Message Types

SWIFT MT messages are identified by a 3-digit number, the first digit representing the Category and the following two representing the specific message inside the category. The categories are: System Messages (MT0nn), Customer Payments (MT1nn), Financial Institution Transfers (MT2nn), MT3nn - FX, Money Market & Derivatives (MT3nn), Collections and cash letters (MT4nn), Securities Markets (MT5nn), Precious Metals & Syndications (MT6nn), Documentary Credits & Guarantees (MT7nn), Travellers Cheques (MT8nn), Cash Management & Customer Status (MT9nn).

There are several hundred of message types in total.


MT Message Block Structure

SWIFT MT messages consist of five blocks of data including three headers, message content, and a trailer.

{1: Basic Header Block}{2: Application Header Block}{3: User Header Block}
{4: Text Block or body}
{5: Trailer Block}

All blocks have the same basic format: {n:...}. The curly braces indicate the beginning and end of a block and n is the block identifier (between 1 and 5). There is no carriage return or line feed between blocks. Blocks 3, 4, and 5 may contain sub-blocks or fields delimited by field tags. Block 3 is optional.


{1: Basic Header Block}

The basic header block is fixed-length and continuous with no field delimiters. It includes the following fields:

  • Application ID (F for financial application, A for general purpose application or L for login and session management)
  • Service ID (01 = FIN/GPA, 21 = ACK/NAK)
  • Logical terminal (LT) address. It is fixed at 12 characters; it must not have X in position 9. Example BANKBEBBAXXX.
  • Session number (four digits) and Sequence number (six digits).

{2: Application Header Block}

There are two types of application headers: Input and Output. Both are fixed-length and continuous with no field delimiters.


It includes the following fields:

  • I = Input
  • Message type
  • Receiver's address with X in position 9/ It is padded with Xs if no branch is required. Example: BANKDEFFXXXX
  • The message priority (S = System, N = Normal, U = Urgent)
  • Delivery monitoring (1 = Non delivery warning, 2 = Delivery notification, 3 = Both valid
  • Obsolescence period. It specifies when a non-delivery notification (003 - 15 minutes, 020 - 100 minutes)


It includes the following fields:

  • O = Output
  • Message type
  • Input time with respect to the sender
  • The Message Input Reference (MIR), including input date, with Sender's address. This is sometimes confusing because it is an output block with an input reference. The important thing to understand here is that the MIR information is related to the original sender of the message that has been received.
  • Output date and time with respect to Receiver
  • Message priority

{3: User Header Block}

This is an optional block and can include several tags, being the most common:

  • 113:xxxx = Optional banking priority code
  • The Message User Reference (MUR) used by applications for reconciliation with ACK.

{4: Text Block or body}

This block is where the actual message content. The format, which is variable length and requires use of CRLF as a field delimiter, is as follows:


Where the CRLF is the carriage return and line feed and is the mandatory fields delimiter.
The content of the text block is a collection of ordered fields in the order specified for the message type. For some message types, the fields are logically grouped into sequences. Sequences can be mandatory or optional, and can repeat. Sequences also can be divided into subsequences. In addition, single fields and groups of consecutive fields can repeat.


{5: Trailer Block}

This block is mostly for SWIFT system use and contains a number of fields that are denoted by keywords and put into curly braces, for example:

{5: {MAC:12345678}{CHK:123456789ABC}}

The most common fields used in the trailer block are

  • MAC: Message Authentication Code calculated based on the entire contents of the message using a pre exchanged key and a secret algorithm.
  • CHK: Checksum calculated for all message types.
  • PDE: Possible Duplicate Emission added if user thinks the same message was sent previously.
  • DLM: Added by SWIFT if an urgent message (U) has not been delivered within 15 minutes, or a normal message (N) within 100 minutes.


MIR (message input reference) and MOR (message output reference) are messages unique identifiers containing the date, logical terminal (including branch code), session and sequence numbers. Nevertheless this identifiers can be confusing sometimes because they must be thought from SWIFT perspective.

A message created by the sender user/application is considered an INPUT message, because it gets into the SWIFT network. When the message is delivered and gets out of the network it is considered an OUTPUT message. Therefore the headers of a sent message are not exactly the same as the headers of the received message at the destination party. Analogous the headers of a message that the receiving user/application gets from SWIFT are not exactly the same as the headers when the message was created and sent by the sending party.

The usage of MIR and MOR are clear when analyzing system messages. A non delivery warning for example, includes the original MIR of the sent message, but not the MOR because the message was not delivered yet. But a delivery confirmation on the other hand, includes both, the sender's MIR and the receiver's MOR.
System messages provide MIR/MOR information using fields 106 and 107 respectively.