We’ve been looking at what we’ve been calling “meta-strategies” – strategies that act upon other strategies – with the goal of implementing something like we’d described in the recent regime-switching post. (Please note that since then I’ve added a category to capture this thread.)
Last time we saw an example of historical forward-walking of a portfolio-oriented day-trading strategy which utilized daily data. This time we do something a bit more interesting and correspondingly complex. Today we’ll look at a real-time forward-walk of a moderate-frequency strategy (trades perhaps a few hundred times in a day) which looks at the top-of-the-book but doesn’t use market-depth. The strategy is a simple mean-reverter that we’ve described before though we’ve had to make some small changes to get it to behave in the context we’re looking at now…
Read more…
EMS Internals, regime-switching, strategy development
'optimization' or 'search'?
We’ve been looking at how a strategy container might view and implement a variety of modes for strategies it will launch and contain. Last time I documented a uniform initialization process for many of them, including a posited walk-forward parameter optimization mode. I’ve implemented an initial version of this that I’ll illustrate through a screencast (first ever – be gentle) below, but before continuing want to raise a couple of cautionary notes about the slope we’re traversing here.
From the very first post on this blog I’ve tried to underline the danger that over ‘optimization’ poses in view of the simple unalterable fact that if you look at enough random junk, you are bound to see things that look impossibly good. Doesn’t mean they’re actually good. In the context of trading strategy development, this is a particular danger as strategy parameter optimizers are easy to come by and can be very misleading if employed naively. I think this is in part due to the term ‘optimization’ which is really a stretch for what these tools do. They’re better described as search tools as they are really searching through a tuple-space of possible parameter combinations that you’ve specified, and then ranking them by some criteria you specify.
They’re still useful, but less as ‘optimizers’ and more as tools for judging the sensitivity of the strategy to different parameterizations. If the strategy demonstrates good performance and stability over a variety of market conditions and parameterizations, you may just have found yourself a winner…
Anyway, I felt that had to be said…
Read more…
EMS Internals, back-testing, performance analysis, portfolio management, regime-switching, strategy development
poor Jorge wasn't ready...
In this post I’m going to revisit some of the topics discussed in the recent ‘containing a strategy‘ and ‘multi-strategy trading with regimes‘ posts, focusing on the process of assembling a strategy and its context in preparation for its launch into any of a variety of modes.
I recently realized that – from the perspective of a strategy container – the process of walk-forward testing is remarkably similar to the regime-switching model we’d discussed previously. Up until now, I’ve employed walk-forward testing in an ad-hoc manner by taking an existing strategy and then writing a little driver very much like a unit-test scaffolding which would walk the strategy forward, permuting parameters based on previous performance. Not a general solution, but straight-forward as I employ the strategy parameter optimizer from stratbox in this kind of a toolkit use-case.
I sat down to write one of these walk-forward scaffolds yesterday and started to think about how I could generalize the solution and roll it into stratbox’s GUI and it occurred to me that I could likely kill two birds with one stone…
EMS Internals, back-testing, regime-switching, technology
or: a computational complexity model for derivatives fraud
lemon-law arbitrage?
Derivatives pricing has always been a notoriously complex, computationally expensive and potentially breathtakingly remunerative undertaking. This is true enough for relatively vanilla, exchange-traded options, but once one goes off-market and starts applying creative financial engineering, it can get much more complicated. Products like CDOs, CDSs, CDO^2s and their ilk have exploded in recent years creating opaque markets of trillions of notional dollars and accounting complexities we’re still only beginning to understand.
A recent paper, Computational Complexity and Information Asymmetry in Financial Products, by Arora, Barak, Brunnermeier and Ge take things a step or two further as they illustrate using information theory that it may be far worse than imagined as totally undetectable fraud can be engineered into these products. They show that fraud with these products can be undetectable in the sense that the pricing process is a formally intractable problem when the informational asymmetry inherent in the development of these products is taken into consideration. In this context, “informational asymmetry” is a polite way of saying “fraud.”
The authors, from the Department of Computer Science and Center for Computational Intractability at Princeton (man, I want one of their business cards!), demonstrate that if the designer of, say, a CDO wants to cherry-pick amongst bundled assets to maximize their own return, they can do so in a way such that it would be impossible for a buyer of the derivative to know they were being stiffed. The problem can be so hard that if you got the NSA’s mythic clusters humming on a pricing model, they might chug away until the sun falls from the sky before they accurately price it… Co-author Rong Ge provides a FAQ to the paper here and I must hat-tip Andrew Appel for his informative post on the paper.
The “perfect crime” is a puzzle that has occupied the (criminal and otherwise) mind of many a bright and motivated soul from time immemorial. While some may indulge towards the vulgar or base through violence or vice and others might ponder the perfect crime of passion, the cerebral Queen of Crime is surely some form of regulatory arbitrage: committing the crime for which the law has yet to be written or creatively engineering a legal loophole for a crime one has perpetrated or is about to perpetrate. The developers of CDOs are to be lauded as it appears they have materially upped the state-of-the-art of the perfect crime.
hmmm… Is there a Nobel for that?
dereferenced, options pricing, our managed markets
you, hf-trading
There seems to be a developing meme out there suggesting that algorithmic-, and in particular high-frequency, trading is some kind of gold-rush route to easy money which brings to mind…
…this revision of a paper I’d read previously: “Statistical Arbitrage in the US Equities Market” by Avellaneda and Lee. It’s a detailed and thoroughly worked (and now re-worked) paper illustrating the development and analysis of a US equity stat-arb strategy based on Principal Component Analysis (PCA) and then revised to use ETFs.
I came across this paper as I have still never used PCA in any of my own strategy development work and read Carol Alexander’s excellent Market Models over my summer vacation with an eye towards giving a PCA hedging model a spin in the near-term. Thus, I wanted another look at this paper as a reference point. Although it’s an excellent paper, I’m not going to urge you to go out and read it immediately unless you have a reasonably pressing practical interest. Instead, I find it interesting largely because of one of its authors – Professor Avellaneda – and its conclusions in the form of its strategies’ performance.
I’ve seen Prof Avellaneda speak a number of times at a variety of quant meetups organized by the relevant Columbia/NYU financial engineering depts. His paper reminds me that at least once during my noisome adolescent years, my father intoned darkly that:
the streets are littered with brilliant minds
Read more…
books, dereferenced, strategy development, technology
mean-reverting strategies (Picture: wikimedia)
The real world, despite having lost some mind-share to reality tv, Tim Geithner and the internet, remains an interesting place and a potentially fruitful source of inspiration for our own efforts at strategy development. In this pictorial post, I’ll take a look at some of the physical phenomena which inspire or reflect various trading strategies/domains.
Read more…
strategy development
One of the challenges of algorithmic trading is that although there’s plenty of interest in the space, practitioners aren’t generally forthcoming about their observations. Academics, instead, focus on things that are frequently not very immediately practicable, or when they might be, always seem to set-up a little hedge-fund on the side while publishing colorful chum about how markets are ‘behavioural’ or somesuch.
Even if it’s hard to find good stuff, one must still look as there’s always more information that can help you than you can effectively process or retain. A few weeks ago I was trying to formalize the expected profit function of an algorithm I’m developing and wanted to see what people had written about the topic. I entered ‘define profit function for trading algo’ into google and was pleasantly surprised to see a paper entitled ‘Multi-strategy trading utilizing market regimes’ by Mlnarik, Ramamoorthy and Savani. It doesn’t directly cover the topic I was looking for, but instead addresses a number of related topics I’ve been interested in for some time:
- the treatment of a strategy as an instrument in its own right
- composing portfolios comprised of strategies
- using regime switching techniques to manage portfolios of strategies
In this post, I’ll briefly review their paper, illustrate how one can easily model strategies in relevant ways using the strategy ‘object model’ I’ve described previously through an example, and conclude with some thoughts on how these kinds of strategies might be implemented and further explored.
Read more…
EMS Internals, dereferenced, portfolio management, regime-switching, strategy development
Mmmm... hardware..
I’ve never been a hardware guy. Hardware has gotten so fast throughout my professional life that it has just never been a big issue. Also, on wall st we had a robust and annual budget for h/w so I’d routinely sign-off on hundreds of thousands of dollars on all sorts of machines I’d never lay eyes on and somehow they always did the trick.
Before 9/11, they’d be in server racks in the building or down the street, but since then they might also be in increasingly far-flung places like weehawken or long island, tampa, even texas or beyond. The machines always seemed unbelievably overpriced – I remember over the years pretty consistently paying something like $40K for a low-end db server. But that’s what it cost and you could only purchase approved products from approved channels, so nobody spent much thought on it. Now that I don’t have the same kinds of constraints – or budgets! – I increasingly have to think of hardware.
As a software engineer, the hardware itself is also insisting that I pay some uncharacteristic attention to it. The evolution of processors has reached a point where the programming paradigms many of us have fruitfully employed over many years are no longer suited for getting full performance out of today’s machines. The recent introduction of remarkably powerful and inexpensive parallel-computing platforms based on GPUs like nvidia’s cuda also outline a future that even current university training doesn’t address in a fashion practically adapted for institutional application. Cores are multiplying like Tribbles.
The lines between persistent storage and main memory are also blurring as consumer SSDs push up from the ‘low’-end while exotic ioDrives and the like offer a glimpse of a world where the performance gap between the two approaches nil and after their long reign myriad metallic platters will spin no more.
Read more…
EMS Internals, market data, technology
My son recently had his first birthday and amazes me daily with his new feats as he runs around increasingly stably exploring the world around him. It occurs to me that the system I use to trade every day, Stratbox, is approaching its fourth “birthday” in the next few months. I hadn’t originally intended to write a system – an algorithmic trading platform – but found that existing products were limited, expensive and didn’t fit my mental model of what they should do.
This isn’t surprising as I wanted the system to support all of the activities associated with our algorithmic trading. It turns out that that’s a lot to ask of a system. It also turns out that you learn as you go and so the system continues to evolve. A few years ago I’d posted about the basics of a strategy container and in this post I’m going to come back to this topic and describe some of the layers of code and thought developed since then.
First, let’s consider the role of a strategy container. Its job is to intermediate between trading strategies and the external environments with which they interact. It must also provide services that strategies can use (e.g., position management) and that it wouldn’t make sense for each strategy to re-implement. In the past I’ve focused on the former responsibility of adapting strategies to external environments. Why is this necessary and interesting? Because it allows us to take the same exact strategy and run it live, or in simulation or in backtest, etc. Interesting and necessary, but not what I want to focus on this time. Instead, I want to look at the services provided to strategies; the ‘ecosystem’ a strategy container provides in the hope that strategies might flourish within it.
Read more…
EMS Internals, FIX Protocol, portfolio management, strategy development, technology
