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.