And how well is it working? "We're going to make it," he insists. "We're in the final stages of testing. Everything is going well. Our implementation will be a success."

While Dell's approach may be unique, its interest in SWIFT is not. SWIFT has moved into the mainstream for large corporations, notes Tom Nelson, cash management specialist for Wall Street Systems. "Even two or three years ago, it was experimental, new, untested and frightening to some," Nelson says. "Now we've turned the corner. It's gone from being discussed to being expected. It's rare now to go into a [request for proposals] where SWIFT connectivity is not a base requirement." Of the 15 to 20 new clients that have bought the high-end Wallstreet Suite treasury workstation in the past several years, only one is not connecting to SWIFT, he reports.

The promise of SWIFT is certainly enticing. "You have an unprecedented opportunity to consolidate your communication channels and use one set of message formats to go to banks anywhere in the world," says Bryan Kirkpatrick, vice president, senior product manager for treasury services and resident SWIFT expert at Bank of New York Mellon. "It's so much easier than dealing with a lot of banks one-off. You won't find a corporate who doesn't bring that up these days." And it absolutely works, Kirkpatrick insists.

So it's no wonder that many large multinationals are now serious SWIFT users, says Brian Wedge, executive director and global product manager for SWIFT within J.P. Morgan Treasury Services. Companies use it for wires, balance reporting and individual transaction advising, he notes, as well as for large payment files coming out of their AP systems. They use it with ERP integration, they use the FIN messages, they use FileAct, especially to carry files in BAI format, and they're showing a lot of interest in the coming XML formats, he points out. And electronic bank account management (eBAM) is definitely attracting a lot of attention. (See Sidebar on Page 29.)

But getting SWIFT to work takes effort, not magic, Kirkpatrick emphasizes. "You have to board banks one at a time. It takes good project management on the part of treasuries. You have to develop a good implementation plan and work with each bank on a timeline for what will happen when. And you need good project management on the part of each bank. It's a complex undertaking, but for many corporate treasuries, it's worth doing."

Kirkpatrick knows of no company that reversed a decision to join SWIFT, but he knows of implementations that have been delayed due to a variety of factors, and instances where bank testing was suspended until agreements could be reached or glitches worked out.

Not all banks support all message types, Kirkpatrick cautions. Also, companies have to have agreements around services, and each bank has its own agreement. The communication channel is standardized and universal, but the agreements around how to use it are not.

Dell's urgency is linked to its ambition. Joining SWIFT is just one part of the company's "larger mission, which is to create a whole end-to-end treasury operation that is globalized, standardized and automated," notes Treasurer Gary Bischoping Jr. And that, Schmitz explains, "dictated our choice of middleware that consumes information from bank statements, translates it into the right formats and feeds it to the workstation and the ERP system." That middleware is "like a SWIFT integrator bolted onto a bank statement data warehouse," he adds, and "SWIFT also seamlessly integrates with our treasury workstation and ERP system."

"When we got to SWIFT," Schmitz explains, "we saw it as a key component of our solution, a single connection point to replace most of the bank proprietary portals' functionality we were using for hundreds of accounts. We needed something to standardize and simplify our bank communication, and that is what SWIFT does best." Bischoping, Schmitz and the Dell team studied the terrain carefully before taking the plunge. Attending Sibos and AFP conferences provided opportunities to hear presentations, meet SWIFT staff and talk with peers. Dell does a lot of benchmarking with peers, and SWIFT experiences became a part of that benchmarking.

Once Dell decided to join, it surveyed its options and quickly eliminated Alliance Lite. "It wasn't robust enough for all our banks and accounts," Schmitz says. "And there are transaction limits, and we wanted to use SWIFT for as many transactions as possible."

But joining directly had its drawbacks. "During our research, we found several companies that had started to join directly and changed to a service bureau," he reports. "There were others that went ahead with direct but said they wished they hadn't."

