Monday, 12 July 2010

Who in the world uses FIX ?

July 2010. I decided to get a snapshot of 3 months (90 days) of data from Google Analytics. I filtered out the occasional visitors and took into account only those who had executed at least one FIX message in either FIX Analyzer or FIX Log Analyzer.

In that period, the 'analyze' buttons on FIX Analyzer and FIX Log Analyzer had been pressed 23,129 times from 6,815 unique visitors in 75 countries.

Yes, I thought I have enough data to give a satisfactory answer about where FIX is getting used today.

Of course, I am assuming that apps which are using FIX to receive/send/execute messages are constantly debugged, diagnosed, studied and that many people turn to the web (specifically our ValidFIX site) to do more of this work...

Anyway, here is the chart and table I produced.

United States214631.49%
United Kingdom120717.71%
Hong Kong1992.92%

With Others* including the following 54 countries: 
  • Andorra
  • Austria
  • Belarus
  • Bolivia
  • Bulgaria
  • Chile
  • China
  • Colombia
  • Croatia
  • Czech Republic
  • Denmark
  • Ecuador
  • Egypt
  • Finland
  • Georgia
  • Greece
  • Hungary
  • Iceland
  • Indonesia
  • Ireland
  • Isle of Man
  • Jersey
  • Jordan
  • Kenya
  • Kuwait
  • Lebanon
  • Macedonia [FYROM]
  • Malaysia
  • Malta
  • Mexico
  • Morocco
  • Netherlands
  • New Zealand
  • Niger
  • Norway
  • Pakistan
  • Poland
  • Portugal
  • Romania
  • Saudi Arabia
  • Serbia
  • Slovakia
  • Slovenia
  • South Africa
  • South Korea
  • Spain
  • Sri Lanka
  • Taiwan
  • Thailand
  • Tunisia
  • Turkey
  • United Arab Emirates
  • Uruguay
  • Vietnam
Hope this helps.

Tuesday, 25 May 2010

Why ValidFIX likes Google (a tale of a pleasant, unexpected discovery.)

There was an interesting post on the official google web master blog in april: Using site speed in web search ranking

In short: speed matters, faster websites get a better ranking in google.

I read the post with interest and then moved on.


In developing our site we did not spend much effort in SEO – we just followed google standard rules – but we did obsess with performance.

People who work with FIX Messages deserve better tools to analyze their FIX messages and since we were going to deliver them through the web we did not want to sacrifice any aspect related to their usability.

To an extent, our obsession dictated our minimal GUI interface and made us work hard to follow strictly yahoo performance rules.

And then the pleasant discovery.

A week or two after google’s post we started seeing our ranking moving up. If a person was googling for ‘fix analyzer ‘ or ‘fix log analyzer’ we were coming as first or second result.

Beating onixs and firstfuturessoftware.

This was great news for us as more people were (and are) likely to find us but it made me wonder what was happening since I could not see new links from reputable websites (such as quickfixengine) linking to us.

Was the google engine just taking its time to update the ranking ?

Maybe, but I believe it’s more likely that we have been rewarded for designing and delivering a fast website.

Thanks for reading this.

Monday, 19 April 2010

Advanced Functionalities For FIX Log Analyzer.

In the past days we have added some beta functionality to the FIX Log Analyzer.

For the average user nothing has changed. The GUI remains the same, but under the carpet...

You can now add parameters to the FIX Log Analyzer URL.  Valid parameters are fixOnly, match and skip. match and skip are mutually exclusive and must not be used together.

fixOnly - ensures that only the FIX messages in the log are printed.
match and skip - specify one or more tag=value pairs so to include/exclude FIX messages

Here are some examples:
- Prints only fix messages and nothing else from the log.
- Explodes only ExecutionReport fix messages (35=8),35=A
- Explodes any fix message but heartbeats and logon messages.,35=A&fixOnly
- Prints only fix messages exploding any but heartbeats and logon messages.

Other common usages are filtering out by sender or receiver component 49=...  56= ... or by specific values on a specific message. e.g ?match=35=8,1=RNZ  would match executionReports of a specific account.

For the time being, we have decided against enriching the FIX Log Analyzer page to allow users to fill fields and click radio buttons so to generate the above urls or similar ones.

We like the simplicity of our pages and we don't want to put off any new user with the advanced functionality. So, for now, if you want to use these features you will have to handcraft the url.

There is also another reason. We are not sure if there are other features you would want us to add, so before going much further we would like to hear from our users.

Depending on your feedback, I would expect we can add a few more useful options, improve the existing ones and later on a little gui panel to configure the user's applications.

Thanks for reading this

Friday, 16 April 2010

Interesting sites for FIX protocol users.

Excluding the official FIX protocol site  what are good sites for people who work with the FIX protocol ?

Generally any FIX vendor's site since they tend to have short tutorials or general documentation about FIX.
In that sense one of my favourite is:  firstfuturessoftware's website.

One of their documents on fix messages helped us when we were developing our FIX Analyzer.

Few days ago, I stumbled upon a newly launched site: The site is an internet forum for people with an interest in FIX with potential to grow big.

Saturday, 3 April 2010

Comparing a few browsers

Building a high performance Rich Internet Application, such as FIX Log Analyzer, requires a constant attention to every detail of your design.
We have been following the list of the best practices for speeding up your website published by yahoo.

We have made sure that our apps run on every a-graded browsers and now we wonder: how do our apps perform on different browsers ?

We ran a simple test with 3000 execution reports (FIX Messages), copied and pasted from 1,084KB file, on a Windows XP 32 bit machine with 1 GB Ram on different browsers.

Below are the results:
  • 4 mins 20 secs I.E.8
  • 0 mins 40 secs. Chrome 4.1.249
  • 0 mins 48 secs. FireFox 3.5.9
  • 0 mins 56 secs. Opera 10.50
It looks like we should recommend any browser but IE for any serious user of our FIX Log Analyzer.

Thanks for reading this.

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.

Thursday, 25 February 2010

Use FIX Analyzer as an alternative to any FIX Dictionary

If you use FIX you are familiar with FIX dictionaries such as FiximateFIXopaedia and Onixs FIX dictionary.
They are useful tools but their navigation style is a pain to use - particularly, if you want several information at once. For instance, what are tags 200, 201, 202 for ?

Have you ever thought that you can use FIX Analyzer to find out this information rapidly.

Just type 8=FIX.4.4|200=1|201=1|202=1 and see the results:

(note: I assign each tag the value of 1 since all I care is to see the tag name resolved)

It gets better when you want to find all of the required fields in a certain type.
Then all you have to type is 35=(your type)

See some examples below:

(note: if you don't specify 8=version, FIX analyzer will default to FIX.4.4)

Hope you enjoy this.
Thanks for reading this.