SWIFT & IntelliMATCH

SWIFT
Overview

Author:
Paramjeet Singh

1. Introduction
2. SWIFTReady
3. SWIFT Addresses
4. SWIFT Messages
5. SWIFTNet
6. SWIFT Reformatters
7. SWIFT Hands-On

2

01

• SWIFT stands for Society for Worldwide Interbank Financial
Telecommunications.
• It is a co-operative society.
• The objective 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 operates a worldwide financial messaging network which
exchanges messages between banks and other financial
institutions.

3

01

• The Society’s headquarters are situated in La Hulpe, on the
outskirts of Brussels.
• 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.
• SWIFT standards came in picture as Telex suffered from a
number of limitations due to its speed, its free format, and the
lack of security.
• Today, SWIFT is an industry-owned cooperative supplying secure
messaging services and interface software to over 7,000
financial institutions in 194 countries.

4

01

• 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.
• Currently the following categories of organization can access
the service:
1. Banks
2. Trading Institutions
3. Money Brokers
4. Securities Broker Dealers
5. Investment Management Institutions
6. Clearing Systems and Central Depositories
7. Recognized Exchanges
8. Trust and Fiduciary Service Companies
9. Subsidiary Providers of Custody and Nominees
10. Treasury Counterparties
11. Treasury ETC Service Providers

5

01

• 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.
• All classes of member pay an initial joining fee and an annual
support charge.
• Users are charged on a per message basis by Unit lengths of
325 or 1950 chars, dependent on message type.

6

01

SWIFT operates a number of services, primarily:
• 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.
• 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.

7

02
Scrum Introduction Across Industries (1)

• SWIFTReady labeling, introduced in 1998, provides a formula for
benchmarking third party products that interact with messages
that flow over the SWIFT network.
• SWIFTReady labels identify products that are SWIFT-compliant,
integrate efficiently in a SWIFT environment, increase traffic
automation and improve straight-through processing (STP).
• SWIFT annually recognizes solutions from independent software
vendors according to their compliance with SWIFT standards,
their efficient integration with the SWIFT environment, and their
contribution to improving industry STP.
• SunGard is a global leader in providing S.W.I.F.T.-enabled
solutions for straight-through processing. S.W.I.F.T. is
recognizing– through the several Gold and Silver ‘SWIFTReady’
labels - the value SunGard applications (intelliMATCH) offer to
the customers.

9

03

• 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),

11

03

General Format of SWIFT 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.
• 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.

12

03

• 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.
• The Logical Terminal ID in position 9 will be present in the header of the
message and identifies a logical channel connection to SWIFT.
• 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.

13

04

• 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.

• 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.

