This past Wednesday, I attended the Chicago Algorithmic Trading Conference, hosted by Options City. It was a half-day conference, consisting of 6 sessions and a networking hour at the end (with an open bar!)
The first two sessions focused on optimization; the first session was on optimizing Java code, led by Freddie Guime of Options City. I have a few Java projects in the wings, but I am not currently doing any code optimization, so Freddie’s talk gave me some good ideas. He showed 3 or 4 different optimization schemes for processing large amounts of data (such as market tick information), and how the schemes compare. One scheme is to use a “divide and conquer” algorithm; another method used caching; another method used the idea of sending complex computations over to the GPU (graphics processing unit) instead of using the CPU.
The second session, led by Robert Engels, also of Options City, dealt with optimization in the Linux Operating system. I’m a big fan of Linux, and it was nice to see what kinds of opportunities are available for real-time processing in Linux.
Both of these first two sessions were interesting, but not in my current scope of work. Nonetheless, I was glad to get to know what are the current areas of focus in the algorithmic trading world.
The third session was a round-table discussion with developers of various capital management groups, hedge funds, and of course, Options City. The questions dealt with how financial programming might be different than other kinds of programming (financial programming is very concerned with latency); how to get solutions to market quickly (use time wisely, automate your tests, don’t overthink the idea; be comfortable with code maintenance); balancing latency and coding creativity (both are important); and the most important resource in a trading shop (good people make all the difference).
Session four was a video and showcase of the University of Chicago Trading Competition, held for university students earlier in the year. The professor in charge of the competition was Darrell Zechman; both the U of C team and a team from St. Louis were on stage to talk about how the competition was structured and what some of the challenges were. The successful approach was to get the finance majors and programmers to work together; one group specifying a solution in English, and the other group coding that idea into Java. The platform that the competition was held on was Options City’s own Freeway platform. I’ll have a lot more to say about that in an upcoming post.
The most interesting session by far was the “Bringing Algos to Life” session, led by Andrew Lisy and Ben Sandman, both of Options City. They demonstrated how a trading idea can be written out in pseudo code, and then coded in Java and then uploaded to the Freeway platform in a matter of minutes. They spent quite a bit of time on the “buy versus build” decision that programmers must often make when designing new software. This session was exceptionally well run, and demonstrated both the capabilities of the Freeway platform and the coding methods in Java that are useful for creating trading systems for Freeway.
The “buy versus build” discussion was demonstrated when the programmers pointed out that while the program would need an order entry method, and a method for representing tick data as bars or candlesticks, it was better to purchase these two components from the Algo Store, rather than spend precious development time writing these from scratch. The development time was spent creating the trading algorithm, which was a simple divergence strategy based on price and On Balance Volume (OBV). (As an aside, the two components cost $250 and $300, for a total of $500, if you were to do this project yourself.)
I learned a lot about Freeway in this session too; Freeway is Options City’s platform for creating algorithmic trading systems,written in Java, and one that supports trading code written in Java. I was surprised to see that very few indicators were available in the platform without purchasing them, or writing them yourself. In the case of writing automated trading systems retail trading software, such as TradeStation, Trade Navigator, Metatrader and AmiBroker, you get all the common indicators you want for free — they’re built into the platform. In Freeway, you have to buy each one, or write them yourself. Maybe that’s because coders working for hedge funds don’t use indicators in their trading systems, or maybe it’s because they want to have their own code running in pure Java, so that they can optimize it. I’m not sure, but that was something I hadn’t expected.
The last session was a CTO round-table, which discussed what CTOs look for in an applicant, buy versus build, programming languages, the cloud and other semi-relevant topics.
I would highly recommend this conference for anyone involved in automated trading systems development. I learned a lot of what was available in the market, what programmers of these types of firms were concerned with, and the teamwork that goes on between the programming staff and the trading staff at trading firms. This was their second year running the conference, and as such, it was small. But all conferences start small, and I am looking forward to next year, with more sessions, maybe separate tracks, and more good information.