Society for Worldwide Interbank Financial Telecommunications

SWIFT stands for Society for Worldwide Interbank Financial Telecommunications. It is a co-operative society. “The object of the Company is for the collective benefit of the Members of the Company, the study, creation, utilization and operation of the means necessary for the telecommunication, transmission and routing of private, confidential and proprietary financial messages”


SWIFT stands for Society for Worldwide Interbank Financial Telecommunications. It is a co-operative society. According to Article 3 of Articles of Association:

“The object of the Company is for the collective benefit of the Members of the Company, the study, creation, utilization and operation of the means necessary for the telecommunication, transmission and routing of private, confidential and proprietary financial messages”

SWIFT as an Organization

The Society’s headquarters are situated in La Hulpe, on the outskirts of Brussels. SWIFT also acts as a United Nations sanctioned International Standards Body (ISO) for the creation and maintenance of financial messaging standards.

SWIFT was formed when seven Major International Banks met in 1974 to discuss the limitations of Telex as a means of secure delivery of payment and confirmation information, primarily in the Treasury and Correspondent banking areas. Telex suffered from a number of limitations due to its speed (50 Baud or approximately 8 bytes per second), its free format (that made automation at the receiving end almost impossible), and the lack of security, with Test keys only being calculated on a subset of the message content.

Three years later in 1977, 230 banks in 5 countries went live. New countries and users were and indeed still are, added 4 times a year with recent figures showing over 184 countries and 6700 institutions connected.


Although originally the network was designed to support the requirements of Treasury and Correspondent banking operations, it has over the years allowed other institutions access to the services, albeit in some cases only to a limited degree. Currently the following categories of organization can access the service:



  Trading Institutions

  Money Brokers

  Securities Broker Dealers

  Investment Management Institutions

  Clearing Systems and Central Depositories

  Recognized Exchanges

  Trust and Fiduciary Service Companies

  Subsidiary Providers of Custody and Nominees

  Treasury Counterparties

  Treasury ETC Service Providers


The Society is owned by its Members, and in order to become the member of the organization one must hold a Banking License. In return Members own shares in the society and have voting rights.

There are a further two classes of user:

a) Sub – members must be >90% owned by member and are typically branches. Whilst they have full access to the system they do not have voting rights or shares.

b) Participants are usually other types of financial institution, and they have access to a limited set of messages and no ownership.

All classes of member pay an initial joining fee and an annual support charge, although the amounts differ for each class. In addition users are charged on a per message basis by Unit lengths of 325 or 1950 characters dependant on message type. The charges also vary depending on Volume tier and Route with the amounts reducing for high volume users and those messages passing along the most common routes such as U.K. to U.S.A.

Market Distribution (Year 2002)






Payment **












Trade Finance













Regional Distribution (Year 2002)






















Middle East









SWIFT Services

SWIFT operates a number of services, primarily:

1) GPA: General Purpose Application, which only allows system messages, i.e.    Messages from a user to SWIFT and vice versa, not from one user to another.

2) FIN: Financial Application, which is the user to user service comprising, System Messages MT0nn, User to User Messages MT1nn through 9nn and Service Messages such as Acknowledgements.

Additionally, SWIFT provide a number of services that are charged for over and above the normal fees. In summary these are:

3) IFT (Interbank File Transfer): For bulk file transfer of messages, for example low net value, high volume Retail payments.

4) ACCORD: A centralized confirmation matching bureau service.

5) Directory Services: An automated and centralized Standard Settlement Instruction service for message enrichment that at present is limited to Treasury and Payment information.

6) RTGS (Y-copy): Mostly used for sending a copy of a message or parts thereof to a third party, for example a Central Bank.

7) Country Specific (e.g. CREST, CHAPSEuro): Where SWIFT is either the carrier of the messages or the supplier of additional network services

SWIFT Addresses

SWIFT addresses are used to not only indicate the final destination of the message but to also indicate parties within the individual message. It is the use of strictly codified addresses that enables the automation of Straight through Processing in conjunction with the fixed tag format of the messages themselves. The term “SWIFT address” actually only relates to a subset of Bank Identifier Codes (BICs), in other words you do not have to be a user of the SWIFT network to have a BIC and these can therefore be used over other networks such as Telex. SWIFT is, however, the recognized ISO (International Standards Organization) body for assigning these.


The following shows the general format of a BIC address

AAAA                BB                    CC                    (D)       (EEE)

