Transformer and Swift MT Messages

Transformer and SWIFT MT Messages

*** CONFIDENTIAL ***

Produced by: Trace Financial Limited
224-232 St. John Street
London
EC1V 4QR

Version : 1.1
Date: 13/09/2010

NO WARRANTIES OF ANY NATURE ARE IMPLIED OR EXTENDED BY THIS
DOCUMENTATION.
Products and related material disclosed herein are only furnished pursuant and subject to the terms
and conditions of a duly executed Contract or Agreement to license Software.

The only warranties made by Trace Financial Limited, if any, with respect to the products described in
this document are set forth in such Contract or Agreement.

Trace Financial Limited cannot accept any financial or other responsibility that may result from use of
the information herein or the associated software material, including direct, indirect, special or
consequential damages.

You should be careful to ensure that this information and/or the associated software material complies
with the laws and regulations of the jurisdictions with respect to which it is used.
The information contained herein is subject to change without notice. Revisions may be issued to
advise of such changes and/or additions.

CONFIDENTIALITY
The information contained within this document is confidential and unauthorised copying or
reproduction by any means is prohibited.

OWNERSHIP
Trace Financial Limited reserves title to, and all copyright and other intellectual property rights in, the
information contained herein and in the associated software material.

Correspondence regarding this publication should be addressed to Trace Financial Limited, 224-232, St.
John Street, London EC1V 4QR.

Copyright © 2010 Trace Financial Limited

Transformer and SWIFT MT Messages Document Version 1.1, 13/09/2010

Document Change Control
Version Date Comments

1.0 19/09/07 Initial version
1.1 13/09/10 Updated to reflect software changes

Transformer and SWIFT MT Messages Document Version 1.1 13/09/2010

Contents

1 Introduction .................................................................................................... 1
2 Trace Financial ................................................................................................ 2
2.1 Transformer ................................................................................................. 2
3 Styles of FIN messages ....................................................................................... 3
4 Transformer SWIFT library ................................................................................. 4
4.1 Introduction ................................................................................................. 4
4.2 Re-use of Definitions ....................................................................................... 4
4.3 Tree structure view ........................................................................................ 7
5 Special field types ............................................................................................ 8
5.1 Introduction ................................................................................................. 8
5.2 Data Source Schemes ...................................................................................... 8
5.3 95a 15022 Party fields ..................................................................................... 8
5.4 Signed Value fields 19A / 92A / 99A .................................................................... 9
5.5 98E Date format ............................................................................................ 9
5.6 35B Identity of instrument ............................................................................... 10
5.7 7775 Party fields ........................................................................................... 11
5.8 15022 Amount and Party Blocks ........................................................................ 12
6 Mapping ........................................................................................................ 14
6.1 General ...................................................................................................... 14
6.2 Dynamic testing ............................................................................................ 14
6.3 Reusable mapping actions ............................................................................... 15
6.4 SWIFT mapping functions ................................................................................ 16
7 Reference view ............................................................................................... 20
8 Validation ...................................................................................................... 23
8.1 Transformer‟s Facilities for Validation Layers ....................................................... 23
8.2 Format validation ......................................................................................... 23
8.3 Standard validation ....................................................................................... 23
8.4 Network validation ........................................................................................ 23
8.5 Additional validation schemes .......................................................................... 25

Transformer and SWIFT MT Messages Document Version 1.1, 13/09/2010

1 Introduction
Messaging issues are a constant challenge to financial institutions, SWIFT FIN (also known as MT)
messages are no exception to this rule, and present their own special complexities and difficulties.

Tools that can genuinely provide improved productivity and quality in the messaging arena are few
in number. This white paper outlines how the functionality provided by Transformer from Trace
Financial can greatly assist in managing the difficulties of integrating diverse and complex message
standards, with specific relevance to SWIFT message handling.

It examines many of the issues that arise when incorporating SWIFT messages into an STP
environment, and shows how Transformer can bring real benefits to this situation.

Transformer has been designed from the ground up as a tool that Business Analysts can use. When
message transformation or validation is required, the Business Analyst does not require any detailed
knowledge of the syntax or peculiarities of the messages involved. SWIFT message are no exception
to this.

If it is necessary to map the Trade Date or the Settlement Value from a SWIFT message, a Business
Analyst using Transformer does not need to know that the date must be in yyyymmdd format, or
that the value must have a decimal comma and requires a leading integer, or that the tag and
qualifier must be set correctly and that the surrounding block structure must be set up.

Mappings and rules involving SWIFT definitions appear to the Business Analyst just like any other
mapping, irrespective of whether the messages involved are XML, fixed width, CSV, FIX, or anything
else. The business analyst does not need to know the format of a SWIFT message or any of the
difficulties that the definitions may provide. There is no worrying about setting up of the 16R/16S
combinations, around blocks, or 15a prefixes, or making sure that the qualifier is set, all of these
functions are provided automatically just by using the relevant fields.

Transformer and SWIFT MT Messages Document Version 1.1, 13/09/2010 1

