The Gateway to Algorithmic and Automated Trading

Happy-Hour Trading

Published in Automated Trader Magazine Issue 18 Q3 2010

“Another double whisky, two packets of crisps, and seven million barrels of oil, please.”

And do have a barrel for yourself. Automated Trader’s Editor, William Essex, rounds off our section on risk with a quick look at a no-tech, uncomplicated, very, very simple question that nobody has ever been able to solve.

William Essex

William Essex

It is with some reluctance, and no small measure of despair, that I conclude this sequence of features on the management of risk in global financial markets by highlighting the single most important question that has faced risk managers in the last half-year. It is not a policy question, and nor is it a question relating to procedures and/or fiduciary responsibilities; nor does it address any kind of high-level defence of the enterprise.

It is:

What shall we do about the drunken oil trader?

The facts are known. The conclusion is inescapable. Anybody with a laptop and a bottle of the strong stuff could bring down any one of the world's markets with a few deft touches of the keys. And you couldn't even spot such a villain by the (until recently) traditional give-away: fat fingers. The worst-case scenario, as of a week or two back, is no longer the rogue trader hiding his positions (they're always men, aren't they?), trading at night, never taking a holiday, but the front-office team celebrating - just about anything - with a once-round-the-oil-markets-before-the-bar-closes stunt. These days, we can all crash all the markets - if we can get our wi-fi connections to work from the table with the best view of the pole-dancer.

And the worst of it? The stories of all the horrors that passed under the radar. You probably know them better than we do. The algo that mistakenly sent 980,000 duplicates of an order to an exchange; the not-so-apocryphal commodities trader who inadvertently raised the pig population of his basement car park from zero to several hundred. And the not-so-funny stories. "I thought the other guy understood that instrument." "I know the rules, but he insisted on having his limits removed." "Not my job to know how these things work." "Wasn't me, guv."

After the liquidity crisis, we all learned a lot about liquidity-risk management. Solutions came into the editorial inbox by the dozen. Then the volcano erupted - remember? We didn't hear of too many eruption-risk management solutions, but after the oil leak, the conversations about business continuity planning developed a new urgency. In the year when Europe became a no-fly zone and an oil company punctured the planet, the risks to be managed were most certainly big, bad and serious.

