Counteracting High Speed Traders

On the Planet Money show, there's been discussion about the practice of High Speed Trading. This is where traders use computers and high-speed connections to the stock market to analyze trade data and put in trades making penny or sub-penny profits on transaction trends by responding faster than other players.

So, for example, if someone is trying to make a buy of stocks, and they can't get them in one lot, their first partial buy might trigger an algorithm in a computer. Then the computer might use it's high speed trading connection to buy up available lots of the stock that it anticipates will soon go up by a small tick, reselling to a slower moving buyer trying to close out the complete order with a slower connection.

Institutional investors, such as those managing your pension mutual funds, are understandably wary of the practice because they're frequently the ones whose transactions become marginally more expensive due to high-speed trading algorithms. So how might they neutralize the effects of high-speed traders?

I see an opening where a larger traders could help to neutralize or even marginally improve transaction costs due high-speed traders via counter trades. In aircraft control theory, there is a phenomenon called pilot induced oscillation (PIO). This is where a pilot tries to damp out an oscillation, but because they're responding with the right response, but out of phase, the situation ends up inducing larger oscillations in the path of the aircraft. Usually, aircraft designers (and pilots) are looking to avoid PIO, but a counter trade would be trying for the opposite by inducing high speed trading responses.

The basic idea would be to issue a number of counter trades to trigger the high speed trading algorithms, then use the window of movement in price that the high-speed algorithm creates to run your intended overall transaction. For example, if you were selling, make a few buys first. Let the high speed algos try to drive the price up by buying up all the shares at that local price level, then you would issue your sale at a higher transaction price. If the high speed trading algorithms stay agressive, then you can continue to open windows for your intended transactions. Alternately if the high-speed algorithms are dialed down to become less aggressive then your marginal losses from the actions are drastically reduced. Either way, counter trading would be one way to bound the high-speed trading algorithms.

Update: in the same vein, here's an article in the Atlantic about how odd trading patterns have been identified in trading data, presumeably from high frequency trading bots.

Phase Change Capsules in Drywall

What a great idea. Daytime heat is absorbed into little capsules of a material that changes phase. The material is mixed into drywall plaster. Rooms stay cool. At night the heat is released. Great primary function, but the material is made from a process that coats Paraffin wax. I have to wonder how that does for fire resistance.

iPad and Interface Single Tasking

Geeks of the world went through a collective wave of anticipation and lament yesterday at the unveling of the Apple iPad. If there was a single most missed feature, it was probably the lack of multitasking. I'm going to say something contrarian here. The iPad doesn't need multitasking now, and possibly not ever.

With the iPad, Apple is taking a step down the path where separation between interface and application (or Model from the View and Controller if you prefer) is not just a convenient software architecture boundary, but is an actual physical interface boundary. As much as you might wish it, humans are, at best, serial-taskers when it comes to interfacing to a computer system. Notice I said system. The next logical step after the iPad is to seamlessly connect it to other higher horsepower devices; devices on the net, or devices in a cloud. Personally, the link net devices are fairly mature over the browser, but I'd like to start maturing the link to my personal, home computing devices, the cloud can come later.

If the iPad is just an interface device with just enough computing power to ease local controls processing, you can then multitask to your hearts desire by giving server type devices tasks to go off and perform. Basically, as long as you can push images onto the iPad and control commands back to a server, and do lightweight processing for compromises between those two extremes, you can think of the iPad as a physical manifestation of a application gui window on your desktop computer.
The only thing you need is a multi-event notification system, which iPhone already has a least laid a foundation.

There are some short-term, established ways to pursue this link, the X window system is a prime example. For more recent examples, you could look at VNC/Remote Desktops type applications to extend your interface device. Ironically, the VNC/Remote desktop applications are less rich than the X system. And of course, browsers are increasingly delivering reasonably responsive application over web technologies. This should only get easier with the rise of HTML5. However, Apple has always dabbled in interesting interface and display technologies. I'm hoping that Apple has it's sights set on a longer term view of this path and is preparing some newly rethought method of linking server side power to an exportable iPad interface that may blow the doors off of all these paradigms.