SWIFT MTS – BLOCKS 1 THROUGH 5

-

 SWIFT MTs – Blocks 1 Through 5

We have discussed in our previous article that there are 5 blocks in a SWIFT MT message. Now we will dive deep into each of these blocks and try to understand them in detail. Please save this page for your future reference (At least till 2025)

There are some common details and we will try to understand what they are

  • All the blocks start with “{”
  • The Block number or block identifier will be displayed at the very beginning followed by a “:” (Separator)
  • This will be followed by the contents of the block
  • The block will end with a “}”

Basic Header Block (Block 1 )

This block is the only mandatory block and contains general information identifying a message.  Let us now dissect the block

{1:F01CITIFRPPAXXX0070970817}

This can be split into different components ( Split using spaces)

{  1  :  F  01  CITIFRPPAXXX  0070 970817}

F – This is application Identifier or AppID . F Indicated that it is a FIN message

01 – This is the service identifier and it consists of 2 digit numbers. 01 indicated that it is FIN. 21 stands for an acknowledgment (ACK) or negative acknowledgment (NACK)

CITIFRPPAXXX – This is a very interesting one. Technically it is called the LT address. It can be further split into the following

CITIFRPP – Bank BIC

A – Terminal ID

XXX – Bank branch code (Part of the BIC)

So the 11 character BIC would be CITIFRPPXXX . This BIC is the sender of the message if the First char of Block 2 is “I” and it indicates the receiver if Block 2 is “O” . We will see what the O and I mean very soon.

0070 – It is the session number of FIN

970817 – The 6 digit number is the sequence number. This is not very interesting from a functional point of view hence will skip it. If you are interested in knowing the details please let me know I will add the details in this article.

Application Header Block (Block 2)

The application header contains information that is specific to the application. The application

header is required for messages that users, or the system and users, exchange. The application header contains information that is specific to the application. The application

header is required for messages that users, or the system and users, exchange.

Example:

{2:O1031734150713NDEANOKKBXXX00739698421607131634N}

The application Header block can once again have two types

  1. Application Header Block for Input messages
  2. Application Header Block for Output messages

You might very well ask ‘what does “Input” and “Output” mean ??’

“Input” means input TO SWIFT

“Output” means output FROM SWIFT

When payment engines of the sender bank generate SWIFT payments then they will Input the message to SWIFT network, the message will then be output from SWIFT network which will then be consumed by the receiver bank

Application Header Block for Input messages

{2:I103NDEANOKKBXXXU3003}

This can be segregated into the different components as follows

I 103 NDEANOKKBXXX U 3 003

I – Input to SWIFT network

103 – SWIFT MT message

NDEANOKKBXXX – This is the Destination address to which this payment is addressed. It contains 12 characters – 11 Char BIC + 1 Char Logical terminal

NDEANOKKXXX – 11 Char Bic

B – Which is the 9th character is the Logical terminal code

 U – This is the message priority. “U” stands for Urgent. The other possible values are S (System) and N ( Normal). The “S” is for user to system messages.

3 – It indicates the delivery monitoring option and is applicable for FIN-type messages.

The chosen option is expressed as a single digit:

  • 1 = Non-Delivery Warning
  • 2 = Delivery Notification
  • 3 = Non-Delivery Warning and Delivery Notification

If the message has priority ‘U’, the user must request delivery monitoring option ‘1’ or ‘3’. If the message has priority ‘N’, the user can request delivery monitoring option ‘2’ or, by leaving the options blank, no delivery monitoring.

003 – Obsolescence Period mentions the amount of time after which the delayed message (DLM) trailer is added to a FIN user-to-User message or if it is a Urgent message then it is the amount of time after which the message can be marked Not delivered and a warning message is sent.

Each unit has a value of 5 minutes so,

003 –  15 mins (Urgent)

020 – 100 mins (Normal)

Application Header Block for Output messages

{2:O1031734150713NDEANOKKBXXX00739698421607131634N}

This can be segregated into the different components as follows

O 103 1734 150713NDEANOKKBXXX0073969842 160713 1634 N

O – Output to SWIFT network

103 – SWIFT MT message