And now - please tell me this is a dream. [Latest we heard: the trader has found a niche just outside the EU - where he's banned - and that could be him on the other end of your trade.]

Are there drunken-trader solutions? Yes. Giles Nelson, Deputy CTO of Progress Software, says: "This is another instance of what we've seen numerous times. The commonality is that somebody or something, an algorithm for example, is placing trades that should never have hit the market. The present case was so unusual, as far as volume, time of day that it was done, that it should never have got to the market and caused the problems that it did."

We're in agreement so far. Questions were even asked in Congress. But there might be a solution short of a Bill To Prohibit The Drinking Of Alcohol By Financial Professionals. Nelson says: "There's a very simple answer to this. Organisations should be forced to have pre-trade risk systems in place, to ensure that either their traders' orders - or their clients' orders in the case of brokers offering DMA to their buy-side clients, for example - go through a set of checks as they go through to the market. If they sit outside what would be considered normal, they are stopped and a further check is then done before the order goes through." Or doesn't, obviously.

So many questions. What's 'normal'? Are you really suggesting that we don't have checks in place already? Actually, no, scratch that second one: the risk is not necessarily that our drunken oil trader will get through our checks, but that somebody else's drunken trader will get through their checks on our behalf, and crash the entire financial system for us. Internal checks do exist, of course (see the box 'Checkpoint latency'). Nelson's point is that 'forced' checks provide some reassurance about the other guy as well.


Nelson says, "Firms can say, to protect ourselves and our staff as well, we're going to put a thin layer of software infrastructure between the order-entry systems and the market. We'll need to have a set of rules for that, which apply to all traders. If a trade goes in which is, say, above a certain volume, stop it and raise an alert. You could have limits applied to individual traders, or to particular types of asset. You set these rules up." Possibly with a margin of - yes, let's call it error - so that a trade exceeding the limit by no more than, say, 10% just starts a red light flashing somewhere rather than scrambling the entire risk-management crisis team.

Yes, but - normal? Your 'dreamcatcher' system would no doubt chug along very happily with a set of rules generated in-house, but if we're close to a 'forced' implementation, what does the industry standard look like? There's a benchmarking issue here, and with it, a competition issue. Traders and clients alike may reject a latency-inducing extra layer, but if we're all doing it, maybe we could compete on the speed of our smart order delaying? If, of course, we're competing on a level, er, delaying field. There actually is an evolving standard for this, and Nelson offers as a reference point. It's a paper on controlling DMA, combining recommendations with current practice. Useful, if you aspire to industry-standard pre-trade risk controls.

Perhaps, at last, this is a step towards that elusive latency standard that gets discussed at such regular intervals. There's an obvious trade-off between speed and security here that would be much easier to resolve if forced implementation of a pre-trade risk system was formulated around some kind of "nobody else is trading faster than you are" guarantee, don't you think? It may come, and in the meantime, perhaps we could take a moment, with all due respect to each other, to reflect on the other commonalities that earn all these disaster stories their headlines. It's not just that they're serious. It's that they're so serious, so utterly absurd, and so consistently committed under the noses of people who should know better. Come on, guys.

Checkpoint latency

Checks on trade orders before they hit the market do exist, but they're not commonplace. The primary reason for this is that client firms object to them: to pass an order through an additional checkpoint at which it has to tick all the boxes to say that it's within 'normal' limits - it gets slowed down. Thus latency. There's also an inherent contradition in placing a "hang on while I check that" system in the middle of a high-frequency trading operation. In a business predicated on risk-taking, there's a coherent argument for not playing safe.

Unless - and let's not get into this now - you make a distinction between known market risk and any other kind. It's a decision. Do you take a moment to fasten your seat belt, or do you take off and burn rubber? Among the secondary resistances to installing additional latency-inducing check systems is that if you're taking advantage of a transient, big, unusual opportunity that nobody else has spotted - that, by definition, is going to deviate away from 'normal' and potentially be blocked.

There would be less of a problem if we were talking about automated trading of the kind that gets you gamed - predictable, detectable, 'safe' enough to be vulnerable, but let's not go there either. There is a contrarian view that in future, the route to profitability might be via slowing things down a little. It's always worth interrogating the received wisdom.

They also happen in offices with hierarchies. Nelson says: "The front office has an awful lot of power, because they're the people making all the money. The people on the risk side of things are playing catch-up. When pressure is exerted, often managers won't support them and they have to cave in."

If Automated Trader TV ever goes into the sitcom business, episode one will feature the conversation between the risk manager who wants to put in a check layer, and the star manager. Oh, and the client who's invested all his safe money and now wants some risk.

Let's jump forward a few months. All the firms in all the world have banished strong drink, et cetera, et cetera, and there are no more rogue traders (ha ha). The follow-up question, given that (a) we trade on information and (b) trading systems - unlike investigative reporters - only need one source for a story - the follow-up question is:

What shall we do about all this data that's flooded the trading floor?

It's not just bad-data risk. Fine if the newswires republish an old story about, let's say, an airline's earnings, and you trade knowing what's happened. Not fine, but manageable, if you trade in ignorance - not a happy situation, but at least you come out of it knowing which pipe(s) to cut. The bigger data problem is big data. Brian Sentance, CEO of Xenomorph, says: "What people need to have is higher quality data, but they're getting challenged by the greater complexity of reporting requirements, greater complexity of data, and higher volumes of data. There's a tug in both directions with regard to the volume of data challenging systems to deal with it, at the same time as regulators and clients want more detailed and highly granular reports on higher quality data."

So the solution to the drunken trader is to slow down the trading system by a couple of clicks, but then the sober trader is left with the problem of too much data, too complex data, and too much compliance/regulatory oversight/hindsight/record-keeping attached to that data. For Sentance, the challenge to be addressed is not just how to achieve business continuity through this gathering 'data storm', and thus how to trade through it, but also, how to accommodate it. Sentence says: "The historical way in which trading institutions have split along business lines - the convertible-bond desk, the equities desk, the fixed-income desk - has meant that everybody has been very siloed in their approach. There's been a lot of wasted effort and cost in trying to pull that data together."

And let's not assume that the people who set up those silos are still around to restructure the data-management function. You have, of course, heard the one about data management at Lehman Brothers?

Let's just stop, shall we? None of this considering the evidence and reaching a conclusion. Let's just stop. These days, you can't just outsource risk management to a boffin or a software system. We're swamped with data. We're trading faster than we think. Real risk is the thing that goes wrong after you've covered all the risks. As you read this, the next drunken oil trader - who won't be drunk, who won't be trading oil - is flexing his fingers and getting ready for a happy few hours on the markets.

I'm going to bed.