• Save
Transformer and Swift MT Messages
Upcoming SlideShare
Loading in...5
×
 

Transformer and Swift MT Messages

on

  • 3,305 views

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

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.

Statistics

Views

Total Views
3,305
Views on SlideShare
3,301
Embed Views
4

Actions

Likes
2
Downloads
2
Comments
0

2 Embeds 4

http://www.slashdocs.com 3
http://www.docshut.com 1

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Transformer and Swift MT Messages Transformer and Swift MT Messages Document Transcript

  • Transformer and SWIFT MT Messages *** CONFIDENTIAL ***Produced by: Trace Financial Limited 224-232 St. John Street London EC1V 4QRVersion : 1.1Date: 13/09/2010
  • NO WARRANTIES OF ANY NATURE ARE IMPLIED OR EXTENDED BY THISDOCUMENTATION.Products and related material disclosed herein are only furnished pursuant and subject to the termsand 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 inthis document are set forth in such Contract or Agreement.Trace Financial Limited cannot accept any financial or other responsibility that may result from use ofthe information herein or the associated software material, including direct, indirect, special orconsequential damages.You should be careful to ensure that this information and/or the associated software material complieswith 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 toadvise of such changes and/or additions. CONFIDENTIALITYThe information contained within this document is confidential and unauthorised copying orreproduction by any means is prohibited. OWNERSHIPTrace Financial Limited reserves title to, and all copyright and other intellectual property rights in, theinformation 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 LimitedTransformer and SWIFT MT Messages Document Version 1.1, 13/09/2010
  • Document Change ControlVersion Date Comments1.0 19/09/07 Initial version1.1 13/09/10 Updated to reflect software changesTransformer and SWIFT MT Messages Document Version 1.1 13/09/2010
  • Contents1 Introduction .................................................................................................... 12 Trace Financial ................................................................................................ 22.1 Transformer ................................................................................................. 23 Styles of FIN messages ....................................................................................... 34 Transformer SWIFT library ................................................................................. 44.1 Introduction ................................................................................................. 44.2 Re-use of Definitions ....................................................................................... 44.3 Tree structure view ........................................................................................ 75 Special field types ............................................................................................ 85.1 Introduction ................................................................................................. 85.2 Data Source Schemes ...................................................................................... 85.3 95a 15022 Party fields ..................................................................................... 85.4 Signed Value fields 19A / 92A / 99A .................................................................... 95.5 98E Date format ............................................................................................ 95.6 35B Identity of instrument ............................................................................... 105.7 7775 Party fields ........................................................................................... 115.8 15022 Amount and Party Blocks ........................................................................ 126 Mapping ........................................................................................................ 146.1 General ...................................................................................................... 146.2 Dynamic testing ............................................................................................ 146.3 Reusable mapping actions ............................................................................... 156.4 SWIFT mapping functions ................................................................................ 167 Reference view ............................................................................................... 208 Validation ...................................................................................................... 238.1 Transformer‟s Facilities for Validation Layers ....................................................... 238.2 Format validation ......................................................................................... 238.3 Standard validation ....................................................................................... 238.4 Network validation ........................................................................................ 238.5 Additional validation schemes .......................................................................... 25Transformer and SWIFT MT Messages Document Version 1.1, 13/09/2010
  • 1 IntroductionMessaging 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 fewin number. This white paper outlines how the functionality provided by Transformer from TraceFinancial can greatly assist in managing the difficulties of integrating diverse and complex messagestandards, with specific relevance to SWIFT message handling.It examines many of the issues that arise when incorporating SWIFT messages into an STPenvironment, 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. Whenmessage transformation or validation is required, the Business Analyst does not require any detailedknowledge of the syntax or peculiarities of the messages involved. SWIFT message are no exceptionto this.If it is necessary to map the Trade Date or the Settlement Value from a SWIFT message, a BusinessAnalyst using Transformer does not need to know that the date must be in yyyymmdd format, orthat the value must have a decimal comma and requires a leading integer, or that the tag andqualifier 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 othermapping, irrespective of whether the messages involved are XML, fixed width, CSV, FIX, or anythingelse. The business analyst does not need to know the format of a SWIFT message or any of thedifficulties that the definitions may provide. There is no worrying about setting up of the 16R/16Scombinations, around blocks, or 15a prefixes, or making sure that the qualifier is set, all of thesefunctions are provided automatically just by using the relevant fields.Transformer and SWIFT MT Messages Document Version 1.1, 13/09/2010 1
  • 2 Trace FinancialTrace Financial is a wholly-owned subsidiary of Trace Group and is a market leading supplier ofmessaging and corporate actions solutions to wholesale financial clients. Trace Financial has beendelivering IT solutions to the financial services sector for over 25 years. Trace Financial providesolutions to support the business operations of Banks, Brokers, Custodians, Fund Managers, ClearingHouses, Market Makers, Securities Houses and other financial institutions.2.1 TransformerTransformer is Trace Financial‟s next generation software solution for making financial messagemapping easy. Transformer is a Java and XML based data dictionary transformation tool aimed atfinancial organisations that have complex messaging requirements. It streamlines theadministration and maintenance of the transformation process and enables compliance with newmessaging standards in a fraction of the time traditionally required. Transformer supportsextensive message definition routines for both XML and legacy systems. These definitions may bemanually 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 messagesWithin the SWIFT standard for FIN messages there are two distinct types of messages adhering totwo different international standards. Some, the older ISO 7775 type messages, are quite flat instructure with little scope for repeating fields. The more modern ISO 15022 type messages arecomplex with repeating structures and the ability to group information together in a more logicalstructure. 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 Analysts point of view these message formats will appear the same. There is noneed to be concerned about the differences between them at a technical level.Transformer and SWIFT MT Messages Document Version 1.1, 13/09/2010 3
  • 4 Transformer SWIFT library4.1 IntroductionData dictionaries within Transformer come complete with pre-supplied parsers, converters andother functions within the product that are specific to the selected dictionary. Typical dictionariesor templates cover the handling of generic message standards such as Fixed Width, CSV or XML. TheSWIFT pre-supplied functions are also available to other dictionaries in recognition that thesefunctions are usable in other standards than pure SWIFT messages; for example the TRAX2 15022library uses similar parsers and converters.The dictionary provides functionality to correctly understand not only the individual fields andsubfields of individual message components but also handles the structural elements of themessages. For example, in the 15022 style of messages, the 16R / 16S blocks are vital to theunderstanding of the message but are also implicit in nature. Setting a field within a GENL blockalone 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 bySWIFT. Usually this is an annual upgrade to the SWIFT Message Definitions, typically in October orNovember. The Transformer definitions are obviously released in advance of the live date of thechanges 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 twopurposes; firstly for obvious identification reasons and secondly to require a conscious action byusers to incorporate the new libraries.Upgrading existing mappings and projects to use the new library is a simple process. Each mappinggroup that uses the SWIFT library simply needs to be updated to point at the new library from itsproperties definition. Obviously extensive analysis of the changes is required to account for changesto fields that are needed by the business and Transformer‟s regression testing and reference viewfacilities can assist greatly in this process.4.2 Re-use of DefinitionsOne of Transformer‟s main strengths is its ability to re-use definitions to highlight the commonalityof definitions. For example, if a set of definitions include a name and address structure that is usedin many locations, then define it once and re-use it as necessary. Sometimes there will bevariations in use and Transformer supports this by allowing individual elements to be restricted asrequired.This facility has been used extensively within the SWIFT libraries. It is used at the lowest level todefine the individual components where appropriate but also at higher levels to provide buildingblock units. As examples, consider the SWIFT date fields in the 15022 group:4 Transformer and SWIFT MT Messages Document Version 1.1 13/09/2010
  • This construct supports all of the various date formats in the 15022 group. It covers examples suchas::98A::XXXX//20070812:98B::XXXX//SEOP:98C::XXXX//20070812135605:98D::XXXX//ANOU/031/ACTU:98E::XXXX//20070812135605as 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 thedate parts of formats C and E are defined using the common Business Object Type of Date. Thetime 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 casessome or all of these formats will not be valid. In these situations the disallowed formats areprohibited 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 thesame generic structure with formats B, D and E disabled.Transformer and SWIFT MT Messages Document Version 1.1, 13/09/2010 5
  • This type of facility allows generic mapping routines to be written at a low level and re-used asrequired.At a higher level a good example would be the party construct in the 7775 Data Dictionary. Herethe full complexity of the SWIFT definitions becomes apparent. Parties can be referred to innumerous ways:Naturally, most of the time only a few of these options are available and the preferred option willusually 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 incompleteSettlement System Instructions. With this construct it is possible to develop mappings that producethe best information possible regardless of where the party occurs. The logic to be applied mightbe 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 interventionThese constructs can be written in a Transformer mapping, tested and then reused whenever thisformat 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 developmentof mapping definitions. It also adds strong functionality in terms of validation and messageprocessing. Using Transformer‟s rules processing for example, validation can be put in place veryquickly to, say, ensure that all Instruments are identified by ISIN codes or to flag for manualintervention if not.6 Transformer and SWIFT MT Messages Document Version 1.1 13/09/2010
  • Business logic may require that each incoming party field is checked against a credit watch list andaction taken if checks fail. Again that is easily implemented within Transformer.4.3 Tree structure viewIn the examples above there have been samples taken from the Tree Structure View that givesdetails of the components in a given message. This information is worth considering for the benefitsit 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. Thesecan 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 simpleright 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 mandatorymessage elements (e.g. TransactionDets). If the border is stacked (e.g. SettlementDetails) itindicates 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 on15022 messages). Additional information is available to show the underlying data type and formatinformation. For example:Transformer and SWIFT MT Messages Document Version 1.1, 13/09/2010 7
  • 5 Special field types5.1 IntroductionThis section of the white paper covers various peculiarities of SWIFT messages and shows howTransformer handles those situations to ensure the validity and accuracy of the data passed throughthe product.5.2 Data Source SchemesIn the SWIFT 15022 type messages several fields have the concept of an optional Data SourceScheme (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!cThe 4!a represents a mandatory field of 4 characters (the qualifier), the 8c is an optional field ofup to 8 characters (the DSS) and the 4!c is a mandatory field of 4 characters (the code). Examplesof the use of this field on the FIN network include: :22F::SETR//TRAD :22F::SETR//OWNI :22F::SETR/CRST/SLOXIn 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 isentered, no validation rules are applied to the code field. The values permitted within the DSS areagreed with the DSS issuer, in the example above CRST is the UK settlement service CREST Co (nowknown as Euroclear).Transformer will validate that valid codes are entered when no DSS is supplied but correctly doesnot check the values against the SWIFT values when a DSS is present. Additional validation rules caneasily be applied to such fields to check specific schemes if required by users by using standardTransformer 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 fieldsThe ISO 15022 standard introduces the concept of generic fields with tag 95 representing Partyinformation. For all the attempts to identify parties and other entities by unique codes to enhancethe potential for straight through processing (STP), SWIFT still needs to identify parties in at leastthree 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 8c34xUsing the 95R format is fair enough where a party is known by a proprietary code, the 8c subfield isa DSS defined by the 111 bodies that have agreed proprietary codes. But using the 95Q format is a8 Transformer and SWIFT MT Messages Document Version 1.1 13/09/2010
  • recipe for STP failures. No system can guarantee matching parties based on name and address sothe 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 theBIC 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 alldefined using a common component type PrimaryPartyId containing all of the formats 95P, 95Q and95R (as well as 95C for completeness). What this means is that a mapping routine can be written toprovide the best identification possible for a party.Consider that the Settlement Instruction database is keyed by an internal code. The record foundmay have a BIC, it may have a proprietary code or it may have just name and address. Now it ispossible 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 beenachieved for all outgoing messages.5.4 Signed Value fields 19A / 92A / 99AThese three formats are potentially quite difficult to process in systems not built with SWIFT inmind. SWIFT value fields generally are not too problematic once the vagaries of decimal commasand the mandatory integer part and optional decimal part are understood but the SWIFT processingof negative numbers can raise issues.Most values in SWIFT have their sign determined by their meaning but some are explicitly signedand 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 thelast example. Many parsers start at the left hand end and may report this as an invalid currencyNNZ or an invalid value D0,12. Transformer has been designed with this type of format in mind andits processing of fields of all message types not just SWIFT into internal Business Object Typesmeans that handling of decimal commas, optional leading signs and effectively floating currenciesare 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 avalidated currency code and the settlement amount itself as a signed decimal value. Consider theactions 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 decimalplace 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, itsinherent converters and knowledge of the formats means that the business analyst devising themapping can work with the business meaning – copy the settlement currency and copy thesettlement value without worrying about the formatting.5.5 98E Date formatThe 98E format of the generic Date/Time component 98a is a new 2007 introduction. Primarilydesigned for trade reporting purposes in line with the European Union Markets in FinancialInstruments Directive (MiFID) this field is likely to cause some issues in terms of its complexity.Transformer and SWIFT MT Messages Document Version 1.1, 13/09/2010 9
  • Whilst at its most basic form it supports a date/time construct just like the 98C format it alsoallows for, optionally and independently, decimal fractions of a second, hours and optionallyminutes plus or minus from the stated time to handle time zones. The format along with thestandard SWIFT approach to negative numbers, an optional N is likely to make this a challengingfield 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 minutesTransformer handles the date and time portions as Business Object Types removing any concerns offormats. For the optional parts it helps by handling the formatting of the subfields. Simply set themilliseconds part and the leading „,‟ is handled automatically. Pass in a time with a time zonebehind GMT and the N is provided by the software.5.6 35B Identity of instrumentThe Identity of Instrument field, 35B, is obviously a very common field in the securities field. It isalso a unique field as it has two optional parts and needs a Network validation rule to ensure thatdata other than an empty tag is supplied. It is also the only format of field that requires a fixedliteral 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 #1The preferred format is of course the ISIN value. Without this coded value, any form of STPbecomes difficult. Indeed this is an SMP guideline for using this field. However some back officesettlement 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 lookupfacilities 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 wherenecessary. A typical routine might well be to take the back office code, possibly with a „type‟ valueto drive a database lookup. The returned code could then be simply mapped straight into the ISINvalue.10 Transformer and SWIFT MT Messages Document Version 1.1 13/09/2010
  • 5.7 7775 Party fieldsBecause the 7775 standard fields do not have a means of identifying specific party types by meansof a qualifier (e.g. :95P::BUYR//ABNANL2A indicates the buyer), they need to use different SWIFTtags for the various parties. This leads to the situation where the following formats are regularlyused for parties:50a, 51a, 52a, 53a, 54a, 55a, 56a, 57a, 58a, 59, 59A, 82a, 83a, 84a, 85a, 86a, 87a, 88aEach 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 challengebut Transformer holds of the various parties 51a, 52a, etc. based on the same underlying Partystructure.Transformer and SWIFT MT Messages Document Version 1.1, 13/09/2010 11
  • As an example here is the structure held for the Fund or beneficial customer on an MT300For this field, tag 83a, only formats A, D and J are valid and the rest have been prohibited withinTransformer. This means that the same party structure is visible everywhere and the mapping rulesrequired to handle a party in any form in any of the 7775 message sets can be written once, testedonce and used wherever necessary with guaranteed results.5.8 15022 Amount and Party BlocksIn 15022 messages, amount and party information is conveyed in blocks delimited by 16R/16Swithin which one of the fields carries a qualifier indicating the role or significance of the party oramount concerned. For example, in the following extract from an MT540 message, a buyer, sellerand 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 ignorethe fact that the seller‟s safekeeping account could be in any of the repetitions of the 16R:SETPRTYblock in the message, and extract the information as simply as if it were in a designated field in afixed width message. In the example above the analyst would simply copy the field:Block4/SettlementDets/SettParties/Seller/Accounts/SafekeepingAcct/OptionAto access the Sellers Safekeeping account AB12323 as required, selecting the field from thedefinitions using the mouse. If the field were missing, no errors or complex logic would be required.12 Transformer and SWIFT MT Messages Document Version 1.1 13/09/2010
  • Transformer simply maps the named value if present or ignores the mapping action if the field ismissing. This behaviour is of course controllable as required.Compare the simplicity of this with many solutions that require looping through all of the SETPRTYentries 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.Transformer and SWIFT MT Messages Document Version 1.1, 13/09/2010 13
  • 6 Mapping6.1 GeneralIn line with Transformer‟s design aim of addressing Business Analyst requirements when it comes toimplementing mapping functionality, mappings using SWIFT definitions appear to a user just likeany other mapping, irrespective of whether the messages involved are XML, fixed width, CSV, FIXetc. The business analyst does not need to know the format of a SWIFT message or any of thedifficulties that the definitions may provide. There is no worrying about setting up of the 16R/16Scombinations around blocks or making sure that the qualifier is set, all of these functions areprovided automatically just by using the relevant fields.Having said that, this information is available if required and allows users to view their output in itsfinal form as a check mechanism.6.2 Dynamic testingTransformer has integrated testing for all of its configuration items. The message definitionsthemselves are tested extensively with a comprehensive suite of test data. These same testfunctions are available for testing mapping definitions. Simply by providing input data, the resultsof running the mapping can be seen and, more importantly, retained within the Transformerdefinitions. This allows for full regression testing of mappings and ensures that any unforeseen sideeffects 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 andtest the effects of individual mapping actions in design mode. This dynamic testing facility is a verypowerful 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 beentransformed 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-clickmenu, the entire field can be seen in its final context. Selecting the TradeDateTime field gives:14 Transformer and SWIFT MT Messages Document Version 1.1 13/09/2010
  • 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 actionsIn an earlier section, the ability of Transformer to define standard structures to represent commonfields has already been discussed. Using this, consistency can be introduced to complex definitionssuch as parties. Transformer extends this functionality into the mapping area. Here it is possible todefine mappings between the component type structures. These generic routines can then be usedwherever specific instances of these formats occur.Consider an example from the mappings necessary to share information between MT and their XMLcounterparts the MX messages. In the MT messages, the Transformer SWIFT library has a standardformat for the party structure.Transformer and SWIFT MT Messages Document Version 1.1, 13/09/2010 15
  • 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 orproprietary code. Obviously the mapping functionality between the two is quite complex andrepeating this every time a party needed mapping would be quite onerous.Transformer addresses this by allowing mappings to be defined between the component types andthen for these to be used anywhere a structure of the relevant type is required. The effect of thisreuse of mappings is that they can be developed and tested extensively in isolation and used in theknowledge of their accuracy. To map between two parties becomes as simple asThe field names may look complicated but they have been selected from the definitions to map theInvestor to the relevant field on the MX Redemption Order. This one action will handle all of theBIC code or name and address formatting issues as defined in the MT_To_MXParty reusablemapping.6.4 SWIFT mapping functionsEven with Transformer‟s advanced functionality in terms of automatically handling formats anddata types there are situations in the SWIFT environment where additional help is required. TheSWIFT library in Transformer provides some specific mapping functions that can be used to handlethese specific situations.6.4.1 Multi-line text routinesMany SWIFT fields are made up of sub-fields that are effectively multi-line text fields. There arename & address fields, narratives, security descriptions etc. Technically in SWIFT terms there is nodistinction between the lines of these fields, they are all one sub-field. In the real world howeverthere is a need to get at these individual lines and Transformer provides several mapping functionsto assist.There is often the additional complication of continuation line characters and these can be quiteproblematical in traditional string manipulation languages and products.16 Transformer and SWIFT MT Messages Document Version 1.1 13/09/2010
  • 6.4.1.1 Mapper CopyMultilineTextConsider 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 CHTo process this into a single narrative field could be quite tedious so the CopyMultilineText mapperis available to achieve that. It has options to preserve newlines, replace them with a space ordiscard 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 EACHIf 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 : SG1L51001825Here preserving the format could be important and an option is available to retain this.6.4.1.2 Mapper CombineMultiLineTextIf you need to set a multi-line text field and formatting is important and you need to know what isgoing into each line of the field then this mapper can help. Effectively you build up the contents inan array of strings and pass the array to the mapper to output the combined field.6.4.1.3 Mapper ExtractMultiLineTextThis mapping function provides the opposite of CombineMultiLineText. It takes the SWIFT field anddelivers it into an array of string variables to be processed as necessary.6.4.1.4 Mapper GetLineIf you know which line of a multi-line field you need then this mapping function will extract thatparticular line into a single output field.6.4.1.5 Mapper CopyFromMultiLineTextConsider a field: :72:/ACC/Payment for further credit to //subsidiary ABC, US, MiamiUsing the other multi-line mapping functions will happily return each line of this as a separatestring but dealing with the continuation characters // can be problematic.This function will automatically remove these characters and combine the string using a value asappropriate, typically a space.6.4.1.6 Mapper CopyToMultiLineTextThis function provides the converse of the preceding function. If you have a long string that needsbreaking up into chunks with continuation characters then this can be quite challenging withconsiderable amounts of string manipulation and length checks. This mapper provides thisTransformer and SWIFT MT Messages Document Version 1.1, 13/09/2010 17
  • functionality automatically with just the need to specify whether the string should be split at wordboundaries or precisely at the field width.6.4.2 Working with BIC codesMost of the time a BIC is simply an 8 or 11 character value. However it does have a structure and ismade up of the following sub-fields: 4!a Bank Code 2!a Country Code 2!c Location Code [3!c] Branch codeTo make these subfields available when required the BIC mapping function is available.6.4.3 Processing the Category n messagesEach 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 ofthese, n92, n95, n96 contain a special field which is the contents of block 4 of the message towhich they relate. In effect they contain a message within a message. Technically this means thatat 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) tospecifically assist this process. These functions allow the entire block 4 of the message to behandled as a unit whether being used to create the n9n message or to interpret the output of ann9n message.6.4.4 7775 Party fieldsAs has been explained earlier the 7775 party fields are all based on a single Transformer componenttype. However the individual formats still present some difficulties in accessing their contents. Inparticular, formats A, B and D all contain a pair of fields which together form the sub-field PartyIdentifier. 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 theseindividually, two mappers are provided. GetPartyIdentifier will return the two separate valueswhilst 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-fieldis: 5*40xA simple enough multi-line field but this field is different. Its contents must consist of pairs of codeand value, separated by / characters. For example: :87J:/ABIC/AAAABBCC/ACCT/ABC12345678901/NAME/ 12345678901234567890123456789012345contains the following entries: ABIC AAAABBCC ACCT ABC12345678901 NAME 1234567890123456789012345678901234518 Transformer and SWIFT MT Messages Document Version 1.1 13/09/2010
  • To work with this type of field two mappers are provided. PartyJToTemp will take the SWIFT fieldand return an array of the code and value pairs. TempToPartyJ does the same thing in reverse.6.4.5 Accessing SWIFT metadataEven with Transformers tight data definitions and the structure embedded in the mappingsthemselves, 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), theformat (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)Transformer and SWIFT MT Messages Document Version 1.1, 13/09/2010 19
  • 7 Reference viewOne of the biggest issues in dealing with any messaging system is the ease with which changes canbe identified and Transformer provides facilities specifically to deal with this by means of itsreference view and ability to easily display constituent parts of a definition. This allows the impactof changes to be identified quickly and effectively. Consider the annual problem of incorporatingthe new SWIFT message definitions.Each year SWIFT produce a new set of changes consisting of new fields, amendments to existingentries and the deletion of entries. Each of these produces unique challenges. Consider the changein definition of a field. In 2007 SWIFT introduced a new date format 98E which contained the abilityto specify fractions of a second along with time zone information. In terms of mappingspecifications, this could be a major issue. A mapping may work perfectly with the existing 98Cdefinition (date and time) but could now receive the same information on a 98E format field. UsingTransformer it is possible to identify the base component type that handles all date formats in theSWIFT library, DateTime. By using the reference view it is possible to see that this component typeis 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 useformat E, select part of that format and check the Exclude Prohibited field. This removes fromdisplay those configuration items that are based on DateTime but explicitly prohibit format E. Whatis left are the items that need to be considered in terms of the change to the SWIFT definitions toallow 98E.20 Transformer and SWIFT MT Messages Document Version 1.1 13/09/2010
  • 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 havebeen expanded in the example. From this we can see that if we use an MT513 and theTradeDateTime in the OrderDetails sequence then 98E is available for this field. Similarly, clickingon the Actions tab will show details of all the mapping actions that reference this field. Obviouslyfor 98E there will be none yet but by analysing the use of 98C the work involved in adaptingmappings for 98E can quickly be discovered.In this selected example taken from the uses of 98C in the TradeDateTime the uses of that field inmappings can be seen. It is likely that these uses and those for 98A may need to be modified toallow for the 98E field in the future.Here there are two mappings involved, BackOfficeInbound and Settlements for the use ofTradeDateTime in the Msg_540_grp item. It is possible that these two mappings would need tochange to incorporate an entry for 98E.Transformer and SWIFT MT Messages Document Version 1.1, 13/09/2010 21
  • By selecting the Actions tab at the top of the reference view, details of the individual mappingactions for the selection can be seen:This pane shows the individual mapping actions that use the node DateTime/OptionC/Date. Thereare no details displayed for the mapping Settlements because whilst the field is available to thatmapping there are no actual mapping actions that use the field. From the information displayed itis clear that the OptionC/Date field is used in a Copy action from the Msg_540_grp to theBOTrade/TradeDate field. Since OptionE supports a similar date format it is likely that this mappingwill need to be enhanced to include a similar Copy action for OptionE.Analysis such as this, when combined with Transformers inherent regression testing facilities meanthat the annual library changes can be incorporated quickly and reliably.22 Transformer and SWIFT MT Messages Document Version 1.1 13/09/2010
  • 8 Validation8.1 Transformer’s Facilities for Validation LayersTransformer‟s design incorporates the fact that messaging requirements incorporate differentkinds, or layers, of validation. These may include validation which is part of a generic messagingstandard, such as SWIFT, validation specific to particular markets or products, validation whichrelates 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 particularrules 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-readableform, this information is available programmatically for message routing purposes.8.2 Format validationAs part of its normal operation, Transformer will check that every field it receives matches thedefinition it is expecting regardless of whether SWIFT is being used or not. This will check theformat 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 ofthe correct format. For example, a date must contain a date in the specified format, numericvalues dont contain alphabetic characters etc.8.3 Standard validationFor 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 standardwith Transformer.8.4 Network validationAll of the standard validation described in the previous sections typically relates to single fields orsubfields. The SWIFT standards also define many additional rules that either apply across two ormore fields or cant be defined using the standard SWIFT definitions. These are termed NetworkValidation rules and are defined at the individual message level. Each rule in Transformer can havean error code and message assigned and these are returned to the user or calling application whenthe rule fails. As standard the SWIFT library uses the SWIFT error codes and messages asappropriate.Some of these rules are very specific and clearly only apply to the message against which they aredefined. However, others are more general and apply across messages. Transformer assists greatlyin 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 presentIn Transformer this is defined as a Condition DefinitionTransformer and SWIFT MT Messages Document Version 1.1, 13/09/2010 23
  • This simple Condition Definition is then applied to the component IdOfInstrument itself as aValidation Rule. These two definitions, the Condition Definition and the Validation Rule mean thatevery IdOfInstrument field throughout the SWIFT definitions will have this rule appliedautomatically.Rule T17 is relatively simple but the Network Validation rules can be quite complex. Here is onesuch 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 messagesthat 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 toMT544-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 ruleagainst eight separate messages…24 Transformer and SWIFT MT Messages Document Version 1.1 13/09/2010
  • 8.5 Additional validation schemesAll 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 completelyproprietary or they may be SMP (Standard Market Practice) guidelines or other standards bilaterallyagreed between counterparties.In all cases, all of the functionality described for Network Validation rules can be applied toadditional rulesets at will.Transformer and SWIFT MT Messages Document Version 1.1, 13/09/2010 25