Specification

XML Library
MessageMaker™ v5.3
© 2004 Synergy Financial Systems Limited
Disclaimer
All rights reserved. This document is confidential and propriety to Synergy Financial Systems, Ltd.
No part of this document may be produced or disclosed in any form or by any means - graphic,
electronic, or mechanical, including photocopying, recording, taping, or information storage and
retrieval systems without written permission of Synergy Financial Systems, Ltd.

Synergy Financial Systems, Ltd. shall have no liability for any loss or expense whatsoever relating to
the accuracy of the information furnished herein or for the use thereof or for omissions therein. The
reader agrees not to hold Synergy Financial Systems liable for loss or expense from any and all
causes including without limitation, negligence, tort, contract, or other causes.

Implied warranties of merchantability and fitness for a particular purpose and all other warranties,
either expressed or implied, shall not apply to any aspect of this document.

© 1999 - 2004 Synergy Financial Systems Limited. All rights reserved.

Document History

Details Author(s) Date Version

Created Anthony Dodd 22/04/2004 1.0

Contents

CHAPTER 1 - XML LIBRARY. .......................................................................................................................... 1

1.1 OVERVIEW ......................................................................................................................................... 1

1.2 BASIC HEADER BLOCK ........................................................................................................................ 3
1.2.1 Basic Header Block - XML....................................................................................................... 4
1.3 APPLICATION HEADER BLOCK ............................................................................................................. 6
1.3.1 Application Header Block - Input ............................................................................................. 6
1.3.2 Application Header Block - Output .......................................................................................... 8
1.3.3 Application Header Block - XML.............................................................................................. 9
1.4 USER HEADER BLOCK ...................................................................................................................... 13
1.4.1 User Header Block - XML...................................................................................................... 14
1.5 TRAILER BLOCK ................................................................................................................................ 16
1.5.1 Trailer Block - XML ................................................................................................................ 16
1.6 SYNERGY CUSTOM BLOCK ................................................................................................................ 17
1.6.1 Synergy Custom Block - XML................................................................................................ 17
1.7 TEXT BLOCK ..................................................................................................................................... 18
1.7.1 The Body of the Text Block ................................................................................................... 18
1.7.1.1 Field Construct................................................................................................................................. 20
1.7.1.2 Options Construct ............................................................................................................................ 25
1.7.1.3 List Construct................................................................................................................................... 26
1.7.1.4 Sequence/Subsequence Construct ................................................................................................. 27
1.7.1.5 Repetitive Sequence Construct ....................................................................................................... 28
Chapter 1 - XML Library.
1.1 Overview

The XML Library was designed to model all aspects of the set of messages defined in the SWIFT
FIN Service description as User-to-User Messages.

User-to-user messages fall into distinct categories to be used for different types of financial
transactions. Individual Message Types (MTs) are identified by a 3-digit number. The first digit
identifies the category of message. There are 9 categories of financial messages, each referring to a
different general usage:

Category 1 Customer Transfers

Cheques
Category 2 Financial Institution Transfers
Category 3 Treasury Markets
Foreign Exchange, Money Markets & Derivatives
Category 4 Collections
Cash Letters
Category 5 Securities Markets
Category 6 Precious Metals
Syndications
Category 7 Documentary Credits
Guarantees
Category 8 Travellers Cheques
Category 9 Cash Management
Customer Status

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 a 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 : is always
the first character 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: TRAILER BLOCK}

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, that is blocks within blocks, or fields delimited by field
tags, depending on the nature of the message.
Message Maker r© v5.3 1
Specification XML Library
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. All user-to-user messages contain Blocks 2, 4, and 5.

The basic structure of each message in the XML Library is as follows

<Top Standards="2003" Trademark="(c) 2003 Synergy Financial Systems Ltd">

<Header>
<Block1>Basic Header Block</Block1>
<Block2>Application Header Block</Block2>
<Block3>User Header Block</Block3>
<Extension>Synergy Custom Block</Extension>
</Header>
<MTrich>Text Block</MTrich>
<Trailer>Trailer</Trailer>
<History>Audit Trail/History</History>
</Top>

We’ll start by detailing the header and trailer blocks, blocks 1-3 and 5 and finish by detailing block
4 the Text Block which poses most of the design issues.

Message Maker r© v5.3 2

Specification XML Library
1.2 Basic Header Block

The Basic Header is given in Block 1 of a SWIFT message and is the only header that appears on
all messages. The Basic Header provides the fundamental reference for any particular message and
is almost always automatically built by the CBT.

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 FIN:

{1:F01BANKBEBBAXXX2222123456}

The components can be separated as follows:

{1: F 01 BANKBEBBAXXX 2222 123456}

(a) (b) (c) (d) (e) (f)

Block Identifier
The Block Identifier for a Basic Header Block is always '1:'.

Application Identifier
The Application Identifier identifies the application within which the message is being sent or
received. The available options are:

F = FIN All user-to-user, FIN system and FIN service messages

A = GPA Most GPA system and service messages
L = GPA Certain GPA service messages, for example, LOGIN, LAKs, ABORT

These values are automatically assigned by the SWIFT system and the user's CBT, but the user
should be aware of their existence and significance. Here we’re only concerned with those
messages with an Application Identifier that tells us the message is for the FIN application.

Service Identifier
The Service Identifier consists of 2 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:

