Sunday, September 30, 2007

FPL Foreign Exchange Breakfast Briefing

Thursday October 18th, FPL is having a breakfast briefing on foreign exchange in London. I will be part of the panel. It is free, so show up if you have the time.

Program can be viewed here.

Thursday, August 09, 2007

Layout and Lables

I've changed the layout of the blog slightly, and added lables (or tags as they are know elsewhere) to most of the posts, a concept that Blogspot has finally adapted.

European Financial Information Summit 2007

I've been invited to speak on the European Financial Information Summit 2007 which will be held in London on the 16th October.

The conference will assess and evaluate the current developments of market and reference data management in the banking sector in Europe.

Subject for the speak will be: Is the Terminal dead? - Terminals vs. direct feeds.

Saturday, July 21, 2007

Inside Market Data

The interview/article below appeared in the last issue of Inside Market Data.


Saxo Bank Plans FAST Data for Q4

Danish investment bank Saxo Bank will develop a proprietary feed handler to capture data via the FAST (FIX Adapted for Streaming data) protocol before the end of this year, and will also decide whether to use FAST for outbound distribution of quote data from its trading platform to clients, officials say.
Saxo is developing the new FAST feed handler to support the upcoming launch of FAST-format feeds from Nordic exchange operator OMX and the Chicago Mercantile Exchange. "We have direct connections to both OMX and the CME, so ... it would be to consume data from these sources," says Karsten Strøbæk, lead developer with Saxo. With the CME set to roll out a FAST-enabled feed later this year, the bank is planning to deploy its handler in Q4, Strøbæk says.
By developing a FAST feed handler, Saxo will be able to draw in both exchanges' data via the same interface - though both exchanges will maintain other versions of their feeds. OMX will roll out its FAST feed later this year alongside a new consolidated feed being built by technology partner Cicada (IMD, April 30), and the CME will maintain its proprietary RLC feed until the end of 2008 (IMD, Feb. 19).
Saxo does not yet have any FAST software in production, but has begun an initial test to evaluate how the protocol would fit into its architecture. However, the bank plans to allocate more development resources to the project once CME and OMX are closer to launching their feeds, and expects to complete all development work on the handler in-house. "We built our own FIX library for the message parsing and handling messages," says Strøbæk, who also serves on the Market Data Optimization Group of the FIX protocol's governing body.
Saxo intends to redistribute the data from the exchanges' FAST feeds to internal applications using its own proprietary data distribution platform. "We've built our own push-based system. [The data] is pushed into a central publishing system, so [any] subsystem can then subscribe to it. Everything is [stored] in-memory," Strøbæk says.
Once the FAST feed handler goes live, Saxo will then examine the possibility of distributing its own market data from the bank's trading platforms for equities, foreign exchange, contracts for difference and futures, using the FAST protocol. "We've built our own B2B server that supports trading in several different asset classes ... [so] one possibility would be to use FAST to distribute quotes from the platform," says Strøbæk.

Jean-Paul Carbonnier

Sunday, July 01, 2007

Working from home

The following has nothing to do with FIX or trading for anything like that, at least not directly.

In one of the blogs I read, I came across some guidelines of what to do if you are so lucky that you can work from home. It is a good thing to work from home. You save the transportation, you can spend the morning with your kids and open the door for the plumber, should she decide to swing by.

So here is a list of ten things you want to avoid if you are in fact working from home:

1. Do not leave your cell phone at home if you leave the house to go shopping or eat lunch.
2. Pick up your phone – also if you are in the bathroom.
3. Arrange some short phone meetings with people at work. They hate your guts because you are working from home and this will show them your commitment to your work – also when you are working from home.
4. Avoid long and complex mail threads with your boss to early in the day as this may result in a call where you have to answer the question of where you are (even if you have been granted permission to work from home, then do not remind your boss of this).
5. Do not drink alcohol early in the day, just because you are home. This also includes beer for lunch.
6. Remember to send the long e-mail with lots of attached spreadsheets that your colleagues have been waiting several weeks for. This serves two purposes: 1) It demonstrates that you are in fact doing something and 2) You can be sure no one will react to what you have sent. It is far to complex and takes to much time to read so you get some peace and quiet.
7. Do not leave your Elvis Costello album playing on the stereo with the volume turned to full throttle when you talk on the phone to your colleagues.
8. Do not take the phone when you sleep. Let it wake you up. Splash then some cold water in your face. Then call back and say you were in the middle of something important. It may well be your colleagues are looking straight through you, but it was worth the try.
9. Try to reach your boss very late in the day, but be absolutely sure he has left the office. This is the kind of attitude a boss likes. You are so engaged in your work, that you did not consider your boss might have left for the day when you called.
10. Dress properly – do not work in your underwear. People will know. No one knows why, but people know if you are talking to them only wearing your undies or g-string.

Advice here-by forwarded …

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 ( 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