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 

How do you actually begin building Trading Systems in The Cloud?

The cloud and understanding how to benefit from it can be confusing. 

In this post we will attempt to avoid over complicating things and instead lay out a simple framework that you can to use to map your existing analytical IP and your historical tick data to The Cloud. 

In the near future, we anticipate that Cloud based historical tick level data stores will be available for back-testing on a 'pay-as-you-crunch' model.

There will also be approaches to creating data layers using the cloud service API and/or virtual data arrays. 

Until then consider this structure:

Logical-Cloud-Architecture-Simple.jpg

How does this really work?

At a high level the the cloud service API provides two things. 

The wrapper for your application services to take advantage of The Cloud and a layer of memory that can load any run time supported by the cloud when the application is launched.

Note - This is a critical nuance as this is what really happens between the application layer and The Cloud service API.

Think about these things:

  1. What programming language is your Intellectual Property (application layer code) written in? This is important when choosing a Cloud service. Make sure the service supports your code.

  2. Can your proprietary data be moved to the cloud? It is important to make sure your data warehouse can scale with your cloud applications and be accessible by your cloud applications. The importance of this will be obvious in the upcoming articles three dimensional data stores (virtual data arrays).

  3. What is a simple but high value component of your application that would provide you with Trading Nuggets if you could run massive back-tests against it.  If you don't already have any, we bet that it wouldn't take you long to conjure something up considering that with The Cloud you now have unlimited processing power at your fingertips.  This may be were you want to start wrapping your IP into a cloud service API.  Once you have completed this first pass it will give you the knowledge and momentum to Start simple and build your library of Algo and Quant Cloud Srvices.

This is just the beginning and things do get more complex but the first step is just changing the way you think about your applications and intellectual property. In future posts we will de-construct an application and show the next level of detail in the cloud revolution.

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):


Amazon EC2 On-Demand Instances

Standard On-Demand Instances

Linux/UNIX Usage

Windows Usage

Small (Default)

$0.10 per hour

$0.125 per hour

Large

$0.40 per hour

$0.50 per hour

Extra Large

$0.80 per hour

$1.00 per hour

High CPU On-Demand Instances

Linux/UNIX Usage

Windows Usage

Medium

$0.20 per hour

$0.30 per hour

Extra Large

$0.80 per hour

$1.20 per hour

 

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.

What's the next big thing in trading?

In my estimation, it's The Cloud.

The Cloud will have as great, or even greater affect on trading as the Internet.

That's a big statement, and I bet that many of you, are nodding your head in agreement.

The Cloud is going to change the way that we think about Intellectual Property, whether we need to own it, buy it, or simply lease it - which is the option that I think will emerge as the de facto standard in 50 or so months.

In the blink of an eye The Cloud will exponentially increase the amount of data that we back-test against and thus, will open up true data mining to the masses.

No longer will quant shops have exclusive access to ripping through the massive amounts of data that really drives the markets.   

Creating tool sets and algorithms for these data sets is going to be a great gig for a the tech folks who hustle and early on stake out their corner of The Cloud.

New brands that are cloud-centric will spring up and will provide their owners with a marketing edge for at least a decade or so.

Here's a first pass at what 'before' and 'after' The Cloud will do for Joe Trader:

Pre-Cloud Retail Trading Architecture:

Algo Futures - Pre-Cloud Retail Trading Architecture - Carl Weiss.jpg

Post-Cloud Retail Trading Architecture:

Algo Futures - Post-Cloud Retail Trading Architecture - Carl Weiss.jpg

Brokers and software developers making Cloud services available to their clients will wipe the deck with old-line brokers and trading platform developers who don't adopt to the new model quickly enough.

We are working towards a product that is a layup to Cloud services.   We will be offering automated trade management for news sentiment algos and leasing of algo IP via slew of .NET web services and will be posting more about it here soon.

Anyone know of any shops offering Cloud Services yet?

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 nth 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?

That is a big question.  We need:

  • Large data stores of transaction level data at our fingertips
  • GUI oriented tools to readily compile this data in different combinations
  • The ability to quickly load lots of this data into memory and then slice and dice it
  • GUI oriented tools that have real-world trading methods that can be dragged and dropped onto a strat for back-testing
  • More GUI & less coding
  • More indicators that are predicated on Transaction Level Analysis and other approaches, and less of the same old hum-drum of tired indicators
  • A reporting tool that can be readily modified without a user knowing SQL
  • The ability to create Automated Trading Drones right from the R&D side of the platform that can be put directly into the market without an extensive re-write to accommodate your broker's API and/or to lose all of the back-testing code overhead
