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

MODERATORS

Roger D. Lang, director of global risk programs, Compaq Computer Corp. Joe Kolman, editor, Derivatives Strategy

PARTICIPANTS

Sunil Panikkath, senior research economist, SAS Institute Inc. Scott Stirling, vice president for sales and marketing, Kronos Software Ltd. Sanjay Mithal, vice president for financial products and services, eCredit.com Christine Berthet, venture partner, TL Ventures Michael Wang, director in internal audit, CIBC Michelle McCarthy, managing director for sales and marketing, Deutsche Bank Group Sendhil Revuluri, director in equity trading, UBS Warburg

Roger D. Lang: Over the years, we've learned a few things about risk management. We know it's important to have an independent risk management function. We also know it's crucial to have standards for collecting, analyzing, reporting, and controlling the risk information. We know that the most competitive firms are able to manage firm-wide risk and use it as a competitive tool. But what is the right risk management infrastructure? And are industry dynamics driving a competitive response we can call best practices?

"If the quants cannot articulate what their firm is doing to aggregate risk beyond their department, at the firm-wide risk level, that's a behavioral issue.” —Roger D. Lang

Sunil Panikkath: Good risk management technology shouldn't constrain you; it should be flexible. You need powerful tools to get data out of legacy systems, you should not have to worry about whether the infrastructure can support new models or simulation techniques, and you should be able to produce new analytics quickly.

Joe Kolman: What's the wrong way to build a risk architecture?

Panikkath: The wrong way would be to try to build a data model that does everything—and to spend months and years doing that. You don't have to have one system and then map data from all existing systems into that one system. Very good technology is available by which automated processes can be put in place to pull regularly, from different systems, only the subset of data required for risk measurement—without having to physically consolidate the data.

Scott Stirling: The danger lies in software companies reinventing themselves in areas that hasn't been their bread and butter. Trading systems have tried to become risk management systems, and have intentionally used the underlying data model to perform that function. Learning that the data-modeling approach was not the correct approach to enterprise-wide risk management was a bitter pill for the industry.

Institutions want the autonomy to choose different risk management techniques—whether it's developed internally in their own financial engineering departments or by specialized software vendors. So an infrastructure has to work in a component-based world, where everything is a component. That will allow for more rapid development of analytics for institutions. They can get data off the legacy systems they already have, and that will bring them closer to a solution. This isn't solved by any means, but XML protocols will help with data integration. I hope software companies encourage a single standard to be adopted by the market as a whole—because that would serve the market better.

Kolman: Companies can have all the fancy models in the world, but at the end of the day the data seem to be an unsolvable problem. No one has managed to get data in and out of risk management systems in a way that makes any sense. Are we, in fact, on the verge of a data Nirvana because of XML, or are we still far away?

Sanjay Mithal: Software companies have not done as well as they might have. Companies need excellent product managers to map business-functional knowledge into the product requirements from which a development specification is derived. Most software engineers do not have the necessary domain expertise to specify, design and develop a complex financial application. A standards body may be the right place to start trying to normalize interfaces, but I think somebody just has to go out there and do it—and that will eventually become the de facto standard in the marketplace. If there are independent applications, XML allows these applications to operate concurrently. It's only when applications with fundamentally different requirements begin to overlap that having one standard becomes a conflict.

Panikkath: There's also a cost and benefit to standardization. The question is, "At what point does the cost of standardization become greater than the benefits of standardization?” There's a continuum from everything being standardized, so there's no need for translation, to nothing being standardized, where everything has to be translated. The answer may not be 100 percent standardization.

"Is there a coincidence between the interests of the trader and the interests of the institution? I think the answer is fairly obvious: no.” —Sunil Panikkath

Christine Berthet: It's not an issue of standards, but of the use and definition of risk by different counterparties. It reminds me of general-ledger reporting and management reporting. In a company, there's a general ledger, but no CEO looks at that data. Management reports are packaged from the general-ledger data in each division. The same thing happens with risk.

There is no common set of data for transactions. There are 25 representations of the data, each of which expresses the risk. Centralizing the data—and creating views on the fly for the users of that data—is therefore not reasonable. The reason this is a problem for a lot of people is simple. Across different functions in a bank, one person is going to be a customer in one place, a vendor in another place, and a third party somewhere else. So is the customer a third-party risk, a vendor risk or a customer risk? Depending on whom you talk to, it's all of those risks. This is a very basic problem in banks, because banks have different relationships with the same customer.

