Taming The 800-Pound Gorilla – Encouraging FIX Compliance Amongst Exchanges Globally

Q: Where does an 800-pound gorilla sit?
A: Anywhere it wants.

I landed my first job in the financial industry back in the Halcyon days of the mid-1990s. From my naïve perspective, everything was wonderful. Stocks only went up. Nobody worried about a company’s P/E ratio, or if it were capable of turning a profit. If it had a “.com” in its name, it was a guaranteed winner. A website that resold airline tickets had a higher market capitalization than the airlines. Within the financial industry, technology was King, and with money growing on trees, it seemed firms had unlimited IT budgets and armies of software developers.
Exchanges, in the mid-90s, were the 800-pound gorillas of the day. They could implement proprietary standards, and firms had no choice but to adopt them. With liquidity centralized on the exchanges, there was no real competition, so everyone in the industry let the gorillas sit wherever they wanted. And with unlimited IT budgets and armies of software developers, accommodating the seating needs of several gorillas wasn’t all that painful.
What a difference a decade makes …
Times have changed. With the global economic crisis, IT budgets and headcounts are shrinking across the industry, and costs must be justified. Liquidity in many regions has become decentralized, with new generations of ECNs and ATS’ taking market share from central exchanges. Interexchange linkages mean that firms don’t have to connect to everyone to achieve price protection and best execution although, obviously, exchanges would prefer firms access them directly and not through their competitors. Firms are discovering they now have far more choices in finding liquidity, and they have less reason to tolerate expensive proprietary or non-standard interfaces.

Is FIX the solution?
FIX provides benefit to the financial industry in the form of a “network effect.” In theory, work done to support FIX for one market can be reused with other markets, effectively sharing the development cost. Proprietary protocols lack the ability to generate network effects and increase costs for the industry. A market that only supports a proprietary protocol is like an 800-pound gorilla that wants to sit on my laptop. The resulting situation is clearly amenable to the gorilla, but to me it’s expensive and inconvenient.
Proprietary protocols are not the only method of escalating market participants’ costs. While many markets claim to implement FIX, some deviate from the standard protocol to varying degrees, which drives up costs. Deviations usually fall into three categories: session, syntax and semantics.

Session costs
With a wide variety of established commercial and open-source FIX engines, session level deviations are few, but notable examples do exist. In these cases, the cost to a market’s participants can be severe. Firms using commercial FIX engines usually do not have the ability to modify an engine to support non-standard session behavior, so firms find themselves at the mercy of their engine vendors. They, in turn, are left scratching their heads wondering why the particular exchange deviated from the session standard and how they can recoup their costs to work around the exchange’s issues.

Syntax costs
Deviations in syntax are more common. These may include failing to send required fields, or forcing participants to send custom, user-defined fields that are not required by the FIX specification. While these do carry some expense and inconvenience, they are not usually catastrophic.
And semantics
Semantic deviations, however, are a market participant’s worst nightmare. The FIX Protocol defines precise semantic usage. Business processes are represented by standard transactional flows of messages, which themselves carry defined identifiers, states and key fields. Market participants’ systems are built assuming certain fundamental semantic behavior. Any nonstandard semantics will often require costly changes and could impose considerable additional latency in the participant’s system.
The costs to the industry of nonstandard behavior include analysis, development, QA, deployment, and integration testing. Firms who use vendor products must convince their vendor to support the non-standard behavior and must wait until the vendor can find the time to create, test and release the change. Just as the “network effect” can reduce costs for standards compliant implementations, nonstandard behaviors multiply these costs. Every $10,000 change to support nonstandard behavior made by 1,000 market participants costs the industry $10 million.

What makes them tick?
Understanding the gorilla’s psychology
may be useful in correcting its behavior Gorillas usually choose to deviate from the protocol and sit on inappropriate objects for one of three reasons: they don’t know any better; it allows for easier interfacing with their internal systems; or they believe they are implementing new business functionality not supported by FIX.

Finding the knowledge
Knowledge of the FIX Protocol is not hard to acquire. The specification itself contains extensive documentation. Posting a question in the FPL website’s discussion forums (www.fixprotocol.org/discuss/) often yields a quick answer. Firms can collaborate with FPL directly and markets can solicit comments from their participants on their Rules of Engagement documents. Understandably, participant firms who will be connecting to the market have a vested interest in pointing out any non-compliant functionality that will be costly to implement.

