Big Brother is not watching you (yet)

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.