Lang: Another way to look at this is to ask what we mean by standardization when we have a front office, a middle office and an IT department with different requirements for the data vs. the end-users. We also have different kinds of businesses—the buy-side, the sell-side and exchanges. That's where best practices seem to be emerging in the decoupled vs. coupled architectures. On the buy-side, people like the decoupled architecture. They like the idea of having their own analytics and their own proxies. It's starting to cut across lines of business, geographies and functions, but where can we go from here? Is there a high premium for flexibility?

Stirling: When the derivatives industry was growing up, the RFPs and the RFIs always used to say, I want the ability to have my own analytics, I want to add a new instrument. I think that's evolved a wee bit; people now say I want the ability to treat my trading system as a component. And I want my risk management valuation model to be a component. I may buy it from someone in New Jersey or in London, but I want to be able to plug and play. That's the revolution toward which we are moving. A data model doesn't have to be an "all-singing, all-dancing model,” to use Roger's phrase, and that's okay. I think that's where technology is taking us today—having all of these disparate components talking to each other. And XML may be one possible route for that.

Kolman: Do our risk systems look at risk in the right way?

Michael Wang: When people talk about risk management, I think they are really talking about risk measurement and risk monitoring. Risk is just a sensitivity measure of a financial product in response to a change in certain risk factors. We need a consensus on what the risk factors we're exposed to are. Then we need to measure the sensitivities to those risk factors. And who has the most intimate knowledge about how sensitive products are to certain risk factors? The traders.

"Traders are the front-line risk managers. But the industry thinks we need sophisticated risk management tools at a higher level—not at the bottom level.” —Michael Wang

In my view, the traders are the front-line risk managers. So if they are the ones who actually manage risks, they should be equipped with sophisticated risk management tools. But in the risk management community, people think we need sophisticated risk management tools at a higher level—not at the bottom level.

Michelle McCarthy: I think the most money has always been spent on the offensive use of risk tools, meaning what an individual trader uses to picture his or her position. He may view his world very differently than his colleagues, and these tools need to be highly customized so he can carry out his individual strategy. What's been missing is the defense—and that means his manager monitoring him and seeing that he's not taking a risk the firm can't afford.

The reason we're in this mess is because we bundle and package risks the way an individual desk likes to look at things, but haven't brought the risk into a more universal framework. And the industry has catered to the individual for a very important reason: they're the engines of wealth. They're the ones who make money. But the industry has done this in a way that has warped the system and has made it impossible to aggregate up.

Wang: I think that is because traders have never been equipped with the kind of tools that can give them an aggregate feel. The tools they use now only give them an isolated feel. Ultimately, if we want to tie traders' performance to their RAROC numbers, we have to give them the tools so they know how their risk profiles fit into the big picture, and so the complicated risk measures make sense to them.

Kolman: So why don't we have the right tools?

McCarthy: It adds costs, it's boring and it's for senior managers who may be removed from trading. But the same reasoning applies to marking to market. Why do we care that products are marked to market under the same framework? Because there needs to be a single set of rules, and the rules must be consistent across trading strategies. People know they can't just mark to market a product in their own special way. They have to follow the rules imposed on them by their firms. That's the layer that's been missing in risk management.

Risk used to be left to the individual. Then, after some banks suffered losses and regulators stepped into the fray through the Basel market risk capital guidelines, standards emerged. In the rest of the financial industry outside banks, there's no regulatory reason to calculate risk—and it's left in un-aggregatable bundles that help people manage their positions. If the people are non-fraudulent and intelligent, that's great—you can just trust them. But obviously, risk management oversight needs to take place—that's been the weakest part of the risk architecture. Senior managers haven't always insisted on aggregate data.

Sendhil Revuluri: I'm surprised you say so much effort has been dedicated to risk systems at the individual trader level, because looking at the systems, I don't think they help us trade. Traders understand what they need to know to manage risk, not just to measure risks. Most of the current systems pay little attention to human factors. They spit out numbers but give you little to go on in terms of actually managing the risk, which in theory is your job as a trader.