Taming the legacy systems
Legacy systems are often the cause of the most difficult incompatibilities in semantics. An exchange may think it is saving money by directly exposing legacy semantics not compatible with FIX to its members. FIX compliance may require that the exchange perform translations or modify its legacy system to accept FIX semantics, and that might increase the exchange’s cost. But doing so benefits the industry; it ensures compatibility with the considerable quantity of FIX software that expects standard FIX semantics, reducing every market participant’s cost. Standard implementations reduce industry cost, while non-standard implementations pass the buck to the market participants and multiply the costs for the rest of the industry, which is never a good idea.

Standardizing innovation
Innovation is vital to the financial industry, and markets should be encouraged to create new functionality. But this can lead to a proliferation of user-defined fields and messages, which sharply reduces the “network effect” and increases costs for the industry.
Most market-specific features I have seen implemented as user-defined fields are already part of the most current FIX standard. Even with resources such as FIXimate (www.fixprotocol.org/FIXimate), with more than 1600 tags, it can be difficult to find functionality if one doesn’t know where to look. FPL also adds new features to the FIX Protocol in response to industry needs. For example, functionality that must be user-defined in a FIX 4.2 session may be standardized in FIX 4.4. But if new features needed by a market haven’t yet become standardized, the best course of action is for the market to request that FPL add the functionality.

Speed up the changes to encourage innovation
Prior to FIX 5.0, new versions of the protocol were released infrequently, often 18 months apart. This simply was not a viable model to support innovation. Now, FPL releases Extension Packs, which are bundled into Service Packs for FIX 5.0. An exchange could write a Gap Analysis proposing a change, which would then be approved and adopted as an Extension Pack. For minor changes, the entire process could be completed within two months. FPL would then publish the Extension Pack, complete with tag numbers and enumerations, allowing for immediate adoption.
Reducing implementation costs for the industry is important to FPL. I work with FPL’s regional representatives to collaborate with exchanges, ATS’, ECNs, and regulators to promote standardization.
The latest FIX version (currently FIX 5.0 Service Pack 2) provides the most value to an industry struggling with limited development resources. Numerous ambiguities and unsupported functionality in earlier versions are clarified in FIX 5.0 SP2. Numerous proprietary, incompatible methods for representing things in older versions of FIX, such as FIX 4.2, are replaced with standard representations in the latest version. And FPL can only add new features to the latest FIX version in the form of Extension Packs. Fortunately, the cost to support FIX 5.0 SP2 isn’t onerous. Existing FIX order handling semantics have remained largely unchanged since FIX 4.4, few of the subsequent changes are mandatory, and all changes are stored in a machine-readable Repository.

Watch the market leaders
Several forward-thinking firms have seen the benefits of standardisation, and we are now seeing a number of exchanges globally supporting the FIX Protocol, as well as its use for market regulation, with growing support for the latest release of FIX 5.0 SP2. One such firm, the Investment Industry Regulatory Organization of Canada, was forward-thinking in responding to its members’ needs. When IIROC polled its member exchanges and ATS’ on the format of the regulatory feed each market must use to report transactions to its new market surveillance system, they were fully supportive of using the FIX Protocol. The markets and IIROC wanted to use the most standardized specification possible and avoid user-defined fields. FIX 5.0 SP2, with an Extension Pack to support IIROC’s needs, was the logical choice.
I worked closely with IIROC and observed first-hand that, while a myriad of user-defined fields dominate the Canadian markets, existing FIX 5.0 SP2 functionality rendered almost all unnecessary. The changes IIROC required were small and didn’t need a single additional field. Initial market reactions have been largely positive. IIROC’s collaboration with FPL has laid the groundwork for standardization and substantial cost savings among the Canadian markets.

It comes down to cost
In today’s competitive landscape, any market, be it an 800-pound gorilla or a smaller player, faces a serious competitive disadvantage if its FIX interface is nonstandard. Would a broker or vendor with limited resources choose a difficult, custom integration job for one market, or use those same resources to connect to five competitors who all follow the standard? Likewise, a market’s new, innovative features are worthless if brokers and vendors don’t implement them. Features using standard FIX fields that can be reused by other markets are more attractive than user-defined FIX fields that are limited to one market.
In these difficult economic times, a nonstandard FIX interface is truly a competitive disadvantage. Fortunately for the industry, many market places have noticed this trend and have chosen standardization. FPL welcomes the opportunity to collaborate with trading venues and regulators to promote standardization, leading to decreased costs for the industry.