MTS & quote state engines

Finite state machines are a standard programming technique we use in our trading system for managing the state of quotes and RFQs. Let’s consider quote state management on MTS. MTS is particularly interesting since MTS treats market maker quotes as ‘proposals’, which are firm, tradeable quotes. This is quite different from purely quote driven markets like Bloomberg and TradeWeb, where the quotes we send are indicative, not tradeable. On those ECNs we only send a tradeable price to an individual client when they click on an indicative quote and initiate an RFQ.

Since for MTS, our quotes are firm, or tradeable, we developers must take great care over the quotes our system sends on the trader’s behalf. If we leave a stale quote out on the market, our traders will lose money. They get very unhappy when that happens. Exactly how and why quotes become stale would lead us into a discussion of the architecture and design of fixed income pricing engines, and the relationship between the prices of futures, benchmark bonds, bonds and swaps. We could also discuss MTS’s transactional quote model, and the associated queueing mechanisms. They’re both issues for another day, so let’s just take it as read that in a fast moving market, we have to recalc bond prices several times a second, and publish the resulting quotes to MTS.

Our system is an autoquoting system: it automates the quoting of bonds on a dozen ECNs. Naturally, our traders control our autoquoting system, just as a pilot controls an autopilot in an aircraft. The quote state engine ensures that the autoquoting system responds to trader operation of its controls in a safe and predictable manner. The controls at the trader’s disposal are the spread, the bid and offer sizes, and whether the quote should be on or off. Now let’s work though some example states and transitions for a quote for a bond…

• States 
  • Dead: we’re not quoting the bond
  • PendingPrice: trader has switched the quote on, but we haven’t had a fresh tick from our pricing engine yet
  • PendingMarketOn: the quote is on, we have a fresh mid price and have applied a spread and sent the resulting bid and offer prices and sizes to MTS, thereby opening a quote transaction, but MTS has yet to close the quote transation
  • Live: MTS has closed the quote transaction, signalling to us that the proposal is live on the market, and therefore tradable
  • PendingMarketOff: trader has switched the quote off, we’ve initiated the quote off transaction, but MTS has not yet confirmed the quote off transaction as closed
• Transitions
  • BankOn: we’re logged on to MTS
  • TraderOn: quotes are grouped by trader. The trader for the group owning this quote is logged on
  • Price: a fresh mid price for this quote has arrived from the pricing engine
  • Trade: a market taker has hit our proposal. We may want to go quote off for a few seconds to let the trader think about the trade before going back on
  • TraderOff: trader has turned off his quote group
  • BankOff: we’ve logged off MTS

Getting the states and transitions right means we avoid trading at stale prices. For example…

• Going quote on with a stale mid price, then subsequently trading at the wrong price
• Trying to send a new quote before the transaction for the previous quote has closed. If the mid price for this quote ticks again, we’ll have a stale quote at the head of the outgoing queue, with a fresher quote behind it

Of course, all the above is an over simplification, and I’ve omitted all sorts of issues like MTS’s channel mechanism and the OpenServer, but you get the idea…

“By the time we got to Hedgestock…

…we were half a million long” [with apologies to] Crosby, Stills and Nash.

Paul Graham has posted a new essay on outsiders vs. insiders – thought provoking stuff as ever. So who are the outsiders in our industry, wholesale finance ?  Hedgestock, the hedge fund industry beano reveals the hedge fund self image: they’re the counter culture, the underground.

In recent years there’s been a big flow of capital, traders and techies into hegde funds. The capital is seeking returns, of course. The traders are seeking compensation too, as well as freedom from the corporate culture of the big trading banks. And the techies are fleeing the sometimes stifling technical culture of the big banks, with onerous change management and architectural standards. Naturally, the techies are chasing big bonuses too.

Paul Graham has a very pro start up bias in his writing. Not surprising, as he hit the jackpot big time with Viaweb. I’ve worked for small, large and medium sized companies. My experience suggests that PG over emphasizes the freedom of start up environments. When I’m struggling against the inevitable bureaucracy of a large organisation, small companies can seem like highly liberated environments. But it’s important to remember that in a small company, you have to do a bit of everything: sales, admin, marketing. In a large org, there are people to take care of that, so you can specialize. If you get the right role, you become free to concentrate on the good stuff, to concentrate on what you do well and what you enjoy.

Back in the early 90s I worked for a medium sized ISV in the oil industry. In many ways that was the perfect environment. The company was large enough to support specialisation, but still small enough to avoid bureaucracy and a process centric approach. Still small enough that everyone knew everyone else.

