Tuesday, June 19, 2007

Testing your FIX parser

If you want to know something about testing, you should read my friend Mark’s blog. He has forgotten more about all aspects of testing, than most people will ever learn. In my previous blog I mentioned, that my group at Saxo Bank has build a test framework that allows us perform various test of our B2B server. This post will try to elaborate a little more on this test framework, but please keep in mind that this is not a post on general test guidelines. I will, as I’ve done in the past, kindly refer you to Mark for this.

First some background to define the setting. We build our B2B server early last year. The initial offering was FX trading on streaming quotes, RFQ and orders. The testing was done by modifying an existing STP service, which we use towards our own external liquidity providers. This was easily done and enabled us to do all the required tests (unit tests, integration tests, load tests and so on).

Since then a number of changes have been made, but mainly in the configuration of client setup, so the “old” test client did the trick quite nicely. 2 weeks ago we released a major new version of the B2B server. It now also supports CFD DMA, as well as equities and futures. As this is all something we do not market make ourselves, we had to ensure that orders placed through this new channel were routed to our existing brokers. A new interface was defined between the B2B server and the main trading system (if you are interesting in the general architecture of our main trading system, drop me a mail and I’ll reply directly; it is somewhat out-of-scope for this blog) and the B2B server was of course extended to now also “speak” exchange traded products.

On the FIX level we did not have to do that much. As previously described we have our own FIX library which already supported all the requirements we had. However, the B2B server still had to be extended to accept the Order – Single messages (and the Amends and Cancels), and more importantly send the correct Execution Reports back, containing all the correct information and tags.

Also, we had to extend the automated test system we have created. We call it the SAFT (Saxo Bank Automated FIX Testing) system. It allows our clients to test 24/7 (well 5.5 since we are closed from Friday evening to Sunday evening). Depending of what you send the system, you will get a pre-defined response back. This way you can test when you want to, during your own hours if you are located in another time zone, without being dependent on support from us.

For example, should you place an order in an instrument beginning with the letter “A”, e.g. Apple, which has the symbol AAPL, it will generate the following sequence.

Client (C) Saxo Bank (S)
C New Order
S Execution Report (39=New, 150=New)
S Execution Report (39=Filled, 150=Trade)

You will get the same sequence placing an order in AAL (), but should you select the symbol CBRY (Cadbury Schweppes) the flow is the following

Client (C) Saxo Bank (S)
(C) New Order
(S) Execution Report (39=New, 150=New)
(C) Amend Request
(S) Execution Report (39=Replaced, 150=Replace)
(S) Execution Report (39=Filled, 150=Trade)

This is where the test framework came in handy. It allowed us to test our own code/messages as well as the SAFT system. Have you seen the (bad) movie Swordfish with Hugh Jackman, John Travolta and Halle Berry. There is a scene where Stanley Jobson (played by Mr. Jackman) moves some blocks around to hack into a computer system. We are still working on the user interface, but this is actually how the test framework works. You can define you “test” by assembling a number of “blocks” to define the message flow, e.g. Place, New, PartFill, Fill. Or Place, New, Amend, PartFill, Replaced, Filled. Or …

As we know before hand what the correct message looks like, we can ensure that when we add new functionality, a message is not suddenly missing a tag or the value of a specific tag is suddenly not correct any longer.

We take the message generated by the system and compare it to the “answer”. Of course tags containing values like date and time, sequence numbers or message length will vary, but the important part is as such static

As mentioned in my last blog we used QuickFIX to build the test framework instead of our own FIX library. This was partly done to get some knowledge of QuickFIX as a number of clients are using it, but also to test if it could replace our own down the line.

Tuesday, June 12, 2007

Screen Events in Stockholm

I did a presentation on FIX.5.0 in Stockholm last month (May 16th).

The presentation has been put on the web for those interested.

The focus was on the following topic areas:

The FIX Protocol: Essential for Maximising Electronic Trading Opportunities
  • The benefits of electronic trading and the use of a standards
  • The application of electronic trading and the FIX Protocol across the Equities, Fixed Income, Derivative and Foreign Exchange asset classes
  • The FIX Protocol, providing messaging support within additional stages of the trade-lifecycle to streamline business practices
  • FIX as a Solution for MiFID
  • FIX 5.0, advanced functionality for an ever advancing industry

Friday, June 08, 2007