2 Trace Financial
Trace Financial is a wholly-owned subsidiary of Trace Group and is a market leading supplier of
messaging and corporate actions solutions to wholesale financial clients. Trace Financial has been
delivering IT solutions to the financial services sector for over 25 years. Trace Financial provide
solutions to support the business operations of Banks, Brokers, Custodians, Fund Managers, Clearing
Houses, Market Makers, Securities Houses and other financial institutions.
2.1 Transformer
Transformer is Trace Financial‟s next generation software solution for making financial message
mapping easy. Transformer is a Java and XML based data dictionary transformation tool aimed at
financial organisations that have complex messaging requirements. It streamlines the
administration and maintenance of the transformation process and enables compliance with new
messaging standards in a fraction of the time traditionally required. Transformer supports
extensive message definition routines for both XML and legacy systems. These definitions may be
manually created, loaded from an existing XML schema or be supplied as pre-built libraries, e.g.
SWIFT, FIX, CREST, TRAX etc.

2 Transformer and SWIFT MT Messages Document Version 1.1 13/09/2010

3 Styles of FIN messages
Within the SWIFT standard for FIN messages there are two distinct types of messages adhering to
two different international standards. Some, the older ISO 7775 type messages, are quite 'flat' in
structure with little scope for repeating fields. The more modern ISO 15022 type messages are
complex with repeating structures and the ability to group information together in a more logical
structure. For example:

ISO 7775 (MT300) ISO 15022 (MT540)

{1:F01…}{2:I300…}{4: {1:F01…}{2:I540…}{4:
:15A: :16R:GENL
:20:REF1A :20C::SEME//AB2F3654
:22A:NEWT :23G:NEWM
:22C:BEBEBB4475CRESZZ :16S:GENL
:82A:CRESCHZZ :16R:TRADDET
:87A:BEBEDEBB :98A::SETT//20070812
:15B: :35B:ISIN GB1234567890
:30T:20020122 :16S:TRADDET
:30V:20020124 :16R:FIAC
:36:1,4475 :36B::SETT//UNIT/154000,
:32B:GBP100000,00 :97A::SAFE//Account 47893
:57A:MIDLGB22 :16S:FIAC
:33B:USD144750,00 :16R:SETDET
:57A:CHASUS33 :22F::SETR//OWNI
:15C: :16R:SETPRTY
:24D:PHON :95P::SELL//CHASUS22
-} :16S:SETPRTY
:16S:SETDET
-}

From the Business Analyst's point of view these message formats will appear the same. There is no
need to be concerned about the differences between them at a technical level.


4 Transformer SWIFT library
4.1 Introduction
Data dictionaries within Transformer come complete with pre-supplied parsers, converters and
other functions within the product that are specific to the selected dictionary. Typical dictionaries
or templates cover the handling of generic message standards such as Fixed Width, CSV or XML. The
SWIFT pre-supplied functions are also available to other dictionaries in recognition that these
functions are usable in other standards than pure SWIFT messages; for example the TRAX2 15022
library uses similar parsers and converters.

The dictionary provides functionality to correctly understand not only the individual fields and
subfields of individual message components but also handles the structural elements of the
messages. For example, in the 15022 style of messages, the 16R / 16S blocks are vital to the
understanding of the message but are also implicit in nature. Setting a field within a GENL block
alone is enough to cause Transformer to generate the relevant 16R and 16S fields.

The Transformer SWIFT library is updated typically annually to reflect the changes required by
SWIFT. Usually this is an annual upgrade to the SWIFT Message Definitions, typically in October or
November. The Transformer definitions are obviously released in advance of the live date of the
changes to allow users to incorporate the changes in their systems.

Each year‟s library is released with the year identified in the name of the library. This serves two
purposes; firstly for obvious identification reasons and secondly to require a conscious action by
users to incorporate the new libraries.

Upgrading existing mappings and projects to use the new library is a simple process. Each mapping
group that uses the SWIFT library simply needs to be updated to point at the new library from its
properties definition. Obviously extensive analysis of the changes is required to account for changes
to fields that are needed by the business and Transformer‟s regression testing and reference view
facilities can assist greatly in this process.
4.2 Re-use of Definitions
One of Transformer‟s main strengths is its ability to re-use definitions to highlight the commonality
of definitions. For example, if a set of definitions include a name and address structure that is used
in many locations, then define it once and re-use it as necessary. Sometimes there will be
variations in use and Transformer supports this by allowing individual elements to be restricted as
required.

This facility has been used extensively within the SWIFT libraries. It is used at the lowest level to
define the individual components where appropriate but also at higher levels to provide building
block units. As examples, consider the SWIFT date fields in the 15022 group:


This construct supports all of the various date formats in the 15022 group. It covers examples such
as:

:98A::XXXX//20070812
:98B::XXXX//SEOP
:98C::XXXX//20070812135605
:98D::XXXX//ANOU/031/ACTU
:98E::XXXX//20070812135605

