Big Brother is not watching you (yet)

By John Cameron
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.”
“Why?”
“We’ll tell you when you get here”
“Can’t it wait until tomorrow?”
“No.”

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.

Related Articles

Latest Articles