Web Services: A Dream Deferred

By Maria Trombly | Securities Industry News | May 3, 2004

May 3, 2004 - At first glance, Web services looked tailor-made for straight-through processing. The set of open standards was poised to wipe all previous proprietary communications methods right off the map. That still might happen, some day. But today, Web services are mostly limited to internal integration projects.

The reason? Web services standards are great, but they aren't fully developed yet. Security, multiparty transactions, orchestration--these are all areas in which different approaches are still fighting it out for dominance. The basic Web services standards that are already there--Soap, WSDL--are nice, but they don't provide much of the functionality needed for STP.

"None of the standards is there yet," said TowerGroup analyst Dushyant Shahrawat. He added that he doesn't expect to see standards approved and fully adopted until 2008.

"Yes, people are using Soap internally for STP," he said. "But the true potential, where firms can talk to each other effortlessly, is still a while away."

It's true that Web services haven't lived up to their hype, said Kurt Vandenberg, a partner at consultancy Capco. But Web services are already becoming very common on Wall Street. "Today, we estimate that roughly 60 percent of firms have some Web services implementations as part of their STP," he said. "That's primarily internal, and not across the full trade lifecycle, but Web services represent a very common integration tool. STP is largely about integration and workflow, and Web services are a great way to integrate messaging and workflow. It's a natural tool for STP."

For example, Bear Stearns has been using Web services internally.

"Bear Stearns has taken a lot of their basic order-entry capabilities and the back-end systems that execute orders on behalf of their traders, and exposed them as Web services so that different IT groups at Bear Stearns could access that infrastructure through. Net Web services," said Sheldon Monteiro, VP of technology at Sapient. "Merrill Lynch on the wealth management side has done a similar thing, putting .Net hooks into its back-end infrastructure."

Monteiro agreed that the lack of standards is slowing down Web services adoption for firm-to-firm communications. "You've got to get a large number of players to agree on exactly what language is being spoken. In order to get that consensus, it takes some time."

Barriers To Entry
In addition to the lack of Web services standards, there are also other factors slowing Web services adoption for STP.

The first, and most important, is that there are other standards in place that work just fine. Why spend money to fix something that isn't broken?

"What I see happening is that FIX is going to become the standard for STP," said Ian Hoenisch, CTO of Electronic Specialist LLC (ESP), an electronic broker-dealer serving hedge funds, institutional investors and brokers.

Another factor is that Web services carry significant costs. They're based on XML communication protocols, which are human-readable. XML messages take up much more space than the proprietary binary formats they seek to replace. Firms that want to use Web services for high-volume traffic flows need to upgrade their networks, or invest in compression hardware. On the plus side, XML messages compress readily. However, binary messages, which are already as compact as you can get, don't benefit as much from compression.

Finally, the very things that make XML relatively easy for humans to read, make it harder for computers to decode, or parse, the messages. For high-volume traffic, companies have to either upgrade to faster computers or buy XML parsing hardware.

These two cost-related factors were important to ESP. "As a smaller firm, we need to be more efficient in the use of capital," said ESP's senior managing director, David Sher. "We're going to try to maximize the software so we can get the most out of the hardware, and that means trying to make the messages more efficient."

Picking Up Speed
But despite these factors, Web services are slowly but surely gaining ground, starting with those processes that have the lowest volumes and the least degree of pre-existing automation.

"On the cash management side, we have a couple of customers who have requested that we interactively work with their applications using Web services to facilitate straight-through processing," said Peter Johnson, SVP for strategic technology at Mellon Financial Corp. "On the asset servicing side, we're not doing any T+1 using Web services as yet, though it's absolutely inevitable."

Mellon uses Java-based Web services built on IBM's WebSphere platform, but Web services built on any platform can talk to those built on any other one. This means that Unix and Linux-based Java applications can readily talk to Windows-based .Net applications, one of the core advantages of Web services.

"Our leading-edge customers are trying to automate their back offices, and they want to do it without human intervention, integrate it into their applications," Johnson said. "It's a system integration problem and that's what Web services are all about."

Johnson added that there are other opportunities for Mellon to use Web services as well, including in the areas of trade capture, correspondent communications, perhaps even the custody world.