as well as variants on these using optional fields. XXXX represents the specific qualifier.

Parts of these definitions are defined using common entities where appropriate. Format A and the
date parts of formats C and E are defined using the common Business Object Type of Date. The
time parts of formats C and E are defined using shared components.

This date structure is used for many of the date fields within the SWIFT library but in most cases
some or all of these formats will not be valid. In these situations the disallowed formats are
prohibited within the definition and will appear like this:

Here, the Late Delivery Date Time component only permits formats A or C but is still based on the
same generic structure with formats B, D and E disabled.


This type of facility allows generic mapping routines to be written at a low level and re-used as
required.

At a higher level a good example would be the party construct in the 7775 Data Dictionary. Here
the full complexity of the SWIFT definitions becomes apparent. Parties can be referred to in
numerous ways:

Naturally, most of the time only a few of these options are available and the preferred option will
usually be A or G, identifying the party by the BIC code where possible.

Often the information for these fields comes from an internal database with sometimes incomplete
Settlement System Instructions. With this construct it is possible to develop mappings that produce
the best information possible regardless of where the party occurs. The logic to be applied might
be something like this:

 Take internal party identifier
 Locate on SSI database
 If BIC code available populate format A
 If name and address available populate format D
 If neither available set information to route message for manual intervention

These constructs can be written in a Transformer mapping, tested and then reused whenever this
format of party is required without having to re-invent the logic each time.

This re-use of common components is not only of direct use in terms of allowing rapid development
of mapping definitions. It also adds strong functionality in terms of validation and message
processing. Using Transformer‟s rules processing for example, validation can be put in place very
quickly to, say, ensure that all Instruments are identified by ISIN codes or to flag for manual
intervention if not.


Business logic may require that each incoming party field is checked against a credit watch list and
action taken if checks fail. Again that is easily implemented within Transformer.
4.3 Tree structure view
In the examples above there have been samples taken from the Tree Structure View that gives
details of the components in a given message. This information is worth considering for the benefits
it brings.

Take an example of an MT300 (from the 7775 group):

Here, several of the elements have been expanded using the icons to show their structure. These
can be collapsed as required ( ) to allow focus on specific areas.

Colours are used to indicate different types of message element. Some are local to this message,
others are reusable components, others are based on library types with restrictions etc. A simple
right click on these allows the definition to be displayed using the Find Definition Of functionality.

Entries with dashed borders are optional (e.g. SplitSettDets), solid borders indicate mandatory
message elements (e.g. TransactionDets). If the border is stacked (e.g. SettlementDetails) it
indicates a repeating field.

The size, spacing and colours may be varied by users as required.

By default each entry displays its SWIFT tag and, where appropriate, its qualifier (specifically on
15022 messages). Additional information is available to show the underlying data type and format
information. For example:


5 Special field types
5.1 Introduction
This section of the white paper covers various peculiarities of SWIFT messages and shows how
Transformer handles those situations to ensure the validity and accuracy of the data passed through
the product.
5.2 Data Source Schemes
In the SWIFT 15022 type messages several fields have the concept of an optional Data Source
Scheme (DSS). These schemes are codes, agreed with the ISO 15022 registration authority, SWIFT,
which allow modification to the valid entries in certain fields.

Take for example the Indicator field 22F. This field has the SWIFT definition:

:22F::4!a/8c/4!c

The 4!a represents a mandatory field of 4 characters (the qualifier), the 8c is an optional field of
up to 8 characters (the DSS) and the 4!c is a mandatory field of 4 characters (the code). Examples
of the use of this field on the FIN network include:

:22F::SETR//TRAD
:22F::SETR//OWNI
:22F::SETR/CRST/SLOX

In the SWIFT user handbooks, the values for the Type of Settlement Transaction field (22F::SETR)
allow values for the code of TRAD and OWNI (amongst others). However, as soon as a DSS value is
entered, no validation rules are applied to the code field. The values permitted within the DSS are
agreed with the DSS issuer, in the example above CRST is the UK settlement service CREST Co (now
known as Euroclear).

Transformer will validate that valid codes are entered when no DSS is supplied but correctly does
not check the values against the SWIFT values when a DSS is present. Additional validation rules can
easily be applied to such fields to check specific schemes if required by users by using standard
Transformer facilities.

This construct applies to the following types of field:

12A Type of Financial Instrument (4 different DSS values)
13B Number Identification (4)
22F Indicator (30)
24B Reason (20)
25D Status (11)
93B Balance (1)
94B Place (3)
95R Party (111)
97B Account (16)
97E Account (8)

5.3 95a 15022 Party fields
The ISO 15022 standard introduces the concept of generic fields with tag 95 representing Party
information. For all the attempts to identify parties and other entities by unique codes to enhance
the potential for straight through processing (STP), SWIFT still needs to identify parties in at least
three different ways (with a fourth for country specific identification). These formats are:

95P BIC 4!a2!a2!c[3!c]
95Q Name and address 4 * 35x
95R Proprietary code 8c34x