In the end, Dell picked a service bureau, partly to speed up the process. "We felt that the fastest way to get results and shorten our learning curve was to use a service bureau," Schmitz says. "Developing the internal resources would slow us down, so the service bureau was the most expedient way to go."

Dell started with the list of service bureaus on the SWIFT Web site, and narrowed the prospects down to 10 by asking its peers, bankers and technology providers to make recommendations. Small shops were eliminated. "Some service bureaus have just five or 10 employees. We wanted to have confidence that our service bureau was sustainable," Schmitz says. Disaster recovery was essential. So was a good record for uptime and 24/7 global access to customer service. Ten RFPs went out and one service bureau was selected. (Dell declines to identify any of its banks and vendors.)

Dell uses its service bureau simply for SWIFT connectivity. "Our service bureau offers a formatting and data transformation service, but we chose to do that ourselves," Schmitz explains. "We want to be bank-agnostic, which SWIFT will do for us, but we also want to be service bureau-agnostic. By owning the data transformation, we stay more independent and flexible." Should Dell decide to change service bureaus, the process would be quick and simple, he notes.

Then Dell put together a cross-functional team of sprinters that included treasury, which initiated the project; accounting; payroll; accounts payable; accounts receivable; and IT. "This was to be an end-to-end project encompassing receipts, disbursements and controls, not a treasury project," Schmitz explains. "We brought in all the affected players, put them on a steering committee and used them to drive the resources we needed."

Dell will flip the switch to start receiving all its bank statements, including all receipts and disbursements, same-day and prior-day. It will use MT 101 messages for payments, MT 199 for message status, MT 940 for prior-day and MT 942 for same-day activity reports. It will use FileAct to send files of ACH payments, as well as ISO 20022.

Although Dell did not include eBAM in its initial SWIFT plunge, because message traffic in that standard is not yet available, "it's definitely a functionality we want to have, so we'll move to eBAM as soon as it is feasible," Schmitz says. The trade services utility (TSU) and enquiries and investigations (E&I) message sets are a lower priority. "We'll investigate using them eventually, but just moving all our payments and statements to SWIFT is a pretty big bite," he notes.

To facilitate receiving SWIFT messages from its sprawling bank network, in addition to directly connected banks, Dell will use "consolidator banks" to collect SWIFT messages from other banks and forward them to Dell. "We'll get the raw 940s and 942s from our consolidators, not consolidated reporting," Schmitz explains. "We'll get all the direct messages. We'll just use other banks to help get the messages to us. That makes it more feasible to pull off our big bang implementation."

One key aid to Dell's plan to bring on all its banks at once was a readiness survey with 20 questions that it sent out early on to all its banks. "The banks were very helpful and provided candid, detailed explanations of what systems and technical capabilities we would need to communicate with them," Schmitz says. "They were very upfront about what they could do and what they could not do."

While Dell's SWIFT project was calculated to eliminate "pain points" for its treasury operations, the experience has hardly been painless. The pain started with the application to join SWIFT. "I filled out the paperwork myself, and it was painful to do all the work around onboarding," Schmitz says. SWIFT now offers a consulting service that makes that easier, but it wasn't available last spring when Dell was joining, he reports.

The pain continued when the bank surveys were returned. "It was not going to be plug and play, as we expected," Schmitz says. "Even though the MT messages are standardized, each bank had its own little wrinkles around how it uses certain fields or codes." And trying to do so much so quickly has been a headache.

"This is a very complex process," he concedes. "We completely underestimated some of the complexities and challenges to taking an all-at-once approach, but we are learning and making it work." Schmitz admits that if he could start over, he'd give more thought to doing it gradually.

One pleasure has been the cooperation among corporate peers. Other companies have been "incredibly helpful when it comes to joining SWIFT," Schmitz reports. "We're like a band of brothers. You can pick up the phone and call a colleague about SWIFT, and they're ready to help you in any way they can."

And now the rewards are imminent. "We'll greatly streamline our operations and controls," Schmitz concludes. "The mechanics of communication will be automated and we'll be free to concentrate on high-value activities when we deal with our banks."

