SWIFT first announced details of its 'Next Generation' programme to a packed audience at Sibos'97 in Sydney. Radical plans were unveiled to develop a new network and range of messaging services which would ultimately replace the current X.25 based SWIFT transport network and FIN service.
Since presenting this early vision in Sydney some of the terminology has changed - SWIFTNet now being the preferred name to describe both the programme and the new network. More significantly, SWIFT has been working to take the new network architecture forward, define its service offerings in detail and begin rolling these out, and in parallel develop new product offerings around its SWIFTAlliance brand.
With the announcement of these far-reaching changes coming fast on the heels of other major programmes in the industry (e.g. preparations for the euro, readiness for Y2K, CLS and GSTPA), the majority of SWIFT members not surprisingly focussed their attention on these other, more immediate initiatives and only comparatively recently found time to question what the likely impact of SWIFTNet on their operations would be.
High on the agenda for these financial institutions remains the task of identifying new business opportunities which are opened up by SWIFTNet. Given SWIFT's plans to release the different SWIFTNet service offerings in phases, their concerns further include needing to understand what constitutes an effective migration strategy to this new world.
Logica has kept in close discussion with SWIFT to understand their evolving plans for SWIFTNet and assess how these will impact the member banks, other financial institutions, as well as the payments and securities marketplace in general. Details of this new world are gradually becoming clear.
The SWIFTNet programme involves a major change in technology and standards. IP supersedes the current X.25 based communications. PKI replaces the current proprietary security mechanisms of SLS and BKE. And for newly defined message flows the intention is that message formats move from the current FIN MT format (now an industry standard and very widely supported within numerous banking applications) to the newer, more flexible XML.
Browser-based solutions such as SWIFTAlliance webstation are also set to change the way banks access and transfer business information. With this technology it will become possible to 'pull' information such as nostro balances from remote applications in real time at the moment the information is required, rather than having to rely on this being 'pushed' at predefined times, such as at end of day. This has the potential to dramatically change the flow of certain categories of messages and brings real-time processing of data a step closer.
It is also clear that SWIFT is extending its reach into the systems of its member banks. In contrast to FIN where SWIFT's control generally ended at the local SAP (SWIFT Access Point), in the new world SWIFT will both manage the communications hardware at the banks' premises and will also supply the SWIFTNet Link (SNL) software - use of which will become mandatory in order to gain access to any or all of the SWIFTNet services over the Secure IP Network (SIPN).
This SNL software will essentially implement the protocol stack required for access to SIPN and the various SWIFTNet services; provide the PKI based security; and also enable SWIFT to perform remote diagnostics on the status of both the router hardware and the SNL software. With direct control over these key functions, in future SWIFT expects to be able to enter into stronger and more segmented service level agreements (SLAs) with its customers.
SWIFTNet Link
SWIFTNet Link was originally designed to allow close integration with each business- or financial messaging application requiring access to the SWIFTNet services. With there typically being several such applications in any given organisation, the implication was that a bank could be left having to support numerous separate implementations of SNL - one for each application needing access to SWIFTNet (e.g. for CLS, GSTPA, a message switch, an RTGS system, and each instance of an Alliance webstation).
Furthermore, SWIFT was prepared to make versions of SNL software available on only a limited number of hardware platforms, i.e. Intel running Windows-NT, IBM RS/6000 running AIX, and Sun Sparc running Solaris. This meant that the many banking applications running on other platforms (such as mainframe technology, fault-tolerant hardware or even other flavours of Unix) would not be able to integrate with SNL on the same platform, requiring instead a second 'box' and a remote connection between the two.
Feedback from the SWIFT CTO Council, commenting on this limited platform support as well as the potential number of copies of SNL which an organisation might need to support, appears to have caused SWIFT to adjust its thinking. The latest information suggests that SWIFT will now additionally allow remote access into a central 'shared' implementation of SNL, dubbed a 'SWIFTNet Link Communications Controller' or SNCC. Adopting the SNCC approach would potentially allow numerous applications and/or webstations remote access to this 'shared' software over a LAN, thereby effectively 'concentrating' a bank's SWIFTNet access (and associated PKI security) into one or only a few points.
Centralising the implementation of SNL using an SNCC in this way clearly has the capability to greatly simplify a bank's SWIFTNet connectivity as well as its associated network security management.
FIN and the new SWIFTNet services
For its next generation of messaging, SWIFT had proposed three separate and distinct services around SWIFTNet.
InterAct (a new interactive messaging capability) and FileAct (a new file transfer service) were the first to be deployed - ready to support the introduction of CLS and GSTPA scheduled for later this year. TransAct was then positioned as a new 'store and forward' messaging service, which would be implemented over a longer time-frame and would ultimately replace FIN.
While TransAct appeared a logical extension of the interactive and file transfer services being provided by InterAct and FileAct, the SWIFT member banks collectively expressed considerable reservation about any proposal to replace FIN. From the banks' perspective, they had invested heavily over the years to build support for FIN message types into their core systems, and so any suggestion from SWIFT to move away from this model would need to be accompanied by clear business benefits.
Partly due to the functional and technical complexity of implementing TransAct, but also in response to this feedback from its members, SWIFT has now changed the value proposition behind TransAct. While the name has not been dropped altogether, SWIFT has subsequently confirmed that FIN will remain the cornerstone of its store and forward messaging strategy - albeit that this service will now also move to the new IP network.
SWIFTNet FIN (as the new service will be known) will become available in the first half of 2002. From this point onwards until when the existing X.25 network is de-commissioned (at the end of 2004), banks will effectively be able to choose whether they continue to direct their FIN traffic over the existing X.25 network or whether they will use the new IP network. For their part, SWIFT will provide a low-level bridge between the X.25 and IP networks, ensuring that both communities will still be able to communicate with each other and that FIN traffic will always reach its destination, regardless of the underlying network technology used by either the sender or the receiver.
What does all this mean for the SWIFT community?
It is clear that much work has gone into defining SWIFT's. proposed new service offerings since the first announcements in Sydney.
A clearer picture is now emerging about how some of the new components, which enable banks and other financial institutions to access the new SWIFTNet services, may eventually be implemented. In particular, it appears that the mandatory SWIFT supplied SNL software will be packaged in such a way as to allow shared, remote access by a number of separate applications and consequently a bank's various connections into SIPN to be 'concentrated' into fewer or perhaps even one single, central point. Not only will this reduce the overheads associated with maintaining multiple copies of this SNL software, but it means that the software which implements the SWIFT network connection and network security can be separated from the routing and message formatting functions of the business application or messaging system behind it. This signals a departure from the style of systems which currently provide interfaces into the SWIFT network.
The latest announcements about the role which FIN will play in the new world clearly go a long way to preserving the significant investments made by the financial community to date in adopting the FIN messaging standards. However, at the same time this presents new challenges to many solutions providers. For suppliers of general purpose banking applications, it essentially means no change other than that they may at some point need to provide additional support for XML formats when these are introduced. However, for suppliers of SWIFT interface systems, it means a re-engineering of their existing FIN applications to allow these to work with SWIFT's SNL software and so provide support for FIN over IP. There is also the challenge of whether to provide additional support for the new interactive and file based messaging services available through SWIFTNet.
It is clear that the solutions providers likely to benefit most from this shift in approach are those who can provide the necessary business logic and value-added services to manage this extra level of complexity on behalf of the banks. Certainly at Logica we have been closely tracking SWIFT's evolving plans surrounding SWIFTNet and are working on the detailed requirements for interfacing our range of payments products and solutions to SWIFT's SNL software. We are also defining business processes to accompany that.
SWIFTNet will indeed have a profound effect on the way banks and other financial institutions exchange financial information and instructions in the future. While InterAct and FileAct provide new and interesting message delivery services to augment SWIFT's existing store and forward capability, it is clear that these alone will not (in the short term at least) generate significant volumes of additional message traffic or substantially increase the usage of SWIFTNet. Rather it will be the migration of FIN over to SWIFTNet which will most likely be the catalyst for significant volumes of message traffic and users moving from the old to the new network - thereby establishing the 'critical mass' for SWIFTNet which SWIFT is desperately looking to achieve.
It now remains to be seen what commercial advantage there is to be gained from an early migration and how quickly SWIFT's promise of greater bandwidth for lower cost is taken up by the market.
Author and biography
Neil Gray is a business consultant with over 15 years of experience in banking and financial institutions. He has extensive expertise and skill in financial message infrastructure with particular knowledge of the SWIFT marketplace.