Bank                 Country            Location            LT         Branch


  • The first four characters represent the Bank code, for example NWBK (NatWest), DEUT (Deutsche Bank).
  • The next two characters represent the ISO Country code, for example GB (United Kingdom), DE (Germany).
  • The next two characters are the location code with some larger financial centers such as London and New York having two, 2L and 22, 33 and 3N respectively.
  • These characters, the first 8, represent the mandatory portions and commonly within the body of a message this will be the normal format, for example NWBKGB2L (NatWest London), DEUTDEFF (Deutsche Bank Frankfurt).
  • The presence of 0 (zero) in position 8 indicates that this is a test & training address. Test & Training is a facility which SWIFT gives its users to test new releases without interfering with live operations. When an organization first joins SWIFT they must spend two months sending messages in test & training before they are allowed to go live. SWIFT monitor this!
  • Optionally a three character branch code can be added at the end of the address. For example NWBKGB2LBIR might be the Birmingham branch. These codes are primarily used for internal routing purposes within the bank, as the branches themselves do not have direct connection. Usage is often more common in some countries than others such as the heavy use by Italian banks.
  • The Logical Terminal ID in position 9 will be present in the header of the message and identifies a logical channel connection to SWIFT. Some organizations may run more than 1 LT on the same CBT and these will be referred to as A, B, C, etc. For example NWBKGB2LA. These are not published in the BIC directory and so all addresses within a message identifying the sender or other parties will not contain this character.
  • LTs will therefore always be padded out to 12 Characters by X’s and SWIFT addresses are therefore either 8 or 11 characters.
  • The presence of a 1 in position 8 denotes that this is not a SWIFT address but the organization has requested that an ISO identifier be allocated to them. For example NWBKGB21. Therefore, this address can be included in the body of a message but you cannot send a message via SWIFT to them.
  • The presence of an X in position 8 denotes that the CBT which is processing traffic for this address is not physically in the same country as the Country Code states.


    SWIFT Messages

    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 which controls the user to user messaging facilities within SWIFT ) – which together provide all of the messaging functions and facilities available to users.

    Actual appearance of a SWIFT message (whether on screen or on paper) is dependent upon how their CBT (computer-based terminal) has been programmed and on any internal processing of SWIFT messages carried out within their own organization.

    A validation error in the application header, text or trailer block will result in a negative acknowledgment (NAK) indicating the reason for rejection.

    Each message received by the system is examined to determine whether it conforms to the format specification for that message type.

    The 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.   Text

    5.   Trailers

    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.

    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 for a 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 the message 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.


    Length of a Message

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


    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 and Line Feed (CrLf) and ends with CrLf followed by a hyphen (-).  Each field within the text begins with a tag number followed by a colon, 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 and with 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 each example.

    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-user messages, 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 is relative 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 the FIN application.


    but for clarity the components are shown separately:

    {1:    F        01      BANKBEBBAXXX     2222  123456}

    A        B        C       D                          E        F


  • “A” Block Identifier: Block identifier for a basic header block is always “1:”.
  • “B”       Application Identifier: The application identifier identifies the application within which the  message is being sent or received. The available options are:

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

    o   A=GPA (most GPA system messages and commands)

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

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

    o   User-to-user message

    o   System message

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

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

  • “D”      LT Address: This 12-character SWIFT address, given in the basic header block, is the address of the sending LT (for input messages) or of the receiving 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 which the message is being transmitted (i.e. the sending LT for input messages or the receiving LT for output messages).

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

      Bank (Financial Institution) Code      4 Characters

      Country Code                                    2 Characters

      Location Code                                   2 Characters

      Logical Terminal Code                       1 Character

      Branch Code                                     3 Characters    

  • “E”      Session Number: The session number identifies the session in which the message was transmitted.  Within the basic header, the session number (four digits) 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’s current output session. (“000001” – ISITC)

    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 FIN message and whether the application header is attached to an input message or to a output message.

    Application Header – Input: For input messages, the application header describes the type of message, whom it is for and how it should be sent. 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 the FIN application:


    {2:    I        100    BANKDEFFXXXX     U       3        003}

      A     B       C        D                          E       F         G


  • “A”     Block Identifier: The block identifier for an application header block is always “2:”.
  • “B”     Input/Output Identifier: The input/output identifier consists of a single letter – either “I” for an input message or “O” for an output message.
  • “C”     Message Type: The 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 Address: This address is the 12-character SWIFT address of the recipient of the message, but with a Logical Terminal Code of “X”.  If defines the destination to which the message should be sent.

    o   A SWIFT address which will be assigned by SWIFT administration is comprised of the following:

      Bank (Financial Institution) Code  4 Characters

      Country Code                      2 Characters

      Location Code                      2 Characters

      Logical Terminal Code          1 Character

      Branch Code                        3 Characters

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

    o   Institutions 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 Priority: This character (used within FIN application headers only) defines the priority by which a message shall be delivered.  The possible values are:

             S = System

             U = Urgent

             N = Normal

    Message priority “S” must be used for user-to-system messages:  for user-to-user messages either “U” or “N” may be used.

    Application Header-Output: For 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 within the FIN Application:


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


  • “A”      Block Identifier: The block identifier for an application header block is always “2:”.
  • “B”      Input/Output Identifier: The input/output identifier consists of a single letter – either “I” for an input message or “O” for an output message.
  • “C”     Message Type: The message type consists of three digits which define the MT number of the message being output.  The example used above is for a Customer Transfer (MT 100).
  • “D”     Input Time: The input time (HHMM) is expressed in the sender’s local time.  If the message is a system message, the input time is the time the message 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 the date the message was input (local to the sender), the sender’s LT identifier and branch code, the sender’s session number and sender’s ISN. 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.  The date given in the system MIR is the generation date in GMT.
  • “F”     Output Date: The output date (YYMMDD) is the date local to the receiver.
  • “G”     Output Time: The 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)


    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.  This header 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 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 and on 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                  


      “A”      Block Identifier: The block identifier for a user header block always has the value “3:”.

      “B”  ISITC Version Identifier: A version/release represents a snapshot in time of the status of the development and maintenance efforts of ISITC as of a specified date.  Up to two releases per year may be approved for implementation and are identified by version control numbers.  Tag 113 is used 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 version number (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 permitted character 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, but only on the system’s storage media, and may be used for retrieval of the messages if the alphabetic characters contained in the TRN were in uppercase.  The TRN will never be output as an MUR.

    Text Block

    The text of a SWIFT message (where applicable) is given in block 4 of a SWIFT message. An example of the text block in a typical FIN user-to-user message follows:


    : 20: PAYREF- TB54302

    : 32A:910103BEF1000000,



    : 59:/123-456-789





    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 be uppercase.

    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}



    {104: U}}

    (Note that the text block will be transmitted as a continuous string of characters without CrLf or blank characters inserted.  In the above 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 line must begin with the “//” continuation character.

    e.g.    :35B:678901234567890123456789012345CrLf

    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 block delimiters. 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}}

    SWIFT Character Set

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

     b c d  e f   h i  j k   m n  o p     t u   w x  y z

    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 Z

    0 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 not recognize 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 message.

    SWIFT Messages – Type of Messages

  1. Category 1 (MT1XX) – Customer transfers and cheques
  2. Category 2 (MT2XX) Financial institution transfers
  3. Category 3 (MT3XX) Treasury markets
  4. Category 4 (MT4XX) Collections & cash letters
  5. Category 5 (MT5XX) Securities
  6. Category 6 (MT6XX) Precious metals and syndications
  7. Category 7 (MT7XX) Documentary credits/guarantees
  8. Category 8 (MT8XX) Travelers cheques
  9. Category 9 (MT9XX) Cash management & customer status
  10.  Category 0 (MT0XX) System Messages


    SWIFT FIN Messages



    MT1XX – Customer Financial Transfers

  • MT1XX Series – One party to the Financial Transfer    i.e. Remitter or Beneficiary, or both parties, must be non-bank (Corporates, FIs etc.)
  • MT 103 – Single Customer Transfer
  • MT 103+ – Single Customer Transfer (strict format for STP – indicated for ‘STP’ through Tag 119 🙂
  • MT102 – Multiple Customer Transfers
  • MT104 – Direct Debit / Request for Debit Transfer
  • MT101 – Closed User Group (CUG Message)

    MT2XX – Bank – to – Bank Transfers

  • MT2XX – Inter-bank Messages, both parties, Remitter and Beneficiary must be Banks (FIs)
  • MT200 – Own Account Financial Transfer
  • MT201 – Multiple Own Account Financial Transfer
  • MT202 – General Financial Institution Transfer
  • MT203 – Multiple General Financial Institution Transfer
  • MT204 –Financial Market Direct Debit Message
  • MT210 – Pre-advice of Credit

    MT9XX – Cash Management & Reporting Statements

  • 9XX Series – includes advices (Debit/Credit) and Reports (Balance, Account Statement)
  • MT900 – Advice of Debit
  • MT910 – Advice of Credit
  • MT950 – (Account) Statement Message (Final/EOD)
  • MT940 – Customer Statement Message
  • MT941 – Balance Report
  • MT942 – Interim  Transaction Report

    SWIFT FIN Messages – Payment Process Flow (Step-wise)

    A Typical corporate to corporate FCY payment would flow as follows

          Customer Sends Payment Instruction to his Bank Branch

          Branch forwards instruction to Bank SWIFT service branch

          Customer branch sends a (Direct) Advice – MT 103 – to the Beneficiary Bank

          Service branch instructs the payment (bank-to-bank) to his Currency Correspondent (Sender’s Correspondent)

          Correspondent transfers funds to the Beneficiary Bank’s Currency Correspondent (typically through the local clearing in the instruction currency)

          Beneficiary Bank’s Correspondent pays funds to the Beneficiary Bank country/regional SWIFT service branch

          SWIFT service branch credits funds to Beneficiary bank branch’s books and sends a credit advice

          Beneficiary Bank branch credits the Beneficiary A/c and sends an advice to the Beneficiary

          Currency Correspondent sends an EOD Account Statement to the Beneficiary Bank Service Branch

    Pre-advice of credit (MT210)

          Beneficiary Bank Branch on receipt of the direct may send a MT210 to its Correspondent

          Similarly, Beneficiary Customer may send a pre-advice of credit to his Bank Branch


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s