Just as most firms have finished migrating their Swift-messaging traffic from ISO 7775 to 15022, the inter-bank communications giant is once again asking the industry to engage in a major migration. This time, the conversion is much larger, as Swift calls for the industry to access its flagship FIN store-and-forward messaging application over a new IP-based network, called SwiftNet, rather than the currently used X.25 network.
"This is a fairly massive undertaking," says Tim Lind, a senior analyst at the Massachusetts-based TowerGroup. "This is a much bigger undertaking than 15022 and it involves more customers across more market segments. Every customer will be impacted."
That means keeping in step with the conversion, due to be completed by the end of 2004, is relevant to almost all large financial institutions in the United States, as well as those in Europe where Swift is even more prevalent.
In total, Swift connects financial institutions in 198 countries, according to Lazaro Campos, a member of Swift's executive committee, who describes the Swift offering as consisting of three layers.
The first layer is the network (currently X.25) which will be converted to the IP-based SwiftNet. Access to the core network was contracted out to Global Crossing in 2002 but that company's bankruptcy forced Swift to reclaim management of the access points. Looking to outsource that function once again, Swift recently decided to farm out the responsibility for providing telecommunication access to four different providers (AT&T, Equant, COLT and InfoNet), thus removing the risk that failure of one would have a drastic impact on the whole user base.
Though financial institutions are responsible for working directly with one of the four telecom providers to arrange SwiftNet access, Swift has established minimum service-level agreements (SLAs) with the companies.
"We do monitor the quality and availability of the access networks to make sure the SLAs to the end customers are developed. We have negotiated minimum SLAs but individual customers, based on their relationships, may be able to negotiate higher SLAs - some may have more leverage," says Campos.
The second layer of Swift's service is its core offering - messaging. Primarily, Swift has been used between firms to communicate cash movements and, over the last few years, has increasingly been used by the securities industry to update counter parties and custodian banks on the changing status of trades.
The third layer of Swift is the applications that sit on top of the network. These applications include Swift's FIN messaging engine, or more recently, CLS functionality. In the future, SwiftNet-accessible applications could include Omgeo's post-trade, pre-settlement tools, such as the new Central-Trade Manager.
In addition to the telecom players, assorted middleware and connectivity vendors have gotten into the SwiftNet migration act. Companies termed "solution partners" are available - for a price - to integrate SwiftNet into a firm's back-office applications. "They ensure the glue," says Campos.
MANAGING THE MIGRATION
As one might expect, the 200 largest institutions which make up Swift's "handholding" accounts will be permitted to determine their own migration timetable while receiving the highest degree of Swift's attention. For the rest of Swift's users, conversion will take place in accordance with a country-specific schedule, which calls for all financial institutions within a particular country (or region as in the case of the United States) to migrate during the same time period.
Northern Trust, a global custodian bank and investment manager with over $1.5 trillion in trust assets and $302 billion under management, certainly qualifies as one of the "handholding" accounts.
Barry Tebbutt, senior vice president in Worldwide Operations and Technology with Northern Trust, says his firm started seriously looking at the SwiftNet migration in the fourth quarter of 2002.
Northern expects to start "testing in earnest" in April or May of 2003, says Tebbutt, converting one of its nine locations at a time. But though it has nine regional locations, Northern Trust employs a hub and spoke approach to dealing with Swift in which the firm's Boston location acts as a conduit into Swift for all others.
"It's financially beneficial if you consolidate many services out of one port," says Tebbutt, who adds that his firm will be using the Swift Alliance Gateway software to connect with SwiftNet for access to applications like FIN, CLS and perhaps Omgeo.
To manage the migration, Northern has dedicated a project manager who "sits between technology and operations," says Tebbutt. The project manger will report to Tebbutt and his technology counterpart, Senior Vice President of technology Frank Cesario.
Northern Trust, one of the many firms burned in the GSTPA debacle is, however, finding a way to leverage some of the technology work that appeared to be a total loss when GSTPA declared bankruptcy last year. Tebbutt says, "Ordinarily there would be a fairly long lead time to establish links into SwiftNet through POPs (points of presence) but since we had that for GSTPA, we are going to leverage that."
Tebbutt says he anticipates Northern being live on SwiftNet by the beginning of the fourth quarter this year, well in advance of next year's deadline.
Though X.25's time is running out, there are no plans to phase out FIN, Swift's longtime messaging application. TowerGroup's Lind says that Swift's research indicated that the FIN application was working just fine.
"When Swift imparted on this IP road, they took a hard look at the FIN application itself and when they went to their customers about it they determined that the application is ideally suited for the business processes which it supports," says Lind. That is largely because the messages flowing through FIN don't need to move in real time, he says. They just need to be guaranteed-delivery and risk proof. "FIN is an armored car," adds Lind.
OPPORTUNITY OR OBSTACLE?
Lind recommends that firms look at the migration as an opportunity to rework some complex and inefficient plumbing. He say that engaging in a hub strategy, much like that employed by Northern Trust, is a good way to streamline Swift communications by reducing the number of entry points into the system. That approach means that firms only have to deal with a small number of connections when changes to the Swift network are required. "That will reduce the number of telecom gateways you need to maintain into Swift," he says.
"It is a mistake to just consider this a technical migration," says Lind. "Some firms will simply try and swap out their X.25-interface device for a new IP-interface device on a one-to-one basis, test it and go, but the firms that will get real value will re-evaluate their strategy for connecting to Swift."
Lind also recommends introducing a "metadata layer" which can act as an interim layer between business applications and Swift's network. Such a layer, he says, will store elements involved in creating Swift messages one step away from core business applications. "That way you don't have to dig into old codes in the legacy systems to accommodate new standards. You just need to go into the metadata layer and change how it is composing messages."
By doing so, he says, firms will benefit from isolating business applications from standards and syntax. "By doing this, I move all business transaction information from legacy systems into this middle metadata layer," he says.
Northern's Tebbutt is mainly concerned with ensuring that the new network connection can handle the capacity that will inevitably come its way. "One of the biggest issues is to ensure that it can handle the volumes," he says. "We will simulate a completed day's traffic stress to make sure it can handle volumes well beyond our normal tolerance levels."
Tebbutt agrees that firms should quickly begin their migration process. "Make sure you have gone though the planning and that you are well prepared - you don't want to leave questions until the last minute."