I wonder if that kind of environment exists anywhere in etrading ?

Trading books

There are a few books on trading that I recommend to other developers…

• Liar's Poker: Michael Lewis writes more generally about business these days, but this is about starting at Salomon as a grad in the 80s. Lots of belly laughs about the depravity of traders.
• FIASCO: in which Frank Partnoy confesses to his part in Morgan Stanley's derivatives shop in the mid nineties, and explains how his colleagues made your average estate agent look like a paragon of moral virtue. Funny and savage. If you enjoy Liar's Poker, you'll lap this up too.
• Education of a Speculator: Victor Niederhoffer worked with Soros and ran his own hedge fund until it blew up in the wake of the LTCM debacle in 98. A brilliant rebuttal of both technical analysis and random walk theories. Analogies with the weather, music and sports are examined and a theory of ever changing cycles presented.
• The Predictors: the quality of the writing could be better, but the story of how Packard and Farmer joined up with the O'Connor derivatives house to try and beat the markets with lots of processing power and some way out algorithms is fascinating. I think UBS are still running the codebase this book describes.
• Fooled by Randomness: an extended meditation on probability and randomness, how poorly they are understood by the public and most market practitioners, and how an awareness of them can be applied in a contrarian trading strategy. Like Soros, the author is a big fan of Karl Popper, especially his ideas on falsification. A delightful blend of anecdote and abstraction.

Against method: routine, innovation and epistemological anarchy

Confused is picking up on CIO's distinction between routine and innovation…

“Organizing for routine work:  Drive out variance”

“Organizing for innovative work:  Enhance variance”

Back in the early 90s the tension between the 'impose a routine' imperative of structured methods like JSP and Constantine/Yourdon and the necessary creativity and innovation of software problem solving drove me mad with frustration. Object orientation was crossing over into the mainstream, and a new generation of methodologies based on structured methods, but tweaked for OO were propounded by their advocates.

The promise of those methodolgies was to make software development routine and predictable, hence their appeal to managers. Of course, we now know software development isn't routine and predictable, and trying to make it so is like trying to nail a jelly to the wall. Trying to make it so is to organize for routine and to attempt to execute innovation. No wonder it didn't work! More recently, agile approaches have acknowledged the essential nature of dev work, and offer a process that works with, not against, its intrinsic nature.

So back in the early 90s I'd become so maddened by the impose routine/execute innovation dichotomy that I spent a week in the Bodleian Library researching a paper that would decisively reject the claims of the software methodologists. It was to be based on twin foundations: the empirical study of programmers, and Paul Feyerabend's Against Method.

I first came across Feyerabend 20 years ago as an undergrad, browsing the Philosophy shelves in Heffers. I came across a copy of Farewell to Reason, and intrigued by the title, bought it. I'd been studying the Philosophy of Science, and covered the usual ground with Popper, Kuhn, Lakatos, Papineau. But no one had mentioned Feyerabend. Once I read Farewell I realised why. It's packed full of exciting, radical & contrarian ideas – for instance he defends the Church against Galileo !

Much of the Philosophy of Science is about science's purported special status in human intellectual activity as a generator of truth and certainty. As such it attempts to give an account of how and why science can generate knowledge, usually in terms of the scientific method. The logical positivists characterised the scientific method in terms of the principle of verification. When that was shown to be self contradictory, Popper's falsificationist ideas came to the fore. They're all epistemology, being theories about knowledge.

Feyerabend is an epistemological anarchist. Against Method is a sustained polemic against the very idea of a scientific method. It argues that any conceivable scientific method is refuted by examples of actual science. He examines cases from medicine, chemistry and physics and shows that no progress could have been made if scientists had stuck by rigid rules as per Popper.

Against Method is full of delightfully contrarian insights such as "semantic sloppiness is the prerequisite of progress" and "the only principle that does not inhibit progress is anything goes". When I returned to the book in the early 90s, it seemed obviously applicable to software development. Now that Agile is widely accepted, that argument doesn't need to be made.

So when I see people asserting that we need more than innovations, we need a process for innovation, I think "the only principle that does not inhibit progress is anything goes". It's a lesson that's been learnt at great length and expense in software development. And it looks like there are many others who could still benefit from Feyerabend's insights.

The write stuff

