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.
Better FIX-assisted auditing tools could transform the way regulators monitor the industry
10pm, 1994 The children are in bed. It’s been a busy day.
Time to kick back, glass of red in hand, and relax.
The phone rings. “We need you back in the office.”
“We’ll tell you when you get here”
“Can’t it wait until tomorrow?”
I enter the office. It’s full of faceless men in dark suits. I know none of them. Despite being dragged in, in the middle of the night, nobody wants to tell me why.
The ‘suits’ it seems are from the regulator. It appears that one of our traders made a lot of money that day, and it's attracted their attention. It was never made clear exactly what they suspected – some kind of insider trading, maybe front running a client - but they weren’t happy, and they were looking for evidence.
That’s why they needed me. Over the previous year, I had written a system which handled the whole trading cycle, from capturing a customer order taken by the sales person, passing it on to a trader, assisting the trader to work orders into the market, then allocating and booking the trades and confirming the completed orders back to the customer by fax, telex or whatever. It was called Trafic (French spelling).
Trafic had been a great success and, at the time of the incident, all orders and trades passed through the system. Every operation by a sales person or trader, and every trade coming back from the market (an early fully electronic exchange) was recorded and time-stamped.
In addition, all phone calls to the sales and trading desks were recorded and time-stamped on magnetic tape. The person responsible for managing the tapes had also been called in. Between the two of us we could reconstruct the exact sequence of events during the day down to the nearest millisecond.
This is what interested the regulators. Theoretically, our records could provide damning evidence against the trader.
Over the past 25 years, computers and automation have increasingly made it possible to provide such a detailed audit trail. The problem was that the transactiondata was encoded and stored in a format that I had chosen. There was no standard, so I made up my own. I had yet to write a convenient audit program that could display and analyze the data. As a result, the regulators had no choice but to call me in to extract and interpret the data they wanted to examine.
I hadn’t heard about FIX back then in 1994. If I had, the story might have been very different.
Establishing a common language FIX is a communications protocol. In other words it defines how messages can be reliably exchanged between two communicating parties, making sure that messages arrive intact, in the correct order and without any being lost.
However, FIX is also a data standard. It defines the detailed content of the messages being sent. Each type of data in FIX is associated with a unique number – the “tag number”. For example, the quantity of an order is defined to be tag number 38. As such, a FIX message is simply a list of tag numbers and their corresponding values. FIX also defines the allowable values for different kinds of data. It specifies that an order to buy is represented by the value “1” in the special data field with tag number 54. An order to sell, stores the value “2” in this field.
This may all seem trivial – and a little arbitrary. Why not, for arguments sake, use “B” for buy or “S” for sell. (Trafic was built for the French market, so it used “A” for buy – acheter – and “V” for sell – vendre.) However, what is most important about FIX is not the way it choses to represent data (tag=value) or the precise values chosen that the data can take. What is most important is that FIX establishes a common standard for financial data.
This standard is now everywhere. Pretty much all financial software, anywhere in the world, understands FIX. Had I known about it back in 1994, it is likely that I would have stored all transaction data according to the FIX data standard. It would have been something that the regulators would have been able to decifer themselves – and I would have got a better nights sleep.
FIX as an integrator FIX was originally designed as a standard way that a broker’s clients could send their orders and receive back their trades electronically. Today, brokers also commonly use FIX to communicate with electronic markets, such as stock exchanges.
As the FIX Protocol itself evolves to meet the demands of its global, and increasingly diverse constituency of users, industry leader, John Cameron of Cameron Edge, looks at the democratic roots of FIX and how FPL is carrying that tradition forward through the use of online ‘wiki’ technology.
“Government of the people, by the people, for the people” – Abraham Lincoln. He could have been talking about FIX.
FIX was, and is, designed and managed by the people who use FIX in their everyday business. It is a solution to real life problems and its continuing close connection to the people and organizations that it serves is, and always has been, its greatest strength. The challenge is how best to manage that vital grassroots connection.
The traditional management structure that drives the development of the FIX Protocol has been very successful. As advised on the FPL website, the protocol’s management is led by “Technical and business professionals from FPL member firms”, these representatives “coordinate their activities and organize their work through a series of committees, subcommittees, and working groups, all overseen by a Global Steering Committee that aims to ensure consistency of protocol application as it is extended into new markets, asset classes, and phases of the trade lifecycle.”
In addition to this structure, it was recognized early on that technology had an important role to play in keeping FIX in close touch with the industry. The FPL website introduced public discussion forums back in the mid-90’s, where members of the financial community can post questions and comments regarding FIX, which are responded to by other members of the community. These forums, www.fixprotocol.org/discuss, along with their search capabilities, form a wealth of invaluable information about the interpretation of the FIX specification. They are a natural complement to the FIX specification documents.
For example, if someone is unsure of some aspect of the protocol, maybe the exact meaning and intended use of a particular FIX field value, they normally start by consulting the FIX specification. If the specification is not clear, they can search postings in the forums using appropriate keywords. If still unsure, they can post a question to a forum, which will normally be answered by other members of the community. Once answered, that query and its answer are a matter of public record on the forum, which may be useful to others in the future. This open, transparent, collaborative process has been essential to the success of FIX. It has meant that FIX has remained in close contact with the industry it serves and has enabled it to react quickly to changing industry demands.
In more recent years, we have seen this public collaborative process popularized and validated in a number of areas: notably the open source movement and, perhaps most strikingly, Wikipedia (www.wikipedia.org). Wikipedia is particularly interesting because it popularized the “wiki” – a technology specifically developed to support exactly the kind of collaborative process that has been at the core of FIX since its beginnings. The traditional FIX collaborative culture and wiki technology are a marriage made in heaven. Enter FIXwiki.
Located at www.fixprotocol.org/fixwiki, FIXwiki is a FIX-specific wiki website that provides a comprehensive and authoritative view of the FIX specification. There is a FIXwiki page for each FIX message, component, field, value or type. In addition to definitions taken from the specification, each page also has an area for user comments, clarifications, corrections, examples or suggestions. It enables representatives from FPL Member firms to actively contribute additional information, provide comments, and share knowledge and insight to support the future development of the FIX Protocol messaging standard and is viewable by the broader FIX user community, providing a valuable reference tool for all market participants.
FIXwiki is not intended to replace the existing FIX forums. The forums are ideal for discussions and it is likely that FIXwiki postings will contain many references to those discussions. A wiki, however, provides a better repository for capturing the clarifications, interpretations and examples of the FIX Protocol that come out of such discussions.
FIXwiki is generated automatically from the official FIX repository, which is the computer readable database underlying the FIX specification. Therefore, FIXwiki and the FIX specification can never drift apart – they are derived from the same underlying data. In fact, it is even possible that FIXwiki could eventually become the specification. Currently, the FIX specification is in the form of a series of Microsoft Word or PDF documents. However, the full text of those documents could be ported to FIXwiki.