Using the 95R format is fair enough where a party is known by a proprietary code, the 8c subfield is
a DSS defined by the 111 bodies that have agreed proprietary codes. But using the 95Q format is a


recipe for STP failures. No system can guarantee matching parties based on name and address so
the opportunities for matching and reconciliation failure for systems using this format are huge.
The 95P BIC format is clearly the way to go forward as recommended by the SMP guidelines.

Many systems though, do not necessarily hold details of the BIC codes. Settlement Instruction (SI)
databases are notoriously difficult to maintain and whilst everyone recognises the benefits of the
BIC value, there are times when it is necessary to resort to name and address etc.

How does Transformer help in this situation? All parties, be they settlement, cash or other are all
defined using a common component type PrimaryPartyId containing all of the formats 95P, 95Q and
95R (as well as 95C for completeness). What this means is that a mapping routine can be written to
provide the best identification possible for a party.

Consider that the Settlement Instruction database is keyed by an internal code. The record found
may have a BIC, it may have a proprietary code or it may have just name and address. Now it is
possible to write just one mapping routine that can be used everywhere; if the BIC exists use that,
if not then use the proprietary code if possible, failing that use the name and address. One routine,
designed and tested in isolation and the best approach for setting party information has been
achieved for all outgoing messages.
5.4 Signed Value fields 19A / 92A / 99A
These three formats are potentially quite difficult to process in systems not built with SWIFT in
mind. SWIFT value fields generally are not too problematic once the vagaries of decimal commas
and the mandatory integer part and optional decimal part are understood but the SWIFT processing
of negative numbers can raise issues.

Most values in SWIFT have their sign determined by their meaning but some are explicitly signed
and not in a particularly helpful way. For example the following are all valid 19A values:

19A::SETT//GBP100, GBP 100.00
19A::SETT//NZD0,12 NZD 0.12
19A::SETT//NGBP100, GBP 100.00-
19A::SETT//NNZD0,12 NZD 0.12-

Similar values can exist for 92A and 99A although without the currency code. The tricky value is the
last example. Many parsers start at the left hand end and may report this as an invalid currency
NNZ or an invalid value D0,12. Transformer has been designed with this type of format in mind and
its processing of fields of all message types not just SWIFT into internal Business Object Types
means that handling of decimal commas, optional leading signs and effectively floating currencies
are not problems that the mapping designer has to worry about.

The values above are made available to the user as two fields; the settlement amount currency as a
validated currency code and the settlement amount itself as a signed decimal value. Consider the
actions a system may need to undertake to map this settlement amount to a fixed format like this:

19A::SETT//NGBP100, GBP000001000000-

The output is fixed width of 13 characters for the value filled with zeros with an implied decimal
place and a trailing sign that is either – or blank.

Transformer handles this as two copy commands one for the currency and one for the value, its
inherent converters and knowledge of the formats means that the business analyst devising the
mapping can work with the business meaning – copy the settlement currency and copy the
settlement value without worrying about the formatting.
5.5 98E Date format
The 98E format of the generic Date/Time component 98a is a new 2007 introduction. Primarily
designed for trade reporting purposes in line with the European Union Markets in Financial
Instruments Directive (MiFID) this field is likely to cause some issues in terms of its complexity.


Whilst at its most basic form it supports a date/time construct just like the 98C format it also
allows for, optionally and independently, decimal fractions of a second, hours and optionally
minutes plus or minus from the stated time to handle time zones. The format along with the
standard SWIFT approach to negative numbers, an optional N is likely to make this a challenging
field to use.

Examples of valid values are:

:98E::TRAD//20070812152500
15:25:00 on 12th August 2007
:98E::TRAD//20070812152500,150
15:25:00.150 on 12th August 2007
:98E::TRAD//20070812152500,1
15:25:00.1 on 12th August 2007
:98E::TRAD//20070812152500,1/02
15:25:00.1 on 12th August 2007 plus 2 hours
:98E::TRAD//20070812152500/N0230
15:25:00 on 12th August 2007 minus 2 hours 30 minutes

Transformer handles the date and time portions as Business Object Types removing any concerns of
formats. For the optional parts it helps by handling the formatting of the subfields. Simply set the
milliseconds part and the leading „,‟ is handled automatically. Pass in a time with a time zone
behind GMT and the N is provided by the software.
5.6 35B Identity of instrument
The Identity of Instrument field, 35B, is obviously a very common field in the securities field. It is
also a unique field as it has two optional parts and needs a Network validation rule to ensure that
data other than an empty tag is supplied. It is also the only format of field that requires a fixed
literal in front of a value, presumably to help systems distinguish between the subfields.

The SWIFT format of the field is:

[ISIN1!e12!c]
[4*35x]

This gives rise to valid entries of:

:35B:ISIN GB0004594973

:35B:IMPERIAL CHEMICAL INDUSTRIES PLC
ORD #1

