SWIFT Message Structure

8/8/2019 SWIFT Message Structure

1/15

SWIFT MESSAGE STRUCTURE

SWIFT Message Structure

The following information has been obtained from the SWIFT User Manual. The information described refers to both the messageformats as well as the utilization of the real SWIFT communications interface. Initially, ISITC participants will utilize only theinformation directly related to the SWIFT message formats.

General

SWIFT processes information (i.e., data, text, or commands) in the form of messages. SWIFT initially offers two applications -GPA (General Purpose Application which controls how users communicate within SWIFT ) and FIN (Financial Application whichcontrols the user to user messaging facilities within SWIFT )- which together provide all of the messaging functions and facilitiesavailable to users.

This chapter describes the following aspect of the messaging service:

The types of message

The structure of a message

How a message is referenced

The priorities applied to messages

How a message is acknowledged

Multi-section messages and reports

Message validation

ISITC sample message

Users should be aware that the actual appearance of a SWIFT message (whether on screen or on paper) is dependent upon how theirCBT (computer-based terminal) has been programmed and on any internal processing of SWIFT messages carried out within theirown organization.A validation error in the application header, text or trailer block will result in a negative acknowledgment (NAK) indicating thereason for rejection.Each message received by the system is examined to determine whether it conforms to the format specification for that message typeThe sequence in which the various parts of a SWIFT message are validated is as follows:

1. Basic header

2. Application header

3. User header

4. Trailer(s)

5. TextAt the first validation failure, the appropriate error procedure is carried out (either session abortion or negative acknowledgment)and no further validation is performed on the message.

9601 2-1

2


2/15


Structure of a Message

All SWIFT messages conform to a defined block structure. Each block of a message contains data of a particular type and is used fora particular purpose.Each block of message begins and ends with a curly bracket (or brace) character "{" and "}" respectively. All main blocks are

numbered, and the block number followed by a colon (:) are always the first characters within any block.A typical SWIFT user-to-user message may consist of:

{1: Basic Header Block}

{2: Application Header Block}

{3: User Header Block}

{4: Text Block}

{5: Trailers Block}Only block 1 (the Basic Header block) is mandatory for all messages. Blocks 2-5 are optional and depend upon the nature of themessage and on the application in which the message is being sent or received.Blocks 1,2 and 3 relate to header information, block 4 contains the text of the message, and block 5 contains trailer information.Blocks 3,4 and 5 may contain sub-blocks (i.e., blocks within blocks) or fields delimited by field tags, depending on the nature of the

message.At the first validation failure, the appropriate error procedure is carried out (either session abortion or negative acknowledgment)and no further validation is performed on the message.

9601 2-2


3/15


Length of a Message

The type of SWIFT message will determine the maximum length allowed for the particular message. Individual transactionmessages such as the 520 series of messages permit for a maximum message length of 2000 bytes. Statement type messages such asthe 950 or 570 series of messages permit a maximum of 10,000 bytes.

9601 2-3


4/15


Presentation of a Message

Each main block is sub-divided into a number of fields and each field contains particular information (e.g., date, time, LT address,session number, ISN, or a tag number followed by the appropriate variable content).All fields within header blocks 1 and 2 are of fixed length and are continuous - no field separators are used.

In the case of the text of a user-to-user message, all message text within the Text block (block 4) begins with Carriage Return andLine Feed (CrLf) and ends with CrLf followed by a hyphen (-). Each field within the text begins with a tag number followed by acolon, followed by the appropriate variable content.For the purpose of clarity within this manual, some message examples are shown here with each block beginning a new line andwith spaces separating the various fields within blocks. The block separators "{" and "}" are also shown. The letters a,b,c,d, etc.,are used in these examples to identify the constituent parts of each block. An explanation of each part or field is given for eachexample.

9601 2-4


5/15


Basic Header Block

The basic header is given in block 1 of a SWIFT message. It is the only compulsory header and appears on all user-to-usermessages, system messages, system commands and acknowledgments. The basic header provides the fundamental referencing of a