Our electronic trading system consists of more than 500K lines of C++. There's some Java and C# in there too. We have 50 traders using that system to autoquote, place and pull orders, autonegotiate RFQs and STP their trades for a dozen ECNs. Last year we did 23 releases to the trading floor.

Developers who come from an ISV or shrink wrap background are often completely confounded by the way development and deployment works in wholesale banking. They're used to long development and release cycles, measured in months and years. They think that since our systems are used to trade billions of Euros of bonds, swaps, futures and options every day, they must have massively heavyweight QA processes, like the shuttle software.

What those ISV developers don't realise are the factors that make trading software different from vendorware…

• Time to market is critical. When a trader wants to quote new instruments, they'll often tolerate flakiness to get to the business opportunity quicker.
• We only deploy to one site, our trading floor. We don't have to worry about being cross platform, or which service pack the users are running. We have a single, well managed, target infrastructure.
• We have the luxury of a dedicated test and release team. There's no way our users will test software, they're too busy trading !  Our testers often save us developers from getting the hairdryer treatment from a trader by picking up bugs before deployment. God bless 'em.

So in many ways developing trading systems is like the new world of web application deployment. Paul Graham was ahead of the game as usual on this. And like Paul Graham says, we're in very close touch with our users on the trading floor. They're quick to let us know when we get it wrong!

Bloomberg: the trader’s intranet

I’ve mentioned before how precious screen real estate is on the trading floor. One of the things traders alway have running is their Bloomberg terminal. Unlike us coders, they won’t have web, email and chat clients consuming that precious screen space. Bloomberg does email and chat anyway. Consequently, when a trader wants to publish some stuff to their colleagues on the floor, they’ll want to publish it on Bloomberg. That stuff may be some indicative quotes or valuations.

Alongside their Bloomberg, traders will always have Excel running. So we support their publication requirements with an XLL that can send an Excel worksheet to a Bloomberg GPGX page. That’s a GPGX, not a GDCO, which is for executable quotes. One click of a button and the trader’s free formatted sheet is out there on Bloomberg. Result: happy trader.

One consequence of this is that as an org, we are ever more locked into those Bloomberg fees: a grand a month for a terminal.

My word is my bond: musings on trust and the MTS raid

Confused is exploring Harris on trustworthiness. Confused reads Harris as explaining the enforcement of standards of behaviour in the market as by contract, rather than covenant. I haven't read all of Harris yet, and I'm expecting him to say something on the 'my word is my bond' market ethos, which is more covenant than contract.

So how does that ethos work in the markets ?  A buy side trader calls a dealer for a quote, and the dealer says '20/25'. The buy side trader says '50 yours' and the dealer says 'done'. At that point they've traded, but the deal has yet to be confirmed by the back offices, so they're not bound by contract yet. If either side subsequently reneges on the trade, they're violating the ethos. Dealers will refuse to quote to a trader who reneges, and a dealer who doesn't honour those trades won't get much business. Both parties have to trust each other until the trade is confirmed. That relationship of trust allows accommodation. Some time back I was on the trading floor helping one of our dealers diagnose an electronic trade on a quote driven market that had RFQed at the wrong price. He called up the counterparty, and they amended the trade price in our favour. Obviously the counterparty valued his relationship with his dealer more than a couple of basis points on the trade.

An instructive recent example of the violation of these implicit trust relationships between market participants was Citigroup's MTS raid. They drove EuroGovies down with a massive wave of selling, then bought them all back, profiting by £14M in the process. They didn't breach any specific rules, but as the story explains " the FSA … is likely to examine the trade with an eye on its very loosely defined rules against behaviour that distorts the market".

Another quote is salient: "It seems clear, now, that Citigroup broke some kind of taboo — but unlike many market conventions, this taboo was not one that anyone could have described or formulated before the event."

To understand what taboo was broken, you have to know that MTS as a market has a special position in the Euro Govt bond markets. It's an inter dealer market where issuers conduct primary market operations. MTS is based in Milan, and is used by the Italian, and other European governments, to issue new debt to the market. Only select dealers get to participate in those auctions of new debt. The right to participate in the primary market auctions is earned by taking quoting obligations. That is by quoting EuroGovies five hours a day. Those quoting obligations ensure that there is always dealer supplied liquidity available so that European governments can conduct treasury operations; for example buying debt back from the market.