Today, however, each partner that wants to communicate with Mellon using Web services has to make sure that the flavors of Web services both parties use are the same. The core Web services standards, such as Soap (Simple Object Access Protocol) are well defined and accepted. But standards-setting bodies haven't agreed on higher-order standards that allow for security, complex transactions and other features.

"Security standards are still evolving," Johnson said. "Regular XML and Soap isn't enough to get you all the way there."

Meanwhile, firms that use third-party software built on the Microsoft Windows platform have a built-in migration path to Web services. With Microsoft's heavy commitment to .Net, Web services are becoming an integral part of new applications.

"Integration costs are one of the biggest costs of buying packaged applications," said Dan Foody, CTO of Actional, which provides Web services management to J.P. Morgan Chase and other Wall Street firms. "You can't just put in an application and leave it unconnected from the rest of your infrastructure. With proprietary technologies, that becomes very expensive. With the move to Web services, it helps customers dramatically cut down the costs of integration. I think every major application vendor is supporting or will soon be supporting Web services."

For example, Comprehensive Software Systems has already converted about 50 percent of its securities processing product to Web services, and will eventually move all code over to the .Net Web services standard. That doesn't mean that all information CSS sends to other firms is sent through Web services. In fact, says CEO Chris Poelma, only in one out of 50 cases is a counterparty using Web services, and then only for certain applications, such as an in-house fixed-income system handling exotics.
"But a year ago it was one in 200," he added.

The lack of higher-order standards is also a problem for CSS. "In fact, it's so much of a problem that we've created a hashing routing to handle the higher-order stacks," said Poelma.

That means instead of being able to work with, say, one security standard and one orchestration standard, CSS has to support all the security standards and all the orchestration work-arounds currently in use. "Rather than waiting for the dust to settle, the best way was to handle all the various perspectives," he said. "The performance cost to us is about 2 percent of the overall time, say from 100 milliseconds to 102 milliseconds."

That has been the case with CSS's new mutual fund module, which is fully Web services-enabled (see Scrutiny story).

"The installation on this new upgrade went smoother than the previous install," said Neal Heifetz, executive manager of operations at HD Vest Financial Services, a CSS client. "And it's given us functionality that we need to process direct mutual fund business."
Part of the functionality comes directly from the Web services-based architecture of the product, said Poelma.

"We use Web services to query data tables that we have on the back end," he said. Those data tables include 154 different types of error checkers, he said.

"That validates that the mutual fund is going to clear and settle and that it meets SEC requirements and doesn't need manual intervention," he said. "Some of our clients have had up to 11 people just to handle mutual funds and with our product they're able to reduce this by two-thirds. You can use other technologies to help you automate this, but by using Web services we're able to gain consistency and interface with disparate third-party systems."

Better by Comparison
Despite the problems, Web services are still better than the alternatives.
"With Web services, it's easier to interface with disparate technologies," Poelma said. "In the long run, it pays back big time."

The component-based architecture associated with Web services also makes integration easier, said Financial Insights analyst Todd Eyler. "CSS has very well-architected applications," he said. "It's very easy to integrate their components with other applications."

For example, for CSS customer Raymond James & Associates, Web services not only offer easier integration with the third-party product but also provide a sound long-term architecture for the company as a whole.

"Our business model is that we have thousands of financial advisers that are in thousands of locations," said Tom Loney, the firm's VP for IT development. "Obviously, we need to create an IT infrastructure that can accommodate that type of business model, so Web services are important to us."

For example, Raymond James is currently using the contact relationship management (CRM) component from CSS, which is written in C#, Microsoft's answer to Java, and uses Web services. "It allows us to be able to deploy a very robust application to a very distributed user population," Loney said.

The CRM function is an important one to the business but isn't directly STP-related.

According to Loney, Raymond James isn't currently using Web services for STP. "But as we go into the future, it's going to become more important," he said. "Other counterparties that we work with, as they develop Web services, we'll be able to communicate with them more effectively via Web services." Loney expects this to happen within the next few years.

ESP also expects to feel pressure from other players to move to Web services. "Once the larger corporations say we're going to real time, we're going to have to react to that," said Hoenisch. "But they're still evaluating how it's going to happen. It's a large infrastructure change for them. STP is a great goal; it can really collapse the inefficiencies in the current T+3 system. There's a lot of money being spent that can be saved. But for Web services, my opinion is that there's a time and place for it, but it's still a little early."