AnaSys MessageObjects (R) - SWIFT-XML Class Library

Overview of SWIFTXMLnet

General Description
Message Templates
XSLT
Description of AnaSys SWIFT-XML Attributes

General Description

Purpose

SWIFT message formats are an international standard, which are being used not only on the closed banking networks, but also in contact with corporate and private customers on private networks or the Internet.
While the standards are well established and widespread, they are still not easy to implement. Typical problems are: misinterpretation of the handbook, difficulties in dealing with separators and optional fields (if the field does not exist, what happens to the separator?), cross-validation (contents of one field may impact contents of another field), identifying location of information (is this field 32B of Sequence A or field 32B of Sequence B?).
In the past couple of years XML has gained huge popularity for messaging, as it is a standardised syntax which is very well suited to address the above mentioned problems. SWIFT have also announced support for XML, but have as yet not actually published any of the existing message standards as XML (some new XML message types have been published for closed user groups on SWIFTNet).
The AnaSys MessageObjects suite contains all currently existing SWIFT FIN message types in a consistent XML notation (developed by AnaSys) and matching XSLT stylesheets for message creation, display, validation and conversion.

Usage

AnaSys MessageObjects can be integrated into interactive programs (especially browser-based applications) to add SWIFT-messaging capabilities to an application (or build a browser-based message-creation application to front-end a SWIFT-gateway solution.
MessageObjects can however, also be used to check/validate a batch of SWIFT-messages created by a host program (detection of faulty implementation) or to aid programmers in directly constructing valid messages in the background processing of existing applications.
Incoming SWIFT messages can be converted to XML to enable detailed analysis of the message, enable complex routing and reporting. In combination with an XML database the storage of SWIFT messages in XML notation enable highly complex message retrieval and management information capability.

See Also

General Description | Message Templates | XSLT | Description of AnaSys SWIFT-XML Attributes



Message Templates

XML and DTD

For each message type an XML-Document containing all possible fields (mandatory and optional) without any field values (just the empty structure) exists, it is therefore called "Message Template". For each message template a corresponding DTD (data type dictionary) exists which holds the information on mandatory/optional structures, permitted repetitions, data types, etc. (see Description of AnaSys SWIFT-XML Attributes for details). The default attributes in the DTD are not visible in the structure of the template, but they are there at run-time (when using a validating parser) - this makes the templates leaner and easier to read. All the MessageObjects XSLT stylesheets rely on the DTD being present and on a validating parser being used.

Besides the XML Message Templates some other useful XML information/lookup files are part of AnaSys MessageObjects, e.g. categories, message types, error codes, field codes, currencies, etc.

Naming Convention

The templates and DTDs are named tmtxxxx.xml and dmtxxxx.dtd where "xxxx" stands for the message type (please note that message types are usually from 000 to 999, but there are also message types 103+ and 102+).

Localization

The default language used for templates/DTDs is English. All other languages must add the language code to the file name as follows:
e.g. tmtxxxx_ar.xml and dmtxxxx_ar.dtd for Arabic.

See Also

General Description | Message Templates | XSLT | Description of AnaSys SWIFT-XML Attributes



XSLT

All AnaSys XSLT code conforms to the XSL Transformations (XSLT) Version 1.0 W3C recommendation dated November 16, 1999 and the XML Path Language (XPath) Version 1.0 W3C recommendation dated November 16, 1999. No platform-specific extensions have been utilized and all XSLT has been tested with MSXML30 upwards, .NET 1.0 upwards and Xalan 1.0.1. upwards to ensure platform independency.

Standard XSLT Utilities

The great benefits of XSLT are its portability and the fact that it is source code, which easily can be corrected, modified and distributed. The Standard AnaSys XSLT utilities have been designed to work on the AnaSys XML Message Templates and to cover a wide area of messaging requirements, such as:

Customized XSLT Utilities

As MessageObjects is highly modular and XSLTs are easily changed, the look and feel of a custom built application can easily be adapted to reflect corporate identity, include logos, build tailor-made data entry forms, etc. We request that clients who customize their version of MessageObjects please use different names for their files and ensure that they have backups of the original files. AnaSys cannot guarantee support and will not accept any liability for changed files. Change/enhancement requests can be placed with AnaSys electronically (support menu on www.anasys.com) - if the request is of general interest it will be incorporated in the next release, alternatively AnaSys will quote clients a price for building the utility to fit their requirements.

See Also

General Description | Message Templates | XSLT | Description of AnaSys SWIFT-XML Attributes



Description of AnaSys SWIFT-XML Attributes

Structure Description Attributes

SWIFT messages consist of fields, which can be grouped and structured in certain ways. In order to describe all currently known SWIFT message types, following structure elements have been identified and implemented as default attributes in the DTD by the AnaSys SWIFT object model:

OType
describes the type of the structure, values are:
"S" for sequences, such as in MT300, which has sequences A to D.
"G" for groups of either/or sequences or fields. Groups only exist in system messages (MT0nn).
"I" for iterations of repetitive rows, such as in MT300, sequence D, second item is iteration nr. 1 (iteration always contains one or more rows on the next lower level).
"R" for rows of fields inside an iteration (rows are always directly below an iteration)
"L" for lists of fields of the same field tag (but possibly different option and qualifier - is only applicable to ISO 15022 MTs and is a shown in the SWIFT User Handbook with the same notation as an iteration of a single field).
"O" for an either/or option of a field such as in MT300 for field nr. 9 in sequence A: either 82A, 82D or 82J.
"F" for a field without either/or option, such as in MT300 for field nr. 4 in sequence A: 22A.
Tag
describes the name of the structure / the field tag of a field, example of values:
For OType "G" the Tag is a capital letter (following OTypes "G" are numbered alphabetically).
For OType "S" the Tag on the top level is a capital letter (following OTypes "S" are numbered alphabetically as for OTypes "G", see MT300 sequences A to D). For OType "S" sub-structures can exist. The Tag of a (sub)sequence is always composed of the Tag of its parent (sub)sequence and a number or a letter, depending on the level of nesting:
(sub)sequences in a sequence are identified as follows:
"A1", "A2", ..., "B1", "B2", ...(see MT300, sub-sequence B1)
a (sub)sequence within a (sub)sequence is identified as follows:
"A1a", 'A1b", ... "C5a", ...
another (sub)sequence a level below is identified as follows:
"A1a1", "A1a2", ...
Currently there are no messages that contain a lower level of nesting. However, should it be necessary, the same principle would be continued.
For OTypes "I" and "L" the Tag is always a number (numbering is consecutive inside the same level, always starts with 1 on each level).
For OTypes "R" the Tag is always a number (numbering is consecutive inside the same iteration, always starts with 1 for each iteration).
For OTypes "O" the Tag is always the numeric field tag followed by the letter "a" to indicate that "a" can take different values in the range of capital letters "A" to "Z" (as in MT300 for field nr. 9 in sequence A: Tag="82a").
For OTypes "F" the Tag is the actual field tag, such as field nr. 1 in sequence A of MT300: Tag="15A".
Group
describes the parent of the current element, where "AA" always designates the top level. "AA_SA" designates sequence A, which is in turn child of top level. "AA_SD_I1" designates iteration 1, which is child of sequence D, which is child of top level.
Status
indicates whether the current element is mandatory or optional:
"M" if the element is mandatory in the context of its parent
"O" if the element is optional in the context of its parent
TextE
gives the description of the element as found in the SWIFT User Handbook (English is default - for other languages separate DTDs can be created).
Nr
designates the position of the element inside its parent. Especially import when parent is an iteration (can have more than 1 row beneath it).
Key
holds a unique key value for the element (for direct reference, especially important when creating data entry screens). All Keys are built according to the following rule:
For OTypes S, G, I, R, L, O: an expression starting with "AA_" followed by the OType and Tag of each ancestor, followed by the Nr of this element ("AA_SD_I1_R1_1" designates the first element in row 1 of iteration 1, which is child of sequence D which is child of top level).
Please note that the template always only contains the first row of an iteration, but when creating or mapping a message more rows may exist - in the above example the first element of the second row etc. would have Key "AA_SD_I1_R2_1".
SelOpt
Values are "Y" and "N".
SelOpt is an attribute that only exists for children of an element of OType "O". SelOpt="Y" signals that this element is the selected option, by default it is set to the first possible option (e.g. for field 32a, where a=A or B, the first child 32A has SelOpt="Y", the second child 32B has SelOpt="N").
Note: Children of OType="O" do not have an OType attribute.
XML element name
follows this rule:
for OTypes S, G, I the element name is the same as the Key
for OType R the element name is the same as the Key for row 1
for OTypes L, O and F the element name is always "Absnum" followed by the (absolute) number of the field inside the MT (same number as in the SWIFT User handbook in the right column).

SubField Description Attributes

SWIFT fields consist of subfields, which must follow certain syntactical rules, which are described by attributes in the AnaSys SWIFT object model.

SubField
is a numeric value starting with 1, which designates the position of the subfield inside the field.
Tag
For all subfields Tag is always the SWIFT tag as in the parent element (parent is either of OType="F" or does not have OType, because that is in turn a child of OType="O").
Format
contains the format description of the subfield in the (slightly modified) notation of the SWIFT User Handbook, such as "16x" or "4!c".
Exceptions to this rule:
Date/Time subfields have Format="yymmdd" etc., subfields containing BIC codes have Format="BIC" or "BIC12"
currencies have Format="CUR"
country codes have Format="CC"
CharType
is a valid character type according to the SWIFT notation:
"n" for numeric
"d" for amounts (numeric and decimal point - in XML we use "." for decimal point, it is translated to/from "," when creating/loading from SWIFT format)
"a" for capital letters
"c" for capital letters and numbers ("n" and "a")
"h" for hex values (0 to 9,A to F)
"s" for sign ("+" or "-")
"e" for space
"x" for all letters (upper and lower case), numbers, space, CrLf and / - ? : ( ) . , ' +
"y" for all letters (upper and lower case), numbers, space and . , - ( ) / = ' + : ? ! " % & * < > ;
"z" for all letters (upper and lower case), numbers, space, CrLf and . , - ( ) / = ' + : ? ! " % & * < > ; { @ #
Lines
Number of permitted lines (always 1 or more), e.g. when Format="4*35x" then Lines="4"
Length
The maximum permitted length of the subfield, e.g. if Format="16x", then Length="16". Where a multi-line subfield is being described, it is the maximum permitted line length, e.g. when Format="4*35x" then Length="35"
MinLength
The minimum required length of the subfield (in general either the same as Length or ="0")
LSep
is an optional attribute. If the beginning of a subfield is designated by a certain value, then LSep contains this value ("/", "//", "BR" for CrLf, "ISIN ", etc.). If the subfield is optional and is not present in the field, then the value for LSep is also not present (e.g. SWIFT notation [/4!c]).
RSep
is an optional attribute. If the end of a subfield is designated by a certain value, then RSep contains this value ("/", "BR" for CrLf, etc.). If the subfield is optional and is not present in the field, then the value for RSep is also not present (e.g. SWIFT notation [4!c/]).
TextE
is the description of the element as found in the SWIFT User Handbook (English is default - for other languages separate DTDs can be created).
Codes
is an optional attribute. If code values are foreseen for a subfield, then it is (usually) Codes="Y". The actual valid codes are found in the lookup file fieldcodes.xml.
For ISO 15022 MTs Codes can be a comma-delimited list of applicable qualifiers pertinent to this particular subfield (and it most always be subfield=1), e.g. Codes="CANC,MINI".
Qualifier
This attribute is optional, and it is only present in ISO 15022 MTs and then only when SubField="1". When Qualifier is present, it is the mandatory value for SubField="1" (the actual node value is, however, not filled because the field may be optional).
CodeText
This attribute is optional and only appears where the subfield uses a code, such as attribute Codes="Y" or Codes="CANC,MINI" or Format="BIC" or Format="CUR", etc. CodeText is empty in the DTD, except when Qualifier exists. CodeText is used to hold the description of the code (e.g. "SWISS FRANCS when Format="CUR" and node value="CHF"). CodeText is usually found in a lookup file (which may be language dependent). The purpose is for producing a readable display.
Key
Unique key of the subfield element (for direct reference, especially important when creating data entry screens). All Keys are built according to the following rule:
Key of the parent, as described in "Key" for structures, followed by "_", nr, "_", field tag, "_", subfield (e.g. AA_SD_I1_R1_1_17A_1 for subfield=1 of field 17A, which is the first field in row 1 of iteration 1 of sequence D).

See Also

General Description | Message Templates | XSLT | Description of AnaSys SWIFT-XML Attributes