Home › 
Current Issue
+ Back issue

Deutsche Börse’s Hanno Klein, Co-Chair of the FPL Global Technical Committee, expounds on the role of FIX semantics in standardised access to trading and clearing services.

Why are Interface Semantics Important?

Hanno Klein, Deutsche BoerseSemantics represent the look and feel of an interface from a nontechnical perspective, but can influence overall implementation and testing effort much more than the syntax. If you will, semantics are the interface language and standardization is about speaking the same language, for example FIX.

The Difference between the FIX Syntax and FIX Semantics

Syntax is the encoding of bits and bytes on the wire; for example, whether you use ASCII or binary values for numbers or whether you have a FIX tag=value syntax or an XML syntax  like FIXML. The syntax consists of messages, components, fields and valid values that are the building blocks for the semantics. FIX semantics is about the business functionality and how it is expressed within the building blocks of FIX. FIX Semantics relates to the elements with which information is conveyed and about the flows through which these elements are passed back and forth between two or more parties. Let me give you some examples.

  • A combination of “35=D” and “35=8” is the tag=value syntax for the semantic “submission of a new order for a simple instrument followed by a confirmation or rejection being returned”. Readers probably know these tags by the more familiar terms NewOrderSingle and ExecutionReport.
  • 59=4” is the tag=value syntax for the semantic “order needs to be filled completely upon entry or cancelled immediately”. The FIXML syntax for the same semantic is TmInForce=”4”.The corresponding term for the order, Fill-Or-Kill (FOK) is a well known part of the FIX language.
  • “38=1000|1138=100|1083=1|108 4=3|1085=50|1086=80” stands for “reserve order of 1000 that is to be displayed initially with 100 and to be replenished whenever a fill occurs with a randomly chosen quantity between 50 and 80”. Some might be more familiar with the term “iceberg order” which is not used by FIX.

The mapping of semantics to syntaxis  not trivial and standardization is about using the same map for the same semantics to ease the burden for the software developer and reduce costs.

How can FIX semantics be used more effectively?

Greater effectiveness will come through an increasing awareness of the importance of FIX semantics for true standardization. FIX training courses could be offered with a focus on semantics and put less emphasis on the technical aspects of the protocol such as the encoding or the session layer mechanics. Usage guidelines for new and existing functionalities can help to understand the semantics behind FIX message layouts.

Without semantics it is impossible to determine which FIX fields or valid values will be present in which contexts. The syntax will merely show all possible values of a field, which may be sufficient for the developer, but not for the person who then wants to test the interface.

Itaú Asset Management’s Christian Zimmer and Hellinton Hatsuo Takada drill down into the usage of FIX in Brazil, isolating the areas where FIX is developing and where there is room to grow.

Christian Zimmer, Itaú Asset ManagamentThe BM&FBOVESPA (BVMF) initiative to provide market data using FIX is just the beginning of moving past the basic usage of FIX in Brazil. FIX is being implemented under the Unified Market Data Feed (UMDF) banner with the objective of integrating the traditional FIX market data and Multimedia Multiplexing Transport Protocol (MMTP) market data streams. The communication efficiency between these two needs to increase a lot, because in Brazil the trading community is starting to go beyond the simple use cases for FIX.

Besides the FIX implementations, one example of this development is the FPL initiative tasked with creating a version of the FIXimate in Portuguese, which the local FIX engineers are contributing to. In the last FPL meeting in Brazil, the local public seemed to be a little bit more aware of FIX, while the use of the FIXimate in Portuguese indicates a growing development of FIX solutions in Brazil.

Currently, some brokers are providing simple execution algos to be used in the Brazilian market. However, these are not delivered via FIXatdl, but via an algo-number indicated in a general purpose FIX-tag. Currently, the algos offered are very simple: mainly VWAP, TWAP, Iceberg, and POV. More sophisticated algos that try to gain some alpha are present too, but they are not originally created by Brazilian market participants. These kind of algos are normally developed from global brokerage firms at their headquarters in the US or Europe and then applied/adapted to the local market (what we call tropicalization).

