SWIFT Standards : History & Introduction

7/27/2019 SWIFT Standards : History & Introduction

1/13

The SWIFTStandards story

Towards the goal of a single standardfor the financial industry


2/13

How it all began

SWIFT was created in 1973 by 239banks from 15 countries with theobjective of automating the telex.

Their vision was to harness emergingcomputer technology and manoeuvrearound the telecommunications

monopolies to send standardisedfinancial messages betweenthemselves, securely and reliably.

Today, with over 7,400 members,participants in 200 countries anddaily message volumes of morethan 10 million, SWIFT demonstratesthe amazing success of their visionand courage.

Who could have predicted thatstandardisation would still be a drivingforce for the industry and so stand asone of the core components of SWIFTtoday 30 years later?

This guide sets out to chart the historyand philosophy of standards at SWIFT.It shows the direction thatSWIFTStandards is now taking torealise its ongoing mission of servingthe communitys needs and topursue the long-term vision ofa single standard for the wholefinancial industry.

"The key to SWIFTs success in standards is our community.The cost savings and efficiencies resulting from our jointdevelopment of standards and rules in payments, treasury,trade and securities are incalculable." Leonard H. Schrank, CEO,SWIFT

"For us, the financial industry,SWIFT is essential to achieving sustained successin the convergence to common standards andbusiness practices." Roland Bff, Senior Vice President,Bayerische Hypo-und vereinsbank.

Member of the SWIFT Board of Directors.Chairman of SWIFT's Pricing Board Task Forceand Standards Committee.

2,300 shareholders - the broadest representationin the financial services industry

170 National Member and User Groups users who face standardisation issues every dayin their businesses

Standards Committee -direct Board oversight drawn

from the 25 independent SWIFT directors

Hundreds of industry experts - have to dateparticipated in the development of SWIFTStandards

ISO 15022 Registration Authority SWIFT registersmessaging standards for the securities industry on behalfof the International Organization for Standardization

ISO 20022 (UNIFI) Registration Authority SWIFTregisters data objects, messaging standards forthe financial industry on behalf of the InternationalOrganization for Standardization

ISO and UN/CEFACT SWIFT works with

the international standards setters

Numerous standards bodies and groups in and beyondthe financial industry - SWIFT has agreements/workingrelationships with these groups or sends peopleto their meetings

SWIFT in standardsStandards in SWIFT

40 expert employees currently dedicated to

standards development, implementation and

convergence activities at SWIFT


3/13

The initiative to create a central po intfor the passing of secure, standardisedmessages came from banks primarilyinterested in payments messages tosupport clearing and settlement. Today,over 200 different SWIFT messages

exist in response to the requirements ofthe main business functionalities in thepayments, treasury, securities and tradeservices markets. These include creditand debit instructions, buy and sellorders, documentary credits,collections, guarantees, interbanktransfers, reporting, settlement,custody, travellers cheques andprecious metals.

SWIFT standard messages arecomputer-processable versions of thetelexes they replaced. The SWIFTlanguage, known as FIN, is heavilyinfluenced by the telex. Effort was spentto ensure compatibility between existing

telex information and SWIFT electronicinformation flows, meaning that theprinted version of a SWIFT messagelooks very similar to its correspondingtelex version.

FIN messages were standardisedas there was common understandingbetween the sender and receiver as tothe meaning of the information passedfrom one to the other. By definition, astandard is a way of doing things that

is followed by all parties that wish to dothis thing. Building consensus is asignificant undertaking in the businessworld, where differentiation givescompetitive edge. But the communityrealised that collaboration could be awinning strategy. FIN-based standardsare successful because they provide acommon language for all SWIFTmember financial institutions and theymeet real requirements.

This approach to standardisation atSWIFT worked well for the industryfor the following 25 years, expandingto embrace the messages needed bynew financial industry players as they

joined the SWIFT community.

But, as the millennium drew to a close,dramatic changes had begun to impactthe business environment. Globalelectronic communication, encouragedby the growth of the internet, becamean integral part of everyday business

life. And, at the same time, shorteningtransaction processing cycles droveusers to seek standards that could offermore functionality and greater value.

From an economic viewpoint,the squeeze had started, forcing thefinancial industry to give more thoughtto reducing costs through increasedautomation, as well as maintainingrevenue streams. As financialinstitutions sought to differentiatetheir offerings, they introducednew business transactions tocreate competitive edge.

The new demands created bythe need for enriched data exceedethe technical capacity of the currentSWIFT messaging standards.

The first quarter century

Drivers for change a new millennium approaches

2


4/13

