You guys are forgetting a major factor in splitting up order flow - fees & commissions. The second you start to split your orders up is the second your fees are sky high and your capital requirements jump up substantially. The amount of money that you would waste in parked capital and lower ROI due to higher fees and commissions would make splitting up the flow not worth it.
People throw around IT terms like âReverse Engineeringâ in ways they were never meant to be used. In the late 1990s I was on the management team as the DBA manager we were given four banking systems that had to be reverse engineered for Y2K. All we were given as input was the data (IMS databases and files), the program load (run time) modules, minimal system documentation, job control language and transaction output. The output was the source code for the programs that explained the system logic and where the Y2K dates were. My team bought $2 million in âreverse engineeringâ tools. These Reverse Engineering tools did not reengineer directly from the data. We were told Reverse Engineering works only where code (load modules) is available (or in some cases additional descriptions were needed) not just data alone. So I can see Reverse Engineering from transaction data is possible for rudimentary trading systems. Where highly trained eyes can pick out subtle logical inferences to price from transactions they may be able to reengineer them into a trading system. There are many systems built on support and resistance and chart patterns that could be reverse engineered if there transaction information is known. But I highly doubt a system with more than simple rules could be reverse engineered by anyone from transactions alone. Just start with the price bars. How could they decipher what price bar relationships triggered such a trade just by observing the transaction data? For example say my system was built on trading a signal from a 12 period Bollinger Band on a 233 Tick Chart when price bars made a certain position with the band. How could a transaction(s) be Reverse Engineered back to the rules of that system? It could not be done. Simulated maybe, but not done. Well maybe Iâm wrong. But I was never presented with a method or product during Y2K that could rebuild code from transactions or data alone. They all told me back then, no code, then no reverse engineering. So that is why I give the most protection to code. It never leaves my computer site. It stays only on the computer and my backup devices. I send nothing to anyone from my systems especially dumps.
Theoretically, a strategy could be "reverse engineered" via a brute-force hack, similar to passwords. Instead of a password dictionary, substitute various trading indicators (BB, stoch, ma etc), price action, candle patterns, time frame analysis, volume, S&R etc, as the relevant 'dictionary'. Then let the mainframe chew on it for a couple days, testing all variations/parameters/combinations/multi-combinations. The final "hack" would be a strategy that roughly approximates entries and exits with actual logic. That strategy could then be back-tested, over a larger data set to determine its usefulness.
The difference is that passwords are limited, while the space of functions that you can apply to a price curve is unlimited. And serious strategies normally don't use classical indicators. So a brute force approach had to generate all sorts of nonlinear combinations of polynomial, trigonometric and other functions. This problem is not solvable in a couple days. Additionally, you only have a limited data set, maybe some 100 trades. This does not allow you to reconstruct the real code even if you get matches with the brute force method. Classical reverse engineering uses some executable and generates the source code from it. This is always solvable, although sometimes difficult. However, reverse engineering a trading strategy from a number of trades is not possible in the general case.
I think most, including the OP, have missed the point. The problem is not reverse engineering because it is not an effcient process as the trader can change his system anytime. The problem is front-running from offshore accounts a trader with a good record. Front-running can dramatically decrease performance or even take it down to breakeven. This is the real issue here. Using two brokers and doubling the position in one while entering the opposite half with another can take care of that at a high expense because of transaction cost. There is no easy way out.
Just a subjective opinion here, but wanted to chime in with knowledge gained as a software maker. If somebody wants your code, they'll want to get it as easily as possible. The most efficient way is to steal it and NOT recreate it, given the amount of effort required. If they are not able to simply take the file from your computer, from a hacker point of view, they will look for points of transfer, where your code is vulnerable. It could the point before compilation, when the script is loaded into memory. Here's a flow chart - http://en.wikipedia.org/wiki/File:Overview_of_the_Common_Language_Infrastructure.svg. In any of these transition points (for example, between CIL and CLR). C# and TS' EL (even protected scripts) are vulnerable at these points since they carry the source code with them, which is then loaded into memory. Encountering such loaders in the forms of viruses is HIGHLY unlikely for any retail trader (or even an institutional one, since they have very strict protection mechanisms) - but I think that's where the focus would go if someone really wanted to get your strategies as opposed to reverse-engineering. Again, just a subjective opinion on the subject.
That still leaves the question of when has this happened? If it is actually technically feasible, it should have happened to someone with enough capital to actually make headlines at some point. The closest thing I can think of is when Goldman was accused of doing something like this, but they weren't trying to actually copy the strategy of the people they were frontrunning, they were simply trading against them, as I recall. It had something to do with a portal they had made available to customers, but were using the data feed from the portal to get customer's orders at the same time they were being entered or something like that. It was a Zero Hedge story in 2009, so it might have actually been just hype. That still isn't the same as the entire premise of this thread, though, which is that someone will, by some means, copycat a trader's or traders' strategy. At that point, why not just reach out to the person and try to hire them? All the additional difficulty and risk seem outside the norm of any kind of business I've worked for and I've worked for quite a few. They don't want to have to rely on outsiders generating part of their profits because that's a risk. No CEO or Chief Investment Officer is going to want part of his profits coming from some guy who may or may not remain a customer of the brokerage. They'll just bring the guy in for a nice steak dinner, some beers and some hookers and it's a done deal.
I have no idea at this point. When it comes to actual trading, all I focus on is my strategy and everything else is just noise. The more I focus on just doing my own thing regardless of what others may or may not be doing, the better my results. So, either my focus is paying off and my strategy is getting better or nobody wants to steal it. http://en.wikipedia.org/wiki/Strategic_dominance
gmst, great points, but I'm not sure how big of a thread the broker and clearing firm is: 1. If they have a list of trades, reverse engineering it will be impossible without having a slight idea of what the system is based on. 2. Maybe I'm wrong, but wouldn't a broker placing trades with you be illegal? The other ways someone can get a strategy are preventable - IT guy, some guy at Ninjatrader who wants to see the code because it might be causing a crash (happened to me about three times so far).