This information is provided as a quick introduction to the SWIFT standard and the MT format. For detail information please check out www.swift.com

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 of boundary delimited blocks, also knonw as FIN
  • MX (ISO 20022): the new SWIFT standard based on XML syntax.

The following section describes the MT message structure.

Message Types

FIN 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:

Category Description Model classes
0System MessagesMT0nn
1Customer PaymentsMT1nn
2Financial Institution TransfersMT2nn
3MT3nn - FX, Money Market & DerivativesMT3nn
4Collections and cash lettersMT4nn
5Securities MarketsMT5nn
6Precious Metals & SyndicationsMT6nn
7Documentary Credits & GuaranteesMT7nn
8Travellers ChequesMT8nn
9Cash Management & Customer StatusMT9nn

For example MT103 is a Single Customer Credit Transfer, while MT202 is a General Financial Institution Transfer.

There are several hundred of message types in total.

MT Message Block Structure

FIN 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 (from the network perspective).
Both are fixed-length and continuous with no field delimiters.


Used in outgoing messages, when a message is input to the SWIFT network.

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)


Used in incoming messages, when a message is output from the SWIFT network.

It includes the following fields; for example:
O 101 1200 220112 BANKBEBBAXXX 2222 123456 220112 1201 N

  • O = Output
  • 101 = Message type
  • 1200 = Input time with respect to the sender
  • 220112 = the MIR date (message input reference) in YYMMDD format
  • BANKBEBBAXXX = 12 characters containing the logical terminal field of the MIR (address of the sender of the message)
  • 2222 = 4 characters containing the session number field of the MIR
  • 123456 = 6 characters containing the sequence number field of the MIR
  • 220112 = String of 6 characters containing the Output date local to the receiver, written in the following format: YYMMDD
  • 1201 = 4 characters containing the Output time local to the receiver, written in the following format: HHMM
  • N = Priority

The Message Input Reference (MIR) 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.

{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:

{4: [CRLF]
:20:PAYREFTB54302 [CRLF]
:32A:970103BEF1000000, [CRLF]
:59:/123-456-789 [CRLF]

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.