A new generation of standardswas required. SWIFT surveyed itsmembership to discover precisely whatwas needed to meet the changingbusiness conditions in the financialindustry. Following consultation with

a spread of market players, it becameclear that a number of requirementswere overwhelmingly important inconsidering the future evolution ofSWIFTStandards.

Standards from end-to-end thecommunity cited the fundamentalrequirement for an approach tostandards that addresses their businessneeds end-to-end, ie, taking intoaccount all the players and all the data

that they exchange in the transactionchain

Scenario-based standards marketpractice leads to a situation where theexact use of standards depends onlocal market factors, such as regulatoryrequirements in a given country. Moreflexible - but precise - standards areneeded to meet these needs

Use of new technology - businessinformation modelling, data dictionaryconcepts and computer-processabledocumentation were acting as catalystsfor using more sophisticatedapproaches to developing andimplementing standards

Standards for store and forward

mode, but also for interactive dialogueand file transfer - as this requirementcoincided with SWIFTs move to anInternet Protocol-based (IP)communications platform, this wishwas well-timed to become a reality.

The industry also expressed anambitious long-term vision, thatof converging to a single industrystandard achieved throughinteroperability of existing standardsand, ultimately, common syntax.

Based on the fundamental needscited by the community, SWIFT beganto follow a new, highly-structuredapproach to developing standards thatis driven by the business requirementsspecified by the industry an approachwhich has now become an internationalstandard.

Business requirements drive standards evolution

New standards development process

5 InternalRepository

Automatedpublication

6 Standardsdocumentation

Validation