Another thing that it's important to understand about MTS is that it's a hybrid market. It's not entirely a quote driven market like Bloomberg, and not entirely a limit order book market like Eurex. Market participants are divided into market makers and market takers. Markets makers send proposals, which are tradeable firm quotes, unlike the indicative quotes of Bloomberg or TradeWeb. Market takers place orders, much as they would on an order driven market. Proposals can cross with orders. However orders cannot cross with orders, so market takers have to trade with market makers, as they do in a quote driven market. Proposals can cross with proposals too.

Since market maker proposals are firm quotes, they are implemented in a transactional fashion, unlike the quotes on true quote driven markets like Bloomberg. Bloomberg's MPF spec specifies that quoting systems should expect an ack once every three quotes, roughly. On Bloomberg, the client doesn't get a tradeable price until an RFQ is initiated, and the quoting system sends a firm price. Since any market taker can trade a market maker's proposal, market makers must know what they're showing on the market at any given instance. Their systems can only know that with certainty because of the transactional model built around getting a quote on the market.

That transactional model has implications. To refresh a proposal a new transaction must be opened for that instrument. That can't be done until the previous transaction has completed. And there's a limit on the number of open transactions a market maker can have. So if a market maker is obliged to quote 300 govt bonds, and they can only have 50 open transactions at any instanct, they have major bottleneck if the market starts to move quickly. Market makers can be left badly exposed, with stale proposals out on the market.

It seems to me that the Citigroup raid was specifically designed to exploit those key features of MTS: market maker's obligation to quote, the hybrid nature of the market, and the transactional nature of proposals. But those market features were all designed to support government treasury operations. The Euroweek article quotes Tom Maheras of Citi as saying the raid was "an innovative transaction that sought to access the liquidity in the European government bond markets". Indeed, and no wonder the government treasury departments were pissed off !

Excel 12

Excel 12 aka Excel 2007 is going to be a big one for front office developers. Having coded XLLs for real time pricing and autoquoting, I was wondering when Excel would support multi threaded calcs. The good news is that Excel 12 adds multi threaded execution of XLL worksheet functions. This means that pricing sheets will now be able to fully exploit multi processor hosts.

So the next question has to be: can one run pricing XLLs in the new Excel Server environment ?  There's a limit to how much processing oomph we can have at a trading desk. Our traders are limited to two 2CPU PCs per desk, due to heat and power restrictions. If they need any more CPU we have to use blades in the machine room as remote desktops. Server hosting of pricing sheets would resolve these issues nicely.

 Fortunately, it looks like the answer is yes, given a bit of wrapping in managed code.

Market structure

The fixed income ECNs are either quote driven or order driven markets. Bloomberg and TradeWeb are the leading quote driven markets, and Liffe is an example of an order driven market. MTS is a curious hybrid.

In an order driven market, an order on one side of the order book for an instrument can potentially match with any order on the other side of the book, given the usual provisos about size and price. In a quote driven market, a trader wanting to buy or sell will request a quote from the dealers quoting on the ECN by clicking on a price.

The key difference is that on a quote driven market, a trader looking to buy or sell can only trade with a dealer. On an order driven market, that trader potentially trades with any market participant. Let's put that another way: on a quote driven market, only dealers supply liquidity. On an order driven market, all participants with orders in the market are supplying liquidity.

As Harris astutely points out, the key factor is the cost of liquidity. Dealers supply liquidity to the market, and the cost they charge is the spread. If you want to sell, you can only trade at a dealer's bid price in a quote driven market. In an order driven market, you can place your sell order at any price. However, if you want the order filled quickly, you'd better place it somewhere near the top of book.

So in an order driven market, there's potentially more liquidity, and so, from a dealer perspective, spreads will be narrower. Ergo dealers prefer quote driven markets.

Why would buy side traders prefer quote driven markets, if they're paying more for the dealer supplied liquidity ?  For one, they don't have to manage an order on the market. And on multi dealer ECNs with RFQs that work as competitive auctions, they should be able to minimise the spread.

Trustworthiness & creditworthiness

Confused is mulling over trust and confidence. For me, Harris captures this distinction perfectly for financial markets. I quote…

"People are trustworthy if they try to do what they say they will do. People are creditworthy if they can do what they say they will do. Since people often will not or cannot do what they promise, market institutions must be designed to effectively and inexpensively enforce contracts. Pay close attention to the mechanisms which ensure that traders will settle their trades. Attempts to solve trustworthiness and creditworthiness problems explain much of the structure of market institutions."

One of the functions of brokers in financial markets is to resolve trust and credit issues. The ebay reputation system addresses trustworthiness, but not creditworthiness, which is a big outstanding issue for any new market model.