• a user-to-user message
• a system message
• a service message, for example, a session control command, such as SELECT, or a logical
acknowledgement, such as ACK/SAK/UAK.

Here we will be primarily concerned with identifier '01' which applies to all GPA and FIN system
and user-to-user messages. Other values include: '21' for message acknowledgements such as
ACK/NAK, UAK/UNK, '03' for SELECT commands, and so on. For full details, see the FIN
System Messages module of the SWIFT User Handbook.

Message Maker r© v5.3 3

Specification XML Library
LT Identifier
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 LT for output messages, and includes the Branch Code.

In the Basic Header, the LT Code within the LT Identifier is specific to the LT that has established
the session in which the message is being transmitted, that is the sending LT for input messages or
the receiving LT for output messages.

Session Number
The Session Number identifies the session in which the message was transmitted. Within the Basic
Header, the 4-digit Session Number is the user's current GPA or FIN Session Number.

Sequence Number (ISN or OSN)

The sequence number always consists of 6 digits. It is the ISN of the sender's current input session
or the OSN of the receiver's current output session.

1.2.1 Basic Header Block - XML

The XML format of this block is as follows, it has been populated with the data in the above
example.

<Block1 APDU="F" SequenceNo="123456" ServiceId="01" SessionNo="2222">

<LTId1
CharType="c" CodeText=""
Format="{SWIFTLT}"
Key="LTId1"
Length="12"
Lines="1"
MinLength="8"
TextE="Address">BANKBEBBAXXX</LTId1>
</Block1>

Attribute Description

Block1
APDU The Application Identifier identifies the application within which the
message is being sent or received. The available options are:

F = FIN All user-to-user, FIN system and FIN service messages

A = GPA Most GPA system and service messages
L = GPA Certain GPA service messages, for example, LOGIN,
LAKs, ABORT

SequenceNo The sequence number always consists of 6 digits. It is the ISN of the
sender's current input session or the OSN of the receiver's current
output session.

Message Maker r© v5.3 4

Specification XML Library
 Attribute Description
ServiceId The Service Identifier consists of 2 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:

• a user-to-user message
• a system message
• a service message, for example, a session control command,
such as SELECT, or a logical acknowledgement, such as
ACK/SAK/UAK.

Here we will be primarily concerned with identifier '01' which

applies to all GPA and FIN system and user-to-user messages. Other
values include: '21' for message acknowledgements such as
ACK/NAK, UAK/UNK, '03' for SELECT commands, and so on.
For full details, see the FIN System Messages module of the SWIFT
User Handbook.

SessionNo The Session Number identifies the session in which the message was
transmitted. Within the Basic Header, the 4-digit Session Number is
the user's current GPA or FIN Session Number.

LTId1
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 LT for output messages, and includes the Branch Code.

See field construct.

Message Maker r© v5.3 5

Specification XML Library
1.3 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. It differs according to whether
the message is a GPA or a FIN message and whether the Application Header is part of an input or
an output message.

1.3.1 Application Header Block - Input

For input messages, the Application Header describes the type of message, its addressee 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 FIN:

{2: I 101 BANKDEFFXXXX U 3 003}

(a) (b) (c) (d) (e) (f) (g)

Block Identifier
The Block Identifier for an Application Header Block is always '2:'.

Input/Output Identifier
For an input message, the Input/Output Identifier consists of the single letter 'I'.

Message Type
The Message Type consists of 3 digits which define the MT number of the message being input.
The example used above is for an MT 100 Customer Transfer.

Receiver's Address
This address is the 12-character SWIFT address of the receiver of the message, but with a LT Code
of 'X'. It defines the destination to which the message should be sent.

The system will replace the 'X' with a specific LT Code on delivery of the message according to the
delivery control exercised by the receiving user.

The Branch Code is mandatory and will be validated. The default of 'XXX' may be used, as in the
example above.

Unless otherwise documented, system messages addressed to the SWIFT system itself should be
addressed to SWFTXXXXXXXX.

Message Priority
This character, used within FIN Application Headers only, defines the priority with which a
message is delivered. The possible values are:

S = System (Not currently available)

Message Maker r© v5.3 6

Specification XML Library
U = Urgent
N = Normal

Message Priority 'S' must be used for user-to-system messages; for user-to-user messages either 'U'
or 'N' can be used. In the absence of user-specified delivery criteria, system messages are always
delivered first, followed by urgent priority messages and then normal priority messages.

Delivery Monitoring
Delivery monitoring options apply only to FIN user-to-user messages, and allow the sender of a
message to request:

automatic MT 011 Delivery Notification once the message has been delivered

automatic MT 010 Non-Delivery Warning if a message is not delivered within the specified
obsolescence period (see below)

both, or neither, options. This may be requested on an individual message basis.

The chosen option is expressed as a single digit:

1 = Non-Delivery Warning
2 = Delivery Notification
3 = Non-Delivery Warning and Delivery Notification.

If the message has priority 'U' then the user must request delivery monitoring option '1' or '3'. If the
message has priority 'N', the user can request delivery monitoring option '2', or, by leaving the
option blank, no delivery monitoring.

Obsolescence Period
The obsolescence period defines the period of time after which a Delayed Message (DLM) trailer is
added to a FIN user-to-user message when the message is delivered. For urgent priority messages, it
is also the period of time after which, if the message remains undelivered, a Non-Delivery Warning
is generated.