MetLife, the $41 billion insurance company based in New York City, took a distinctly different approach. MetLife also got its SWIFT connectivity through a service bureau (BankServ), but only after exhaustive preparation, reports Mary Ellen Putnam, vice president of the international business unit at Las Vegas-based BankServ. "They really did a good job with internal cost analysis," Putnam says. "Their internal rate of return estimate of 69.5% over five years was real and measurable. They did a great job of identifying their needs. They organized project teams that included all the stakeholders–IT, treasury, accounts payable, accounts receivable, payroll. They took 18 months to be sure they did it right."

MetLife is big, global and transaction-heavy, with 11 primary banks and hundreds of other bank relationships. But like Dell, it chose to use a service bureau rather than join SWIFT directly. Frank Campione, corporate treasury manager, has said in a white paper that connecting directly would have "entailed considerable upfront infrastructure charges for new servers, security software and new staff." MetLife declined to participate directly in this article.

Prior to using SWIFT, MetLife's treasury consolidated its banking activity through one bank's proprietary multibank platform. But it was paying high fees for this service and having trouble automatically reconciling payments and cash positions as a result of not having straight-through connections to its various banks, according to its case study. Getting the needed bilateral agreements to add new banks to the system took weeks. Once SWIFT provided consolidation with direct connections to each bank, the company's transaction costs fell and reconcilement improved.

MetLife's SWIFT plan included its securities division and AP, as well as treasury. It helped that MetLife has on staff experts in treasury operations, IT and project management who formed the SWIFT implementation team. The company also had a treasury system that could process basic SWIFT message formats and resources to build its own middleware for message transformation. The MetLife project team included three staffers from treasury, five from IT, including the master project manager, staff from SWIFT, a project manager and implementation manager from BankServ, and project managers and product specialists from each of MetLife's 11 primary banks.

Treasurers still take the lead in corporate SWIFT projects, but increasingly, corporate interest is spreading to risk. "More often we see risk officers involved in the planning," says Eileen Dignen, managing director for banking accounts and initiatives for the Americas at SWIFT, "and more conversations around managing risk."

"Today's approach is more holistic," notes Elaine Filus, a principal at consultancy Treasury Strategies in Chicago. "Companies are looking across the enterprise at what SWIFT can do for areas like AP, AR and payroll, and then seeking a SWIFT connection they can all use."

The economic crisis spurred more interest in SWIFT as some treasuries found themselves bound to banks that were faltering, reports John Cowart, senior product manager for global transaction banking at Deutsche Bank. "They wanted more power to redirect traffic around troubled banks," Cowart says. "SWIFT gives them more ability to change addresses and implement contingency planning. Risk managers have also started to take a real interest in SWIFT."

Growth has been solid. More than 600 corporations have joined SWIFT to date, with 40 new entries so far in 2010, Dignen reports. The largest industry group is financial services, but automotive, software, pharmaceuticals and food companies are also showing strong interest, she notes.

Volumes vary, but overall, corporations are receiving more traffic than they are sending. "The biggest flows are information being sent to corporate members for liquidity and risk management," Dignen says. FIN traffic has gone up 40%, and FileAct traffic is up 75% so far this year, she reports.

What's new is the expanded use many corporations are making of SWIFT, reports Susan Feinberg, senior research director for the Tower Group in Needham, Mass. "Many started using SWIFT to receive daily bank statements but have graduated to using it for payment initiation, including bulk files," she reports.

The newest products are eBAM and a trade finance message set that is an adjunct to the TSU and can be used to initiate and confirm bank participation in letters of credit and other trade finance vehicles, Feinberg explains.

SWIFT still appeals more to market leaders than to the herd, Treasury Strategies' Filus suggests. "Companies that want to be on the leading edge and get ready for the future are drawn to SWIFT," she says. "They want to move to the best-of-breed solution. They're willing to settle for a fairly low ROI if they think they're positioning themselves for what's coming."