particular message within an application session of a particular LT.

The basic header has the same format for both input and output messages. However, the information contained in the basic header isrelative to the sender when the message is input but relative to the receiver when the same message is output.The following is an example of a basic input header, as it might appear at the beginning of a user-to-user message input within theFIN application.

{1:F01BANKBEBBAXXX2222123456}but for clarity we will show the components separated:

{1: F 01 BANKBEBBAXXX 2222 123456}A B C D E F

"A" Block IdentifierThe block identifier for a basic header block is always "1:".

"B" Application IdentifierThe application identifier identifies the application within which the message is being sent or received. The available options are:

F=FIN (all user-to-user and FIN system messages)(used for ISITC)

A=GPA (most GPA system messages and commands)

L=GPA (certain GPA session control commands, e.g., LOGIN, LOGIN acknowledgments,ABORT)

These values are automatically assigned by the SWIFT system and the user's application, all users should be aware of their existenceand significance.

"C" Application Protocol Data Unit IdentifierThe Application Protocol Data Unit (APDU) Identifier consists of two numeric characters. It identifies the type of data that is beingsent or received and, in doing so, whether the message which follows is one of the following:

User-to-user message

System message

Service message, e.g., a session control command (such as SELECT)

Logical acknowledgment (such as ACK/SAK/UAK).