The values for the obsolescence period are 003 (15 minutes) for 'U' priority, and 020 (100 minutes)
for 'N' priority. An obsolescence period can only be specified when delivery monitoring has been
requested (option 1 or 3 for urgent priority messages, option 2 for normal priority messages). If no
delivery monitoring has been requested, and an obsolescence period is specified, the message will
be NAKed with error code H25.

GPA input Application Headers are similar to their FIN equivalents except that GPA messages do
not specify priority, delivery monitoring, or obsolescence period.

Message Maker r© v5.3 7

Specification XML Library
1.3.2 Application Header Block - Output

For output messages, the output Application Header defines the type of message, who sent it and
when, and when it was delivered.

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 FIN:

{2: O 100 1200 010103BANKBEBBAXXX2222123456 010103 1201 N}

(a) (b) (c) (d) (e) (f) (g) (h)

Block Identifier
The Block Identifier for an Application Header Block is always '2:'.

Input/Output Identifier
For an output message, the Input/Output Identifier consists of the single letter: 'O'.

Message Type
The Message Type consists of 3 digits which define the MT number of the output message. The
example used is for an MT 100 Customer Transfer.

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, according to
Greenwich Mean Time (GMT).

MIR
Every input message is assigned a unique MIR. This is a string of 28 characters which consists of
the date, local to the sender, when the message was input, and the sender's full SWIFT address,
Session Number and ISN.

If the output message is system generated, the system MIR will show a Pseudo-Logical Terminal
(PLT) address, for example, DYLRXXXXXXXX, 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, according to GMT.

Output Date
The Output Date (YYMMDD) is the date, local to the receiver, on which the message is delivered
to the receiver.

Output Time
The Output Time (HHMM) is the time, local to the receiver, at which the message is actually
delivered to the receiver.

Message Priority
The Message Priority, for FIN messages only, is repeated in the FIN output Application Header.

GPA output Application Headers are similar to their FIN equivalent except that for GPA the
Message Priority is not included
Message Maker r© v5.3 8
Specification XML Library
1.3.3 Application Header Block - XML

<Block2 Dir="I" InpDate=" " InpTime=" " MT="101" OutDate=" " OutTime=" "
SequenceNo=" " SessionNo=" ">
<LTId2 CharType="c" CodeText=" " Format="{SWIFTLT11}" Key="LTId2"
Length="11" Lines="1" MinLength="8"
TextE="Address">BANKDEFFXXX</LTId2>
<PrioDelMon CharType="c" Combo=" " Format="1!a[1!c]" Key="priodelmon"
TextE="Delivery Monitoring">U3</PrioDelMon>
<Obsol
CharType="n" Format="3!n" Key="obsol" Length="3"
Lines="1" MinLength="3" Status="O"
TextE="Obsolescence Period">003</Obsol>
</Block2>

Attribute Description

Block2
Dir For an input message, the Input/Output Identifier consists of the
single letter 'I' or ‘O’ respectively.

InpDate The input date, date, local to the sender, when the message was input.
This is extracted from the MIR. (Output Application Header)

InpTime 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, according to Greenwich Mean
Time (GMT). (Output Application Header)

MT The Message Type consists of 3 digits which define the MT number

of the message being input. The example used above is for an MT 100
Customer Transfer.

OutDate The Output Date (YYMMDD) is the date, local to the receiver, on
which the message is delivered to the receiver. (Output Application
Header)

OutTime The Output Time (HHMM) is the time, local to the receiver, at which
the message is actually delivered to the receiver. (Output Application
Header)

SequenceNo ISN extracted from the MIR. (Output Application Header)

SessionNo Session Number extracted from the MIR. (Output Application Header)

Message Maker r© v5.3 9

Specification XML Library
Attribute Description

LTId2 (Input Application Header)

This address is the 11-character SWIFT address of the receiver of the message. It consists of the 8
character BIC and 3 character Branch Code. It defines the destination to which the message should
be sent.

The system will replace the 'X' with a specific LT Code on delivery of the message according to
the delivery control exercised by the receiving user.

LTId2 (Output Application Header)

This address is the 11-character SWIFT address of the sender of the message. It consists of the 8
character BIC and 3 character Branch Code. It defines the destination to from which the message
was sent.

See field construct.

Message Maker r© v5.3 10

Specification XML Library
Attribute Description

PrioDelMon (Input Application Header)

Priority
This character, used within FIN Application Headers only, defines the priority with which a
message is delivered. The possible values are:

S = System (Not currently available), U = Urgent, N = Normal

Message Priority 'S' must be used for user-to-system messages; for user-to-user messages either 'U'
or 'N' can be used. In the absence of user-specified delivery criteria, system messages are always
delivered first, followed by urgent priority messages and then normal priority messages.

Delivery Monitoring
Delivery monitoring options apply only to FIN user-to-user messages, and allow the sender of a
message to request:

• automatic MT 011 Delivery Notification once the message has been delivered
• automatic MT 010 Non-Delivery Warning if a message is not delivered within the specified
obsolescence period (see below)
• both, or neither, options. This may be requested on an individual message basis.

The chosen option is expressed as a single digit:

1 = Non-Delivery Warning, 2 = Delivery Notification, 3 = Non-Delivery Warning and Delivery

Notification.

If the message has priority 'U' then the user must request delivery monitoring option '1' or '3'. If the
message has priority 'N', the user can request delivery monitoring option '2', or, by leaving the
option blank, no delivery monitoring.

