A short time ago, at my local Fidelity office,I had the opportunity to have a one-on-one conversation with a Fidelity field technical representative. I shared with him my thoughts about Wealth-Lab. I gave him my thoughts in the following document...

Wealth-Lab Pro is Fidelity’s most powerful trading tool!

1) Strengths:
a) A wealth of capabilities
i) Charting, ~400 technical indicators
ii) Strong strategy development and backtesting capability, with extensive performance reports
iii) A neural network component
(1) Slow indicator - I wrote my own, 5x faster. This because original indicator parses network XML for each symbol. It used to compile the input script multiple times, when my version was 20x faster. This was fixed in 2017.
iv) An automated trading component allowing strategy-directed day trading with Fidelity accounts
v) Elegant extensible design. A user can code completely new functionality and it will be integrated seamlessly by having appropriate signatures in the .dll. This capability exists for indicators, position sizers, performance visualizers, optimizers (I wrote PSO!), and data providers. Native and user extensions are peers.
2) Weaknesses
a) Mature fat client design
i) Power users have exploited even undocumented features to their fullest extent. Any change to core Wealth-Lab will introduce risk of custom extension failure (and angry customers).
ii) Extension libraries have been built, including users’ private libraries not visible to Fidelity.
iii) Requires C# programming skills (drag and drop functionality is far less powerful)
b) The inherent design problem…
i) First, runs each symbol through the backtest period in a vacuum, without consideration of capital, developing a list of orders. The strategy alternately opens positions and closes positions according to the strategy algorithm. Typically, if no position exists for a symbol, the rules to open a position are run. If a position is open, the rules for closing a position are run.
ii) After the last symbol, cash management is considered, picking from the combined order list according the rules of the selected PosSizer. Many orders may be excluded for insufficient buying power. BUT, since this isn’t known until after the strategy has run, ofttimes a strategy will be trying to close a nonexistent position when it should be trying to open a position. If priority is not used, the same strategy will produce different results for identical conditions.
iii) It should be the other way around – run each symbol for a bar, then run the PosSizer for that bar, letting the strategy know whether the signal passed or failed cash management.
iv) Exacerbated during a market downturn when all instruments look cheap, resulting in excessive rejected buy orders.
v) Workaround is difficult and convoluted
c) Limited support
i) Is there a Fidelity support team for Wealth-Lab Pro? Core WealthLab hasn’t had an update since (2016 ?) 6.9.19.0. Fidelity’s flagship tool seems to be Active Trader Pro, which does not have strategy development capability. For that glaring reason, Active Trader Pro is fairly useless to me.
ii) MS123 (German affiliate) website provides most help, through their website and forum, but focused on a non-US, priced, version of Wealth-Lab. They can’t touch core Wealth-Lab. Is their support team any deeper than Eugene and Robert(Cone)? The relationship between Fidelity and MS123 seems strange. If Fidelity ever comments on the forum, they don’t identify themselves.
3) Consider marrying Wealth-Lab Pro and Active Trader Pro?
a) Make Wealth-Lab Pro a component of Active Trader Pro
b) Considerable design and implementation effort, but…
c) This could be the most powerful consumer trading tool on the planet!

Thanks Len. For the record, MS123 is a Chicago, IL LLC whose President happens to be German ;) But you're right, Eugene and Robert are primary Wealth-Lab support.

Stay tuned. If everything goes as expected, keep an eye out for Wealth-Lab Pro updates starting later this year. We'll let you know more when we do.

Thank you LenMoz for doing that.

QUOTE:
Wealth-Lab Pro is Fidelity’s most powerful trading tool!... v) Elegant extensible design. A user can code completely new functionality and it will be integrated seamlessly

Totally agree.

QUOTE:
2) Weaknesses ...
i) Power users have exploited ... undocumented features to their fullest extent. Any change to core Wealth-Lab will introduce risk of custom extension failure....

And that's true of any framework. If you're using "private" framework data types, you can expect that API to change and break your code. As computer professionals, we all live with that. What would be good is to better document some of the "public" data types whos API wouldn't be changing. That would allow us to extend the framework more effectively without using the Object Explorer of Visual Studio.

The ability to extend the WL framework into external packages may be the most powerful feature of WL. I'm using a couple Math.Net routines (such as multiple linear regression) now in my private WL DLL library. And I'll eventually use R.NET to interface with R to do further regression model development and plotting.

QUOTE:
iii) Requires C# programming skills

True if you want to get creative, which is the primary reason for using WL in the first place; otherwise, there are simpler alternatives. By coding one's strategy in a compiled--and optimized--computer language, you maximize your speed of execution. For numerically intense problems, this is an advantage.

QUOTE:
b) The inherent design problem…
i) First, runs each symbol through the backtest period in a vacuum, without consideration of capital, [etc]...
iii) It should be the other way around – run each symbol for a bar, then run the PosSizer for that bar, letting the strategy know whether the signal passed or failed cash management.

Totally agree, but there's an implementation logistics problem doing it the other way around. Let me explain:

The current implementation of WL has time as the fastest moving variable, with symbols as the next fastest. That's done that way because the WL indicators operate on individual time series data (stock DataSeries) one symbol at a time. That needs to work that way to fit the indicator problem into processor L2/L3 cache to get cache hits (i.e. maximizing Principle of Locality for each indicator computation); otherwise, cache misses would slow the processor down by 15 to 20 times.

I have tried thinking about working around this Principle of Locality problem, but there isn't a good solution. The only option may be to compute all the indicators prior to entering the trading loop, then transposing the data space with symbols being the fastest moving variable with indicator vectors being the slower moving variable. Just performing this transposition of time data (indicator results) with symbol data may take minutes because the transpose would be done at front-side bus speeds (266 or 333MHz w/cache misses) instead of processor cache speeds (4GHz). After performing this transposition, trading decisions can now be made "across symbols" efficiently because symbols is the fastest moving variable. (NOTE: Plots have to be done with the fastest moving variable on the x-axis, so any plots over time must be done pre-transposition.)

What realistically can be done is to take the trading results and display them in a 2D scatter plot (e.g. risk vs gains) by symbol in a performance visualizer so one can see how each symbol performs compared with all other symbols on the scatter plot. But this is still employing an after-the-fact trading result. It's not taking PosSizer or signaling into account as part of the trading decision.

QUOTE:
a) Make Wealth-Lab Pro a component of Active Trader Pro

Agreed if it's done from a marketing prospective. Let me explain. An entry-level product can often be used to up sell a customer into a higher-end product. So if a budding Active Trader Pro user can be wooed into using Wealth Lab without spoiling his Active Trader Pro experience, then I'm all for it. For example, Wealth Lab could display its Alerts on Active Trader Pro so orders could be place via the latter.

Superticker,

QUOTE:
there's an implementation logistics problem doing it the other way around

See my new topic "Design pattern for in-line PosSizer"