Friday, February 3, 2017

SWIFT message block structure

SWIFT Financial Application (FIN) messages. They have the following structure:

{1: Basic Header Block} {2: Application Header Block} {3: User Header Block} {4: Text Block or body} {5: Trailer Block}
These five SWIFT message blocks include header information, the body of the message, and a trailer. All blocks have the same basic format:
{n:...}
The curly braces ({}) indicate the beginning and end of a block. is the block identifier, in this case a single integer between 1 and 5. Each block identifier is associated with a particular part of the message. There is no carriage return or line feed (CRLF) between blocks.
Blocks 3, 4, and 5 may contain sub-blocks or fields delimited by field tags. Block 3 is optional. Many applications, however, populate block 3 with a reference number so that when SWIFT returns the acknowledgement, it can be used for reconciliation purposes.
Note:
For further information on SWIFT message blocks, see Chapter 2 of the SWIFT User Handbook FIN System Messages Document.
The basic header block is fixed-length and continuous with no field delimiters. It has the following format:
{1:    F    01   BANKBEBB   2222   123456}
(a)   (b)  (c)     (d)      (e)      (f)
a)
1: = Block ID (always 1)
b)
Application ID as follows:
·         F = FIN (financial application)
·         A = GPA (general purpose application)
·         L = GPA (for logins, and so on)
c)
Service ID as follows:
·         01 = FIN/GPA
·         21 = ACK/NAK
d)
BANKBEBB = Logical terminal (LT) address. It is fixed at 12 characters; it must not have X in position 9.
e)
2222 = Session number. It is generated by the user's computer and is padded with zeros.
f)
123456 = Sequence number that is generated by the user's computer. It is padded with zeros.
There are two types of application headers: Input and Output. Both are fixed-length and continuous with no field delimiters.
The input (to SWIFT) structure is as follows:
{2:    I     100    BANKDEFFXXXX    U       3       003}
(a)   (b)    (c)      (d)          (e)     (f)      (g)
a)
2: = Block ID (always 2)
b)
I = Input
c)
100 = Message type
d)
BANKDEFFXXXX = Receiver's address with X in position 9/ It is padded with Xs if no branch is required.
e)
U = the message priority as follows:
·         S = System
·         N = Normal
·         U = Urgent
f)
3 = Delivery monitoring field is as follows:
·         1 = Non delivery warning (MT010)
·         2 = Delivery notification (MT011)
·         3 = Both valid = U1 or U3, N2 or N
g)
003 = Obsolescence period. It specifies when a non-delivery notification is generated as follows:
·         Valid for U = 003 (15 minutes)
·         Valid for N = 020 (100 minutes)
The output (from SWIFT) structure is as follows: 
{2:   O      100   1200   970103BANKBEBBAXXX2222123456   970103  1201   N}
(a)  (b)      (c)   (d)           (e)                      (f)    (g)   (h)
a)
2: = Block ID (always 2)
b)
O = Output
c)
100 = Message type
d)
1200 = Input time with respect to the sender
e)
The Message Input Reference (MIR), including input date, with Sender's address
f)
970103 = Output date with respect to Receiver
g)
1201 = Output time with respect to Receiver
h)
N = Message priority as follows:
·         S = System
·         N = Normal
·         U = Urgent
This is an optional block and has the following structure:
{3:  {113:xxxx}  {108:abcdefgh12345678}     }
(a)      (b)             ( c)
a)
3: = Block ID (always 3)
b)
113:xxxx = Optional banking priority code
c)
This is the Message User Reference (MUR) used by applications for reconciliation with ACK.
Note:
Other tags exist for this block. They include tags (such as 119, which can contain the code ISITC on an MT521) that may force additional code word and formatting rules to validate the body of the message as laid down by ISITC (Industry Standardization for Institutional Trade Communication). For further information, see All Things SWIFT: the SWIFT User Handbook.

{4: Text Block or body}
This block is where the actual message content is specified and is what most users see. Generally the other blocks are stripped off before presentation. 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
-}
The symbol CRLF is a mandatory delimiter in block 4.
 The example above is of type MT100 (Customer Transfer) with only the mandatory fields completed. It is an example of the format of an ISO 7775 message structure. Block 4 fields must be in the order specified for the message type in the appropriate volume of the SWIFT User Handbook.