PrioDelMon (Output Application Header)

Priority
This character, used within FIN Application Headers only, defines the priority with which a
message is delivered. The possible values are:

S = System (Not currently available), U = Urgent, N = Normal

Message Priority 'S' must be used for user-to-system messages; for user-to-user messages either 'U'
or 'N' can be used. In the absence of user-specified delivery criteria, system messages are always
delivered first, followed by urgent priority messages and then normal priority messages.

See field construct.

Message Maker r© v5.3 11

Specification XML Library
Attribute Description

Obsol
The obsolescence period defines the period of time after which a Delayed Message (DLM) trailer
is added to a FIN user-to-user message when the message is delivered. For urgent priority
messages, it is also the period of time after which, if the message remains undelivered, a Non-
Delivery Warning is generated.

The values for the obsolescence period are 003 (15 minutes) for 'U' priority, and 020 (100 minutes)
for 'N' priority. An obsolescence period can only be specified when delivery monitoring has been
requested (option 1 or 3 for urgent priority messages, option 2 for normal priority messages). If no
delivery monitoring has been requested, and an obsolescence period is specified, the message will
be NAKed with error code H25.

(Input Application Header)

See field construct.

Message Maker r© v5.3 12

Specification XML Library
1.4 User Header Block

The User Header is an optional header available within FIN for user-to-user messages only. It
appears in Block 3 of a SWIFT message, and allows users to provide their own reference within the
headers 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. Relevant parts of the User Header will be repeated in related system
messages and acknowledgements.

Block 3 may contain tag 113, defining banking priorities, and tag 108, which is a user reference.
The user reference part of the User Header may be used as one of the selection criteria when
retrieving a message.

The optional field tags 103 and 115 are also used in Block 3 for the FIN Copy service. The order of
tags, when present, is 103, 113, 108 and 115.

An optional field tag 119 can be included in Block 3 of certain messages to specify that different
validation rules are to be applied. Agreed code words in field 119 indicate what validation rules
SWIFT will apply. If field 119 is present, it should appear after field 108.

{3: {103:PDS} {113:xxxx} {108:abcdefgh12345678} {119:STP} {115:162220240696423,66}}

(a) (b) (c) (d) (e) (f)

Message Maker r© v5.3 13

Specification XML Library
1.4.1 User Header Block - XML

<Block3>
<BLOCK3_1 Absnum="1" Group="BLOCK3" Key="BLOCK3_1" Nr="1" OType="F"
Status="O" Tag="103" TextE="Service Code" href="/103.HTM">
<BLOCK3_1_1 Absnum="1" CharType="a" Format="3!a" Key="BLOCK3_1_1"
Length="3" Lines="1" MinLength="3" SubField="1"
Tag="103" TextE="Service Code"/>
</BLOCK3_1>
<BLOCK3_2 Absnum="2" Group="BLOCK3" Key="BLOCK3_2" Nr="2" OType="F"
Status="O" Tag="113" TextE="Bank Priority" href="/113.HTM">
<BLOCK3_2_1 Absnum="2" CharType="x" Format="4!x" Key="BLOCK3_2_1"
Length="4" Lines="1" MinLength="4" Status="O" SubField="1"
Tag="113" TextE="Banking Priority"/>
</BLOCK3_2>
<BLOCK3_3
Absnum="3" Group="BLOCK3" Key="BLOCK3_3" Nr="3" OType="F"
Status="O" Tag="108" TextE="MUR" href="/108.HTM">
<BLOCK3_3_1 Absnum="3" CharType="x" Format="8x" Key="BLOCK3_3_1"
Length="8" Lines="1" MinLength="0" Status="O" SubField="1"
Tag="108" TextE="MUR"/>
<BLOCK3_3_2 Absnum="3" CharType="x" Format="8!x" Key="BLOCK3_3_2"
Length="8" Lines="1" MinLength="8" Status="M" SubField="2" Tag="108"
TextE="MessageMaker Key">39D10680</BLOCK3_3_2>
</BLOCK3_3>
<BLOCK3_4 Absnum="4" Group="BLOCK3" Key="BLOCK3_4" Nr="4" OType="F"
Status="O" Tag="119" TextE="Validation Flag" href="/119.HTM">
<BLOCK3_4_1 Absnum="4" CharType="c" Format="8!c" Key="BLOCK3_4_1"
Length="8" Lines="1" MinLength="8" Status="O" SubField="1"
Tag="119" TextE="Validation Flag"/>
</BLOCK3_4>
<BLOCK3_5 Absnum="5" Group="BLOCK3" Key="BLOCK3_5" Nr="5"
OType="F" Status="O" Tag="115"
TextE="Payment Release Information Receiver"
href="/115.HTM">
<BLOCK3_5_1 Absnum="5" CharType="x" Format="32x" Key="BLOCK3_5_1"
Length="32" Lines="1" MinLength="0" SubField="1"
Tag="115" TextE="Payment Release Information Receiver"/>
</BLOCK3_5>
</Block3>

Message Maker r© v5.3 14

Specification XML Library
Attribute Description

Block3

BLOCK3_1
Tag 103 FIN Copy Service Code.

See standard field attribute list.

BLOCK3_2
Tag 113 Banking Priority

See field construct.

BLOCK3_3
Tag 108 Message User Reference (MUR)

