Interview with Professor Andrew Kumiega, IIT

This week’s interview is with Dr Andrew Kumiega, Professor at the Illinois Institute of Technology, another speaker at the upcoming High Frequency Trading World events in London and New York.

Dr Kumiega has applied his Ph.D. in Industrial Engineering to research positions in both the manufacturing and the financial industry over the last 20 years. He has held multiple Director level positions in financial trading firms responsible for front office financial engineering. He currently works for a proprietary trading firm. Dr Kumiega is an Adjunct Facility member at both at Illinois Institute of Technology and University of Chicago. His industry research interests include: implied volatility models for equity derivatives, pricing models for convertible bonds, multi-factor stock selection models, credit analysis, and project management for finance. Andrew Kumiega is the co-author of Quality Money Management along with multiple journal articles. Andrew Kumiega holds a B.Sc. Engineering Management from the University of Illinois, Chicago, a M.Sc Industrial Engineering from the University of Illinois, Chicago, a Ph.D.in Industrial Engineering from the University of Illinois, Chicago and a M.Sc. Finance from Illinois Institute of Technology.

High Frequency Trading Review: Andrew, what’s your definition of high frequency trading?

Andrew Kumiega: That’s probably the hardest question to answer!

Some people believe that if you’re in the microsecond world, which a lot of the trading firms are, you’re a high frequency trader. Some people believe if you’re in the hundredth of a second world, you’re a high frequency trader. I’ve even been in conferences where people believe that sending an order to a dark pool and having it done in 20 minutes, they’re a high frequency trader!

But I think when most people talk about the idea of high frequency trading, they really mean algorithmic trading, where a machine goes out and executes orders per some predetermined algorithm. Does the machine control every step of the process or not? If the machine controls every step of the process, then I consider it to be a high frequency trade.

HFTR: Even if it stretches to 20 minutes or longer?

Andrew: Yes, because what’s happening is that algorithm may be bouncing orders all over the world, but it’s still being done without any human intervention.

People are getting hung up on speed but the real question is does the algorithm in the system handle this transaction automatically? If so then I consider you to be high frequency or algorithmic. Whereas if a person has to be involved in the process, then you are not.

HFTR: Fair enough. Now, you have a Masters in Finance and a PhD in Industrial Engineering. What are some of the parallels between industrial engineering and financial engineering, particularly around algo trading system development?

Andrew: Industrial engineering applies stochastic mathematics to problems in manufacturing and business in order to decrease variation in revenue and increase profit. To accomplish this, industrial engineers have developed a multiplicity of tools for optimization, time series, stochastic mathematics, simulation, and process control.

In the early days of financial engineering, many of the educational programs were based in the industrial engineering department. Today, many top notch programs are still there. So, to answer your question, rather than being a parallel body of knowledge, industrial engineering (IE) is the same body of knowledge as financial engineering (FE).

The most interesting point is that most of the tools from IE have been transferred to FE, with one glaring exception. The one set of tools that has not been transferred is Quality. Quality refers to a broad set of statistical tools designed to optimize algorithms that control stochastic processes. I believe these tools will be transferred to finance for the same reason every other automated process in the world uses these tools. Defect reduction and increased efficiency will be key components of competitive advantage in high-frequency trading. And, quality is free. It more than pays for itself.

HFTR: How important is the back-testing process in producing Quality systems? One of the topics you will be talking about at the upcoming “HFT World” events in London & NY, is the importance of back-testing to optimise performance. What are some of the key steps HFT firms should be taking when monitoring performance of their trading systems in order to fine-tune them?

Andrew: The key to building any machine is to follow a Quality design and development framework. A quality framework requires that you first determine specifications of the outputs of the machine. Second, you build a prototype of the most complex parts to ensure technical success. Then, you build a full working prototype to gather data and ensure the machine is capable of producing outputs according to the original specifications. Third, you build the machine. Fourth and finally, after the machine is built, you continuously monitor the machine to ensure it is meeting the original specifications. Performance monitoring should occur on all trading system outputs, not just the P&L.

The goal of the monitoring it to quickly discover any unexpected variation in the system and then determine its root cause so it can be removed in the next development cycle. Quality Money Management, which incidentally is the name of our book, is effectively the application of Kaizan (i.e. continuous improvement) to high-frequency finance. Quality Money Management can also be viewed as the application of IE to automation processes in finance.