The content of the text block is a collection of fields. For more on SWIFT fields, see SWIFT field structure. Sometimes, 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. For example, sequences such as those in the SWIFT Tags 16R and 16S may have beginning and ending fields. Other sequences, such as Tag 15, have only a beginning field. In yet other message types, no specific tags mark the start or end of a field sequence.
The format of block 4 field tags is:
:nna:
nn = Numbers
a = Optional letter, which may be present on selected tags
For example:
:20: = Transaction reference number
:58A: = Beneficiary bank
The length of a field is as follows:
nn = Maximum length
nn! = Fixed-length
nn-nn = Minimum and maximum length
nn * nn = Maimum number of lines times maximum line length
The format of the data is as follows:
= Digits
d = Digits with decimal comma
h = Uppercase hexadecimal
a = Uppercase letters
c = Uppercase alphanumeric
e = Space
x = SWIFT character set
y = Uppercase level A ISO 9735 characters
z = SWIFT extended character set
Some fields are defined as optional. If optional fields are not required in a specific message, do not include them because blank fields are not allowed in the message.
/,word = Characters "as is"
[...] = Brackets indicate an optional element
For example:
4!c[/30x]
This is a fixed 4 uppercase alphanumeric, optionally followed by a slash and up to 30 SWIFT characters.
ISIN1!e12!c
This is a code word followed by a space and a 12 fixed uppercase alphanumeric.
Note:
In some message types, certain fields are defined as conditional. For example, when a certain field is present, another field may change from optional to mandatory or forbidden. Certain fields may contain sub-fields, in which case there is no CRLF between them. Validation is not supported.
Certain fields have different formats that depend on the option that is chosen. The option is designated by a letter after the tag number, for example:
:32A:000718GBP1000000,00
Value Date, ISO Currency, and Amount
:32B:GBP1000000,00
ISO Currency and Amount
Note:
The SWIFT standards for amount formats are: no thousand separators are allowed (10,000 is not allowed, but 10000 is allowed); use a comma (not a decimal point) for a decimal separator (1000,45 = one thousand and forty-five hundredths).
:58A:NWBKGB2L
Beneficiary SWIFT address
:58D:NatWest Bank
Beneficiary full name and address
Head Office

London
A message always ends in a trailer with the following format:
{5: {MAC:12345678}{CHK:123456789ABC}
This block is for SWIFT system use and contains a number of fields that are denoted by keywords such as the following:
MAC
Message Authentication Code calculated based on the entire contents of the message using a key that has been exchanged with the destination and a secret algorithm. Found on message categories 1,2,4,5,7,8, most 6s and 304.
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.
Copyright IBM Corp. 1997, 2004


4 comments:

  1. thank you for the great article!

    Do you have more information on how to populate {5:{MAC}} and the Checksum algorithm for {5:{CHK}}?

    ReplyDelete
    Replies
    1. Hi, did you get reply for this? did you find out how to populate these two fields?

      Delete
  2. If you are sending a MT103 and if you only have the destination BIC, do you know how to find out the destination address (destination BIC + LogicalTerminalID)?

    ReplyDelete
  3. Ok now according to how the University of MN calculate the grade points average, which I think is the standard way that most colleges follow, is:

    You can perform different GPA calculations through this Major GPA Calculator.First off I wish I have a 4.0 GPA like you do, so three thumps up on that one.

    63 credits means you've taken 21 courses all of which were 3 credits each.

    Based on grade points (GP), a letter grade C is worth 2.0GP, C+ is worth 2.333GP, B- is worth 2.667GP, B is worth 3.0GP, B+ is worth 3.333GP, A- is worth 3.667GP, and A is worth 4.0GP.

    Now knowing that you have 216.0 grade points, this means that when you divide the total grade points with the number of credits you racked up, you get the grade points average.

    So 216.0 divided by 63, you get 3.429. This should have been worth around B+ but since you have a 4.0, you must have done better than you think or maybe 216.0 isn't quite the right total points.

    But I hope this helps...let me know.

    ReplyDelete