Transaction Level Analysis (TLA) - The Blog

IMHO, this story is mostly noise.  Sergey Aleynikov took some source code home from the office one day ...and got caught.

Sergey should get a fair trial and if convicted, do very hard time as stealing Intellectual Property is abhorrent and repugnant, but his crime is not that of being a global criminal mastermind, it is of being a schmuck and a common thief.

Here's the deal...the source code in question, is in all likelihood, useless.

Here's why:

Goldman Sachs can be thought of as one big global grid of computers.

This massive grid of computers is run on a Category 5 Hurricane of software that takes an army of engineers, traders, quants, statisticians and the like build and maintain...It is one of the world's largest ongoing engineering efforts.

Goldman, in its unique market position, has lots of proprietary information flowing about that they analyze in real-time to make trading decisions which make them a lot of money.

Here's the catch...Sergey only has some of the source code that once compiled runs the Goldman Sachs grid....and you need most, if not all of it, to make real-time decisions.

I am not privy to the details of what is in the source code that Sergey stole, but even if it is Goldman's 'Crown Jewels' it won't work very well, and likely not at all, without all of the myriad of proprietary data feeds that Goldman is updating with almost every clock cycle on almost every processor in their grid.

Did Sergey steal all of this too?  Can the code that he stole be installed and run in real-time?  To do this, he would have to hack into every nook and cranny of the Goldman Grid to replicate this torrent of information that feeds the algorithmic decision making engine that only Goldman has access to.

Furthermore, if Sergey could replicate the entire Goldman Grid, does he have the capital needed to fire off these programs?  Never mind all of the direct connections needed to all of the exchanges.

Lemme know if I am off base here.

The Good News

Today you can readily port your current quantitative, algorithmic and automated trade platforms over to The Cloud.

The Bad News

Your trading platform's current architecture will not automatically allow you to take advantage of the massive processing power that The Cloud avails of itself.

The biggest challenge is that proprietary strategies or algorithms will require an additional translation to be executed so that your algorithmic instructions can be parsed out to multiple processors simultaneously.

Your current platform does not have this instruction set embedded in it....Bummer.

We will be publishing a post shortly on this and will give you an overview of two different approaches to solving this problem either via an ad hoc overlay of parsing services or from a code base that was built from the ground up with parallel processing in mind.

More Bad News

Cloud Based Historical Tick Data Stores for back-testing are not yet online.

The first offerings will be offered not by data vendors, or the exchanges, but as a service available only by proprietary Cloud based algo/quant trading platforms - with access to the Historical Tick Data store only by their own platform using their own API.

What's Next?

We are currently speaking with trading software vendors, data vendors and exchanges about their intended Cloud Tick Data Store offerings and will be publishing a post on the state of their upcoming offerings and their pros and cons.

Where's the Sunshine?

Though the infrastructure and the technology to enable The Cloud today is here today the Algo/Quant tool-kits and their supporting services are not yet in place....But the first offerings are entering Beta as we speak.

So now is the time to start rolling up your sleeves, to start figuring out how best to lean into The Cloud to improve your trading organization and have some fun with a new technology.

If you have any facet of a Cloud Trading offering, either in development, beta or production, please feel free to ping us to chat.

carl at algofutures 

Some folks have written me saying that The Cloud does not have application in the Trading Industry because of latency issues.

Some of you may already be familiar with my thoughts on The Latency Hype so I won't delve into them here.

For this blog post, let's put Trade Execution Services within The Cloud aside for the time being and focus solely on the R&D side of your trading business.

The Cloud harmonizes the intrinsic elasticity of the Demand for Processing Cycles with the inelasticity of the Supply of Processing Cycles

One of the great advantages of The Cloud is that you can ramp up processing power without having to provision and/or commit to servers.  Once you are done with your calculations you release your leased processing cycles back into the pool of The Cloud and forget about them.

All of the hardware, software, rack space, electricity, etc. that it took to run your calculations are now offered on a pay-as-you-go model via The Cloud.

Gone are the days of provisioning your data processing resources for your projected peak load.

With The Cloud's real-time scalable pay-as-you-go model you can spin up 1,000 servers and run them for an hour for the same cost as spinning up 1 server and running it for 1,000 hours.

How cool is that?

...and the cycle time is cheap.  Below are cycle costs from Amazon's Web Offering (EC2):

Note - we are Vendor Neutral and are only quoting Amazon's pricing as an example,  not an endorsement.

There are different types of Cloud offerings and depending upon the type of number crunching that you do, or would like to do, and the composure of your current Intellectual Property code base, Amazon may not be the best offering for you.

In our next post about Algo and Quant Trading in The Cloud, Tim Kraska will document a Logical Design for Cloud Services that will enable you to port your current IP to The Cloud.

Every once in a while my spider senses pick up a familiar signal...that is, The Herd is moving in lock-step and picking up speed.

This time around it's about the obsession of shaving latency.

Shaving latency seems to have become the biggest cottage industry in trading.

Every day I get more and more spam about latency....and you know that things are out of hand when the spammers are on to it.

How about this one:

Dear Friend,

I am a Nigerian Prince who has been exiled from my country.  My father has deposited $420,000,000(US) in a trading account in Zurich.

If you give me your latency shaving algos, in return, I will share our increased profits with you 50-50.

Please e-mail your source code, router IPs, passwords, etc to:

honey-I-found-an-answer-to-our-prayers@lagos.net

I agree that speed is important, but is it the whole ball of wax?

Could it be that the latency shaving stuff is just another arms race? 

A contest where no one is the clear winner?

Won't we all continue to have pretty much the same speed as the technology continues to evolve and leak out?

Wouldn't it be better to spend your time working on algos that are just plain smarter at analyzing and digesting all of the true market data that is currently available than simply playing the same old card over and over again of trying to be faster?

I was chatting with developer friend at a prop shop in Chicago and he told me that their in-house programming bench consisted of 6 guys and that each and every one of them was only working on shaving latency.

If a shop's algos can only thrive with that extra n^th of second in their pocket then perhaps it's time to focus a little more of energy developing cleverer setups and entries....Just a thought.

Anyone care to comment?  Am I off base here?