The MUR is broken into two fields, the first can be supplied by the operator and is made up of 8
characters.

The second part of the MUR is reserved for use by MessageMaker™. MessageMaker™ uses this
field to hold the unique or primary key of the message.

See field construct.

BLOCK3_4
Tag 119 Validation Flag

See field construct.

BLOCK3_1
Tag 103 FIN Copy Service Code

See field construct.

Message Maker r© v5.3 15

Specification XML Library
1.5 Trailer Block

Trailers are added to a message for the following reasons:

• for control purposes

• to indicate that special circumstances apply to the handling of the message
• 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 3-letter code, followed by a colon, followed by the trailer information
itself.

For example, Block 5 of a user-to-user message, sent with a MAC and a Checksum Trailer, may
appear as:

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

One or more trailers may appear in Block 5 of a SWIFT message. Users are expected to take due
note of trailer information. This is especially important in the case of PDM and PDE trailers, in
order to avoid duplicate payments.

1.5.1 Trailer Block - XML

<Trailer>
<TrailerRec>
<TrailerType>MAC</TrailerType>
<TrailerText>417720873</TrailerText>
</TrailerRec>
<TrailerRec>
<TrailerType>CHK</TrailerType>
<TrailerText>123456789ABC</TrailerText>
</TrailerRec>
</Trailer>

Message Maker r© v5.3 16

Specification XML Library
1.6 Synergy Custom Block

The Synergy Custom Block has been provided to allow us to extend the message beyond the
SWIFT message format. Currently the block only supports the additional “Charge Code” field
which allows an organisation track costs against message processing, where each user via the
department or organisational unit to which their attached is allocated a charge code, which is
automatically appended to each message they create.

1.6.1 Synergy Custom Block - XML

<Extension>
<Extension_1 Absnum="1" Group="Extension" Key="Extension_1" Nr="1" OType="F"
Status="M" Tag="X01" TextE="Charge Code"
href="/X01.HTM">
<Extension_1_1 Absnum="1" CharType="c" Format="6c" Key="Extension_1_1"
Length="8" Lines="1" SubField="1"
Tag="X01" TextE="Charge Code"/>
</Extension_1>
</Extension>

Attribute Description

Extension

Synergy Custom Block

Extension_1
Charge Code (Optional).

See field construct.

Message Maker r© v5.3 17

Specification XML Library
1.7 Text Block

The Text Block is where the main content of the message is held. It contained within the MTrich
XML node which has the following format. The example given below is the MTrich node of an MT
543 “Deliver Against Payment” message.

<MTrich
Key="MTrich"
Length="10000"
MAC="Y"
MT="543"
Rules="E89,E92,E87,E70,E88,E99,E14,E52,E86,E08,E62,E84,E90,E93, ….."
Title="Deliver Against Payment">

…… body of message

</MTrich>

Attribute Description

MTrich
Key The id or unique identifier for the node “MTrich”.

length The maximum length of the message.

MAC Indicates whether a MAC (Message Authentication Code) trailer is

mandatory. The following simple rules apply, the following message all
require a MAC trailer.

• all messages in Categories 1, 2, 4, 5, 7 and 8

• MT 304
• all messages in Category 6 except MT 600, MT 601, MT 605,
MT 606, MT 607, MT 608 and MT 609

MT The Message Type (MT).

Rules The semantic validation rules which are applied to the components of this
SWIFT message.

Title The description of this message.

1.7.1 The Body of the Text Block

The body of the text block is made up of a collection of fields or tags, from here on in we’ll refer to
them as fields. SWIFT provide us with a number of permutations on the way these fields are laid
out in the body of the text block.

1. A body consisting of a collection of fields and options (a collection of mutually exclusive

fields). Each field is made up of a collection of subfields corresponding to the breakdown of
Message Maker r© v5.3 18
Specification XML Library
 the field within the SWIFT specification. An example of this type of message is an MT 111
“Request to Stop Payment of a Cheque”.

2. A message consisting of fields, options and lists (a repeated collection of fields, options and
further lists). An example of this type of message is an MT 210 “Notice to Receive”.

3. A message where the fields, options and lists are broken into sections referred to as
sequences. These sequences can be either mandatory or optional. An example of this type of
message is an MT 300 “Foreign Exchange Confirmation”.

4. A further complication is added where a sequence can be designated as holding fields,

options, lists and further sequences referred to as a subsequence. An example of this kind of
message is an MT 340 “Forward Rate Agreement Confirmation”.

5. Finally sequences and sub sequences can be designated as being repetitive. An example of
this kind of message is an MT 564 “Corporate Action Notification”.

Each of these structures needs to be represented in an XML format; the next section will discuss the
various constructs found in the Clarity Suite Message Maker XML Library for SWIFT FIN
messages.

Message Maker r© v5.3 19

Specification XML Library
1.7.1.1 Field Construct

Even the most basic message in the SWIFT FIN schema is made up a collection of fields which are
either mandatory or optional; in turn each field is made up of a series of optional and mandatory
subfields.

The following is an example of a field 51A from MT 101 “Request For Transfer”, it shows node
AA_SA_7_51A which defines the field with child nodes AA_SA_7_51A_1. AA_SA_7_51A_2 and
AA_SA_7_51A_3 which represent the 3 subfields of this field type. Where possible the subfields
should correspond to the description contained in the SWIFT documentation, but this may not
always be so as some subfields may pose complications which require a more subtle approach.

