Category Archives: financial services

A Few Quick Takeaways From A Speech By Morgan Stanley's Jim Rosenthal

I had the privilege of hearing an after-dinner speech by Jim Rosenthal, COO of Morgan Stanley Smith Barney and Head of Corporate Strategy for Morgan Stanley overall.  The speech was particularly interesting because of Jim’s almost accidental IT experience; Jim’s background is in strategy, not IT, but he nevertheless served for two years as Head of Firmwide Technology at Morgan Stanley.  This made the speech, delivered to an IT audience,  all the more interesting because it was something of an exposé:  an outsider’s inside view of IT.

I don’t have time to provide comprehensive notes, so I’m just going to jot down some of the key things I took away:

  • Technology is second biggest expense in banks next to producer compensation.  Banks should treat it as such.
  • Regulators are our friend.   If anyone is going to push technology up the importance agenda, it’s going to be the regulators.
  • IT execs need to earn the right to participate in the business conversation.  This is done through delivery on both strategic and myriad tactical items.
  • IT needs to steep senior management in technology.  Technology is critically important to banks and technology leaders have an obligation to educate senior management to relevant technology issues.
  • Put performance metrics on change.  Don’t just put metrics on operations but also define and measure key metrics related to strategic change.
  • Kryder’s law:  magnetic disk storage areal density doubles annually.  While I’m not sure I understand the math in either the referenced article or the Wikipedia entry, this means that stored information grows even faster than processor speed (i.e., Moore’s law).
  • Data architecture is the key to coping with Kryder’s law.  Data architecture lets you control what would otherwise be an uncontrollable wave in the future.
  • We will never put our data in the public cloud.  We love cloud computing, but for private, internal clouds.
  • Technical skills and quant skills are converging.  It’s not about the technology anymore, it’s about what we can do with the data.
  • IT is odd in the sense that it seems to feel it deserves more respect than it gets.  There is an odd tension about whether IT is a first- or second-class citizen.  IT needs to be a first-class citizen and CIOs need to learn to work senior executives and the board to make it such.
  • Banks need to think of themselves as technology companies that happen to work in financial services.   (This is analogous to Google who considers itself to be a technology firm that happens to be in media/advertising.)

The Dawn of Financial Services Open Source Intelligence (OSINT)

I was happily surprised to read this article today, Wall Street Firms, Hedge Funds, Recruit CIA, Ex-Military Intelligence. The subtitle sums it up nicely:

Financial firms are particularly eager to recruit former Afghan and Iraq war vets with intelligence operations experience since they can bring new technology and techniques to research and analysis.

That’s good news for Mark Logic in financial services because OSINT is:

  • An area in which we have developed significant expertise, not only in terms of product requirements, but also in how to support customers in building and deploying complete OSINT systems
  • An application that we are starting to see in other verticals. For example, when we hosted our webinar, Harvesting Deep Web Content for Open Source Intelligence, we had not only the usual suspects (i.e., government agencies), we had — much to my surprise — a few attendees from other markets as well.
  • An application that does not lend itself well to the predefined world of traditional database technologies. It is a near perfect fit for MarkLogic. It is — in fact and quite literally — exactly what MarkLogic Server was originally designed to do. (Maybe one day, I’ll tell that whole story.)

Here’s an excerpt from the article on open source intelligence in financial services:

Today, the private sector needs timely, relevant and actionable “intelligence” to secure their businesses against potential threats, he explains. Some of this intelligence can be produced with open source information ” publicly available information that anyone can lawfully obtain.

The full story is here.

FpML Derivatives Trading Repositories with MarkLogic Server

We’ve recently seen some interesting developments with Mark Logic in the financial services sector, particularly in the area of derivatives.

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 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.