Print this

The OTC derivatives world is heading toward electronic, real-time transactions, but not before a brouhaha over digital protocols.

By Nina Mehta

It may be a breeze to whip porn and CDs back and forth over the Internet, but just try exchanging details about a plain-vanilla swap. At this late date, you still have to work out the details with your counterparty via a fax machine or—gasp—telephone conversation! And if any little thing is out of alignment in the document (which you'll probably save as a Word file), the trade will fail.

The problem with swaps and other financial instruments is only one manifestation of Wall Street's most critical and intractable technology problem: standardizing language and getting different programs to talk to one another. As a result, financial transactions are more expensive, time-consuming and error-prone than they need to be.

Wall Street firms have tried a number of ways to solve this problem, from off-the-shelf middleware to custom-designed interfaces. None has proved to be the magic bullet. Now, however, a solution with real promise may be just around the corner.

XML (extensible markup language) appears to be the long-awaited lingua franca that will unite the disparate worlds of data management. It's a descriptive language that defines objects and allows them to be sent digitally from one location to another. Financial XML—a version of XML tailored to the financial services industry—would thus allow institutions to describe swaps and other customized transactions according to a standard protocol.

If everything works right, it could be the answer to everyone's prayers. A financial XML specification would make it easier for banks and firms to get simultaneous quotes on swaps. Electronic confirmations would erode the likelihood of errors. A standard would also—significantly—help fight the good fight by advancing the cause of straight-through processing for dealers and end-users. Moreover, a protocol would improve efficiencies in developing derivatives instruments by "creating scalability and reducing cost, operational risk and the settlement time frame,” points out Dushyant Shahrawat, an analyst at Needham, Mass.-based TowerGroup and author of a recent report on XML specifications.

A financial XML protocol would also make risk management possible in ways that haven't existed before. Instead of having to rely on pricey, clunky middleware that schleps data from one program to another, firms could turn to a data standard that makes data inherently more mobile. So far, the lack of a standard in the over-the-counter derivatives arena has "restricted the ability of financial services firms not just to exchange data among themselves but also to send out this information to vendors and sell-side firms for various kinds of analyses,” notes Shahrawat. With an XML specification, portfolios could be tossed back and forth between banks or broker-dealers as casually as frisbees—and therefore could be stressed, tested and risk-managed in one fell swoop.

That, anyway, is the dream. At the moment, however, the road to digital nirvana is rockier, with competing standards, territorial skirmishes, criticism and some questions about motivation desecrating the landscape.

The players

The two main contendersfor an XML derivatives trading protocol are JP Morgan and Pricewaterhouse-Coopers, on the one hand, and Integral, a software vendor based in Palo Alto, Calif., on the other. Morgan's protocol, which it is developing via a consortium of large banks and broker-dealers and which is tentatively scheduled for release next month, is called FpML. Morgan (and others) tout it as an industry-based standard. Integral's FinXML, meanwhile, was developed by Integral, hews closely to the product definitions provided by the International Swaps and Derivatives Association, and is downloadable at no charge at CFOWeb.com, the firm's still-skeletal (but growing) derivatives and risk management portal.

Not surprisingly, the creators of these two protocols see the prospects for their offspring differently. According to Morgan, FpML's advantage is that it's being developed by the people that count and for the people that count—that it can, in short, be judged by its genes.

Morgan is advocating an industry-led standard because, it says, such a specification will address the needs of banks and broker-dealers. If a protocol takes into account the requirements of the various firms that helped develop it, "it's likely to be more inclusive of a broader range of requirements [than a vendor-developed standard],” argues Brian Lynn, vice president of derivatives architecture at Morgan and co-chair of the FpML standards committee. "It's also likely to have been subjected to scrutiny, so errors aren't as likely to creep in. It's a question of whether you want to have something developed by one firm for the benefit of that firm and maybe anybody else, or something developed for the benefit of the industry as a whole.” FpML will initially cover vanilla swaps and forward rate agreements, with interest rate options to be added to the menu in a subsequent round of product definitions, and equity derivatives after that. The protocol will be issued to vendors and end-users under a free license.

But Morgan, naturally, is banking on more than just the immediate usefulness of swaps confirmations. Once financial XML gets some wind in its sails, "new business ventures,” as Lynn puts it, will hit the ether. Of course, this is happening at the very time that large investment banks and sell-side firms are realizing they must start generating income from risk management and analytical services for clients, rather than from traditional transaction fees.

"It's a question
of whether you want to have something developed by one firm for the benefit of that firm and maybe anybody else, or something developed for the benefit of the industry as a whole.”
—Brian Lynn, JP Morgan

An example of one such venture is Cygnifi, Morgan's recently launched application service provider for the derivatives market. Although Cygnifi was planned before FpML was conceived, having a protocol that will permit bulk interfaces and the quick exchange of data leverages what the site can offer customers. And SwapsWire, a six-dealer consortium (including Morgan) for the on-line pricing and eventual execution of interest rate swaps, will sit as snugly on the back of FpML as a well-fitted saddle on a quarterhorse.

While Morgan is on the stump for an industry-led XML specification to standardize trading, however, Integral is happy to talk shop and hail the practical benefits of its strategy. For a vendor, time-to-market is an issue, and the exigencies of the marketplace made Integral last summer clamp a set of wheels on its XML specification and roll it on-line. "FinXML is a commercial XML implementation for finance,” says Harpal Sandhu, the firm's CEO. "There's a big difference between what we're doing here and what's being talked about through the consortium mechanism.”

Integral makes no bones about FinXML not being a standard. Morgan has been focusing on language and working on the softcore details of the specification from an academic, groupthink perspective, suggests Sandhu, whereas "we are building the language and using it from a commercial perspective on CFOWeb.com.” The result is that FinXML is currently downloadable and covers a greater number of instruments and markets than FpML. Integral's bottom line: "We wanted to build a network,” notes Sandhu. "Our customers are the banks providing their financial products on the web to end-users. They need to do it in a cost-effective way, and the only way they can do it is if XML exists, web sites exist and the infrastructure exists that allows them to do it in an automated fashion.” But Integral isn't a nonprofit organization. It will make money by collecting a fee from banks every time they do a transaction on CFOWeb .com and by charging them a monthly per-asset fee. And Integral, of course, needs to get people to use its portal in the first place.

"No one's working
on XML to make our lives easier. It doesn't provide new functionalities, and there's no clear net benefit for vendors, except for the ease of software implementation.”

Infinity, a SunGard company, is also turning to XML to improve the lot of the derivatives and risk management community. The firm is trotting out a cross-asset XML-based data model called the Network Trade Model. NTM prescribes a common message format that enables transactions from different systems to be processed smoothly by analytical engines or imported into data warehouses. Essentially, it offers a kind of standard interface for risk-management applications, and has contributed to Microsoft's DNAfs architecture, an applications integration framework pitched at the financial services industry.

In keeping with its strengths (and assets), Infinity developed NTM to absorb some of the pain of data management. NTM covers a broad range of financial instruments, but with an eye toward applications integration rather than the confirmation process. "SunGard has over 300 products,” points out Brian Robins, head of marketing at the Wayne, Penn.-based vendor. "It's beneficial for our customers if we can connect those systems together, because then it's easier for them to transfer information around different systems and achieve straight-through processing, which translates into reduced costs and improved efficiency.” NTM has been rolled out in one European client to connect the front office with its middle-office analytics and cash-management systems, and is now being test-driven in the United States.

"SunGard has
over 300 products. If we can connect those systems together, it will be easier for clients to transfer information around different systems and achieve straight-through processing.”
—Brian Robins, SunGard

Sour grapes

The success of a standard, of course, will depend on the extent to which it's put to work executing transactions. If it doesn't meet the needs and specifications of treasurers and swaps dealers, it will go the way of the 33 LP. Beyond that, there needs to be a range of analytical and risk management applications tailored around the product definitions built into the standard. And naturally, there's skepticism about whether vendors will cotton to a specific vendor-based protocol as opposed to an industry-vetted protocol. There are worries that such a specification could wind up being "vendor-controlled”—and a consequent reluctance among vendors even to imagine XMLizing products, according to the language of a competitor.

At the same time, many vendors say they don't see a need to rush headlong toward any XML protocol. "XML will benefit the banks since they'll be able to service smaller banks and institutions,” harrumphs one derivatives software vendor, "but no one's working on XML to make our lives easier. It doesn't provide new functionalities, and there's no clear net benefit for vendors, except for the ease of software implementation.” Standardization may aid customers by enabling more firms to offer risk management solutions because the barriers to entry are lower, but from a vendor's perspective that's not necessarily ideal. In addition, many vendors now feed their cash flows through consulting and data-integration services, and those nest eggs could get pulled asunder.

The inevitable fact, though, is that vendors will find themselves adapting to XML as their clients make the eventual switch. Those in the derivatives market with even a glancing familiarity with XML have no doubt that a protocol will ramp up OTC trading and risk management efficiencies. Many liken what's expected to happen as a result of an XML rollout over the coming months with the sea change that took place in the early and mid-1990s in equities and fixed income, when the FIX protocol standardized the front-office order-management process between broker-dealers and customers.

Indeed, the FIX Protocol Ltd. Association will soon be ushering in an XML version of FIX, called FIXML. "FIX is being modified to handle market data for electronic communications networks and new order-delivery rules for exchanges, and we're doing more with options strategies,” says John Goeller, director at Salomon Smith Barney and chair of the FIXML Working Group. The Chicago Board Options Exchange, for instance, recently issued a FIXML specification. "With FIXML and more standardization, we can share information in equity derivatives much more easily with exchanges and our customers,” adds Goeller. FIXML, like FpML, will be maintained by end-users. In addition, S.W.I.F.T., the standard-bearer messaging format in the post-trade arena for OTC derivatives, is getting ready to handle XML formats on its private network for member banks and broker-dealers. The 25-year-old organization says it will be able to support FpML or an FpML-type protocol on its system in the first quarter of 2001, but that it will handle any protocol its members want.

While there are a range of initiatives growing up around financial XML protocols, many are complementary or focus on different instruments and markets. The stated (and sensible) goal of XML developers is not to be the proud parent of an XML protocol but simply to get a standard to the market for the benefit of all market participants. So apparently, there remains a pocket or two of altruism in the markets—at least until the battle of the ASPs gets underway.

Yet one issue that will become more pressing as XML protocols exit the factory and begin to be used for transactions is the potential unruliness of multiple protocols. Standardization is clearly a virtue, but too many protocols could jeopardize the cause. Specifications will have to be interoperable or at least able to map to one another, so counterparties don't wind up with a mess of protocols and message formats that can't communicate with each other, points out TowerGroup's Shahrawat. There are promises of interoperability on all sides, but so far little action. Still, it's early, and XML advocates are only just beginning to give form to what has been, until now, a godless void.