15`

04

The sequence in which the various parts of a SWIFT message are validated is
as follows:

{1: Basic Header Block}
{2: Application Header Block}
{3: User Header Block}
{4: Text Block}
{5: Trailers Block}

Note: 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.

16

04

• 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.
• The type of SWIFT message will determine the maximum length allowed for the
particular 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 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.

17

04

The following is an example of a basic input header:

{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)

18

04


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

• "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).

19

04


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

• "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)

20

04

Application Header – Input: For input messages, the application header describes the
type of message, whom it is for and how it should be sent.
{2: I 100 BANKDEFFXXXX U 3 003}
A B C D E F G
• "A" Block Identifier
• "B" Input/Output Identifier
• "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.
• "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

21

04

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.
{2: 0 100 1200 910103BANKBEBBAXXX2222123456 910103 1201 N}
A B C D E F G H
• "B" Input/Output Identifier
• "C" Message Type
• "D" Input Time: The input time (HHMM) is expressed in the sender's local time.
• "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.
• "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)

22

04

• 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.
{3: {113:9601} {108:abcdefgh12345678}}

A B C

• "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.

23

04

An example of the text block in a typical FIN user-to-user message follows:
{4:
: 20: PAYREF- TB54302
: 32A:910103BEF1000000,
: 50: CUSTOMER NAME
AND ADDRESS
: 59:/123-456-789
BENEFICIARY NAME
AND ADDRESS
-}
• All Swift Text Messages have a maximum of 35 characters per line.
Note: This is the block we usually map with, in intelliMATCH.

24

04

• 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.

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}}

25

04

CBT’s (computer-based terminal) communicating with SWIFT use EBCDIC code. The
character set is as follows:

a bcd ef g hi jk l mn op q r s tu v wx yz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0123456789
/ - ? : ( ). , ' + {}
Cr Lf Space

26

04

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

SWIFT Message Types:

27

05

• SWIFTNet is the latest version of SWIFT, which operates using Internet
Protocols, but still as a private network.
• It does not use the World Wide Web. It uses the same high level of
security based on Public Key Infrastructure that was used on the older
network, but now provides banks with a number of newer services,
some of which are browser-based.

29

05
SWIFTNet provides the banks with following services:
• SWIFTNet InterAct Realtime: is a protocol designed and supported by
SWIFT. The protocol is used to exchange financial messages between
organizations connected to services on the network (using XML
standards )
• SWIFTNet InterAct Store and Forward: is a protocol designed and
supported by SWIFT. The protocol is used to exchange financial
messages between organizations connected to services on to the
network (using XML standards ). SWIFT stores the message centrally,
removing the need for the sender and receiver to be connected to the
network simultaneously, unlike SWIFTNet InterAct Realtime.
• SWIFTNet FileAct Realtime: the exchange of bulk messages (e.g. non-
urgent and low value payments)
• SWIFTNet FileAct Store and Forward: the exchange of bulk messages
(e.g. non-urgent and low value payments). SWIFT stores the message
centrally, removing the need for the sender and receiver to be
connected to the network simultaneously, unlike SWIFTNet FileAct
Realtime.
• SWIFTNet Browse: a secure browser for accessing account information
• Online payment initiation, payment tracking and status reporting (e-
Payments plus)

30

06

There are three types of Reformatters available in intelliMATCH:

1. Swiftcpp.rfm: To create an import format for MT 100, 900, 910, 940, or 950, select
the SWIFTCPP reformatter. It is utilized to process Cash Statement and Advice
messages.
Reformats SWIFT Cash message data to a fixed-column width, space-delimited
data file.
The optional parameters for this reformatter are:
• -FlagRejects=Y: This option writes records normally sent to the *.ERR file to
the output file (.rfo file); those records have the text string “reject” appended.
You can also map the reject string so Recollector immediately writes all
rejected items to a batch file.

Note: The records with string ‘Reject’ will not be imported.

• –Bal62to64=Y: This option creates a Tag 64 from Tag 62 if one does not exist.

32

06

2. AllSwift.rfm: To create an import format for MT 103, 192, 202, 292, 320, 340, 341,
515, 535, 536, 540, 540-548, 574, 579, 971, select the ALLSWIFT reformatter.
Reformats all SWIFT messages by determining the type of message, then applying
the appropriate reformatting instructions.
Optional parameters in the form of SWIFT message numbers can be listed to direct
the reformatter to only process specified message types. If no parameters are
specified, all support messages will be processed.

3. Tradeswift2.rfm: Reformats a SWIFT data file’s securities messages to a fixed-
column width, space-delimited data file. This reformatter does not require any
parameters.

33

06

The ALLSWIFT or SWIFTCPP reformatter reads your SWIFT file and:
• Removes non-printable characters (such as carriage returns and tabs)
• Interprets SWIFT codes as tags
• Concatenates multi-line fields (without carriage returns) and re-writes them on a
single line
• Re-writes the data in a fixed-column-width, space-delimited format that
Recollector can read
• The output file of the reformatter has the .RF0 extension. It is this .RF0 file that
Recollector actually imports into the IntelliMATCH database.
• Once you have an .RF0 file for your SWIFT cash data, you can create a custom
import format based on the data’s layout.
• Recollector automatically creates an error file for each reformatter if the
reformatter determines that a SWIFT import file does not conform to SWIFT
standards. Use a text editor to view the error file.

34

06

Commonly used SWIFT Tags:

Tag Record Option Selected
20 Statement Reference (not Deselect all options
normally mapped)
25 Account No. Deselect all options
28 Statement No. and Page Deselect all options
No.
60 Opening Balance Deselect all options
61 Items Check ‘Add a record for this Tag’ check
box
62 Closing Balance Check ‘Add a balance for this Tag’ check
box

More Tags:

35

06

Basics:
• Earlier, with every new SWIFT message released, the Sungard was forced to write a
new reformatter to accommodate the new SWIFT file.
• With the release of AllSwift.rfm, it will determine the SWIFT message type that we
are reformatting, and then will open up the appropriate .ini file which will contain
the information on how to reformat the SWIFT file.

36

06

Determining the current swift message
The :20: section of the swift message contains the current message type. Our current
swift reformatters use the function GetMessageType to determine the current
function to call.
We will now use the information in the :20: section of the swift message to open an .ini
file of the same name and read in the formatting information.
e.g.,
:20:9400101178032602 = 940 message type. The file 940.ini would be opened.
The .ini file must be located in the same directory as the AllSwift.rfm reformatter.
Any swift message that we attempt to process and does not have an appropriate *.ini
file will fail.

37

06

The .ini file will have the following sections:
• Text Comments, version number and any changes made to the .ini
file.
• [TAG DATE] Instructs the reformatter how to format dates.
The tag date section has the heading [TAG DATE]. The entry for this section is Date=<date
format>, where <date format> is as follows:
%y = 2 digit year
%Y = 4 digit year
%d = day
%m = month
Using the formula %m/%d/%y would yield 03/05/01 for March 5, 2001.
• [HEADER] How to process information in the header.
HH2940
• [DEFAULT] Defines the number of characters for output if the function does not exist,
i.e. buffer.

38

06

• [TAG ORDER#] The order the tags will be read in the swift message, and whether the tags
are mandatory (M) or optional. (O).
A tag order entry is set up as follows:
<tag name (s)> M|O|# [<Default buffer>] [<function name (s)]
Tag name (s) refers to one or more tag names that may be present on this line. Tags should
begin and end with a semicolon. If a swift tag is defined as 83 A,C or D, then the tag name (s)
section would read :83A: :83C: :83D:
Immediately following the tag name (s) is a flag indicating whether the tag is mandatory,
optional or optional leading to a subsequence. The letter M indicates a mandatory tag, where
the reformatter will reject the message if the tag is missing. The letter O indicates a tag which
may or may not exist. A number indicates that this tag is optional, however if it exists then we
are to jump into the tag order section indicated by this number. If we have a repeating
sequence, then the number would be the same as the current tag order.
As an option you can set a default buffer for the function to be called by this tag. By using the
letter B followed by a number we will set up the default buffer. This will be explained in the Tag
Format section.
The function names will indicate what function to call to process this row. If this parameter is
empty, then we skip this row in the file. There must exist one function for each possible tag
name. Function names must start with the letter “F”. If there is more than one tag name then
the first tag name will call the first function, the second tag name will call the second function
and so on.

39

06

Sample Tag Order Entries
:20: M F20 Tag :20: is mandatory and will be processed by function F20
:15B: O Tag :15B: is optional and will not be processed
:30V: 2 Tag :30V: is optional and will jump to tag order 2
:82A: :82D: M B9 FA FD Either Tag :82A: or :82D: is required, we jump to either function FA or FD and
use buffer 9 as the default buffer for this function.

• [TAG FORMAT] The function definition for each tag, which defines how to reformat a
particular Tag.
The tag format section of the .ini file describes the processing that will take place for each tag. Each
entry will have the function name and the function definition where the two are separated by a
space.

40

07

SWIFT Basics
 For SWIFT files, map formatter/attributes on tag-by-tag basis.
 Tags in SWIFT Cash files are 2 characters long; usually they are 2-3 characters
long.
 MMO is Ledger (L) and Statement (S) indicator and is mandatory for SWIFT files.
 In .CSV files, we don’t have balances but in SWIFT files, we do have.
 In order to be SWIFT certified, one user-defined class is mandatory.
 ISN, ISIN, CDIN are indicators for Security ID.

42

07

Identify the Message Type (type of SWIFT File/Message to import) and Reformatter:

1. Swiftcpp.rfm: To create an import format for MT 100, 900, 910,
940, or 950, select the SWIFTCPP reformatter.
2. AllSwift.rfm: To create an import format for MT 103, 192, 202,
292, 320, 340, 341, 515, 535, 536, 540, 540-548, 574, 579,
971, select the ALLSWIFT reformatter.
3. TradeSwift.rfm: To create an import format for securities
messages.

43

07

Create a Formatter using the appropriate Reformatter:
1. Map all the mandatory fields

For Cash Items:
• Company
• Account
• Amount
• Class
• DCIP
• Date (posted/issue or available/paid)
• Serial number (check items only)

For Cash Balances:
• Account
• Balance
• Date
• Company
• Debit/Credit

44

07

2. Import Format Options:
 Set Tag Length to 2
 Strip Non-pintables

45

07

3. Apply the Reformatter:

46

07

4. Format Tags and Fields:
 Give Name of appropriate Tag
 Set Default Start Line
 Check ‘Add a record for this tag’

47

07

5. Field Map - Location:

Select the appropriate Tag from the drop down (for every field)

48

07

Import the data into IntelliMATCH
 Import the SWIFT file into intelliMATCH database

Matching
 Match the imported SWIFT file in intelliMATCH

49

Thank You!

Author:
Paramjeet Singh

SWIFT & IntelliMATCH

More Related Content

What's hot

Viewers also liked

Similar to SWIFT & IntelliMATCH

Recently uploaded

SWIFT & IntelliMATCH