So we’re still in the middle of the recruiting round I alluded to earlier. Joel on Software is one of my regular reads, and I’ve followed his recent posts on recruiting. One post presents an amusingly stereotyped caricature of the relationship between developers and traders, and bank attitudes to technology. Scroll down to the bit about “Use cool new technologies unnecessarily”: I think Joel must have read Liar’s Poker. Needless to say, it’s not really like that…

I’m still reading chapter 14 of Harris, on bid ask spreads. As always with Harris, it’s highly enlightening and thought provoking. I commented earlier on how the dynamic equilibrium between market and limit orders affects spreads, and how eSpeed charges for market orders in order to minimise spreads. Later in ch 14 he goes on to enumerate the factors that determine the equilibrium spread in order driven markets. In decreasing order of importance they are: information asymmetry between traders, time to cancel limit orders, volatility, limit order management costs, value of trader time, difference between limit and market order fees and trader risk aversion.

All this put me in mind of how bid ask spreads have collapsed in the fixed income rates markets in recent years; by 80% in the last five years, according to some estimates. A lot of that must have been driven by the greater transparency of electronic markets: buy side clients like pension funds can see live ticking prices for euro govies on Bloomberg and TradeWeb, and initiate competitive multi-dealer auctions.

Bloomberg and TradeWeb are quote driven rather than order driven markets, so Harris’ thoughts on equilibrium spreads don’t all apply, especially the ones on limit order cancellation and management costs. For the order driven markets, like Eurex Bonds, eSpeed and MTS, I wonder how much of the collapse in spreads is due to autoquoting engines driving down the cost of limit order management.

For those not familiar, autoquoting engines can translate a stream of bid and ask prices and sizes into buy and sell orders on order driven markets. When the bid and ask change, the engine pulls and places buy and sell orders as necessary. One autoquoting engine vendor used widely by fixed income dealers is ION.

Autoquoting engines are like nuclear weapons, once invented they can’t be uninvented. Dealers may yearn for the days of voice quoting, limited transparency and wide spreads. But there’s no going back. Autoquoting engines almost totally eliminate the time to cancel limit orders, and the costs of managing those orders – apart from any fees. If we accept Harris’ arguments, the use of autoquoting engines must bear down on the equilibrium spread.

eSpeed market orders

September 8, 2006

In his discussion of the interplay of market orders and limit orders, Harris goes on to point out that eSpeed charge a higher fee for market orders than limit orders. Which is interesting for me, since eSpeed is Cantor‘s fixed income ECN, and our desk uses our system to trade on it. They charge more for market orders to encourage limit orders, and thereby narrow spreads between best bid and ask. In theory, narrower spreads should make eSpeed appear a more attractive trading venue than the other fixed income ECNs.

In chapter 14, Harris has a marvellously clear explanation of the interplay between market and limit orders. To simplify massively, imagine an order book with a very sparse flow of market orders. Traders placing limit orders on that book will have to improve on the prices of the existing limit orders to become top of book, and match with one of the rare market orders. But in doing so, they’ll narrow the spread between best bid and ask. As the spread gets narrower, market orders will trade at better prices, causing market order flow to increase, and spreads to widen. As spreads widen, market order prices worsen, making limit order based strategies more attracive. And so the system is in dynamic equilibrium.

IronPython 1.0

September 7, 2006

I’ve been an enthusiastic Python advocate since 2000. Most recently I’ve been using it to code data cleansing scripts to filter output from a database before loading it into my R scripts. So it’s good to see the IronPython project come to fruition with its 1.0 release. Hopefully some of those corporate architecture departments that spend their time telling us front office coders why we can’t improve time to market with high productivity tools will take note. Either that, or they should try typing “Python Hedge Fund” into www.jobserve.com to figure out why banks are losing their best developers to hedge funds.

Do you fancy trying your hand in a London front office role, working closely with bond, swaps, futures and options traders ?  If so email me at the address on my About page. And when I say “young”, I mean young in spirit, rather than body…