Over the past few months I've been talking with people on both sides of the Atlantic - exchanges, brokers and ISVs - about the emerging concept of electronic specifications in financial services, and the FIX Trading Community's proposed "FIX Service Profile" in particular.

It's important to begin with words of support for the initiative; the idea of electronic specifications as a way to reduce the massive inefficiencies that currently plague the task of making and maintaining connectivity is spot-on. It is the idea we've been championing at FixSpec for almost three years (and indeed our founding vision), so wider recognition of the underlying problem and initiative is certainly welcome.

In a recent Tabb video though I hinted that the FIX Service Profile may not be the panacea that some are hoping for. Many people contacted me after watching the video to understand more, so I wanted to use this blog to share some of the very consistent feedback I've heard both in recent months and indeed since FixSpec's launch in late 2012.

The first - and biggest - challenge is the classic "chicken and egg" problem.

Brokers and exchanges won't invest their precious time to convert their Word or PDF documents into an electronic format unless there is demand from customers (or their ISVs) who can consume it. I've heard all of the usual predictions of major FIX Trading Community firms being obliged / coerced / forced to create and distribute in this format, but unfortunately I simply don't believe them. It didn't happen for FIXatdl. It didn't happen for FIX Repository. So why is this time different?

On the flip side, ISVs and brokers have no incentive to change their systems to process a new format until there is a critical mass of specs available in that format. Discussions with major ISVs indicate that most already have internal, well-established, XML-based schemas to configure gateways. So why would they take on the effort and risk of moving to a format which arguably erodes their competitive position? They won't. The most likely alternative response is to follow the FIXatdl path; hack together an internal conversion tool to map the "formal" schema into your internal schema and then continue to use that.

ASIDE: FixSpec's response to this current market reality, is to stop promoting a one-size-fits-all approach and instead work with ISVs to generate proprietary XML exports directly out of our repository. This approach means that electronic specs are accessible to ISVs today.

The second challenge is scope, and the clue is right there in name - this is only about FIX. But the simple fact is that most exchanges in the world today don't exclusively offer FIX for order entry, and most offer market data in some format other than FIX FAST. So restricting to FIX means the initiative is only half of a solution for exchanges, and actually isn't actually that useful for brokers who rarely have a "fixed" FIX interface anyway.

Financial services connectivity (especially pre-trade) always has been - and always will be - multi-protocol, and it is time that we as an industry started to recognise that and build formats, products and services that are multi-protocol from birth.

In a previous job at a large ISV, I found it interesting to compare the tasks of developers building gateways for order entry verses those building market data gateways. Sure, market data APIs change far less frequently than order APIs, but think about the core infrastructure required to even begin the task - there are no consistent "standards" to refer to, no handy online decoders, and no open-source projects to help seed an architecture. This simple observation means that a "Market Data Service Profile" would be of even higher value than one restricted to one order-entry protocol.

So where does this leave us? My sad prediction is that FIX Service Profile will follow the well-trodden path of other formats before it, failing to achieve traction and being consigned to become yet another dusty PDF a website somewhere. The problem isn't the absence of a format, it's the environment and the approach itself.