What we’re proposing is the exact same techniques that are used to build every complex machine in the world, from things like pacemakers to jet aircraft. Think of how a plane is built. The algorithms for the plane are built using this exact method.

If you measure the output of the algorithm, then what you get in the back test should match what’s happening in the production system. If they don’t match, then you have to go through a Kaizan process to find the root cause of the variation and fix it.

HFTR: So what happens then when you get the ”Black Swan” type events, you know, the completely unexpected that can totally throw out the statistical collective results?

Andrew: I’ll be honest with you. Just like in the real world where you can’t prepare for a Black Swan, in the algorithmic world you can’t prepare for a true Black Swan either. That’s why it is called a Black Swan, right? But, a firm can put in place the procedures that will minimize the effects of the Black Swan. In IE it is called designed-to-fail-safe. The interesting point about your original question is that IE also contains Reliability Engineering and Safety Engineering.

By continuously monitoring the quality of a system you can calculate the current reliability distribution of the system. The current reliability distribution allows an engineer to schedule machine maintenance prior to a machine failure. The last interesting fact is that most critical injuries occur during machine failures. So, the real question is not how to predict a Black Swan, but how do we identify a shift in the quality of the system that indicates a high probability of a machine failure. The answer to this question is straightforward. Ben Van Vliet and I discussed the SPC technique in depth in a recent publication in the Journal of Trading.

We believe if a machine is becoming unreliable since it is making items outside the specification limits, it’s time to turn off the machine. Imagine, running a candy plant and turning up the production rate once the process starts making twice as much bad candy as normal. As the percentage of bad candy increases, the plant manager keeps increasing the rate and hiring more people to inspect the candy. Eventually, the machine that is making bad candy bursts into flames. The plant manager would then state it was a Black Swan that burnt the factory to ground. While it would be true that the machine that burst into flames caused the fire, most educated people would blame the Manager for the plant fire. Many plant managers have been fired over the years for ignoring a quality issue that led to a production line failure. Fund managers should have the same level of responsibility for quality issues as plant managers.

If you think about it from an IE view of the world, it’s straightforward. You want to be monitoring your trading outputs and any time that outputs change, you want to perform Kaizan on your process to determine why your process changed. This will reduce your failures in your trading system. It might even take you out of the market prior to a true Black Swan if the input data indicates a process shift. However, it will never insulate you from a 9-11 type of Black Swan.

HFTR:  That make sense. My final question is on the “build versus buy” argument. When considering whether to build or buy, what are the factors that HFT firms should be looking at?

Andrew: In general, I believe you should build the items that give you a competitive advantage. The problem with buy-versus-build is that without a system design document all of the costs are rough guesses. In our framework the actual building of the system does not take place until Stage 3. With good system specifications and a buttoned-down process, the decision should be straightforward, just like in robotics. A firm would never build a robot if they could buy it off the shelf for less. A firm never builds bearings for a robot if they can buy it off the shelf for less. A firm only buys what it cannot build efficiently.

The real problem – and this is why we wrote the book – is that people are making buy vs. build decisions prior to coming to stage 3.

So, what happens is they say, “Oh, we’re going to build everything.” Okay, well, they don’t even know what they’re building yet. So it’s not a question of buy vs. build, it’s do I build good, clean specifications prior to implementing the project or not?

Let’s take an example. I may need to build an option pricing model. On the other hand, maybe it’s best for me to buy it from Numerix. Numerix has a lot of these pricing models already built. So, maybe the first time through, I try using Numerix. Well, if I have Numerix C++ Objects and I make money on it, then I should just for the first iteration of the machine, buy Numerix and start earning income. And, on the second iteration, if in the Kaizan world, I’m continuously making things better, right? So on the second iteration of the machine, if I take the Numerix objects out and put my objects in and I make more money than the estimated costs of the coding then I should pull out the Numerix piece now and upgrade the machine.

The lack of cost analysis and variance reduction is the real issue in buy versus build. That’s why we built this framework, Ben Van Vliet and I, because firms need a business framework that is similar to the Kaizan framework used in other industries that manage highly automated processes.

HFTR: Great, thank you Andrew.