About Us  |  Search  | FAQ  | Contact Us
Risk Management
Human Resources
Smarts Cards
Optimise CRM
Data Warehousing
Disaster Recovery
Swift Messaging
BPM & Workflow
Capital Markets
Global Custody

Page last updated
February 15, 2003




SWIFT and Easy Messaging......Not jolly likely


It might be the thought that pops into mind, if you have been involved as deeply with S.W.I.F.T. (Society for Worldwide Interbank Financial Telecommunication) messaging as I have.

Actually, SWIFT and Easy might appear to be an oxymoron (oxymoron: a contradictory expression, such as "military intelligence", "government efficiency"). SWIFT messaging is certainly not trivial - personnel needs training and experience to get a grip on SWIFT, and a whole industry has evolved to aid in connecting and processing SWIFT enabled applications. So, what is it that is so special about SWIFT?

From Revolutionary to Maiden Aunt
SWIFT started about 25 years ago. In those days electronic data transfer was nearly unheard of and terribly modern. 12 years ago I myself got my first modem and connected to Compuserve from home, over the phone; and had intense discussions with IT-professionals that disputed that such a thing was even possible (one of my colleagues started believing me and was totally in awe when I transferred a file for him). Then, about in 1995, I started using the internet and got much the same reaction from IT-folk in large corporations ("...only for a small community, too insecure, will never be part of our strategy.."). In those days, when you searched for "SWIFT" on the internet, you got naughty pictures of a naughty lady named Stephanie Swift, who claimed to be "the real Swift"; S.W.I.F.T. themselves then had no presence on the internet.

So, 25 years ago, worldwide telecommunication as SWIFT was doing it, really was revolutionary! However, in the meantime things have changed rapidly and SWIFT technology has become so established and downright old-fashioned as the proverbial maiden aunt (who obviously managed to get rid of sexy Stephanie).

Next Generation
After 25 years, there is a new generation of users and developers out there and it makes sense to review the whole set-up. Back in 1997; if I remember correctly - SWIFT addressed this issue and promised a "Next Generation", as it was aptly called. The first step in the new architecture is a new communication design. Changes in the security features and message standards are soon to follow. While on the one hand it will be nice for developers to use newer technology (IP rather than X25, PKI rather than BKE, XML rather than CrLf delimited lines), on the other hand: are there additional benefits to be gained at all? Will messaging get easier? Or are we simply letting the next generation of users/developers do their own thing and make the same mistakes as before but on a new platform? (I have a cynical streak, maybe a side effect of being a SWIFT oldie and of having teenage kids). In order to be able to measure success or failure, the benefits and drawbacks of today's SWIFT need to be assessed; we can then think about our visions for tomorrow.

Fast, and; nearly even more important; secure transmission is one major benefit. Banks have high security requirements. Today this is taken care of with BKE, authentication and encryption (encryption is optional in most situations). Reliability of transmission is achieved by implementing a high level protocol (sequencing and acknowledgement, windowing) as well as a low level protocol (multiplexing). In the past the transport protocol was changed from BSC to X25 and it would have been easy to now take it to IP. For additional safety encryption could have been made mandatory. But SWIFT is taking it one step further and wrapping it all up into an API, which will be mandatory to use when connecting via IP (thus keeping the workings inside it secret).

In my opinion, what genuinely makes SWIFT an authority in itself is the issuing of standards and the combination of the network and the standards. This is the true added value over a simple telecommunications provider: messages are syntactically checked and only positively acknowledged when correct. This ensures correct implementation of standards and avoids lengthy discussions between parties. Standards are language independent and neutral (numeric field tags). One of the things that really always impress me positively is the international community coming together and co-operating on common goals and a common idiom.

I am not really sure that I am pleased about the introduction of the SWIFTNet Link API (SNL), because now we depend on the workings of a third party (SWIFT has bundled third party software into the API) and through-put, ease of installation and platform independency have been lost. The Swiss national clearers Telekurs and SIS have just lately decided to go with the other approach: simply change the transport protocol to IP and encrypt - but keep everything else the same as before (while the Swiss corporate bodies are adverse to changes by nature and in general, here I tend to agree with them because first tests with our equipment have shown a much better through-put and an easier migration than with SNL).