In Saxo Bank we have developed our own FIX library, instead of using the commercial offerings or the open source libraries available. From a historical perspective it was mainly due to two separate reasons: the commercial products very vastly expensive and there really was no open source libraries at the time we entered the FIX world 6 or 7 years ago, at least not of a production quality.

There are many advantages to having build your own FIX library to handle the message parsing and the session layer, the main one being flexibility. Apart from our B2B server, which is – needless to say – using the FIX protocol, we are most often the client side in the client-server relation ship and must as much adhere to whatever “interpretation” of the protocol the server side has seemed fit to implement. In a separate post I will try to elaborate on some of the more horrifying examples of protocol violations, but we have pretty much seen it all: custom tags, extra tags, added repeated sections and stuff best clarified as message re-interpretation or re-definition. We have been able to handle it all and more importantly from a business perspective in a swift and efficient manner.

With the release of FAST, FIX version 5.0 and the fact that we internally in the bank are moving away from C++ towards C#, we have considered using QuickFIX instead. Not so much because we are tired of our own library, but resources are scares, and we would rather spend our time on areas where we can really add value to the business and not just fool around with the protocol (however satisfying that may be). By moving to QuickFIX we may get some “for free” – I know, I know, there is no such thing as a free lunch. If some other party extended the QuickFIX library to support FIX.5.0 we would not have to do it. It is as simple as that.

The switch is, for obvious reasons, not going to happen just like that and not without an extensive test period to ensure that the flexibility and scalability is in order. We have just added support for CFDs to our B2B server. Several of our clients are using QuickFIX, so to get some experience with it we have developed a new test framework using QuickFIX and not our own FIX library. The test framework is build in such a way that we can unit and regression test the B2B Server, ensuring all is working as expected when new features are added (again a separate post on this).

Our initial findings suggest that it is a major step in the right direction, compared to inventing the wheel (again) yourself. Nothing is perfect, and some unfortunate design decisions have made stuff more cumbersome, and require you to code around. My good colleague Sebastian Bargmann, who is our QuickFIX ninja has found the following:

On the positive side:
· A complete framework of all FIX versions from 4.0 to 4.4.
· Full source available in portable C++ (as portable as C++ can be that is)
· .NET and java wrappers.
· Most of the administrative messages are handled by QuickFIX (e.g. logon, logoff, heartbeat and so on).
· Automatic logging to file and database which is easily extendable to support any custom logging requirements.
· Automatic message storage (in QuickFIX’s own proprietary format).

On the negative side:
· It is a framework in the original meaning of the word. A very thin OO encapsulation of the protocol, but the abstraction is not “big” enough.
· The .NET code is an ultra thin wrapper around the framework. No delegates on top of the callback-events created by the C++ code.
· Everything is created as classes. There is really nothing wrong with this, but the simple types are still chars, int’s and so on. QuickFIX claims to be strongly types, but this claim is not really valid.
· The documentation is non-existing. You really need to read the C++ code (and show quite a lot of passion) to understand what is going on and how everything is connected.
· The configuration is done by an ini-file, which is difficult to use. Some of the stuff is even full of errors.
· The use of multiple sessions for e.g. FX trading – where you should have a trade session and a quote session – looks initially simple. It turns out, however, to be somewhat difficult because all messages have to pass through the same singleton instance of the connection handler. What this means is, that for each message coming in, you have to check what session is supposed to receive it.
· Special tags needs to be hard coded. If you for instance have a requirement that tag 50 is mandatory in the header, you need to add this to each and every message that is being send. This should really have been configutable.
· The supplied sample code is way to simple.

A nice framework that needs some tweaking, but once this is done, you will end up with something usable.

Tuesday, June 05, 2007

FPL Americas Exchanges and ECNs Briefing 2007

I'm going to be in The Big Apple from Sunday 17th until Thursday 21st.

Monday I will attend the FPL Americas Exchanges and ECNs Briefing 2007 conference (http://fixprotocol.org/documents/3327/FPL%20Exchanges%20ECNs%20web%20%20invitation.pdf) where I will moderate one session and take part in the panel of another.

If anyone is attending and would like to meet for a drink, let me know.

To Blog or Not To Blog

It has almost been a year since my last post.

Reason? Partly I have been busy with my new house, the family and the job. Partly I just "ran dry". The poetic stream dryed out.

Well, I'm back (I hope).

All the best