Excerpts from a roundtable discussion sponsored by Sophis, held on June 19 in New York City.

MODERATORS

Joe Kolman, editor, Derivatives Strategy

PARTICIPANTS

Arnaud Vinciguerra, head of research and development, Sophis Ed Berko, president, IQ Financial Systems Inc. Neil Chriss, president and COO, ICor Brokerage Michael DeAddio, chief technology officer, Cygnifi Jeff Larsen, CEO, ICor Brokerage Sunil Panikkath, senior research economist, SAS Institute Inc. Scott Stirling, vice president for sales and marketing, Kronos Software Ltd.

Joe Kolman: Outsourcing is grabbing an increasing share of operations in the finance industry, and XML standards are likely to help integrate data between different Internet-based and other systems. But one important issue that hasn't been addressed is how to integrate thin-client or browser-based systems with more conventional fat-client-server architectures.

Arnaud Vinciguerra: Over the past 10 years, the industry and the needs of traders have changed considerably. What we have seen is that the same data are used for an array of purposes, and there frequently are disparate communication protocols at work. As trading portfolios become larger and more complex, there is a greater need for performance and high-speed distribution of real-time risk reports, for example. And yet a risk report at one desk may be completely incompatible with one at another—and all this at a time when there is a greater need for accurate information than ever before. So the problem is compounded. The solution to this is to get things right at the beginning—with a simple common denominator that can serve as a basis on which to build.

"There is a greater need for performance and high-speed distribution of real-time risk reports. And yet a risk report at one desk may be completely incompatible with one at another.” — Arnaud Vinciguerra

Kolman: What about the idea that simply going one way will muddy the waters? In other words, that going with the thin client will muddy the waters because we know the fat-client infrastructure exists and will continue to exist in the future.

Michael DeAddio: People will not walk away from multi-year, multimillion dollar investments lightly or at all. As an application service provider, you have to be able to go in and integrate with an existing system. For example, you have to be able to integrate an archaic collateral management tool with a thin-client, fat-server-type risk management system. As a vendor, you're not going to make any money if you can't make those two live in harmony.

You need to be able to create that integration, but XML is not a silver bullet. Integration is always difficult, and mapping is always difficult. With the advent of the Internet, however, various factors have aligned to make integration more relevant and more real.

Scott Stirling: I agree. A tremendous amount of effort that has been spent developing existing infrastructures. At Kronos, we don't believe all that effort should be wasted. It may not be feasible to extract everything needed from some source systems, but I still believe institutions and software companies have a responsibility to ensure that these companies take their technology to the next step.

I don't mean to oversimplify, but we're essentially talking about a bunch of stuff that doesn't talk to each other. And we require those programs and applications to talk, so we can get the results we require—whether we're sitting on a trading desk or in a risk management department.

Kolman: Is CORBA a way of integrating these disparate systems?

Stirling: CORBA is a key technology for distributed systems. However, the complexity of adopting CORBA throughout an institution has hindered its implementation. This task becomes even more difficult when the need is to integrate systems between many institutions. XML offers a simpler technology for this.

DeAddio: CORBA is a well-thought-out, overly engineered kind of standard. The beauty of XML is that it's simple.

Neil Chriss: The appeal of a thin-client system, of course, is that it's easy to get to the client. You can put something on a server and with minimal difficulty have a system up and running. The problem is uploading crucial information—in our case, credit information—so the system can properly handle bilateral credit issues. That will remain a stumbling block for many institutions.

This is why companies will ultimately go the route of integrating thin clients with thin-client systems. Every institution we talked to is fully aware of the issue and is taking huge steps to solve the problem. In other words, everyone realizes that the real power of computing and the real power of the Internet lie in getting disparate systems to talk to each other. But I don't think the problem was ever entirely technological; it's about the institutions themselves being willing to take the steps necessary to solve the problem.

Kolman: What is the range of solutions to this thin-client/fat-client problem?

DeAddio: There's no general solution. People are hopeful that FpML will one day be a solution to describing transactions and pouring those descriptions across the Internet. But generally speaking, what we're finding is that people don't think FpML is there yet.

For high-speed messaging systems, the size of the packets that contain FpML messages are quite large, so people don't see self-describing high-speed messages being FpML-based. But what we do see is a pragmatic attitude—namely, that the importance of the solution dictates the amount of resources a firm applies to that problem. So you go to someone and say, "Look, if you want to want to trade interdealer over-the-counter derivatives, you're going to have to give us credit information.” And they say, "We'll take whatever steps are necessary to get you the credit information, and if we use it a lot we'll take the steps necessary to automate that process.” Therein lie the beginnings of a system to integrate a customer's fat-client credit system with a thin-client brokerage system.

