By Hanno Klein
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?
Semantics 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.
User Resources for Better FIX Semantics
The main source of information continues to be the official FIX specification, which is a set of documentation consisting of seven volumes. Volumes 3, 4, and 5 cover the pre-trade, trade and post-trade areas. Volume 7 is called FIX Usage Notes and focusses on FIX semantics for specific asset classes, such as FX, and specific usage environments, such as exchanges.
A fairly new source of information is the FIXwiki available at www.fixprotocol.org/fixwiki, which was donated to FPL by John Cameron of Cameron Edge. FIXwiki is an annotated version of FIXimate, where FPL members are able to add usage information to any message, field or valid value. Anyone has reading access to the FIXwiki and can see the annotations provided by FPL members. An interactive source of information for all registered users of the FIX website is the FIX discussion forum at fixprotocol.org/discuss.
Finally, there are a number of best practice guidelines (e.g. order book management, continuous quoting) that have been published by FPL Working Groups or Committees. These are available from the FPL Program Office by emailing fpl@fixprotocol.org.
Improving FIX Semantics
The situation would dramatically improve with a migration of the FIX community to the latest generation of the protocol, FIX 5, which was introduced in December 2006, now almost 5 years ago. Semantically, FIX versions 5.0 and above (FIX 5.0 Service Pack (SP)1, SP2) have remained very stable compared to the FIX 4.x versions.
There is a need to further remove semantic ambiguities in the protocol to provide greater clarification and aid implementations, which resulted from intentional changes in newer versions and unintentional overlaps with existing semantics when introducing extensions.The documentation around FIX semantics is still limited in some areas and FPL is keen to improve this, so it can meet the needs of the trading community as effectively as possible.
How can Execution Venues use FIX Semantics to Improve their Performance?
More and more execution venues want to provide their customers with a standardized interface using FIX. Performance suffers whenever a mapping is needed between different semantics, and often the core system of an execution venue has been built without FIX semantics as an integral part. This leaves the execution venue with a tough choice between performance and violation of FIX compliance. As usual, the answer is that compliance is sacrificed where performance is critical and would otherwise suffer.
It is very important to note that FIX semantics have been enhanced in recent years in order to support the highest levels of performance. Deutsche Börse and OMX invested significant effort over a few years to reduce the verbosity of FIX and this has led to a number of improvements in FIX 5. Performance is often not associated with semantics and only seen as being impacted by technical aspects such as the encoding of a message (ASCII vs. binary).
Examples of Improvements of FIX Semantics in FIX 5
Traditional FIX semantics require six messages for an IOC order that is partially filled 3 times: a NewOrderSingle to submit the order, an ExecutionReport to confirm receipt of the order, three ExecutionReports to convey the partial fills and a final ExecutionReport to convey the fact that the order was cancelled. This was a good approach in the early days of FIX when the notion of an algo trader did not exist. FIX 5 has the option to reduce the number of messages to two in a high speed environment: a NewOrderSingle to submit the order and a single ExecutionReport to convey the partial fills as well as the cancellation. Let me explain why this works.
The semantics of an Immediate or Cancel (IOC) order is well defined and will always end in the order being cancelled. The semantics of the FIX field CumQty is to convey the overall executed quantity. The FIX repeating group FillsGrp (added in FIX 5.0 SP1) lists prices and quantities of individual fills. This allows it to convey all information within a single ExecutionReport message, which dramatically increases performance for IOCs submitted via FIX.
FIX Semantics Evolving Role
Adherence to the same semantics within the same context, be it an asset class or a user environment, will be the key factor to reduce overall software development cost for the financial industry. Different terminologies are still one of the main speed bumps in communicating across organizations because such differences simply increase the learning curve for new hires, as well as the effort to interact with multiple external counterparties.
FIX is well positioned to provide such common semantics for trading, clearing, as well as reference and market data distribution services. A recent FIX initiative to develop a new High Performance Protocol will analyse and further improve FIX semantics by addressing the level of verbosity in responses. A full echo of input values is valuable in some cases, whereas a short acknowledgement of receipt is all you need in other cases. The flexibility of FIX to support different approaches may seem to be a contradiction with the notion of a standard as a single approach, however, standardisation needs to be seen in context.
It is not necessary that everybody across the globe drives on the same side of the road, but it is probably a good thing that each country defines a single side as the right one (or was it left?).