<AA_SA_7_51A Absnum="7" Group="AA_SA" Key="AA_SA_7_51A" Nr="7" OType="F"

Status="O" Tag="51A" TextE="Sending Institution"
href="/FINAL/US1M/Doc/AFF007.HTM#MT101-7-FIELD-51A">
<AA_SA_7_51A_1 Absnum="7" CharType="a" Format="{DC}"
Key="AA_SA_7_51A_1" LSep="/" Length="1" Lines="1" MinLength="1"
Status="O" SubField="1" Tag="51A" TextE="Debit/Credit Indicator"/>
<AA_SA_7_51A_2 Absnum="7" CharType="x" Format="34x" Key="AA_SA_7_51A_2"
LSep="/" Length="34" Lines="1" MinLength="0" Status="O" SubField="2"
Tag="51A" TextE="Party Identifier"/>
<AA_SA_7_51A_3 Absnum="7" CharType="c" Format="{BIC}"
Key="AA_SA_7_51A_3" LSep="BR" Length="11" Lines="1" MinLength="8"
SubField="3" Tag="51A" TextE="BIC"/>
</AA_SA_7_51A>

The important attributes here are the OType=”F” (Object Type ‘F’ield) on the field node and the
SubField attribute on each of the subfields, the value of the SubField attribute indicates the order of
the subfield within the field definition.

The following describes each of the attributes found in this kind of construct.

Attribute Description

Field Node e.g. AA_SA_7_51A

Absnum Absolute Number; represents the number of the fields as given in
the format specification for that message type.

Group The Key or suffix of the parent construct to which this field
belongs.

Key A unique identifier for the field construct.

Nr Represents the number of the fields as given in the format

specification for that message type. Similar to absolute number,
employed here for backward compatibility with older systems.

Message Maker r© v5.3 20

Specification XML Library
Attribute Description
OType Object Type, describes the object and the construct we’re
dealing with. The following are all the valid object types
recognised by Clarity Message Maker.

Object Type Description

F Field
I Iteration/List
O Option
R Row
S Sequence/Subsequence

Status Indicates whether the construct is optional or mandatory. “O”

implies optional, where as “M” employs mandatory.

Tag SWIFT field tag.

TextE A description of the field. The value in this attribute is used as a

key when looking up the localised version of this description.

Message Maker r© v5.3 21

Specification XML Library
Attribute Description

Subfield Node e.g. AA_SA_7_51A_1

Absnum Absolute Number; represents the number of the subfield’s parent
field or option construct as given in the format specification for
that message type.

CharType The character set supported by this subfield.

CharType Character Set

x ABCDEFGHIJKLMNOPQRSTUVWXYZ
0123456789<SPACE>
abcdefghijklmnopqrstuvwxyz/\\-?:(),.'+

y ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
abcdefghijklmnopqrstuvwxyz/\-<SPACE>?:(),.'+"=!%&*;<>

z ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789<SPACE>
abcdefghijklmnopqrstuvwxyz/\-?:(),.'+"=!%&*;<>@#{

c ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789

C ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789<SPACE>

e <SPACE>

h 0123456789ABCDEF

s +-

A ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz

B ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz0123456789

d 0123456789,

X ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789<SPACE>
abcdefghijklmnopqrstuvwxyz\-?:(),.'+

N N

w …. No character restriction, used in custom messages such as

Tested and Non-Tested Telex

Codes A list of code or qualifier values applicable to this field.

CodeError A comma separated list of text validation codes which are

enforced for this particular subfield.

Message Maker r© v5.3 22

Specification XML Library
Attribute Description
CodeText Holds a key to a localised description of a code or qualifier value.
Used when the field has a fixed code or qualifier value.

Digits The maximum number of digits allowed to the left of the decimal
place, normally used when dealing with exchange rates.

Format The format of the subfield, may indicate the type of functions to
be applied when validating the contents of the subfield..

Key A unique identifier for the subfield construct.

LSep Indicates a separator which occurs to the left of the subfield

separating this subfield from the next or end of field. A special
value of “BR” is used to indicate Carriage Return and Linefeed
(CrLf).

Length The maximum number of characters allowed in the subfield.

Where Length and MinLength are the same value this indicates
a fixed length field.

Lines The number of lines of text supported by the subfield.

Lookup Either “code” or “qualifier”; indicates that a code or qualifier

lookup should be provided to the operator when editing this field.

MinLength The minimum number of characters allowed in the subfield.

Where Length and MinLength are the same value this indicates
a fixed length field.

Qualifier A fixed value qualifier for the subfield, often found in ISO 15022
message formats.

RSep Indicates a separator which occurs to the right of the subfield

separating this subfield from the previous subfield or start of
field. A special value of “BR” is used to indicate Carriage Return
and Linefeed (CrLf).

Status Indicates whether the construct is optional or mandatory. “O”

implies optional, where as “M” employs mandatory.

In the absence of a Status attribute and mandatory status is

employed.

SubField The index or offset of the subfield within it’s parent field
construct.

Message Maker r© v5.3 23

Specification XML Library
Attribute Description
Tag SWIFT field tag of the parent or containing field construct.

TextE A description of the field. The value in this attribute is used as a

key when looking up the localised version of this description.

Message Maker r© v5.3 24

Specification XML Library
1.7.1.2 Options Construct