One of the challenges is that to run all of this stuff you till need custom programming, system admin staff and a plethora of hardware.

In the near future The Cloud will eliminate most of the monotonous and redundant stuff while simultaneously making available pools of electronic Intellectual Property.

I think that as this Clap (Cloud Application) evolves and is rolled out to the masses the net effect will be a level of software and services that will make each and every trader's jaw drop on a regular basis.

The Cloud  and Claps are category changers. 

While the tools to develop in the cloud are rounded out, we are continually pushing for new ways to distribute, yet protect, Algorithmic Trading Intellectual Property.

Our current approach is to use a sceeto (Self Contained Electronic Exchange Transaction Objects) to distribute the IP (Intellectual Property) of an Algorithmic Quant Shop to a trader's desktop without pushing down all of the unnecessary overhead...it's a pretty cool approach.

   

When the S&P 500 e-mini where beginning to get some traction we used to S&P 500 pit Squawk Box all day long.


You wouldn't need to look at the screen all day long...you could go about your work, ours being software, and the Squawk would let you know when to focus on the market.


For me, my ears would pique when the frequency of the barks increased and the action switched from bid to ask, and vice versa.


You could also hear the muscles in the announcer's neck tighten and his pitch rise a bit.


Hearing that audio pattern was what moved my focus from the monitors where I was working on software to monitors that were plotting the e-mini.


Though we have yet to throw audio into the Nano-Trading mix, I am sure that  patterns are in there that can be manifested aurally, and that any trader who had the inclination could keep the market on in the background and within a couple of day's start to hear patterns.


If we do this test here, the first pass will be kept simple, and we will use pleasant sounding tones (I never understood why rings of telephones can't be substantially more pleasant and soothing).


Perhaps, with a filter on lot sizes, each time a market transacts at Bid then Ask then Bid then Ask then Ask a wind chime could play for ½ second and follow with a soft Pop for each consecutive upward Price tick.  


Simultaneously we would plot these movements on a chart and write the data out to a log file.


Within this entire approach there is no mention of a Technical Analysis indicator, such as MACD, or Stochastics.  They do not apply here as these Minor Price Events don't lend themselves to being averaged. 


But they do lend themselves to indicating where Price may be going in the next few milliseconds.


My gut tells me that if someone did this in an iterative fashion for a week or so they would find patterns that they could profit from.


I think that the patterns that will dominate and offer the most lucrative rewards will be when a series of Program Trades start to fire and chew up the available inventory in the book.


From our experience, Program Trades tend to fire off simultaneously.  Traders still herd, though today, most of it is done programmatically.


This is one of the benefits of focusing on Transaction Level Analysis as opposed to Technical Analysis.  It may take a little more programming work and fast infrastructure the payoff is in this information.


Currently, we do most of this pattern recognition discovery work programmatically, but I miss listening to 'my buddy' from the pit on the Squawk so maybe this little project will be ratcheted up the priority list.


Hope this helps.

May be we can explain what Nano-Trading is by explaining what it is not.


What Nano-Trading is Not:

·         Nano-Trading does not use Technical Analysis indicators (MACD, RSI, Stochastics, etc).

·         Nano-Trading is not about 'fast' or 'high frequency' trading yet it still needs a massive amount of processing power, custom software and low latency to succeed.

A little more on what Nano-Trading is:

·         Nano-Trading is more like Morse Code....Dot, Dot, Dash, Dash, Dot, Dash, Dash

o   Where the Dot's and the Dash's are discrete Price movements....kinda like:

§  Price Up, Price Up, Price Down, Price Down, Price Down, Price Up

·         Feel free to make up your own 'Morse Code' algos.

·         Nano-Trading offers setups that are consistent for a particular market across all market environments.

·         Increased volatility does not alter a Nano-Trading system, it only provides more setups.

 

Hope this helps clarify some things and sets you pondering the possibilities.

Nano-Trading systems will go through a lot of data to find Minor Price Events (MPE), which are graphically depicted below.

The colored markings below represent manifestations of tiny price movements that we have found interesting.

his approach was developed in order to go through the massive amounts of data that a back-testing platform can generate when it is developed to monitor every transaction as opposed to just the OHLC of a particular time based bar.

Graphical representation can be configured to so suit one's particular disposition.

The idea is to leverage software to do the heavy crunching and then display MPEs so that a Trading Strategy Architect can look for patterns in the data.

Once the patterns are discernible, algorithms can be written specifically for a particular pattern.

This algorithm can then be tested, tuned, and if profitable, launched into production.

Hope that you found this interesting.


Algo Futures ES Program Trading MPE Map Example.jpg

Find recent content on the main index or look in the archives to find all content.