Even if the algos were customized by the international firms to fit local market data, we have our doubts that on the actual trading floor there are many buy-side traders using these advanced methods. There are mainly two reasons for the nonusage of the advanced algos. First, there is a lack of confidence whether international teams understand well the local Brazilian market. Second, most of the  time the big buy-side firms have mandates to achieve a 100% fill rate – something not guaranteed by the alpha-creating algos. This demand originates from the way the big asset management firms work in Brazil: they are more fundamental, and focused on allocation rather than trading.

The usage of FIXatdl could improve the usage of algos because of its standardization, but it is still hard to move forward on this issue.The sell-side seems not to be too enthusiastic, and thus, does not provide the buy-side with this efficient alternative. The buy-side is also not demanding it, which implies that there will be no advances.

In addition to FIXatdl, we expect the efforts of the FPL High Performance Interfaces Working Group to become applicable in the Brazilian market. The success depends on, obviously, if the exchange permits a separated access to their matching engine with this protocol dialect. But as there is always demand for lower latency, the outlook is positive for this initiative. The same might be true for the FPL Inter-Party Latency Working Group. Although there are hardware solutions to this problem and these hardware solutions may create less additional latency, it seems to be much easier for any mid-sized firm to use FIX-based latency analysis rather than buying an expensive system just for this purpose.

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.

FIX has grown rapidly from the historic base of cash equity product, and pre-trade and trade business process support, to a point where it now supports a broad range of product types; Fixed Income, Foreign Exchange, Equities and Derivatives. This organic growth has been driven by the business benefits of FIX, and a dynamic user and vendor community. JP Morgan’s Andrew Parry explores the technical aspects that will take FIX to the next level, in particular in relation to global derivatives.

The success of FIX, to date, is supported by a simple premise. It is useful, provides valued business outcomes, and has an active user, vendor, and consultancy community, rather than trying to be the most beautiful possible technical solution.

To expand FIX further we need to continue the lines of work opened up in FIX 5.0 so that we can continue to provide valued business outcomes with what is, by now, a far larger model in terms of data and function support than when FIX began.

These lines of work such as correctness, machine readable business rules and process rules – discussed below – should improve the core of the FIX model, and increase the ease of use, both for software tool makers, and our end users.

Companies such as Google and Apple provide a good example of this approach. The end user of Google maps does not have to understand the technology behind it, whereas application developers are provided with a Google Maps API. We should approach the FIX model in the same spirit.

An analysis: Service Packs
FIX 5.0 onwards supports a service pack model, which supports the addition of minor changes within a matter of months'. This approach has particular value for the derivatives industry, which has a high rate of business driven change, and increasing regulatory requirements.

By adopting the service pack model, we promote standardised additions, instead of customised user extensions, which are commonly required in the absence of a timely way to make contributions. We will go on to look at how the service pack model has been used to a wide range of features to support derivatives in FIX 5.0 onwards.

Building Blocks
The service pack approach has been used to provide business correct building blocks, which can be re used. Taking an example from FIX 5.0-SP2( Service Pack 2), which has provided timely support for the business requirements and regulator demands of credit derivative contract specification standardisation and central clearing in America and Europe.

EP83 – Enhancements for Credit Default Swaps Clearing.  “The following new fields were added to the Instrument Block …  AttachmentPoint (1457), DetachmentPoint ( 1458 )”.

These fields are in support of CDS index tranches, which give investors the opportunity to take on exposures to specific segments of the CDS index default loss distribution. For example the “0% to 3% tranche” with attachment (0% ) and detachment (3%) is the lowest tranche, known as the equity tranche, and absorbs the first 3% of the losses on the index due to defaults.


Correctness
The percentage data type used for AttachmentPoint and ExhaustionPoint should only allow values between 0% and 100% (inclusive) to be business correct. The attachment and exhaustion points are always between 0% and 100% of the notional amount. This is data type correctness.

Where a tranche is being modelled, both AttachmentPoint and ExhaustionPoint should be used, otherwise the tranche is unbounded. This is model structure correctness.

AttachmentPoint should always be less than ExhaustionPoint, otherwise the Tranche would have zero or negative width. This is business rule correctness.

Where we have standardised tranches, such as “0% to 3%” we should have a way of tying back to a reference data source to confirm that this is indeed one of the standard tranches. This is reference data correctness.