While I value the SWIFT message standards highly for being a standard per se, it does not mean that I like their format; I don't. However, efficient communications needs some system of variable length tagged fields, and the numeric tags make a field unique and language neutral. Today there are new methods available (I shall speak a bit about XML later on). Again, I am not totally impressed with some of the newer standards; ISO15022 is certainly more systematic than the older formats (e.g. sub-field components are always separated in the same way, sequences are always indicated by a start and an end tag), but allows too much variety (actually field tags have been extended with help of qualifiers and an inflation of qualifiers is now upon us; together with an inflation of complex network validation rules needed to keep the syntax valid). If you look at the lack of support for ISO15022 data entry in the vendor community and the lacking readiness of many banks for the November 2002 standards, that will give you an indication that not everybody considers ISO15022 the greatest invention since pasteurised milk (as some marketing efforts would lead us to believe).

Another drawback is the creation of the standards; the democratic procedure of standards developments in international committees has in the past led to badly structured standards (you can't expect everybody to be a banking and an IT specialist at the same time). As a matter of fact I have heard anecdotes and seen protocols of some meetings that make me wonder how the work ever got done... Also, with the qualifiers in the ISO15022 we have left the ground of language neutral fields (qualifiers are derived from English) and the SWIFT XML drafts I have seen use lengthy English expressions.

For a while EDIFACT had been praised as a candidate for future messaging standards. While undoubtedly a lot of effort went into international standardisation and all sorts of business areas were covered (not only banking), EDIFACT in my opinion has suffered from its implementation as a bilateral agreement without a central authority such as SWIFT. A consequently logical structure is a great help for the building and interpreting of messages; but here EDIFACT has been overtaken by the abilities of XML.

Among colleagues I have heard the remark that "the XML fad will pass and go the same way as the EDIFACT fad"; in other words: just sit tight, do nothing and wait for it to go away. I couldn't agree less with that assessment. XML actually does exactly what SWIFT has done for the last 25 years: provides tagged fields, allows for optional or mandatory presence, for sequences and repetitions. But it is not simply a different flavour of the old notation: there are standard products (XML parsers) that understand the syntax, can check it and can make any atom of information available directly (like: "get me all fields with a currency data type", or "get me field 32B in sequence C"). Now, of course XML standards can be done efficiently or less efficiently, there is no inherent guarantee for a wise implementation. What is, however, truly useful is the possibility to deliver a DTD or Schema (a kind of grammar to validate the XML) and to transform XML into another XML structure or into HTML or PDF with help of XSLT. (If you have never heard of these abbreviations before, don't worry. Just trust me: there are programmers and software out there that can deal with it.)

The Internet has become part of our lives. I have heard that a fast Internet connection is now expected as a standard part of the office rental contract in Zurich; and that companies won't consider renting premises that don't have it. Would you have imagined this a mere decade ago? It is the Internet that has given birth to HTML, XML and TCP/IP; all of them standardised, platform independent technologies. There are huge opportunities connected to this environment, and yes, the e-bubble burst. Not surprising with all the exaggerated claims that were made. We now have lovely powerful hardware and developer's toolkits (when I started programming it was coding sheets and a pencil, come into the bank at night to use the production environment for testing, the mainframe had 1 MB RAM), but programming is just as slow and bug-prone as before (programs now have to be graphical and sophisticated, hardware, operating systems and programming paradigms change approx. every 2 years). So, the industry is only just catching up on new technology (including SWIFT).

The Vision
Where is all of this taking us? The Internet is currently being used very well for content management, such things as e-learning (web-casts, webinars) and customer support. SWIFT is doing a good job along those lines. The next step is building browser-based applications for the Internet. Hardly any of today's available interface products can do that. What would truly be terrific would be for SWIFT to distribute the SWIFT User Handbook on CD not in HTML but in XML format. Such intentions have been announced but not yet followed through with. Imagine doing your yearly standards update by copying the CD onto your intranet SWIFT web-server and thus automatically getting all updated data-entry screens plus validation (and of course the online documentation). Or a service bureau or even SWIFT themselves could run their own web-server and provide connectivity over the Internet. Another nice variety would be to provide subscription to a SWIFT web-service. Today you can get online information on SWIFT BIC codes by registering and logging in to the appropriate screen on www.swift.com. A bit tiresome to do every time you need it. A BIC web-service would provide an XML-based protocol ("SOAP") to allow your home-grown browser application to integrate BIC lookup into it; the data is requested in the background without the user noticing that another server is being accessed

Funnily enough the Internet revolution is taking us back to a centrally located CPU, which delivers data to a dumb terminal; but with the ability to choose from servers all over the world; not just your own enterprise.

This, I think, is something to look forward to and which is really worth waiting for.


Elisabeth Lehmann
Founder and CEO
AnaSys AG


MT 103




Home  |  About Us  |  Search  | FAQ  | Contact Us