There’s an old wall st saw: “Sell Rosh Hashanah, Buy Yom Kippur” that, according to this guy at least, has had good performance since 1915.

I haven’t tried to reproduce his work to confirm it, but I’m certain that anyone who bought today’s close is a serious mensch!

Although we’ve been in business since 2005, we’re still something of a start-up and certainly an entrepreneurial entity, so when a VC friend of mine suggested checking-out meetup.com’s technology and business groups I was open to the idea. This past week I attended my second meeting of the “ny tech” group and was as impressed the second time around as the first. It’s quite a production – from the venue, to the organization, to the ideas, people and products being presented – all for $5! (Though they sadly announced a price increase to $10 starting next meeting.) If you have even a small inclination towards entrepreneurial ventures or emerging technologies, it’s well worth a look-see.

The venue is the enormous lobby of the IAC building which is right on manhattan’s west side highway. So, as you sit watching the presentations, to your back you have giant windows overlooking the murderously speeding commuters hurtling to bedroom communities for 100 miles in every direction. In front of you is the single largest and coolest high definition monitor you have ever seen. Seriously. It’s about 30-odd feet high and maybe 120 feet long. It’s absurd.

Five or so presenters are each given 5-10 minutes to show their technology and tout their business model or idea. Almost all of them are good or interesting in some fashion but fear not! good, bad or otherwise, no presenter will consume more than 10 min.s of your life. The format is extremely crisp; presenters are briefly introduced after which they have 5 min.s to speak their piece. Afterwards, they get no more than 3 minutes to field questions. If you’re particularly interested in a particular speaker, each speaker is made available at one of the building’s structural columns at the end of all presentations. After too many years of interminable corporate meetings, the experience of such a crisp and efficient and knowledge-yielding format is really a revelation. Mayhaps there is something to this whole startup thing after all…(!)

The technologies are all pretty much of the web2.0 / social-networking varieties, so they’re not intrinsically of particular interest to me but they are interesting. The format is also prohibitive for showcasing sophisticated “vertical” technologies like our own, but the cleverness and innovation of people is evidently unbounded and it’s in that spirit that I find the presentations compelling.

The businesses ranged from a pretty well established (and excellent!) charity to an enthusiastic web hacker who’d put together a simple site “just because” and it had taken off, leaving him blinking in the light and delighted to learn that he’d hit on something people liked (and might even pay for!) This guy’s site, muxtape.com was actually my favorite of the bunch despite being by far the simplest. It evokes the time when friends would give each other mixed tapes of carefully selected, personally targeted tracks of music. Very fun – I’ve been listening to it ever since. His elegant use of amazon’s ludicrously cool ec2 infrastructure as his back-end is the only hint that nothing is as simple as it first appears..

Anyways, this is a pretty off-topic post and I don’t want to belabor the point, but you might want to check it out or find another interesting meetup near you…

The booths we checked out included a few of the big sell-side firms shilling their creatively-named execution quality algos and their white-labeled oms/ems offerings. They had, by far, the best shwag (I should thank Merrill for their nice umbrella and commend citi for the very knowledgeable lady at their booth) but their algo offerings weren’t very interesting to me as they aren’t of the alpha-seeking variety.

My favorite exhibit from an innovation perspective was actually a hardware offering from a firm named tervela which makes, essentially, a complex-event-processing (CEP) engine implemented in hardware. Very cool. I can’t imagine why any big shop would use any other sort of CEP solution. I had heard of them before as a guy I knew had joined them before their product had been delivered, so they were already on my radar, but seeing the hardware running was a big next step. Given the nature of their offering, it actually seems to me to have a bigger market in military than trading applications, but in both spaces it looks pretty compelling.

We looked at a few of the ems/algorithmic trading vendors and they didn’t offer any surprises but still had points of interest for us. The three systems we looked at were portware, tethys, and flextrade, and they can all credit themselves with knowledgeable, engaging and enthusiastic presenters in their respective booths. The platforms each had their own personalities and strengths. Portware had a very pleasant looking user interface and was, to me, most intuitively laid-out. The tethys platform seemed to have a real affinity for options and had sophisticated analytics to support that inclination. And flextrade just seemed like the most solid and mature of the platforms, but it’s hard to know such things from a trade show drive-by.

I was very interested to see that each platform offered user-interface level programmability via scripting of the sort I’d spoken of here but with a big difference. Instead of providing a scripting language, portware and flextrade offer users the ability to bring up an editor and add columns to tables via the platform’s native programming language – java and c++ respectively. Whew – can you imagine your average end-user whipping out some c++ to add a column. Mutant super users, maybe!

Overall we were very impressed by these trading systems. In particular we were happy to note that their strengths aren’t ours. If you want to use, say, lehman’s super-ginsu execution strategy (I’m making up that name), all of the platforms have the order available as a custom FIX order type which you can easily select from a pull-down menu. So their integration with a multitude of sell-side execution-quality algorithms is very complete and seems well-done. But their offerings are very limited compared to our own when it comes to the development and analysis of alpha-seeking strategies. They’re really not even close and it seems clear that their emphasis on the resource-intensive efforts of connectivity and broker integration has allowed us to create the class-leading platform for alpha-seeking strategy development.

