Trade on MICEX via FIX

On Wednesday MICEX officially announced that public testing of the MFIX Transactional - FIX interface for trading - starts on July 24th.

This is the second solution (the first was for market data) implemented by EPAM Systems and capital market division in particular for MICEX.

MFIX Transactional is the result of Kyiv and Saratov teams cooperation. Professionalism, responsibility, focus and real customer involvement were key factors to overcome all pitfalls and deliver.

Well done guys and keep going!

PS For those of you who can read Russian try links below (under cut).

FIX logs analyzer. Part I.

x

FIX Log Analyzers (FIX Grep and FIX Eye) are the small tools, which were started for internal use only, developed with the lapse of time and finally grew up to the powerful (but still lightweight) product suit.

BTW Today there is a free demo version of FIX Eye available for download from official B2BITS web site.


History
Originally the main purpose of the utility was making testers' life easier. Namely:

• Help FIX  newbies read and understand FIX logs
• Save time for searching orders and related messages in logs to analyse order life-cycle

Additional requirements were:

• Deal with any free-form text file (often there is a need to extract messages from log files with a lot of debug info)
• Deal with multiple files (in most cases in and out messages are stored in multiple files, also data for different sessions can be in different files)
• Deal with archives (log files grow fast so there is a need to take into account housekeeping procedures normally performed at the end of the day)

FIX Protocol Dictionary

In this post I will explore the phenomena of the online FIX dictionaries, why they appeared and gained popularity. Then I will explain the consideration we have been guided by when designing our own Fixopaedia.







FIX protocol organization releases specification in several formats, none of which in fact is formal (actually they also have recently adopted an online dictionary developed by the 3rd party):

• Word documents for FIX
• PDF for FIX
• Schema for FIXML

What exactly are people looking for when going to online dictionaries? I would single out several types of requests:

1. What do specific FIX field and its values mean?
2. What fields are defined for specific message type?
3. What other messages are relevant to specific message type?

Basically this means that a perfectly organized specification enables the user to easily find the answer to his questions without even having the specification stored somewhere on his computer. Word and PDF documents are definitely not the best format for such people.

So let's analyze what should user do to find answers to the questions above.

Case 1.

User searches for the word "OrdType" and finds full definition of the corresponding field e.g. the way it is done here: http://btobits.com/fixopaedia/fixdic44/tag_40_OrdType_.html

Case 2.

User searches for the words "New Order Single" and finds full definition of the message e.g. the way it is done here: http://btobits.com/fixopaedia/fixdic44/message_New_Order_Single_D_.html

Case 3.

User wants to browse all messages related to the order so he searches for the word "Order" and finds the list of messages e.g. the way it is done here: http://btobits.com/fixopaedia/fixdic44/index.html?message_New_Order_Single_D.html

Obviously there are users that prefer to navigate rather than search, so this functionality must also be available.

Does all the above mentioned mean that Word and PDF formats of specification are not useful at all? Of course not. Those formats are perfectly suitable when you study FIX from the beginning or when the new version of the protocol is released.

Designing FIXopaedia

So what are the key concepts we followed while designing FIXopaedia?

1. Access to the information. User should be able to find information with minimal effort.
2. Effective layout. Present as much information as possible on the same screen i.e do not waste screen space.
3. Navigation. User should benefit from hypertext as much as possible easily navigate between relevant fields and messages. At the same time data must be structured so the user is able to navigate from highest to the lowest level.
4. Compactness. User must be able to get all required information in one place without extra navigation e.g. message name and type, field name and type (including possible values), required attribute, short description and corresponding FIXML tag - everything must be shown on the same page.
5. Completeness. Maximum information available in standard must be present in the online FIX dictionary.
6. Speed and lightness. Do not overload page with heavyweight pictures, scripts or server side processing. The display time must be unnoticeable as well as search time.
7. Searching facility.
8. Non-aggressive pretty looking color schema.

So this was an intent, which resulted in FIXopaedia. Do you think we reached the goal? Do you think we missed some must-have or nice-to-have features? Feel free to comment.