2 Business ValiGroup (per pr

Scope & requirements

Feedback

3 Modelling Group(per project)

Businessinput

4 Standards, Workstation,methodology & guidelines

4

1 Businesscase

Population(business modelling)

Standardisation requirements areproposed by the SWIFT community,developed with the community andimplemented by the co mmunity.

Those financial institutions who committo become part of the development

exercise are alsothe first users.

1. A business case is built oncommunity requirements and approvedby the SWIFT Board.

2. A Business Validation Group (BVG),composed of industry experts,review this and scope out the project.

3. A Modelling Group (MG), composedof industry experts, capture the specific

business information.

4. SWIFTStandards experts buildthe model from this, using themodelling methodology.

5. SWIFTStandards expertspopulate the internal repository.

6. After validation by the BVGand finetuning through theModelling Group, the standardis published automatically.


5/13

Payments Securities Treasury Trade services

SWIFTs new business standards

Now that the process is in place,new SWIFTStandards can be readilydeveloped as market needs prescribe.

These portfolios of s tandards are madeavailable for organisations to integrateinto their own solutions. SWIFT also

combines selections of its newstandards with the IP-based SWIFTNetmessaging services as packagedSWIFTSolutions. These areimplemented in accordance withrulebooks by specific closed usergroups in the community to meetparticular business requirements.

SWIFT has chosen to represent itsnew standards in XML syntax, butwhere business is stable and needsare met by the current FIN-basedstandards, these traditional messageswill remain available as long as theyare required by the specific marketand are economically viable.

The goal is to provide end-to-endstandards for the community as

required in each of the markets thatSWIFT supports. Good progress hasbeen made, as the mid-2004 statusfor each of the financial marketscurrently served by SWIFT shows.

6

Initiation

Clearing and settlement

Reporting

Corporate to bankpayment initiation

Bulk credit transfers

Cash management

Direct debits

Exceptionsand investigations

Pre-trade/trade

Pre-settlement

Reconciliation

Post-trade

Corporate actions

Investment funds

Pre-trade/trade

FX order and response

Confirmations

Netting reports

Derivatives - FRAs, single& cross currency IRS

Interest rate swap

Guarantees

Collections

Letters of credit

Trade services utility(prototype)

Trade services utility

Traditional SWIFTStandards New SWIFTStandards available Future SWIFTStandards


6/13

Whilst the requirements andbusiness expertise for developingSWIFTStandards is provided bypractitioners in the industry, the processrelies upon tools, such as the modeland the repository, to turn their needs

into reality.

Why build a model? One might equallyask the same question for any project building an aeroplane, designing a newgadget, mapping out a complexbusiness proposal. Going through thisprocess helps to focus, spot overlapsand gaps, and ensure the logic isappropriate.

In the standardisation context,modelling consists of three layers.

The business layer focuses onunderstanding the business,independently of the solution that

will be used to meet its requirements.At this level, a model is produced torepresent the roles of the players,business activities and data involved.Using the analogy of an architectswork, this phase can be compared toa checklist identifying for what purposea building would be used, who will livethere and do what, how much spaceis required for the activities and thekind of infrastructure needed.

Based on the models produced,the logical layer specifies how thebusiness data can be exchanged ina structured way, following a numberof rules. This layer can be comparedto the initial sketches that the architectdraws based on client requirementsthrough to the detailed plans.

There is also a third layer, the physicallayer, which delivers messages andrules in the appropriate syntax orprogramming code. This phasecorresponds to the concrete executionplans for the bricklayers, plumbersand electricians, where the actualmaterial is defined.

The methodology for this new businessinformation modelling uses UML(Unified Modelling Language) notationsoftware, which is syntax-independent.

This means that the model can be builtand remain valid, whichever syntax

may be chosen for the third physicalrepresentation layer. In effect, thestandard is created with the buildingof the business information model inthe logical layer.

The main benefit of this approachis that the business discussions areseparated from the delivery of thestandard messages. Modelling providesan abstract, technologically neutraldescription of the solution that actsas a bridge to the concrete, technicalimplementation. The model providesthe global end-to-end view of anybusiness, a stable source from whichdifferent messages meeting a varietyof needs can be produced.

As explained, modelling consists,amongst other considerations,of identifying the business players,business activities and data involvedin a scenario. Each item is defineduniquely. An order date, cash

account or settlement amountalways has the same meaning.

In using the new, more formaland business-centric standardsdevelopment approach, a uniqueand unambiguous list of businessobjects, as they are knowntechnically, is created. Theseobjects are listed in a central datadictionary, which can be consultedin the same way as one consultsa traditional dictionary.

As the new standards developmentprocess is repeated to build modelsfor different businesses, modellersand implementers benefit from thereusability of the business objectsthat have been previously input to

the dictionary. Objects can be reuseby the customer to build applicationin whatever way is needed to meetthe requirements of the particularbusiness or institution. Design rulesare provided to ensure that this canbe achieved without introducingdivergence.

Modelling key to the standards development

and implementation process Objects the building blocks of standards

8


7/13

The dictionary is only one componentof the overarching financial industrymessaging standards repositorymaintained by SWIFT on behalfof ISO (International Organizationfor Standardization). In addition to

the common business objects, allsupporting messaging standards-related information can be storedthere for the financial industry,including:

Business components used intransactions across all markets

Business models

Formats (messages and theirrelated structures logical

and physical layers) Processing rules

Effectively there is no need to reinventthe wheel when developing andimplementing standards. Do-it-yourselfstandardisation is renderedunnecessary. This saves resourcefor the individual organisation and

guarantees consistency of usageacross different businesses andmarkets.

Using the repository to its full potential,customers will be able to downloadmodels and formats that can almostbe plugged in to their own systems.Such ease of implementationencourages parties to use standardisedmaterial, safe in the knowledge thatthey will be following an approach thatis in line with the international standardssetters and adopted by more andmore of the financial industry players.

The choice of syntax is madeat the third layer of the modellingmethodology the physicalrepresentation of the standards.

To continue the earlier analogy ofbuilding a house, this could be the

shape and colour of bricks usedin the building that determine theappearance of the house.

Any syntactical language could bechosen to represent standards, but

XML is perceived as the de facto syntaxfor communication between varioussystems running on disparate platformslinked through internal or external IPnetworks.

Two main drivers led SWIFT to chooseto deliver its new standards in XML.Firstly, back in 1998 when technologicalevolution, increasing complexity ofbusiness requirements and abroadening of its business coverageled SWIFT to overhaul its approach tostandardisation in order to increase the

value delivered to the community, theFIN language needed evolution totackle new opportunities. The obviouschoice to completely re-engineer thesyntax - was rejected because of themajor impact on the entire community.It was deemed far better tocomplement FIN, as required formore complex businesses, byadoption of a different syntax.

The clear candidate was andstill is XML.

Secondly, XML has the advantageof being a major industry trend, in linewith the general move to openstandards (like IP technology and PKIsecurity). As part of a broader familyof languages, it is also universally

accepted by the soft ware industry,resulting in many implementationtools and products being commerciallyavailable. It is used by bothinternational standards setters, suchas ISO and UN/CEFACT, and majortechnology companies like IBM andMicrosoft.

Strict design rules are still appliedto ensure that the syntax is not usedloosely or in a way that could lead tomisinterpretation. This is a further keycomponent of successful standardsdevelopment. SWIFT enforces the rulesin its tool set to generate XML in aconsistent way.

But, for any institution, adopting XMLpresents a major change in IT

architecture, requiring time, planningand adoption costs. SWIFT consultedfinancial institutions and softwareproviders that have practical experienceof adopting XML. All confirmed thatthey opted for XML as part of thetechnology choice when redesigningtheir internal architecture. Indeed, XMLis then used as the common internalformat which allows the streamliningand automation of intra-organisationtransactions between multiple legacysystems.

However, faced with strict cost savconstraints and eager to ensure reton investment, financial institutions not moving to XML unless theirbusiness requires the data richnessthat XML provides. Specific concern

relate amongst others to the lengthXML messages, issues with procesperformance, throughput andbandwidth, and on how to deal withthe legacy systems. These aspectsare being addressed, but the realityis that simple economics will createthe environment where change isnecessary, as maintenance costsrise over time.

On a global level however, the pointat which the adoption takes place wvary in different markets and busineareas. Institutions move at differentspeeds, leading to a patchy landscain terms of adoption and posingparticular issues for the take-upof XML for communication

between companies.This leads to the issue that SWIFTis currently addressing: coexistencebetween the two languages it uses traditional FIN and new XML.

The dictionary grows into a financial messaging

standards repository

Syntax why XML

10


8/13

And, finally, there is the aspect ofcommunity management where theimpact of different adoption rates,approaches and SWIFTs role haveto be evaluated.

However, one thing is certain. Theparallel existence of FIN and XML-based standards continues for the timebeing, as it gives users greater choice.

This is already a reality in the paymentsand securities markets. This flexibilityfulfils the need for richer data for thosewho choose to use it, and it helpsbridge the different pace of adoptionwithin the community.

The immediate challenge FIN/XML coexistence

Coexistence between FIN and XMLconsists of creating:

compatibility - agreement on thestandard way to convert basic data,such as amount, price, date

interoperability - agreement on theway to use data, expressed in eitherlanguage, in support of businesstransactions, without impact on theirexecution

transparency - the possibility to useeither language without any data lossor even needing to know whatcounterparties use

Agreeing on an approach that meetsthe SWIFT co mmunitys requirementsdepends on the reconciliation ofseveral dimensions. From a businessperspective, the specifics of eachbusiness area and its drivers need

to be taken into account.

As far as the technical aspect isconcerned, a range of approaches arepossible from providing basic mappingrules to the community at one end ofthe scale through to full migration to

XML-based standards at the other end.

New business opportunities supportedby the introduction of new standardshave to be investigated to determinethe costs, benefits and return oninvestment.

12


9/13

Introducing a new modelling approachto standards development is essentialto meet the core needs of thecommunity, but the opportunities thatthis opens up for standards evolutiondo not stop with delivery of new

business standards. Now thatstandards development in accordancewith the new process is business asusual for the co mmunity, SWIFT hasmoved its focus towards supportingthe challenges of implementing thosestandards efficiently in the industry.

Alongside its duty of ensuring that theway forward for coexistence of the twomessage standard syntaxes (FIN and

XML) causes minimum disruption forits community, SWIFT is focussing onthe wider-ranging issues of standardsintegration.

On each occasion that a new standardor upgrade is required by thecommunity, the customer (and indeedSWIFT) uses resource and budget toimplement the changes in the relevantsystem applications. Easing the

integration process has the potentialto create substantial cost savings andincrease efficiency for the industry.

Information that can be processed bycomputers provides a key to the wayforward. Machine-processable, asopposed to human-readable, standardscan be injected directly intoapplications limited or no humanintervention is required for the standardto be integrated. Benefits include notonly the savings in expert manpowerand time, but also the reduction inerror and misinterpretation.

XML-based standards are machine-processable and offer an easyintroduction to injectable standards.Indeed, whilst XMLs initial focus was

to provide information about thecontent of human-readable documents,its larger potential as a specificationlanguage for machine-processablemessages has been quickly realised.It has become a very powerful metalanguage, providing information aboutthe structure and meaning of all sortsof data, in a way that can beinterpreted both by humansand machines.

The rapid growth of internettechnology has inspired several newways of communicating, and manyorganisations are developingstandards for these, most based on

XML. But hardcoding XML into

applications is not the solution. Whilstthis offers a short-term fix, the industrysuffers from the drawback of inflexibility.Should the syntax change in the future,considerable work would be needed toeffect hardcoded application changes.

An approach that recognises andbuilds applications based on thereusable objects behind the individualitems in a message avoids this trap.

This is SWIFTs proposition.

To address the issue for the long term,moving from a message syntax-centricapproach to working with standardisedobjects is the best way forward forfuture-proofing business applicationsand for enabling easy mapping byusers into back-end systems.

Looking forward the big picture of standards implementation

14

The concept of injection

To play a video game, one needs a console and a game card.

When a different card is put into the console, the behaviour

of the video game changes it generates different screens,

use of buttons, sound, etc. It works because the console

understands the information on the card and interpretsit correctly ie, the information on the game card is injected

into the console.


10/13

SWIFTs approach to standardisationgives huge scope to customers andvendors to deliver applications thatwill not be rendered obsolete bydevelopments in the future, and whichfacilitate cost savings and straight

through processing today.

However, changing the environmentto use the new flexibility is not achievedovernight. The community needs to beable to maintain, upgrade or replace itsheritage systems at the rate that suitsits own business requirements. SWIFT

has produced an initial range of supporttools and documentation, includingschemas, samples and messagingrules. These are being developed intoa full range of implementation products,such as the electronic repository andtransaction information, to helpcustomers in a variety of integrationscenarios.

SWIFTs efforts to help the industryin the development and implementationof standards extend beyond interactionwith customers and partners in its owncommunity. SWIFT is committed topromoting and facilitating standards

convergence efforts, both inside andoutside the industry, and feels stronglythat a common approach tostandardisation is the way forward.SWIFT sees a vital need to containdiversity and discourage proliferation,so ensuring that expertise, time andresource are not dissipated. Its goalis to help the industry to set its sightsin the same direction and to facilitateprogress along that route.

Numerous message developmentinitiatives are currently underway,driven by communities of userslooking for more cost-effectivecommunications to support specificbusiness processes. This trend is

currently inevitable, with differentconstituencies facing differentstandardisation challenges andpriorities. Whilst SWIFT cannot addressall the various standardisation needsrelated to financial transactions, it ispossible to preserve interoperabilityand consistency between standardsdeveloped by different organisations if a common standardisation approachis adopted.

To be effective, such a commonstandardisation approach had tobe defined and promoted at thehighest levels in the standardisationarena, with the de jure internationalstandards setters. Bodies like ISO

and UN/CEFACT guide the industrytowards the standard use ofmethodologies and tools, and provithe right neutral environment tocoordinate and prioritise developmein the best interests of the financialand other industries.

Tools to support implementation

Promoting standards convergence


11/13


12/13

Since message standards supportthe way business is processed, theyneed to take into account marketpractices, ie, the particular useof the standard to meet the legalrequirements, regulations and specific

domestic system requirements ina country or region. To come to theultimate goal of a single messagestandard would require priorharmonisation of all market practicesworldwide. Whilst such a utopia isprobably unrealisable, SWIFT seesmarket practices as an important partof promoting standards convergenceand plays an active role in facilitatingtheir harmonisation. SWIFT does nottry to change market practices, butsupports them as they evolve, helpingto minimise local market specifics.It dedicates resources to supportthe Securities Market Practice Group,and foresees an equivalent activityin other markets.

SWIFT is deeply committed tostandards convergence. Its work ondevelopment and implementation,its concern for customer usability, itswhole strategy, is concrete evidenceof its belief that standards convergence

is in the interests of its community andthe financial industry as a whole.Indeed, the pragmatic approach thatSWIFT is promoting can be appliedin industry sectors well beyondthe financial arena. Benefits ofstandardisation grow, the greaterthe number of adherents.

SWIFTs ultimate vision is a singlestandard for the financial industry,and its work in harmonising andcentralising standardisation aremilestones along the route toachieving this goal.

Harmonising market practiceTowards the vision

20

1973Creation of Swift

Development of 200+FIN based messagesfor payments, securities,treasury and trade services

2004UNIFI (ISO 20022)

ConvergenceDelivery ofnew XML-based

standards

1998Business modelling

51680-OCT04


13/13

www.swift.com

For more information about any aspect of SWIFTStandards and standardsconvergence, please email [email protected] or visit the Standards pageson www.swift.com

Copyright S.W.I.F.T. SCRL (SWIFT) 2004

All rights reserved. Reproduction is however authorisedwith acknowledgement of the source, reference and dateof publication, and all notices set out here.This publicationis supplied for information purposes only, and shall notbe binding nor shall it be construed as constituting anyobligation, representation or warranty on the part of SWIFT.

SWIFT, S.W.I.F.T., the SWIFTl ogo, Sibos and SWIFT-derivedproduct and service names - such as but not limited toSWIFTNet and SWIFTAlliance - are trademarks of S.W.I.F.T.SCRL.SWIFT is the trading name of S.W.I.F.T. SCRL.Patent pending: SWIFTNet - TrustAct - e-paymentsPlus.

All photographs in SWIFT brochures feature SWIFT employees,customers and business partners.

Documents

SWIFT Standards : History & Introduction