So it was good to see the state of the industry and it was especially good to see our niche persisting at trade tech.

This week I attended another of the excellent quant seminars I’ve written about before. This time the talk was about stochastic modeling of equity markets and was presented by Robert Fernholz of Intech. Intech is evidently a subsidiary of Janus which manages some large amount of money presumably based on some of the portfolio management theory on which Dr. Fernholz is an expert. If you visit their site, you’ll be greeted by a bigger version of their credo which I’ve, um, honored as this post’s banner: “Math is power.”

Right then. While Mao would likely have been capable of convincing me otherwise, it’s probably best for everyone involved that portfolio managers are running around with esoteric mathematical models rather than the sorts of munitions favored by 20th century Chinese revolutionaries…

My interest in the talk was largely spurred by my interest in a variant of a problem I’ve discussed here namely, how-to generate useful synthetic markets. As I’d written before, the problem isn’t impossibly difficult for a constrained set of instruments. So, generating useful models for analyzing a pair trading strategy across pairs of correlated instruments is possible and it allows you to apply option-pricing techniques to the analysis of trading strategies. Swell. But if I want to do the same thing for a portfolio management strategy that’s looking at, say, the entire US market things become more complex.

As an example, consider applying this technique to a sector rotation model. In order for the synthetic markets you generate to produce meaningful or interesting results would seem to require that you capture the behavior of how equities within a sector interrelate and also how sectors relate to one another. It gets complicated pretty quickly.

Robert Fernholz has spent many years working on this kind of problem applying tools of a mathematical sophistication I will never wield, so hearing what he had to say had to be interesting. And it was. I think. His talk was very mathematically rigorous and unless you had read and digested his earlier papers beforehand, I don’t think you’d have a great shot at following him in great detail. The high point of his talk, for me, was his sequitur following a particularly dense bunch of proofs that “…now we will leave the world of math for that of statistics”.

After he had spoken for an hour packed with dense slides showing increasingly realistic (and complex) models he stopped to field questions. A couple of the professors who had hosted the event gamely tried with a few inquiries, but the rest of the crowd blinked and emitted a stony silence and a few sideways glances meant to ascertain if they were the only ones lost in space…

While I don’t think I was deep-space-nine lost, I certainly didn’t master every point made during the talk and I don’t think I came away from it any closer to achieving my own, limited, goals wrt developing concrete techniques for applying MC simulation across so diffuse a set of instruments as a nation’s equity markets. But it did give me an appreciation for the different approaches taken to related problems.

While the extremely precise theoretical approach taken by academics is ultimately necessary, the fact that Dr Fernholz spent an awful lot of work just coming up with a model in which markets didn’t necessarily devolve to one uber instrument reminded me of one of the more distasteful characteristics of philosophy. While it may not be possible to formally prove that the chair I’m sitting on exists to the satisfaction of some kind of philosopher, it certainly isn’t profitable to argue about it.

Among the more challenging questions we face when describing the Puppetmaster environment are those like “how do you create new proprietary trading strategies within the environment?” It’s a difficult question because of expectations – people want to hear about some super simple scripting language that any non-technical person can immediately learn and be up and algorithmically trading in no time. A few platforms intended for retail users offer such things – one is even appropriately named easy language. When researching approaches for our system, we spent some time learning easy language and found that it in fact did make easy things easy!

The problem was that it also made sophisticated things impossible.

This led us to pursue another, more powerful, approach for which we are currently seeking a patent.

That said, once upon a time I’d worked on a system into which some enterprising engineer had embedded a TCL interpreter with which one could monitor and manipulate objects within the runtime environment. We didn’t use it for much, but it was certainly interesting and helped with debugging the live system. Ever since then, I’ve had an interest in embedding a simple language+interpreter into my systems.

Thus, when a friend who builds systems for UBS told me about a talk on the groovy language in the google auditorium. I went along to see what it was about. (Admittedly, I was in significant part motivated to see inside the mysterious googleplex. I found it disappointing unless you fancy an environment that looks like an apple store with free razor scooters for anyone who might fancy a spin…)

The talk itself was also a bit disappointing as the speaker was very permissive with the questions and google had graciously given the crowd access to free beer. Many will argue that java programmers aren’t the sharpest tools in the shed and while I won’t weigh-in on that issue, I’m pretty certain that adding beer to the equation isn’t likely to help.

In any case, I did come away from the talk understanding that 1) if our business takes off in a big way, we will not attempt to motivate people with silly toys and 2) that groovy (or any other such scripting language) isn’t a reasonable mechanism for enabling non-technical people to write trading strategies.

