At the cross-roads between Retail platform and Custom implementation

A

Aston01

Anyone that has been around trading for a little while has no doubt been exposed to the constant "Which is the the better platform for ..." debate. Most retail platforms appear to be designed as discretionary platforms that to varying degrees support some level of automation. Whether that level of automation is adequate for your particular purposes is a debate to be had elsewhere.

In looking further into the process of fully automating a strategy I have found there appears to very few if any robust platform choices that don't require a fairly significant amount of ecosystem buy-in.

Starting with coding languages:

TradeStation you're committing to EasyLanguage
MultiCharts its EasyLanguage or .NET
NinjaTrader its NinjaScript
... and the list goes on​

Then you factor in Brokerage options:

TradeStation is limited to it's own (w/o a hack)
MultiCharts & NinjaTrader give you a considerable amount more flexibility
... and then everyone else seems to fall somewhere between the extremes​

Now take into account universal instrument support:

TradeStation has a more robust Options trading ability, but lacks even very basic self awareness of strike data within EasyLanguage (meaning you can't easily access strike specific Delta or IV without a substantial workaround). So if you want to trade options discretionarily with TS great, want to automate your system prepare for a headache.

Then again neither MultiCharts or NinjaTrader natively support Options at all.

Say you want to trade FX or Futures ...well whether it be commissions or datafeed granularity your dealing with another mixed bag of choices.
​

What I find is the current platform landscape appears to be a mix of forced compromise each with their own group of loyal advocates, without a single platform that allows you to trade anything you wish through any broker you choose while written in a non-proprietary language.

Custom code:

So this brings us to the "Custom" implementation where you can create anything to your heart's desire with enough coding, but that generally means you need to recreate 95% of the wheel. Because lets face it most likely only a certain part of your system required the flexibility of custom code and most of your core non-proprietary framework needs are really about the same as everyone else.

So for those of you that have successfully crossed this road, considering hindsight is closer to 20/20, what insight can you offer us at that crossroad between retail platforms an acquiring a stable custom automated trading code framework that included datafeed & brokerage connections, very basic money management and strategy components that could be easily plucked off and further refined as needed?

I personally am at the point where further development is going to mostly be centered around developing workarounds for specific platform handicaps. This just doesn't seem like a worthwhile investment of resources going forward. I am not opposed to outsourcing a custom framework, but it's easy enough to see how with some standardized guidelines depending on the developer/developers you worked with this could prove to be a bumpy/buggy road as well.
 
be glad. a trading firm i was with preferred to use a mix of trading systems. one has exceptional charting ability. Another has coding. They have their own custom superdom program to do the actual trading. there are some platforms with every bling but they are really, really expensive. the firm can easily afford it.

For poor joes like myself, I did a custom implementation with API, take a peek at http://hftstrat.com. Helps me to use Python for futures. If I had the money, I would probably buy one.
 
I personally really like the idea of using Python, its so readable even programmers not very familiar with it can fairly easily follow the logic. And if you do happen to need a component rewritten in C++ or similar for pure speed being a glue language the high speed version fairly easily plugs right back into the system.
 
Last edited:
I'm fortunate that my background is in computer science so I prefer writing and reading Java/C# syntax, but even with that you still need to make platform decisions. I've made "aum thresholds" guidelines. At certain points, it just makes sense in a dollars-in-dollars-out prospective to invest in (as an example) a well built FIXT engine. At some point further, it just makes sense (again, dollar to dollar) to move to Jersey and go right into the exchange using a broker's id.

If you start with an etrade account and a $200 balance on one side, and a fiber splice into an exchange at the other, it's a series of steps that cost more in dollars and time, but also get cheaper provided you have the revenue to support them.

I wouldn't let the technology guide you as much as the financial impact. And when your revenue grows or shrinks in the future, make sure you adjust your platform accordingly.

At a nuts and bolts level, I think an advantage that "full stack" programming languages (c++/java/c#) offer, especially the latter two, is that they can occupy a lot of real estate between the two extremes of platform design. The big languages work well with ~200 line simple stock screeners, all the way up to HFT, although if you get into "real HFT" (latency arbitrage style) I'd imagine that abstracted languages with runtime compilers get tossed out the window. Those worlds can even use custom hardware so there's no way a beefy JIT compiler option is going to work.

A lot of this also can come down to what you'd rather work with. Python or R might be "better" for me in some regards, but I don't like using them and have far more experience and skills with c#/java, so I stick with those. That might seem trivial, but it's the difference between me happily jumping into debug a problem at 5am with code I'm comfy with versus something that I sort of understand and am reluctant to optimize or enhance.
 
Risk619,

Very well put. It would be nice if someone would start a sticky in this forum where a lot of these core design choices could be expanded upon to create a common resource. As it stands now when you read through the forum there are a lot of fragmented conversations on the same topic but no place to aggregate these pieces of wisdom. The nuts and bolts are the reason for even coming to the forum to begin with.
 
Aston01 said:
Risk619,

Very well put. It would be nice if someone would start a sticky in this forum where a lot of these core design choices could be expanded upon to create a common resource. As it stands now when you read through the forum there are a lot of fragmented conversations on the same topic but no place to aggregate these pieces of wisdom. The nuts and bolts are the reason for even coming to the forum to begin with.
More...

It's interesting coming from computer science and software development land, where everything is fairly open source. Looking at something like facebook, the actual source code used to build it is largely irrelevant: the implementation is what matters so much. I think you could probably get three guys to remake Twitter's core components in a month, again showing that the software itself isn't as important as the organization. And for most shops, the life cycle of a software product is a few years. A ten year old application is generally remarked as a dinosaur.

But in quant/trading land, the source code (mainly talking about models and strategies) is the secret sauce so everyone is very guarded about it. If you had a good system and I got ahold of it, I could just change the API key to my account, turn it on, and now it makes money for me.

That compounded with the legal restraints of anyone working in a firm to keep their mouths closed keeps a pretty big wall up around system design I think. I'm also guessing that most people know that secrets don't last long these days. A single thumb drive of a big HFT shop's source code uploaded to a torrent index could literally bankrupt it overnight.

Sorry for going a bit off topic, but I'm with you in the general black magic and mystery surrounding system design. Very different from normal development.
 
I agree with you about keeping the "secret sauce" underwraps that just makes good sense. That part generally accounts for such a small relative portion of system design there shouldn't be any reason the other 95% can't be discussed.

Whats interesting to me is you take a retail platform where everything is heavily documented and if something is missing from the documentation then its outrageous. Yet with the custom code group try to get someone to explain the logic behind something benign and it's guarded as "proprietary"....Go figure.
 
Aston01 said:
I agree with you about keeping the "secret sauce" underwraps that just makes good sense. That part generally accounts for such a small relative portion of system design there shouldn't be any reason the other 95% can't be discussed.

Whats interesting to me is you take a retail platform where everything is heavily documented and if something is missing from the documentation then its outrageous. Yet with the custom code group try to get someone to explain the logic behind something benign and it's guarded as "proprietary"....Go figure.
More...

Ditto for the "discretionary" trading community (ie: people using their hands to click and type trades), in that for every trader there are two websites promoting some awesome formula for success, half of which are fairly well spelled out in detail.

But like you said, if you ask a quant/algo trader how to iterate an array, they'll run away and call their lawyer.
 
Aston01 said:
I agree with you about keeping the "secret sauce" underwraps that just makes good sense. That part generally accounts for such a small relative portion of system design there shouldn't be any reason the other 95% can't be discussed.
More...

what do you consider the other 95%.
 
You must log in or register to reply here.
Back
Top