Andy Gluck has an interesting post on his blog about integrating web services. In it, he promotes the concept of Web Services being the new silver bullet for financial advisor applications.

From the post:

Web Services provide significant improvement in efficiency and savings. They free advisory firms from re-keying client data into multiple applications, which saves labor and reduces errors. Service to clients is also improved because you no longer have to input all of the holdings every time you do analytics on a portfolio. If your analytics program, say Morningstar Principia, can take a Web Service from your portfolio accounting application or get it directly from your custodian, you are likely to run your analytics program more often.

I’m seeing the "Web Services is the solution" theme more and more in technology articles about our industry. I’m going to disagree with the prevailing sentiment. Not only are Web Services not the solution, they actually make the fundamental problem *worse* from a vendor perspective.

The biggest technology problem in our industry is that every vendor has to write an individual, unique interface to every other vendor. The more vendors there are, the more work there is for each vendor to do.

Suppose I’m writing a Financial Planning system. I want to import my accounts and positions from Schwab Portfolio Center because that’s what my first client uses. I write to Schwab’s spec, which is in comma-delimited format*, and has three separate files, one for account-level information, one for share balance-level information, and one for current price information. I’ll be optimistic and say that it takes me a week to write to the Portfolio Center spec. Great! One happy client.

So I launch my new Financial Planning software, it gets rave reviews, and I’m contacted by five more advisors who want to buy it. Woo hoo! Unfortunately, none of the five use Schwab Portfolio Center. One uses Advent Axys, one uses Black Diamond, one uses dbCAMS, one uses Advent APX, and one uses Investigo. Hmm… Well, since I’ve already written to Schwab Portfolio Center, the rest of these should be easy, right?

Wrong.

The Investigo data is in an XML format* based on transactions and doesn’t provide a share balance file. So I have to scan the transactions and add up all the share balances to get the current share balance that my financial planning system needs. Black Diamond provides a share balance file, but no account name file, plus their share balance file is always two days behind*. dbCAMS uses an older fixed-length format specification for all of their files, and Advent doesn’t even make their file specifications available so I’m not sure which fields are which. I suppose I’ll just look at their raw data and make some intelligent guesses.

So just to get my next five clients up and running, I’m looking at months of work. And don’t forget, these file formats aren’t stable. They change periodically, with no warning, and often require the interfaces to be completely rewritten. Interfaces are a full time job for years until you get an interface library built. If you’re a portfolio management system vendor, you can add custodial interfaces and transaction files to the mix, increasing your work exponentially.

So how does this get worse with Web Services?

Now, instead of just having to worry about file formats, each vendor has to worry about the other vendor’s transport mechanism. It’s not enough to write an interface to the other vendor’s data format, now we have to worry about how the data is being sent to us. With Schwab, we have to drag the files off an FTP site*. With Black Diamond, they present the data in a custom file spec, wrapped up in a SOAP package, available through a web site with a user id/password*. Maybe Investigo uses REST and integrates with Microsoft Passport, so you have to figure out how to log in to Passport before you can get to the data. Advent decided to use JSON version 1.1, and FinFolio uses WCF.

With vendors also worrying about the data transport mechanisms for all the other vendors, we’re now talking about two full-time jobs… for every single vendor. And don’t forget about the ongoing support costs. Guess what was our biggest support issue at Techfi? Not even a close comparison–interfaces.

From the client’s perspective, Web Services are great–no more moving text files around. You click a button and your data imports, no matter where it is. But you don’t get anything without paying for it, even if you don’t see these costs reflected directly. Your vendors have to commit significant extra resources to maintaining web service interfaces, in addition to the file format mappings. What other features could they be working on? Could they have fewer staff, reducing the price of the software?

So what’s the solution to this nightmare? How can we eliminate the hidden interface tax being levied on every vendor in our industry? It’s simple–a generic file specification that covers data format, and transfer mechanism. It needs to be open, comprehensive, free, and supported by all of our major vendors.

*That* is our silver bullet.

If we had a generic interface spec for the industry, then my prior example would change as follows:

Suppose I’m writing a Financial Planning system. I want to import my accounts and positions from Schwab Portfolio Center because that’s what my first client uses. I write to the industry standard specification. I’ll be optimistic and say that it takes me a week to write to the industry standard spec. Great! One happy client.

So I launch my new Financial Planning software, it gets rave reviews, and I’m contacted by five more people who want to buy it. None of the five use Schwab Portfolio Center, but it doesn’t matter. All of their portfolio management systems use the industry standard spec so my work is done. I sign up my next five clients.

A generic industry specification is the single most important thing we could be working toward as both advisors and vendors. Once each vendor supports this generic specification, it will be the last import we ever have to write, freeing up countless developer hours, eliminating our largest support requirement, and reducing the price of all advisor software.

This is not idle speculation. There are many precedents for vendors cooperating to build generic specifications in other industries. In fact, the advisor software segment is one of the few industries that *hasn’t* built a generic spec.

I’ll give you an example–Microsoft/Intuit. These guys are bitter rivals, matching each other feature for feature, and competitively slashing prices on their two competing products, Money and Quickbooks. But in the midst of their rivalry, they teamed up to eliminate a common problem–downloading account info from banks.

There are thousands of banks and investment accounts out there where Money/Quickbooks customers need to download account data. It would have been extremely time consuming to write to every bank’s proprietary format, forcing Microsoft and Intuit to have large staffs of developers writing and maintaining interfaces (sound familiar?). Luckily, they were smarter than us. They set their rivalry aside, and created something called the Open Financial Exchange (OFX).

OFX is a standard layout for bank account and investment account information. It also dictates which transport mechanism (XML over HTTP) the vendors used, with the end result being that all Money/Quickbooks clients can download their account information from virtually any bank, all without Microsoft or Intuit having to maintain a library of interfaces. Brilliant.

I’d love to see the same level of cooperation between our industry vendors. Imagine if Advent, Schwab, Fidelity and Ameritrade got together to create a standard interface spec for our industry? If those four companies could be convinced to drive the process, we could have a generic spec by year-end. At the very least, we could be having round-table discussions about specification particulars during break-out sessions at this year’s conferences.

Web services are a great thing, but *only* if we build them out within the framework of a generic industry file specification. If each vendor publishes their data using their own version of "web services" then we’re making the fundamental problem worse, and creating significantly more work for each vendor, which will ultimately result in increased software prices or decreased services.

I can’t finish this post without answering one question: Could Silver Bullet, cashEdge, eMoney, etc. pull off a generic specification? Unfortunately, I doubt it. These are for-profit corporations that have shareholders with money invested, who ultimately want to see a profit. What’s the point of eliminating the "interface tax" for all advisors, if we just replace it with a "silver bullet" tax that goes to yet another company. In fact, I would expect those companies to fight hard against any truly independent effort to create a generic industry spec, since their entire business models are built around the difficulties of maintaining hundreds of proprietary interfaces.

There is no reason to have an intermediary in our data stream. With a generic set of specs, supported by the major players in our industry, we can have direct point-to-point data transfer without any strings  attached. If Microsoft/Intuit can pull it off for investor accounts, we can pull it off for advisor data.

…

* In my "Financial Planning System" example, I don’t actually know what formats the different PMS vendors use. This is just to give you an example of the wide variety and complexity of writing to different vendor’s proprietary specs.