An option describes a mutually exclusive collection of fields. When creating a SWIFT message an
operator may be presented with different flavours or options of the same field, e.g. for a field 52
“Ordering Institution” an operator can choose one of two options 52A or 52D for example, the
choice is normally dependent on the kind of data the operator has to work with. Here 52A allows
the operator define the ordering institution where a BIC (Bank Index Code) has been provided, 52D
on the other hand allows the operator define the same ordering customer but where no BIC is
available they can supply the actual postal address of the ordering customer instead.

The following XML has been taken from MT 101 “Request For Transfer”, it shows the definition of
the 52a “Account Servicing Institution” option, which allows the choice of using either a field 52A
or 52C to represent this information. The XML presented here is made up of the option definition
node AA_SA_6_52a with a definition of each mutually exclusive fields; AA_SA_6_52a_52A and
AA_SA_6_52a_52C as children of the option node.

<AA_SA_6_52a Absnum="6" Group="AA_SA" Key="AA_SA_6_52a" Nr="6" OType="O"

Status="O" Tag="52a" TextE="Account Servicing Institution"
href="/FINAL/US1M/Doc/AFF006.HTM#MT101-6-FIELD-52A">
<AA_SA_6_52a_52A Absnum="6" Key="AA_SA_6_52a_52A" SelOpt="Y" Tag="52A">
<AA_SA_6_52a_52A_1 Absnum="6" CharType="a" Format="{DC}"
Key="AA_SA_6_52a_52A_1" LSep="/" Length="1" Lines="1"
MinLength="1" Status="O SubField="1" Tag="52A"
TextE="Debit/Credit Indicator"/>
<AA_SA_6_52a_52A_2 Absnum="6" CharType="x"
Codes="HK,AT,GR,BL,IT,CC,IN,AU,PT,ES,IE,FW,SC" Format="34x"
Key="AA_SA_6_52a_52A_2" LSep="/" Length="34" Lines="1"
Lookup="code" MinLength="0" Status="O" SubField="2" Tag="52A"
TextE="Party Identifier"/>
<AA_SA_6_52a_52A_3 Absnum="6" CharType="c" Format="{BIC}"
Key="AA_SA_6_52a_52A_3" LSep="BR" Length="11" Lines="1"
MinLength="8" SubField="3" Tag="52A" TextE="BIC"/>
</AA_SA_6_52a_52A>
<AA_SA_6_52a_52C Absnum="6" Key="AA_SA_6_52a_52C" SelOpt="N" Tag="52C">
<AA_SA_6_52a_52C_1 Absnum="6" CharType="x"
Codes="CC,CP,IE,HK,PT,SW,ES,FW,RU,SW,AT,CH,AU,GR,IT,BL"
Format="34x" Key="AA_SA_6_52a_52C_1" LSep="/" Length="34"
Lines="1" Lookup="code" MinLength="0" SubField="1" Tag="52C"
TextE="Party Identifier"/>
</AA_SA_6_52a_52C>
</AA_SA_6_52a>

The important attributes to note are the OType=”O” (Object Type O’ption) on the option definition,
also not the absence of an OType attribute on each for the fields defined with in the option. Instead
we see a new SelOpt attribute which has the value “Y” or “N”, where “Y” indicates that the
operator has selected this particular field option. The remainder of the XML consists of the subfield
definitions which have been described in the previous section.

Message Maker r© v5.3 25

Specification XML Library
1.7.1.3 List Construct

A SWIFT message often consists of a field, option or a collection of fields and options which are
marked as repetitive; here we refer to this construct as a list.

The following sample XML construct is taken from an MT 103 “Single Customer Credit Transfer”,
it shows a list consisting of one field which may be repeated a number of times. Restrictions on the
number of iterations in a SWIFT message was dropped in the November 2003 Standards Release.
The XML fragment shows the list definition node AA_2 which contains a row definition node
AA_2_R1 which in turn will contain the fields, options and other lists that can be repeated.

<AA_2 Group="AA" Key="AA_2" Max="0" Min="0" Nr="2" OType="I" Status="M" Tag="L1"

TextE="List" href="">
<AA_2_R1 Group="AA_2" Key="AA_2_R1" Nr="1" OType="R" Status="M" Tag="1"
TextE="Row" href="">
<AA_2_R1_1_13C Absnum="2" Group="AA_2_R1" Key="AA_2_R1_1_13C"
Nr="1" OType="F" Status="O" Tag="13C" TextE="Time Indication"
href="/FINAL/US1M/Doc/AIG002.HTM#MT103-2-FIELD-13C">
<AA_2_R1_1_13C_1 Absnum="2" CharType="c"
Codes="RNCTIME,CLSTIME,SNDTIME" Format="8c"
Key="AA_2_R1_1_13C_1" LSep="/" Length="8" Lines="1"
Lookup="code" MinLength="0" SubField="1" Tag="13C"
TextE="Code"/>
<AA_2_R1_1_13C_2 Absnum="2" CharType="n" Format="{HHMM}"
Key="AA_2_R1_1_13C_2" LSep="/" Length="4" Lines="1"
MinLength="4" SubField="2" Tag="13C"
TextE="Time Indication"/>
<AA_2_R1_1_13C_3 Absnum="2" CharType="s" Format="{SIGN}"
Key="AA_2_R1_1_13C_3" Length="1" Lines="1" MinLength="1"
SubField="3" Tag="13C" TextE="Sign"/>
<AA_2_R1_1_13C_4 Absnum="2" CharType="n" Format="{OFFSET}"
Key="AA_2_R1_1_13C_4" Length="4" Lines="1" MinLength="4"
SubField="4" Tag="13C" TextE="Time Offset"/>
</AA_2_R1_1_13C>
</AA_2_R1>
</AA_2>