1734 – The local Input time in the format (HHMM)

150713NDEANOKKBXXX0073969842 – This is the message input reference this can be further split the following

150713 – Date in YYMMDD format

NDEANOKKBXXX – Logical terminal address of the sender of the message ( 8 Char BIC + Logical terminal code + 3 digit branch code of the BIC)

NDEANOKK B XXX

0073 – Session number

969842 – Sequence number

160713 – Output date

1634 – Output Time

N – Priority. N stands for normal and U for Urgent.

Use header Block (Block 3)

The user header block is common to all swift messages and is used in certain situations. This block contains information in different tags and these tags are available between 2 curly brackets.

 {3:{113:URGT}{108:INTLPMTS}{121:5798a701-effe-43e5-8d14-eec27ea3d8ec}}

Text Block (Block 4)

This block contains the contain the main content of the message that includes amounts, value dates, charges, etc.

The contents of each type of message widely vary and the best place to view the details of the SWIFT MT message is SWIFT’s official website. It contains details of all the swift messages.

Link:

https://www2.swift.com/knowledgecentre/products/Standards%20MT/publications#November%202021

 We will discuss some of the text blocks of some of the messages in future articles.

Trailer Block (Block 5)

The trailer either indicates special circumstances that relate to message handling or contains security information.

{5:{CHK:D628FE016232}}

SOURCEs ( Thanks to them):

https://www.ibm.com/docs/en/ftmfz/3.2.5?topic=messages-user-header-block-block-3-sr-2017

SWIFT MT Message Structure Blocks 1 to 5

Popular posts from this blog

SWIFT MT – SERIAL AND COVER METHOD

-
Image
  SWIFT MT – Serial and Cover Method This is one of the most important articles from SWIFT payments’ perspective and it is critical that you fully understand the concepts laid out here. Payments are cleared and settled via 2 primary methods: Through a payment market infrastructure (PMI) Through correspondent banking Through payment market infrastructure: This is the case where bank A and bank B are direct participants of this PMI aka CSM. IN General usage the concept of serial and cover does not apply here but if you put a gun to my head, I would say is very close to the serial method. Through correspondent banking: This is the case where banks open accounts with each other (Nostro/Vostro) and settle funds directly. The prerequisite here is that banks need to open accounts with each other or in other words they need to have an  accounting relationship  with the other bank. Now, let us try to understand the connection between sending/receiving SWIFT messages and the moveme...
Read more

SEPA CREDIT TRANSFER – REJECT FLOW

-
Image
  SEPA Credit Transfer – Reject flow : Even though the happy path is the most common case, there are always exceptions and the different parties in an SCT payment chain can reject the payment due to several reasons. The status of the payment has to be conveyed to the ordering customer so that corrective action can be taken. Let us try to understand who are all the parties that can send Rejections and how they do it Reject definition:  “A ‘ Reject’  occurs when a SEPA Credit Transfer is not accepted for normal execution before inter-PSP Settlement. ” – EPC rule book. The main point to note here is that a payment is rejected before the settlement of the payment happens between banks. In case the payment is settled then the payment has to be Returned (we will get to this in the next article). Ordering bank (Originator PSP):  Upon receiving a Pain.001, the ordering bank (Originator PSP) will start processing the instruction and may decide to reject the pay...
Read more

SEPA CREDIT TRANSFER – RECALL FLOW

-
Image
  Sepa Credit Transfer – Recall flow : SEPA credit transfer – recall is a process through which an Originator or Originator PSP wants to cancel or get back the funds of an earlier credit transfer that was sent. Both the Originator and the Originator PSP can recall the payment for several reasons and here are some of them Originator: payment sent with incorrect information Wrong amount Payment sent to the wrong party Originator PSP: A duplicate message sent Fraudulent credit transfer message sent There are different parties in the payment chain and let us see how the different parties react to the recalls. It is important to note that when Originators initiate a recall they communicate to their PSP either via a payment message or email/phone call/branch visit. PSPs on the other hand send a message directly. Whenever an Originator initiates a recall request then it does not guarantee them the funds will be returned. There are 3 sub-flows within a recall flow: Payment not settled Posi...
Read more