The activity started with our partnership with docGenix, a spin-off from legal powerhouse Allen & Overy, who has built a MarkLogic-based application for managing derivatives contracts. I’ve blogged about docGenix previously in this post entitled MarkLogic Unleashed on Contracts.

When you boil it down, there are two primary IT problems with derivatives trades:

• Managing the thousands to tens-of-thousands of pair-wise master agreements that govern the trading between parties. These documents, in the absence of an exchange, provide the legal framework for trading, covering such terms as risk management and the effect on the business relationship in the event of, say, a credit downgrade for one of the parties. This is what docGenix does. They don’t just store the information — much more importantly, they provide tools to let you analyze it.

• Managing the trading records associated with individual derivatives trades. These trades are traded “over the counter” with the final record exchanged in financial products markup language (FpML), an XML standard format for swaps, derivatives, and structured products.

Per FpML.org:

The very flexibility and rapid evolution of over-the-counter (OTC) derivatives has challenged technology. For most of the life of the OTC derivatives industry, technology development has focused on building tools for pricing and risk managing these transactions, functions that are primarily internal to the firms entering these transactions. Because of the wide variety and rapid change in the products that are traded, it has typically been viewed as not cost effective to build standard electronic mechanisms for interchanging details of the transactions between participating firms. The perpetual fear was that any such standardized data interchange mechanism would be doomed to being obsolete, as new product attributes could not be added and agreed to in the data interchange standard as quickly as they could be by trading desks.

Per the site again, FpML aims to deliver the following benefits:

• Financial instruments are specified in a format that is readable to both computers and humans. This enables system-to-system communication within business-to-business e-commerce applications.

• Financial information can be readily exchanged between diverse sets of applications, as applications and technology vendors provide both turn-key applications and core technology that support FpML-based information exchange.

• Processing costs will be reduced as a result of lower communication costs between applications and lower system implementation costs.

• The wholesale financial services market can take advantage of interactive technology to reduce operational risks while increasing business opportunities.

From the Mark Logic perspective, there are several attractive things about FpML.

• It’s XML-based. We believe MarkLogic Server is the world’s best place to put XML, so we love XML-based standards formats.

• It’s constantly evolving. Looking at the most recent specifications (registration required), you can see versions: 1.0, 2.0, 3.0, 4.0, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7 second working draft, and 5.0 working draft. From a technology perspective, it makes sense that the standard evolves. But from an XML repository perspective, it makes the information semi-structured and thus difficult to manage using traditional storage technologies such as relational databases. (Information in 6 different well defined formats is certainly not well structured, but it’s certainly not unstructured either. Hence, my preference for semi-structured as a way to describe this and other somewhat-structured information.)

• It’s complex. Wading through hundreds of pages of the standard makes it clear that managing an FpML repository is not for XML dilettantes.

• It’s big. I’m told that FpML respositories will run, order of magnitude, in the 10 to 100 TB range. Scaling to this range is just one thing that breaks RDBMSs when trying to store FpML.

• High-performance is required. MarkLogic specializes in high-performance queries against multi-terabyte, semi-structured XML repositories.

This is a new area for us — we are just starting to work with the first few customers — but it’s an area that holds a lot of promise for both technological and business (e.g., increasing focus on transparency with derivatives) reasons.

If this is something you’re looking at doing, give me a ping at ceo-at-marklogic-dot-com.