This is no fault of the groovy language which seems fine enough. It’s a problem with the complexity of algorithmic trading. Trading is an intrinsically uncertain, asynchronous and demanding activity. I send orders to exchanges and they respond in their own good time. It might be 20ms if I’m sitting on top of the exchange or it might be seconds if I’m around the world or it might be days or more if it’s some kind of conditional order, but it’s certainly not a fixed time and it’s an uncertain message I’ll receive in response. Messages arrive when they arrive and you have to be ready for them.

If you’re trading a portfolio re-balancing model that trades infrequently and in size then it might suffice to send a few or perhaps a few hundred vwap orders a month and things will mostly take care of themselves. Here, maybe a scripting language is sufficiently expressive. But if you want to implement that vwap algorithm yourself or implement a strategy that trades against your broker’s vwap algorithm or implement a high-frequency strategy that is very “close to the market” requiring extreme low latency and precise order management or write a discovery algorithm that’s employing proprietary understanding of the ubiquitous and ephemeral “dark pools of liquidity,” then no scripting language will suffice.

From a technology perspective, my curiosity for groovy was sated – it’s certainly possible (and even easy!) to embed a powerful scripting language into your application. But from an algorithmic trading perspective, the problem is designing a trading-specific language that allows easy things to be simply done while allowing complex strategies to be efficiently expressed as well. This remains an area of active interest and research as it may someday complement our existing methodology, but for now we think we’ve got the best solution for the difficult “problem with easy.”

This past week I had the opportunity to see MIT’s Professor Andrew Lo present his paper “What Happened to the Quants In August 2007?” as part of the seminar series on quantitative finance presented by NYU and Columbia and sponsored by BlackRock and other relevant institutions. If you’re in the NYC area and interested in such things, I recommend attending any lectures which might capture your fancy.

I had read his paper some time back and implemented, within the Puppetmaster environment, the mean-reversion trading strategy he used as a microscope into what transpired last August. I was interested to see him speak as he’s a seminal thinker on hedge funds and quantitative finance, but also because the strategy he described works pretty well and I thought he might hint at various improvements.

I’ve stolen a line from his paper to serve as the title of this post as it captures one of the central dilemmas faced by algorithmic traders.

The quote is:

In the face of the large losses of August 7-8, most of the affected funds – which includes market-neutral, long/short equity, 130/30, and certain long-only funds – would likely have cut their risk prior to Thursday’s open by reducing their exposures or “de-leveraging”, either voluntarily or because they exceeded borrowing and risk limits set by their prime brokers and other creditors. This was both prudent and, unfortunately, disastrous.

My business partner likes to speak of the art and science of algorithmic trading and, while it might make me cringe as a bit touchy-feely, this is a perfect example of where she’s precisely right. In the case Professor Lo describes, these funds may have been compelled to unwind their strategies as they were excessively levered. (Ironically, the funds that were able to hold fast were almost immediately rewarded with record gains which nearly offset the record losses they’d incurred.) But there’s a general problem here for quantitative strategies, namely, what to do when a profitable strategy incurs unusual losses?

While there’s considerable science which can be applied to this question, at the end of the day the decisions one makes or, better – the policies one establishes – rely as much on the “art” the practitioner applies as any quantitative measure which can be objectively administered. Since a significant advantage of programmatic execution is that it takes such discretionary decision-making out of the trading equation, this is an issue of some consequence. While there’s no magical formula that I know of, there are at least two reasonable approaches to the question.

The first is to have a coherent understanding as to why your strategy is profitable, so that when it seems to stop working you can develop and test explanatory hypotheses with an eye towards developing a well-reasoned approach to the issue. Of course, if your strategy is the result of some sort of data-mining effort, than this can be difficult or impossible – yet another argument against a purely data-mining approach to strategy development! In the example Dr. Lo provides, an astute practitioner might be able to deduce that similar strategies had over-committed and been forced to liquidate; patience might be maintained while the world reverted to a (hopefully!) profitable state of equilibrium. While this approach may be workable in some cases, it seems to ask a lot from the practitioner as a day-to-day policy and might cause more problems than it resolves in the heat of the moment.

The second and probably more workable approach is to structurally minimize the problem by treating strategies like financial instruments in their own right and then apply traditional portfolio management techniques to their allocation. With this approach, we might only allow some fraction of our (levered) portfolio to be managed by any particular algorithm and partner it with other strategies which exhibit negative or complementary correlation characteristics. While it’s well-understood that in periods of serious financial dislocation “correlations go to 1″ and thus this approach won’t cure all ills, it provides a sound decision-making foundation for addressing the issue. Dynamic portfolio re-balancing schemes can thus be used to address these cases perhaps in concert with an effort to understand the root causes of the under-performance.

It’s certainly possible that even a sophisticated and automated application of portfolio management to this problem would yield similarly prudent yet disastrous results, but this seems to me to provide the best framework for reasoning about such issues and implementing appropriate preventive policies.