By John Cameron
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 transaction data 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.
However, FIX is not just used for external communications. Many organizations now use FIX for routing orders and trades between the different internal programs used for order processing. These days it is almost inconceivable that any commercial financial software would be successful without the ability to “talk” FIX. Equally, it is unlikely that custom software written in-house would be designed without a FIX capability.
This makes FIX the natural “glue” for integrating the numerous programs that typically run within any financial organization.
Even old “legacy” software that knows nothing of FIX will typically be integrated into an organization by writing a wrapper around it that translates its proprietary external communications into FIX.
So, increasingly, FIX tracks the whole life cycle of an order or trade within an organization, and even across multiple organizations.
FIX as an audit tool
In general, a message sent between program A and program B is not necessarily stored anywhere. If it is not stored, there is no historical record that the message was ever sent or received – i.e. there is no audit trail. However, FIX messaging is a little special.
FIX inevitably leaves a trail because of the protocol’s insistence that any message sent must be able to be re-sent at the request of the receiver.
For example, suppose that program A sends message number 100 to program B. Program B can, at some time later, ask program A to re-send message 100. This capability is present in the protocol in case message 100 is lost or corrupted during transmission. Furthermore, a sending program needs to be able to re-send earlier messages, even if it has crashed or has had to stop and restart for any other reason. This means that the program cannot keep a record of its sent messages in computer memory, because that memory will be lost if it restarts. Instead, it must store all sent messages in permanent storage – for example in a disk log file – which can be reloaded when recovering from a restart.
In addition, FIX requires that the sending time of each message is recorded in the message itself (in the required “SendingTime” field – tag number 52) – so all messages are conveniently timestamped.
As a result, any program that uses FIX will always have a time-stamped audit trail in the form of its FIX log files.
It should be noted, however, that the audit trail is only guaranteed for sent messages, although increasingly many FIX programs now also log received messages.
Standard language = standard auditing tools
A standard format for financial data means that standard tools can be written for processing that data. In particular, generalpurpose software tools can be written which can be used to audit any FIX program.
An open, widely used standard like FIX offers software entrepreneurs a global market in which to compete.
Large companies may also choose to write their own standard in-house auditing tools that can be applied across all the disparate systems within their organization.
Lastly, regulatory bodies can now write their own standard auditing ‘Big Brother’ tools to assist in detecting suspected irregularities in the operation of any financial organization, or even across multiple organizations.
FIX is watching you
Good FIX monitoring tools are already available – ie tools that watch FIX. But tools that specifically target auditing – using the ability of FIX to watch you – are less common. In fact I am not aware of any.
In the wake of recent events, it is clear that financial transactions need to be better regulated. Ironically Bernie Madoff was one of the early adopters of electronic trading, and FIX in particular. In fact, Madoff used my company’s FIX engine, despite his firm having a culture of writing everything inhouse. I expect that the authorities have been combing through any of his FIX logs that they have been able to locate. However, it is currently not a requirement to keep FIX logs and many companies delete them at the end of each trading day. The regulators could require that FIX logs be kept.
Big Brother certainly wasn’t there when we really needed him. Maybe he could use some better FIX tools in future.
For those of you curious as to the fate of the suspected trader back in 1994, for whom I was pulled from my restful slumber: apparently the regulators failed to find anything in Trafic’s records, so no action was taken. The outcome would have been the same even if the records had been in the form of FIX data but the authorities
might have reached their conclusion sooner, and probably would not have needed my assistance.
And the company? It no longer exists. It was swallowed up in a merger a year later and the whole country operation was closed down. My cherished Trafic, an early STP trading system, was lost forever.