Wednesday, 24 March 2010

A few thoughts on the FIX Protocol conference in London - march 2010

Yesterday, I was at the FIX protocol conference:
There must have been about 500 people there.
I come back with mixed feelings about the conference. I certainly attended a few interesting sessions but I also got stuck in some so-and-so presentations. I might write a few other posts about the conference but first I will indulge in saying what I did not like.

The session: The design aspects of the fix protocol – by H. Klein and M. Simpson

1] the session slides were going through in a very unexciting way about a few designated message types such as ExecutionReport, MassQuote, etc.  Even worse, a whole slide was dedicated to the fact that some fix tags had been deprecated since 4.3 and therefore we should not use them.

C’mon guys, it’s march 2010 do we really need this ?

2] M. Simpson talked about some benefits of FIX.5.0.  one of these being App. Versioning.
If I understood this correctly it’s a feature that would allow you to get some messages in one version (say FIX.4.2) and some other messages in another version (say FIX.4.4)  Surely that’s okay for me. It means that tools like our FIX Log Analyzer will become even more useful.  But seriously guys can anybody think of a good justification for such a feature. How ugly (and I am using a euphemism here) would it have to be the code that will handle this part.

Thanks for reading this and if you were at the conference too please share your thoughts with us.


Thursday, 18 March 2010

FIX Message and the SOH delimeter.

FIX Messages look like this: 8=FIX.4.4|9=122|35=8|49=A|56=B|...|10=14|
Tag-value pairings separated from each other by a delimeter character: the ASCII "SOH" 0x01 (see ).

Since the SOH is not an ASCII printable character it's not uncommon to see it replaced in documents and logs with other characters, such as | (pipe), # (hash), or short strings such as   < soh >
And here comes the interesting thing: if the log of your fix application prints the raw fix messages how is Fix Log Analyzer going to display that ?
The answer depends on the browser you are using.
Internet Explorer (both version 7 and version 8) shows a little rectangle.

Firefox shows a little square with 0001 inside. (nice)

Chrome does not show anything (not even an empty space)

Bottom line: Chrome's rendering of FIX messages is the least desirable for FIX web tools. I hope they will fix this soon in later versions.

Thanks for reading this.
M. Renz

Wednesday, 10 March 2010

8 Most Common Error Messages in ValidFIX.

here is a short list of some of the most common errors and warnings you might come across when inspecting
your FIX messages with either Fix Analyzer or Fix Log Analyzer.

1. Error: Not a valid message type.
This happens when the value for the tag 35 (msgType) does not exist.
35=8 is correct (execution report: all fix versions)
35=AA is correct (security status: but only for versions 4.3 and 4.4)
35=CA is correct (no matter the fix version)
35=XXX is wrong (in any fix version)

2. Error: Not a valid item in the enumeration.
This happens when a tag which expects only a specific set of possible values is given an invalid valid.
For example for tag 55 (side of order) only 1 and 2 are acceptable values.
55=1 (means buy)
55=2 (means sell)
55=A is wrong.
55=Buy is wrong

3. Error on BodyLength. Expected 9=?
4. Error on CheckSum. Expected 10=?
BodyLength is the byte count starting at tag 35 (included) all the way to tag 10 (excluded). The checksum is the defined as the sum of all the bytes in the message up to the check sum field modulo 256. Generally those errors happen only when FIX messages have been handcrafted (although In some cases - I am afraid - it might just be buggy fix engine)

5. Error: Missing Mandatory Field ???
Each message in FIX must have at least some required tags. Such as 8,9,35,49,56,34,52,10. Tag 35 in particular defines the message type and additional required tags.
For example if 35=8 (execution report) we would expect tag 14 (cumQty) tag 54 (side) to be present in the message.

6. Warning: Unexpected Tag ???
Tag 35 defines all the mandatory and optional tags that message might contain. It is a mistake - although not an uncommon practice - to send tags which are neither mandatory nor optional.
For instance if 35=0 (heart beat) we would not expect to see tag 44 (price)

7 Invalid countries
8 Invalid currencies.

Valid currencies are CAD,EUR,GBP,
They are defined by ISO 4217 Currency code (
Similarly the list of all valid countries is defined by ISO 3166 Country code(

... and now up to you.
Do you think there are some errors or warnings that our tools don't print ? let us know and we will try to include them.
Please remember that this list is not complete, so make sure you run a little test to prove we don't handle your case before telling us.

Sunday, 7 March 2010

FIX PROTOCOL - cheat sheets

I have done a quick experiment.
I have used the same engines that we use to parse the user's FIX messages in FIX Analyzer and FIX Log Analyzer to create some cheat sheets for the FIX protocol.
Do you need quick reference for all mandatory fields for every FIX message ? if so please check them out.
I have uploaded them at:

I will keep an eye on our logs to see if people access them. Feel free to add your comments to this blog particularly if you find them useful or if you want to ask for other cheatsheets.

As I said this is no more of an experiment, but who knows I might add a few more if people like them.

Thanks for reading this.

Monday, 1 March 2010

ValidFIX and Browser Support

I did not expect to write this on my third post. Until a few hours ago our FIX tools were only working on IE.
So, for instance, if you were a Firefox user you might have come to our site, thought you had found something interesting and then left unexcited.

Well, let's make it clear: this was unintentional. Our intention is to support all graded browsers. We have now fixed the problem and are now taking steps to make sure it won't happen again. We have to thank the persistance of a few people who come to our site did not see it working and told us.

On a positive note, since we are going to be more careful about how our web tools perform on different browser I am going to post soon a benchmark with some interesting results on the difference performance of each browser.  So stay tuned.

Thanks for reading this.