Stirling: The problem with traditional fat-client architectures is that the systems do not scale to a large number of users. Most systems deployed at institutions have this kind of an architecture and consequently cannot be rolled out in a cost-effective and practical manner to a much larger community. The need to offer systems over the Internet or through a VPN will require a new generation of thin-client-server systems.

Kolman: So how do we integrate existing client applications in this new environment? Jeff, when you were at Chase you had this problem. How did you move older systems into a more modern systems environment?

Jeff Larsen: I went from Manufacturer's Hanover to Chemical to Chase without ever changing firms. All three of those firms were substantial derivatives players. That experience led me to believe that if you take the best of system A and the best of system B and bring them together, you risk having the new system crash. Combining two systems can be very expensive and does not work particularly well.

"If you take the best of system A and the best of system B and bring them together, you risk having the new system crash. Combining two systems can be very expensive and does not work particularly well.” — Jeff Larsen

Part of the problem with combining systems has nothing to do with technology; it has more to do with the people involved. If you can get everybody to work together, then perhaps you can mix system A and system B, but you can't always do that. The traders, back-office, middle-office and technology personnel all have views about what should be used, and those views are heavily influenced by their desire for no change and for keeping their jobs.

These systems-related issues are really important. At the end of the day, you have to ask, "What is the best solution and what is the solution that can be supported? Are we mixing apples and oranges here?” Sometimes you have to go with what's the suboptimal solution on paper—just because it is often the best solution in the short run.

Kolman: What kinds of ideas did you discuss when you were integrating older and newer systems?

Larsen: We always returned to the idea of taking a system and adding functionality to it bit by bit. The important thing was to add a little at a time, as opposed to taking two giant systems and slamming them together. You have to be careful not to bite off more than you can chew when you integrate two systems. With a big business on two systems, you can't have the systems fail when you make changes.

Kolman: ASP systems may be fairly sophisticated, but banks will inevitably trade arcane instruments in-house. I would think this would present a challenge to risk management systems, because if you have true system-wide risk management, you're going to have to take the clean stuff from the in-house systems and integrate it with the ASP data. Is that a risk?

DeAddio: If you look at a lot of big shops, the most arcane stuff sits in a drawer somewhere—beyond the scope of the normal risk management system. So there's not too much of a difference from the way it actually transacts today. The issue of whether the risk management system is off-site or on-site is almost immaterial. At least with off-site systems, you've got some flexibility to get in and out, which means you have a better chance of integrating your clean stuff than you would have with everything on-site.

Kolman: Let's suppose you're doing risk management on a back-office client, and they give you 95 percent of what they have and keep 5 percent on their own system—maybe even on spread sheets. How do you deal with that type of integration problem?

Ed Berko: The short answer is that a back-office service provider cannot be realistically expected to process 100per - cent of an institution's transactions. Consequently, the service provider is not in a position to perform risk analysis on the institution's entire portfolio. And the financial institution will need to supplement the risk statistics provided by the service provider.

"A back-office service provider cannot be realistically expected to process 100 percent of an institution's transactions and is not in a position to perform risk analysis on the institution's entire portfolio.” — Ed Berko

Sunil Panikkath: There are mathematically legitimate ways to aggregate risk measures in a centralized manner that make use of calculations done in a decentralized way. You certainly can't add the VARs—we know that much. But if you go one level below that, say to how you value your exposure in response to a given set of scenarios, and ask the system to value other exposures looking at the same set of scenarios, the aggregation component can be centralized. That's feasible and it's being done today in projects handled by my organization as well as by others. Fundamentally, it's really no different from efficiently performing incremental VAR measurement. In other words, the integration problem arising due to lack of full instrument coverage by a provider can be solved in realistic ways.

Chriss: Your point relates to the idea that the difference between a thin- and thick-client is a continuum, as opposed to an absolute. It's a mistake to think of an institution as one solid blob here, with the thin server over there. Someone mentioned that most exotic instruments are already being valued outside the main risk management systems. The point is, companies are already dealing with integrating systems in-house, and when you talk about aggregating risk you're essentially talking about integrating systems. The central risk management division of a bank already computes risk management for regulatory capital purposes and for the rating agencies. They're already aggregating data from all around the firm—bringing together spreadsheet models and controlled risk system models, and combining disparate systems—which often don't even run on the same operating systems—to come up with a single VAR model. Banks understand and have been grappling with the problem of integrating systems for years.