Some skeptics think SWIFT's potential far exceeds the immediate, practical rewards. With the right to join SWIFT, corporations have acquired a powerful engine, observes Bruce Lynn, managing partner at Financial Executives Consulting Group in Darien, Conn. "Now they need to figure out how to build a car to go with it."

Standardization remains a challenge, but that problem is being addressed by the Common Global Implementation group, a SWIFT-sponsored forum of major players that is wrestling with the nitty-gritty details of getting all banks to implement the new ISO 20022 format standards in the same way, Feinberg says. "If they can come up with a blueprint for consistent implementation for true automation, that will be big news," she says.

The full payments XML conversion is in the hands of the trailblazers, the few large corporations that were among the first to join SWIFT, generally using their own direct connections, Cowart says. These players are using their influence and determination to bring about the introduction of XML so they can receive more robust data about their transactions, such as remittance details that will allow them to automatically apply incoming payments. To get that payoff, the rich data has to be in XML ISO when coming from banks, Cowart says. If you just convert 940s or 942s to XML, all you obtain is 940 and 942 information in an XML format without the additional data, he points out.

What lies ahead could be transformational. The first generation of companies joining SWIFT were seeking connectivity to a reliable global financial communication system. The next generation will be looking for groundbreaking applications to ride those rails, predicts Gary Greenwald, the visionary chief innovation officer for Citigroup's global transaction services: "We're moving from the connectivity mode to the killer app mode."

The first killer app could be eBAM, he says. "It was built for basic bank account management, but I see a lot of opportunity beyond that. It could bring efficiency to supply chains. It could dematerialize a lot of paper contracts and streamline workflow," Greenwald says. "People are looking for the right model to eliminate a lot of manual work, and that could be eBAM."

EBAM GAINS TRACTION

The loudest buzz about SWIFT-for-corporates innovation this year involves the electronic bank account management (eBAM) messages. Traction is coming, but it won't be a fast start, predicts Eileen Dignen, SWIFT's managing director for banking accounts and initiatives for the Americas. "We're seeing test traffic today. We'll see more production traffic later this year, and it will build in 2011."

EBAM is at a stage where the middle of the communications chain has been completed, but the two ends still have to be built to connect corporates and banks to that message set, explains Brian Wedge, executive director and global product manager for SWIFT at J.P. Morgan Treasury Services. "The standards and the network are in place. But the senders and receivers have to figure out how they will actually generate and process the messages," Wedge says.

"Banks will start with eBAM Lite, so they can sell an eBAM product, but once a message comes in, the process may become manual," warns Susan Feinberg, senior research director for the Tower Group in Needham, Mass. Banks might print out the documents accompanying an eBAM message and then process it like a fax, which may or may not satisfy the corporate sender. Data entry errors could crop up and little progress will be made in accelerating the process. Once volume gets big enough, banks will invest in automating the back-office part, Feinberg predicts. A few banks will vie for leadership with fully automated solutions and try to sign up the early adopters. They could white-label their solution to other banks that haven't made the investment, she adds.

One reason for the excitement around eBAM is that it would standardize and automate something that so far has been manual, explains Glen Solimine, head of sales for Wallstreet Treasury, the Wall Street Systems workstation for mainstream treasuries.

"Companies can automate payments and reporting without SWIFT, but the only alternative to eBAM is paper processing," he points out. "Bank account management traditionally was considered a mundane but necessary chore. It was never a hot topic, but now that eBAM standards have been set, the mind set has changed, and people are excited about the potential benefits."

EBAM has a simple messaging foundation but the potential to do more, says Gary Greenwald, chief innovation officer for Citigroup's global transaction services. Call it eBAM Lite and eBAM Heavy.

"Lite is sending a message to the bank to add a signer to an account," Greenwald says. "Heavy is full re-engineering around powers. We're working with 10 multinationals that want eBAM Heavy." –Richard Gamble

For nitty-gritty details on selecting a provider, see How to Pick a Swift Service Bureau and Tips on Joining Swift.