The important attributes to note here are the OType=”I” (Object Type I’terator) or the list definition
node, with the OType=”R” (Object Type R’ow). It’s the row definition that is repeated for each
iteration, with the Key attribute being changed reflect the index of the row, for example row 1 has a
Key attribute of AA_2_R1, row 2 will have a Key attribute of AA_2_R2, row 3 will have
AA_2_R3 and so on. The Key attributes on the contained fields, options and further list will also be
change to reflect which iteration they belong to. This functionality is performed within the
MessageMaker™ Application Programming Interface (API) by such functions as addRow. See the
“MessageMaker™ Application Programming Interface (API) - User Guide” for further details.

Where a list is nested within other lists or repetitive sequences/sub sequences the Key attribute will
be changed to reflect iterations within the nested structures. It’s important that every element within
the message has a unique Key attribute (node names may be repeated).

Message Maker r© v5.3 26

Specification XML Library
1.7.1.4 Sequence/Subsequence Construct

Certain messages are broken into sections referred to a sequences and sub sequences; here we
discuss the necessary XML for these constructs.

The following sample XML construct fragment is taken from the definition of Sequence A of the
MT 300 “Foreign Exchange Confirmation”. Here we see the sequence definition AA_1 containing
the child nodes representing the field, option, list and sub-sequences definition contained with in
this sequence. The same format applies to the XML for a subsequence construct.

<AA_1 Group="AA" Key="AA_1" Nr="1" OType="S" Status="M" Tag="A"

TextE="General Information" href="">
<AA_SA_1_15A Absnum="1" Group="AA_SA" Key="AA_SA_1_15A" Nr="1"
OType="F" Status="M" Tag="15A" TextE="New Sequence"
href="/FINAL/US3M/US3MA/Doc/AEG001.HTM#MT300-1-FIELD-15A">
<AA_SA_1_15A_1 Absnum="1" CharType="0" Format="{CRLF}"
Key="AA_SA_1_15A_1" Length="0" Lines="1" MinLength="0"
SubField="1" Tag="15A" TextE="Sequence Identifier"/>
</AA_SA_1_15A>

…. More field definitions …

</AA_1>

The important attribute to note here is the OType=”S” (Object Type S’equence/S’ubsequence)
which identifies the sequence definition, the body of the construct consists of fields, options, lists
and other sequences (subsequences).

Message Maker r© v5.3 27

Specification XML Library
1.7.1.5 Repetitive Sequence Construct

Here we look at the construct used to express a repetitive sequence/sub sequence.

The following XML fragment taken is from the description of optional sequence D in an MT 303
“Forex/Currency Option Allocation Instruction”. What we see below is the sequence node AA_4,
which contains an iteration node AA_SD_1, which in turn contains a row node AA_SD_I1_1. It’s
the row node that contains our field, option, list and subsequence definitions; again it’s the row
node that is repeated with each iteration of the sequence/sub sequence.

<AA_4 Group="AA" Key="AA_4" Nr="4" OType="S" Status="O" Tag="D"

TextE="Allocation Details" href="">
< AA_SD_1 Group="AA_SD" Key="AA_SD_1" Max="0" Min="0" Nr="1"
OType="I" Status="O" Tag="1" TextE="Allocation Details" href="">
<AA_SD_I1_1 Group="AA_SD_I1" Key="AA_SD_I1_1" Nr="1"
OType="R" Status="O" Tag="1" TextE="Allocation Details" href="">
<AA_SD_I1_R1_1_15D Absnum="33" Group="AA_SD_I1_R1"
Key="AA_SD_I1_R1_1_15D" Nr="1" OType="F" Status="M"
Tag="15D" TextE="New Sequence"
href=" /US3MA/Doc/AFG033.HTM#MT303-33-FIELD-15D">
<AA_SD_I1_R1_1_15D_1 Absnum="33" CharType="0"
Format="{CRLF}" Key="AA_SD_I1_R1_1_15D_1"
Length="0" Lines="1" MinLength="0" SubField="1"
Tag="15D" TextE="Sequence Identifier"/>
</AA_SD_I1_R1_1_15D>

…. More field definitions …

</AA_SD_I1_1>
</AA_SD_1>
</AA_4>

The key attributes to note here are OType=”S” (Object Type S’equence/S’ubsequence) on the
sequence node, the OType=”I” (Object Type I’teration) on the iteration node and finally the
OType=”R” on the row node. It’s the row definition that is repeated for each iteration, with the Key
attribute being changed reflect the index of the row, for example all elements contained within row
1 start with a Key attribute of AA_SD_I1_R1, row 2 will have elements that start with a Key
attribute of AA_SD_I1_R2, row 3 will have AA_SD_I1_R3 and so on. This functionality is
performed within the MessageMaker™ Application Programming Interface (API) by such functions
as addRow. See the “MessageMaker™ Application Programming Interface (API) - User Guide”
for further details.

Message Maker r© v5.3 28

Specification XML Library