I agree there needs to be uniformity at a certain level—to measure the susceptibility of banks to a six-sigma event or something that will cause bankruptcy, for example. Consistency is important there. But at the individual trader level, I don't think consistency should be highest aim of a bank's risk management system.

Also, if your primary goal is to lower cost production, you have to support standards. Exchanges and those providing trading platforms are doing to have to support standards. Anyone who doesn't support some sort of XML is not going to survive, because they're not going to be able to offer customers a solution. If your goal is not cost reduction, however, but to match a book and extract some profit from that book, then consistency is no longer the sine qua non.

Lang: We're talking about how standardization and consistency aren't so important in virtual reality. That hits a nerve with me, because I've been called in on jobs where within one company there's no standardization of models. And when you look at two desks trading with each other—one desk doing the arbitrage, the other desk providing the hedge—you find mismatches. But, son-of-gun, they're both making money.

Revuluri: Standardization is not the solution to every trouble. But when you look at what people are trying to provide, that seems to be their first postulate and they move on from there. I am not saying it isn't a good thing, but to provide a system that helps risk managers risk-manage, you need a lot more than that.

Stirling: Standardization isn't going to help the trader on his portfolio. A risk manager managing the risk of an institution's entire floor book needs to collect information from different systems, so standardization will certainly help there. What will help traders is a more responsive architecture, whereby they can extrapolate from an existing system, so they can respond in some form of real time.

Revuluri: The first step in managing a portfolio is time-snap risk measurement, which, I think, is what you're saying. Every risk management system and every trading system I've seen has as its output a big grid of numbers—which means whatever it means. Systems have to go beyond that. There needs to be more intelligence applied.

Kolman: So what do traders want? What would traders like to see from software and systems that would allow them to make more intelligent risk management decisions at the desk or portfolio level?

Panikkath: I would question the premise of that question. Is there a coincidence between the interests of the trader and the interests of the institution? I think the answer is fairly obvious, and that's why institutions globally try to look at things differently from the way traders do.

Stirling: They require very different architectures. An enterprise-wide system has a very different approach from what's required for the real-time responsiveness of a trader. I wouldn't attempt to use a risk management system on a trading desk. It's not designed for that. Trading systems, however, need to move to the next step—and standardization isn't a part of that. It's about adopting Internet technologies and being more responsive.

The monte carlo engine that goes on behind the portfolio in the vasp project will be very, very fast, allowing dealers to run portfolios intradae vasp project will be very, very fast, allowing dealers to run portfolios intraday.

Calculations are cheap. CPU is cheap. Perhaps there's a lot we can do with technology, aside from the standardization of XMLs, that would make your life as a trader. Maybe this involves distributing calculations and getting rid of bottlenecks in data models. But trading systems shouldn't try to pretend they are risk management systems, and risk management systems should not lean backwards trying to be trading systems.

Berthet: The role of traders is not to be risk managers. Traders are supposed to maximize the revenue and the profits, and risk management is a constraint around the trading—as close as possible to the action. The only output needed from a trading system is a consistent aggregation—so the overall risk view has meaning and can be fed back to the traders as a constraint. Therefore, the only standard needed is translation, so the aggregation makes sense. The function of risk management should not be at the trader's level.

Kolman: To what extent do real-time position limits—trading limits imposed by management on traders—provide an answer to these issues? Is that only dealing with a small piece of the pie, or does it get you better than halfway home?

Berthet: It doesn't address the issue of risk aggregation vis-à-vis a counterparty. Or the concentration risk of a certain instrument or long position. For that, aggregation is needed at a higher level than that of the individual trader.

Kolman: But if you make decisions on a trader-by-trader basis that are more granular, rather than using net positions, and you aggregated those numbers for different instruments, wouldn't that be responsive?

Berthet: But then you're telling traders how to do their jobs, instead of giving them a framework.

Lang: It's clear that what's emerging is a need for flexibility and decoupled architecture. We should also be thinking about best practices for behavior. Let's say, for instance, we go into an insurance company and see a person managing fixed-rate products with four quants. If the quants cannot articulate what their firm is doing to aggregate risk beyond their department, at the firm-wide risk level, that's a behavioral issue. Once we solve that, perhaps we can start tackling the data and the technology requirements.