:35B:ISIN GB0004594973
IMPERIAL CHEMICAL INDUSTRIES PLC
Ord #1

The preferred format is of course the ISIN value. Without this coded value, any form of STP
becomes difficult. Indeed this is an SMP guideline for using this field. However some back office
settlement systems still do not use ISIN codes and have their own internal codes be they Sedol,
CUSIP, Bloomberg, EPIC etc. To use the ISIN code, they may well have a database to provide lookup
facilities but this can be very tedious to have to code each time.

Transformer assists of course allowing these SQL queries do be defined once and reused where
necessary. A typical routine might well be to take the back office code, possibly with a „type‟ value
to drive a database lookup. The returned code could then be simply mapped straight into the ISIN
value.


5.7 7775 Party fields
Because the 7775 standard fields do not have a means of identifying specific party types by means
of a qualifier (e.g. :95P::BUYR//ABNANL2A indicates the buyer), they need to use different SWIFT
tags for the various parties. This leads to the situation where the following formats are regularly
used for parties:

50a, 51a, 52a, 53a, 54a, 55a, 56a, 57a, 58a, 59, 59A, 82a, 83a, 84a, 85a, 86a, 87a, 88a

Each of these has several formats ranging through:
A [/1!a][/34x] (Party Identifier)
4!a2!a2!c[3!c] (BIC/BEI)
D [/1!a][/34x] (Party Identifier)
4*35x (Name & Address)
J 5*40x (Party Identification)

amongst others.

To handle the possible mappings for each of these when they are required could be a real challenge
but Transformer holds of the various parties 51a, 52a, etc. based on the same underlying Party
structure.


As an example here is the structure held for the Fund or beneficial customer on an MT300

For this field, tag 83a, only formats A, D and J are valid and the rest have been prohibited within
Transformer. This means that the same party structure is visible everywhere and the mapping rules
required to handle a party in any form in any of the 7775 message sets can be written once, tested
once and used wherever necessary with guaranteed results.

5.8 15022 Amount and Party Blocks
In 15022 messages, amount and party information is conveyed in blocks delimited by 16R/16S
within which one of the fields carries a qualifier indicating the role or significance of the party or
amount concerned. For example, in the following extract from an MT540 message, a buyer, seller
and receiving agent have all been defined:

:
:16R:SETDET
:22F::SETR//TRAD
:16R:SETPRTY
:95P::BUYR//UBSWCHZH80A
:16S:SETPRTY
:16R:SETPRTY
:95P::REAG//CHASUS33
:16S:SETPRTY
:16R:SETPRTY
:95P::SELL//ABNANL2A
:97A::SAFE//AB12323
:16S:SETPRTY
:16S:SETDET
:

Transformer‟s SWIFT message definition and parsing facilities allow the business analyst to ignore
the fact that the seller‟s safekeeping account could be in any of the repetitions of the 16R:SETPRTY
block in the message, and extract the information as simply as if it were in a designated field in a
fixed width message. In the example above the analyst would simply copy the field:

Block4/SettlementDets/SettParties/Seller/Accounts/SafekeepingAcct/OptionA

to access the Sellers Safekeeping account AB12323 as required, selecting the field from the
definitions using the mouse. If the field were missing, no errors or complex logic would be required.


Transformer simply maps the named value if present or ignores the mapping action if the field is
missing. This behaviour is of course controllable as required.

Compare the simplicity of this with many solutions that require looping through all of the SETPRTY
entries looking for the SELL qualifier on the 95a Party field (which could of course be 95P, Q or R)
and then checking to see if the 97A value were present.


6 Mapping
6.1 General
In line with Transformer‟s design aim of addressing Business Analyst requirements when it comes to
implementing mapping functionality, mappings using SWIFT definitions appear to a user just like
any other mapping, irrespective of whether the messages involved are XML, fixed width, CSV, FIX
etc. The business analyst does not need to know the format of a SWIFT message or any of the
difficulties that the definitions may provide. There is no worrying about setting up of the 16R/16S
combinations around blocks or making sure that the qualifier is set, all of these functions are
provided automatically just by using the relevant fields.

Having said that, this information is available if required and allows users to view their output in its
final form as a check mechanism.
6.2 Dynamic testing
Transformer has integrated testing for all of its configuration items. The message definitions
themselves are tested extensively with a comprehensive suite of test data. These same test
functions are available for testing mapping definitions. Simply by providing input data, the results
of running the mapping can be seen and, more importantly, retained within the Transformer
definitions. This allows for full regression testing of mappings and ensures that any unforeseen side
effects of, say, changing a back office source format can be identified easily and quickly.

Additionally, once a set of input data has been associated with a mapping, it is possible to see and
test the effects of individual mapping actions in design mode. This dynamic testing facility is a very
powerful feature of Transformer and can save considerable time in developing complex mappings.

The following example shows how an input date value in the form of yyyy/mm/dd has been
transformed into the SWIFT yyyymmdd form just by using the simple Copy action in Transformer.

By selecting the field in the mapping destination tree, and choosing the option from the right-click
menu, the entire field can be seen in its final context. Selecting the TradeDateTime field gives:


Selecting the entire message gives the very incomplete (and invalid!) message:

Note though that this message has been built as a result of the one copy action. The block 4 tags,
the 16R/S:TRADDET entries and the :98A::TRAD// have all been built automatically.
6.3 Reusable mapping actions
In an earlier section, the ability of Transformer to define standard structures to represent common
fields has already been discussed. Using this, consistency can be introduced to complex definitions
such as parties. Transformer extends this functionality into the mapping area. Here it is possible to
define mappings between the component type structures. These generic routines can then be used
wherever specific instances of these formats occur.

Consider an example from the mappings necessary to share information between MT and their XML
counterparts the MX messages. In the MT messages, the Transformer SWIFT library has a standard
format for the party structure.


Similarly, the MX messages also define a standard structure:

These two structures allow for all the possible formats of the parties; BIC, name and address or
proprietary code. Obviously the mapping functionality between the two is quite complex and
repeating this every time a party needed mapping would be quite onerous.

Transformer addresses this by allowing mappings to be defined between the component types and
then for these to be used anywhere a structure of the relevant type is required. The effect of this
reuse of mappings is that they can be developed and tested extensively in isolation and used in the
knowledge of their accuracy. To map between two parties becomes as simple as

The field names may look complicated but they have been selected from the definitions to map the
Investor to the relevant field on the MX Redemption Order. This one action will handle all of the
BIC code or name and address formatting issues as defined in the MT_To_MXParty reusable
mapping.
6.4 SWIFT mapping functions
Even with Transformer‟s advanced functionality in terms of automatically handling formats and
data types there are situations in the SWIFT environment where additional help is required. The
SWIFT library in Transformer provides some specific mapping functions that can be used to handle
these specific situations.

6.4.1 Multi-line text routines
Many SWIFT fields are made up of sub-fields that are effectively multi-line text fields. There are
name & address fields, narratives, security descriptions etc. Technically in SWIFT terms there is no
distinction between the lines of these fields, they are all one sub-field. In the real world however
there is a need to get at these individual lines and Transformer provides several mapping functions
to assist.

There is often the additional complication of continuation line characters and these can be quite
problematical in traditional string manipulation languages and products.


6.4.1.1 Mapper CopyMultilineText
Consider a typical multi-line field:

:70E::ADTX//24 FEB 2005 PLEASE BE ADVISED THAT
THE COMPANY IS PROPOSING A SUBDIVI
SION OF EACH ORDINARY SHARE OF SGD
1.00 EACH IN THE CAPITAL OF COMPANY
INTO 2 ORDINARY SHS OF SGD 0.50 EA
CH

To process this into a single narrative field could be quite tedious so the CopyMultilineText mapper
is available to achieve that. It has options to preserve newlines, replace them with a space or
discard them completely. The output from the mapper could be:

24 FEB 2005 PLEASE BE ADVISED THAT THE COMPANY IS PROPOSING A SUBDIVISION OF EACH
ORDINARY SHARE OF SGD 1.00 EACH IN THE CAPITAL OF COMPANY INTO 2 ORDINARY SHS OF SGD
0.50 EACH

If the input was of the form:

70F::ADTX//
OUR REFERENCE : 042049 / 0003
ASSET NAME : OVERSEAS-CHINESE BANK
ASSET DESCRIPTION : SGD1
SEDOL/ASSET ID : 6663689
ISIN CODE : SG1L51001825

Here preserving the format could be important and an option is available to retain this.

6.4.1.2 Mapper CombineMultiLineText
If you need to set a multi-line text field and formatting is important and you need to know what is
going into each line of the field then this mapper can help. Effectively you build up the contents in
an array of strings and pass the array to the mapper to output the combined field.

6.4.1.3 Mapper ExtractMultiLineText
This mapping function provides the opposite of CombineMultiLineText. It takes the SWIFT field and
delivers it into an array of string variables to be processed as necessary.

6.4.1.4 Mapper GetLine
If you know which line of a multi-line field you need then this mapping function will extract that
particular line into a single output field.

6.4.1.5 Mapper CopyFromMultiLineText
Consider a field:

:72:/ACC/Payment for further credit to
//subsidiary ABC, US, Miami

Using the other multi-line mapping functions will happily return each line of this as a separate
string but dealing with the continuation characters // can be problematic.

This function will automatically remove these characters and combine the string using a value as
appropriate, typically a space.

6.4.1.6 Mapper CopyToMultiLineText
This function provides the converse of the preceding function. If you have a long string that needs
breaking up into chunks with continuation characters then this can be quite challenging with
considerable amounts of string manipulation and length checks. This mapper provides this


functionality automatically with just the need to specify whether the string should be split at word
boundaries or precisely at the field width.

6.4.2 Working with BIC codes
Most of the time a BIC is simply an 8 or 11 character value. However it does have a structure and is
made up of the following sub-fields:

4!a Bank Code
2!a Country Code
2!c Location Code
[3!c] Branch code

To make these subfields available when required the BIC mapping function is available.

6.4.3 Processing the Category n messages
Each of the various series of SWIFT messages contains a set of n9n messages e.g. 196, 599 etc.
Their format is common across the series and they are handled differently because several of
these, n92, n95, n96 contain a special field which is the contents of block 4 of the message to
which they relate. In effect they contain a message within a message. Technically this means that
at that point in the n92 message for example, there is a choice of all possible SWIFT messages.
Clearly that would be very difficult to work with.

Transformer provides two mapping functions (CopyBlock4 and CopyOriginalMessageField) to
specifically assist this process. These functions allow the entire block 4 of the message to be
handled as a unit whether being used to create the n9n message or to interpret the output of an
n9n message.

6.4.4 7775 Party fields
As has been explained earlier the 7775 party fields are all based on a single Transformer component
type. However the individual formats still present some difficulties in accessing their contents. In
particular, formats A, B and D all contain a pair of fields which together form the sub-field Party
Identifier. The SWIFT definition of this sub-field is:

[/1!a][/34x]

This is actual two data items; account type and account number. To get at or to set these
individually, two mappers are provided. GetPartyIdentifier will return the two separate values
whilst SetPartyIdentifier simplifies the process of setting these two values.

Format J of the various 7775 party fields is also a challenge. The SWIFT definition of this sub-field
is:

5*40x

A simple enough multi-line field but this field is different. Its contents must consist of pairs of code
and value, separated by / characters. For example:

:87J:/ABIC/AAAABBCC/ACCT/ABC12345678901/NAME/
12345678901234567890123456789012345

contains the following entries:

ABIC AAAABBCC
ACCT ABC12345678901
NAME 12345678901234567890123456789012345


To work with this type of field two mappers are provided. PartyJToTemp will take the SWIFT field
and return an array of the code and value pairs. TempToPartyJ does the same thing in reverse.

6.4.5 Accessing SWIFT metadata
Even with Transformer's tight data definitions and the structure embedded in the mappings
themselves, there are still occasions when it is necessary to access the metadata of the definitions.
The mapper SWIFTDefinition will return, for any given message element, the tag (e.g. 98), the
format (e.g. 98A), the qualifier if appropriate (e.g. TRAD), the sequence label if appropriate (e.g.
GENL) and the message type (e.g. 540)


7 Reference view
One of the biggest issues in dealing with any messaging system is the ease with which changes can
be identified and Transformer provides facilities specifically to deal with this by means of its
reference view and ability to easily display constituent parts of a definition. This allows the impact
of changes to be identified quickly and effectively. Consider the annual problem of incorporating
the new SWIFT message definitions.

Each year SWIFT produce a new set of changes consisting of new fields, amendments to existing
entries and the deletion of entries. Each of these produces unique challenges. Consider the change
in definition of a field. In 2007 SWIFT introduced a new date format 98E which contained the ability
to specify fractions of a second along with time zone information. In terms of mapping
specifications, this could be a major issue. A mapping may work perfectly with the existing 98C
definition (date and time) but could now receive the same information on a 98E format field. Using
Transformer it is possible to identify the base component type that handles all date formats in the
SWIFT library, DateTime. By using the reference view it is possible to see that this component type
is used everywhere for date formats.

On the left you can see the structure that forms the DateTime component type and on the right,
everywhere that uses that type in some form. However to find only those places that actually use
format E, select part of that format and check the Exclude Prohibited field. This removes from
display those configuration items that are based on DateTime but explicitly prohibit format E. What
is left are the items that need to be considered in terms of the change to the SWIFT definitions to
allow 98E.


Now we can see that option E is only used in TradeDateTime and in turn where that is used.
Ultimately this leads to the messages such as MT513, MT540 etc. Note that not all entries have
been expanded in the example. From this we can see that if we use an MT513 and the
TradeDateTime in the OrderDetails sequence then 98E is available for this field. Similarly, clicking
on the Actions tab will show details of all the mapping actions that reference this field. Obviously
for 98E there will be none yet but by analysing the use of 98C the work involved in adapting
mappings for 98E can quickly be discovered.

In this selected example taken from the uses of 98C in the TradeDateTime the uses of that field in
mappings can be seen. It is likely that these uses and those for 98A may need to be modified to
allow for the 98E field in the future.

Here there are two mappings involved, BackOfficeInbound and Settlements for the use of
TradeDateTime in the Msg_540_grp item. It is possible that these two mappings would need to
change to incorporate an entry for 98E.


By selecting the Actions tab at the top of the reference view, details of the individual mapping
actions for the selection can be seen:

This pane shows the individual mapping actions that use the node DateTime/OptionC/Date. There
are no details displayed for the mapping Settlements because whilst the field is available to that
mapping there are no actual mapping actions that use the field. From the information displayed it
is clear that the OptionC/Date field is used in a Copy action from the Msg_540_grp to the
BOTrade/TradeDate field. Since OptionE supports a similar date format it is likely that this mapping
will need to be enhanced to include a similar Copy action for OptionE.

Analysis such as this, when combined with Transformer's inherent regression testing facilities mean
that the annual library changes can be incorporated quickly and reliably.


8 Validation
8.1 Transformer’s Facilities for Validation Layers
Transformer‟s design incorporates the fact that messaging requirements incorporate different
kinds, or layers, of validation. These may include validation which is part of a generic messaging
standard, such as SWIFT, validation specific to particular markets or products, validation which
relates to particular counterparties, and validation which is an “in house” requirement.

Each of these can be represented in Transformer as a Validation RuleSet, within which particular
rules can be applied to individual messages, fields, or types of information.

When a message fails validation Transformer provides detailed and helpful error reporting,
detailing both the field(s) and ruleset(s) involved. As well as being available in a human-readable
form, this information is available programmatically for message routing purposes.
8.2 Format validation
As part of its normal operation, Transformer will check that every field it receives matches the
definition it is expecting regardless of whether SWIFT is being used or not. This will check the
format of the field in terms of field length, character set, cardinality, validity of codes etc.
Additionally the built in Business Object Type checking will ensure that the underlying data is of
the correct format. For example, a date must contain a date in the specified format, numeric
values don't contain alphabetic characters etc.
8.3 Standard validation
For SWIFT specific fields other checks are automatically applied such as:

 Do decimal values have embedded decimal commas?
 Do decimal values have the correct form? For example 0,123 is valid but ,123 is not
 Are the qualifiers valid?
 Are any Data Source Scheme structure fields correct?
 Are the tags specified correctly?
 Are the 16R / 16S sequence and subsequence delimiters specified correctly?
 Is the overall block structure correct?

No action is needed to ensure that all of these checks take place, they are provided as standard
with Transformer.
8.4 Network validation
All of the standard validation described in the previous sections typically relates to single fields or
subfields. The SWIFT standards also define many additional rules that either apply across two or
more fields or can't be defined using the standard SWIFT definitions. These are termed Network
Validation rules and are defined at the individual message level. Each rule in Transformer can have
an error code and message assigned and these are returned to the user or calling application when
the rule fails. As standard the SWIFT library uses the SWIFT error codes and messages as
appropriate.

Some of these rules are very specific and clearly only apply to the message against which they are
defined. However, others are more general and apply across messages. Transformer assists greatly
in defining and maintaining these through its use of condition definitions. Take an example:

Rule T17 applies to Identification of Instrument fields.

At least Identification of a Security (Subfield 1) or Description of Security (Subfield 2)
must be present; both may be present

In Transformer this is defined as a Condition Definition


This simple Condition Definition is then applied to the component IdOfInstrument itself as a
Validation Rule. These two definitions, the Condition Definition and the Validation Rule mean that
every IdOfInstrument field throughout the SWIFT definitions will have this rule applied
automatically.

Rule T17 is relatively simple but the Network Validation rules can be quite complex. Here is one
such example:

Rule E62 applies to MT540-7.

In (sub)sequence E3, if an exchange rate (field :92B::EXCH) is present, the corresponding
resulting amount (field :19A::RESU) must be present in the same subsequence. If the exchange
rate is not present then the resulting amount is not allowed.

In Transformer this is again set up as a re-usable condition definition and looks like this:

One huge benefit of Transformer is that these rules can be tested in isolation from the messages
that they relate to and applied across the message knowing that they will work.

As one final example, consider the rule E89. This applies to MT540-3 against 19A::SETT and to
MT544-7 against 19A::ESTT

If sequence C is present two or more times, the settlement amount (field :19A::SETT) must
be present in every occurrence of sequence C or in none (Error code(s): E89).
In the former case (when sequence C is present two or more times and the settlement
amount (field :19A::SETT) is present in every occurrence of sequence C) then:
 the settlement amount (field :19A::SETT) must be present in one occurrence of
subsequence E3 and
 the sum of all occurrences of the settlement amount (field :19A::SETT) in
sequence C must be equal to the settlement amount (field :19A::SETT) in
subsequence E3 and
 the currency code in the settlement amounts (fields 19A::SETT in (sub)sequences C
and E3) must be the same for all occurrences of these fields in the message.

This rule shows the complexity that can be achieved using Transformer. Consider testing this rule
against eight separate messages…


8.5 Additional validation schemes
All of the validation described in the previous section comes as standard with Transformer.
However, some installations require their own local rules to be applied. These may be completely
proprietary or they may be SMP (Standard Market Practice) guidelines or other standards bilaterally
agreed between counterparties.

In all cases, all of the functionality described for Network Validation rules can be applied to
additional rulesets at will.


Transformer and Swift MT Messages

More Related Content

What's hot (16)

Viewers also liked (8)

Similar to Transformer and Swift MT Messages (20)

Recently uploaded (20)

Transformer and Swift MT Messages