Skip to content

SWIFT MT

The following section describes the MT message structure and key concepts of the standard.

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 Prowide Model classes
0 System Messages MT0nn
1 Customer Payments MT1nn
2 Financial Institution Transfers MT2nn
3 MT3nn - FX, Money Market & Derivatives MT3nn
4 Collections and cash letters MT4nn
5 Securities Markets MT5nn
6 Precious Metals & Syndications MT6nn
7 Documentary Credits & Guarantees MT7nn
8 Travellers Cheques MT8nn
9 Cash Management & Customer Status MT9nn

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.

Input

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)

Output

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]
    :50:CUSTOMER NAME [CRLF]
    AND ADDRESS [CRLF]
    :59:/123-456-789 [CRLF]
    BENEFICIARY NAME [CRLF]
    AND ADDRESS [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 and MOR

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.

SCORE

Standardised CORporate Environment (SCORE) is a SWIFT standard for the exchange of financial information between corporate customers and their banks.

For MT messages, it is based on exchanges of the MT798 proprietary envelop message with many sub-message types. Some of the inner payloads are MT messages, but other are proprietary messages defined just for SCORE.

The Prowide Core library contains several helper API to handle the MT798 envelop and the inner messages. And the Prowide Integrator library complements that, by adding a set of specific model classes for each SCORE message such as the MT798<745>, 798<760>, 798<726>, etc... along the full structure validation of the envelop and the inner messages.