Users will be primarily concerned with APDU identifier "01" (ISITC) which applies to all GPA and FIN system and user-to-usermessages. Other values include: "21" (for message acknowledgments such as ACK/NAK, UAK/UNK, "03" (a SELECT command),"05" (a QUIT command), etc.

"D" LT AddressThis 12-character SWIFT address, given in the basic header block, is the address of the sending LT (for input messages) or of thereceiving the LT (for output messages), and includes the branch code.In the basic header, the Logical Terminal Code within the LT address is specific to the LT that has established the session in whichthe message is being transmitted (i.e. the sending LT for input messages or the receiving LT for output messages).

9601 2-5


6/15


A SWIFT address or BIC can be requested for any financial institution, whether or not you are a SWIFT member participant, bycontacting SWIFT administration. The SWIFT address which will be assigned by SWIFT administration is comprised of thefollowing:

Bank (Financial Institution) Code 4 CharactersCountry Code 2 CharactersLocation Code 2 Characters

Logical Terminal Code 1 Character Branch Code 3 Characters

"E" Session NumberThe session number identifies the session in which the message was transmitted. Within the basic header, the session number (fourdigits) is the user's current GPA or FIN session number. ("0000" - ISITC)

"F" Sequence Number (ISN or OSN)The sequence number always consists of six digits. It is the ISN of the sender's current input session or the OSN of the receiver'scurrent output session. ("000001" - ISITC)

9601 2-6


7/15


Application Header Block

The application header of a SWIFT message provides information about the message itself.The application header is given in block 2 of a SWIFT message. If differs according to whether the message is a GPA or a FINmessage and whether the application header is attached to an input message or to a output message.

Application Header - InputFor input messages, the application header describes the type of message, whom it is for and how it should be sent.GPA input application headers are similar to their FIN equivalents except that GPA messages will not specify priority, deliverymonitoring, nor obsolescence period.The following is an example of an input application header, as it might appear at the top of a user-to-user message, input within theFIN application:

{2: I 100 BANKDEFFXXXX U 3 003}A B C D E F G

"A" Block IdentifierThe block identifier for an application header block is always "2:".

"B" Input/Output IdentifierThe input/output identifier consists of a single letter - either "I" for an input message or "O" for an output message.

"C" Message TypeThe message type consists of three digits which define the MT number of the message being input. The example used above is for a

Customer Transfer (MT 100).

"D" Recipient's AddressThis address is the 12-character SWIFT address of the recipient of the message, but with a Logical Terminal Code of "X". If definesthe destination to which the message should be sent.A SWIFT address which will be assigned by SWIFT administration is comprised of the following:

Bank (Financial Institution) Code 4 CharactersCountry Code 2 CharactersLocation Code 2 CharactersLogical Terminal Code 1 Character Branch Code 3 Characters

The system will replace the "X" with a specific Logical Terminal Code on delivery of the message.

Institution which are not part of the SWIFT network will be assigned a Branch Code of BIC.The branch code is mandatory and will be validated. The default of "XXX" may be used, as in the example above.

"E" Message PriorityThis character (used within FIN application headers only) defines the priority by which a message shall be delivered. The possiblevalues are:

9601 2-7


8/15


S = System

U = Urgent

N = NormalMessage priority "S" must be used for user-to-system messages: for user-to-user messages either "U" or "N" may be used.

Application Header-OutputFor output messages, the output application header defines the type of message, who sent it (and when), and when it was delivered.GPA output application headers are similar to their FIN equivalents except that, for GPA, the message priority is not included.The following is an example of an output application header, as it might appear at the top of a user-to-user message output withinthe FIN Application:

{2: 0 100 1200 910103BANKBEBBAXXX2222123456 910103 1201 N} A B C D E F G H

"A" Block IdentifierThe block identifier for an application header block is always "2:".

"B" Input/Output IdentifierThe input/output identifier consists of a single letter - either "I" for an input message or "O" for an output message.

"C" Message TypeThe message type consists of three digits which define the MT number of the message being output. The example used above is for aCustomer Transfer (MT 100).

"D" Input TimeThe input time (HHMM) is expressed in the sender's local time. If the message is a system message, the input time is the time themessage was generated by the system, expressed in Greenwich Mean Time. (GMT)

"E" Message Input Reference (MIR)Every input message is assigned a unique Message Input Reference (MIR). This is a string of 28 characters which consists of thedate the message was input (local to the sender), the sender's LT identifier and branch code, the sender's session number and sender'sISN.If the output message is system-generated, the system MIR will show a Pseudo-Logical Terminal (PLT) address, e.g.,SWFTXXXXXXXX, identifying as the sender the particular suite of programs which generated the message within the system. Thedate given in the system MIR is the generation date in GMT.

"F" Output DateThe output date (YYMMDD) is the date local to the receiver.

9601 2-8


9/15


"G" Output TimeThe output time (HHMM) is expressed in the receiver's local time.

"H" Message Priority

The message priority, for FIN messages only, is repeated in the FIN output application header. ("N" - ISITC default, no priority)

9601 2-9


10/15


User Header Block Required for ISITC version control

The user header is an optional header available within the FIN application and is available for user-to-user messages only. Thisheader block is mandatory as it is utilized to identify the version of the message standard applicable for processing and validating the

particular message to which the header applies. It also allows a user to provide his own form of reference for a particular message.

A user header can only be assigned by the sender of a message and, if assigned, will always appear on the output message copy andon related system messages and acknowledgments.The user reference part of the user header may be used as one of the selection criteria in a SWIFT retrieval.The user header appears in block 3 of a SWIFT message. If used, at least one of the two possible sub-blocks must be defined.The following example shows the format of a user header:

{3: {113:9601} {108:abcdefgh12345678}}A B C

"A" Block IdentifierThe block identifier for a user header block always has the value "3:".

"B" ISITC Version IdentifierA version/release represents a snapshot in tme of the status of the development and maintenance efforts of ISITC as of a specifieddate. Up to two releases per year may be approved for implementation and are identified by version control numbers. Tag 113 isused by ISITC to identify the version of the standard that applies to the message.Version identifiers are four digits long and identify the year the version was created (i.e. 1996 would be 96) as well as the versionnumber ( 01 or 02) as there are a maximum of two versions of the standard per year.

"C" Message User Reference (MUR)Tag 108 defines a free-format field in which users may specify their own reference of up to 16 characters of all the permittedcharacter set.

If an MUR is not specified, the TRN (from field 20: in the text of a user-to-user message) is automatically copied into this field, butonly on the system's storage media, and may be used for retrieval of the messages if the alphabetic characters contained in the TRNwere in uppercase. The TRN will never be output as an MUR.

9601 2-10


11/15


Text BlockThe text of a SWIFT message (where applicable) is given in block 4 of a SWIFT message. An example of the text block in a typicalFIN user-to-user message follows:

{4:

:20:PAYREF- TB54302:32A:910103BEF1000000,

:50:CUSTOMER NAME

AND ADDRESS

:59:/123-456-789

BENEFICIARY NAME

AND ADDRESS

-}In the text of user-to-user messages, CrLf is a mandatory delimiter.In those cases where character type "a", "a", "a", or "a" is used in the field format description, the alphabetic characters must beuppercase.The text part of a GPA message or a FIN system message differs only in that each text field is seen as a sub-block of block 4, with

block delimiters at the beginning and end of each sub-block. For example, the text block of a Non-Delivery Warning (MT 010) may

appear as:{4:{106:910103BANKBEBBAXXX1221654321}

{108:ABCDEF}

{431:07}

{102:BANKUS33XXXX}

{104:U}}(Note that the text block will be transmitted as a continuous string of characters without CrLf or blank characters inserted. In theabove example, the sub-blocks have been shown on separate lines for purpose of clarity.)All Swift Text Messages have a maximum of 35 characters per line.In the event that the necessary information spans more than one line, the current line must end with a CrLf, and the subsequent linemust begin with the "//" continuation character.

e.g. :35B:678901234567890123456789012345CrLf

//1234567890...

9601 2-11


12/15


Trailers Block

General

Trailers are added to a message for control purposes: or to indicate that special circumstances apply to the handling of the message:or to convey special/additional information. They may be added by the user or by the system.Trailers always appear in block 5 of a SWIFT message. Each trailer appears as a separate sub-block and is bounded by blockdelimiters.Each trailer begins with a three letter code, followed by a colon, followed by the trailer information itself.For example, block 5 of a user-to-user message, sent with an authentication trailer and checksum trailer, may appear as:

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

9601 2-12


13/15


SWIFT Character Set

CBTs communicating with SWIFT use EBCDIC code. The character set is as follows:

a b c d e f g h i j k l m n o p q r s t u v w x y zA B C D E F G H I J K L M N O P Q R S T U V W X Y Z0 1 2 3 4 5 6 7 8 9/ - ? : ( ). , ' + {}Cr Lf Space

All alphabetic characters in all headers, and in text of user-to-system messages, must be in upper case. The system does notrecognize lower case letters as equivalent to upper case.Although part of the character set, the curly brackets are only permitted as delimiters and cannot be used within the text of user-to-user messages.

9601 2-13


14/15


15/15

ISITC SAMPLE MESSA

ISITC FORMATSPECIFICATIONS

Message Text Blcok

:30:920116 X'OD25'

:20:5731C X'OD25'

:31P:911231PTC666666 X'OD25'

:35A:FMT83735,86 X'OD25'

:35B:/ACUS/362157F3 /ASEC/GNMA X'OD25'

/APN/1559868 X'OD25'

/AIR/9,0 X'OD25'

/AMD/160515 X'OD25'

:82D:ZBEST X'OD25'

:83C:/106843 X'OD25'

:87D:/4444 X'OD25'

AUTRANET X'OD25'

:88D:AFFILIATED ACCTS X'OD25'

:33T:USD106,210142 X'OD25'

:32B:USD89594,03 X'OD25'

:34G:USD314,01 X'OD25'

:34M:USD89305,02 X'OD25'

:72:/AORG/125000, X'OD25'

/AFCT/1,123456 X'OD25'

/APAY/PU X'OD25'

/ATXN/D X'OD25'

- } - End of Message Text Block

9601

Documents

SWIFT Message Structure