Published on

SWIFT Overview, and working with IntelliMATCH

Published in: Economy & Finance
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. SWIFTOverview Author: Paramjeet Singh
  2. 2. 1. Introduction2. SWIFTReady3. SWIFT Addresses4. SWIFT Messages5. SWIFTNet6. SWIFT Reformatters7. SWIFT Hands-On 2
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 02 SWIFTReady
  9. 9. 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
  10. 10. 03 SWIFT Addresses
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 04 SWIFT Messages
  15. 15. 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`
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 04 The following is an example of a basic input header: {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
  20. 20. 04 The following is an example of a basic input header: {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 users 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 senders current input session or the OSN of the receivers current output session. ("000001" - ISITC) 20
  21. 21. 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" Recipients 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
  22. 22. 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 • "A" Block Identifier • "B" Input/Output Identifier • "C" Message Type • "D" Input Time: The input time (HHMM) is expressed in the senders 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 senders LT identifier and branch code, the senders session number and senders 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 receivers 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
  23. 23. 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 • "A" Block Identifier • "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
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. 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
  28. 28. 05 SWIFTNet
  29. 29. 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
  30. 30. 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
  31. 31. 06 SWIFT Reformatters
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. 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
  37. 37. 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
  38. 38. 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
  39. 39. 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
  40. 40. 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
  41. 41. 07 SWIFT Hands-On
  42. 42. 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
  43. 43. 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
  44. 44. 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
  45. 45. 07 2. Import Format Options:  Set Tag Length to 2  Strip Non-pintables 45
  46. 46. 07 3. Apply the Reformatter: 46
  47. 47. 07 4. Format Tags and Fields:  Give Name of appropriate Tag  Set Default Start Line  Check ‘Add a record for this tag’ 47
  48. 48. 07 5. Field Map - Location: Select the appropriate Tag from the drop down (for every field) 48
  49. 49. 07 Import the data into IntelliMATCH  Import the SWIFT file into intelliMATCH database Matching  Match the imported SWIFT file in intelliMATCH 49
  50. 50. Thank You! Author: Paramjeet Singh