Trading strategy portfolios in XTester: shared capital, risk and the new Studio

Two strategies can look good in separate backtests and work poorly on the same account. One uses capital the other needs. Several algorithms open similar positions at the same time. Drawdowns that seemed acceptable in isolation overlap. A portfolio of trading strategies therefore needs to be tested as a single system, rather than treated as a folder of promising reports.

At XTester, we are working through the design of a programmable layer for managing such a portfolio. In parallel, we are developing the new XTester Studio environment based on Code - OSS. These are related development efforts, but they have different timelines and statuses: progress on Studio does not mean the portfolio manager is ready or will be included in its first release.

Why portfolio backtesting is more than adding up reports

An individual backtest shows how a strategy would have performed under a given set of conditions. But if each strategy is given the entire notional account balance and its results are then added to the others, the model has several independent pools of capital. A real shared balance does not work that way.

Imagine two strategies trading the same instrument. The first has already opened a position when the second receives a signal in the same direction. That entry may be valid for the second strategy. For the portfolio, it increases total exposure to one market. If there is not enough free margin, part of the trade may not go through at all, or its size will have to be reduced.

That is why a joint simulation needs to account for shared available capital, event ordering, orders and fills. Each algorithm's contribution to the result needs to be tracked, while fees, constraints and aggregate drawdown must be accounted for across the account. Otherwise, the portfolio report will show a result that could not be achieved under the chosen conditions.

The strategies themselves should be tested for robustness first. Walk-forward and out-of-sample testing are useful for this. The next step is to test what happens when the strategies run together. Neither stage replaces the other.

What changes with the new XTester Studio

Studio is being built on Code - OSS, the open-source foundation of Visual Studio Code. It is XTester's own application, not a requirement to install VS Code and find an extension for it. We are taking the editor and workspace from that existing foundation, while retaining XTester's C#/.NET trading engine and separating it from the Windows interface.

The internal feature register dated September 3 records Studio's first working workflow: from a C# project through compilation and data to a backtest, chart, trades and statistics. This does not mean that all the capabilities of the current XTester have been ported. Individual subsystems still need to be migrated and tested.

We plan to show the first public stage in early October. Its purpose is to provide a working environment for C# strategies and historical testing, rather than include every future feature from the outset. The article on XTester Studio's architecture explains the choice of foundation in more detail.

The current Windows version continues to be developed separately. We have released XTester's 91st preview version. This is neither a release of the cross-platform Studio nor a release of the portfolio layer described here.

How we envisage programmable risk management

The idea is to bring users' own strategies and third-party strategies together in one portfolio. A marketplace could eventually become one source of strategies. But the ability to connect strategies should not depend on having a marketplace: a clear, common way of working with them needs to come first.

We are considering a separate management module above the strategies: an orchestrator. A trading strategy proposes actions in its own market. The manager sees the whole account and allocates allowable risk based on market conditions, the algorithms' track records and positions that are already open.

Capital and risk are not the same thing here. Equal capital allocations do not mean equal exposure for the portfolio. The instrument, volatility, leverage, position size and relationship to other positions all matter.

Level	Question it answers
Individual strategy	Is there a trading signal under its rules?
Management module	How much risk can be allocated to this strategy now?
Constraint checks	Does the action stay within the account's established limits?
User	Which rules and permissions are acceptable?

We are considering ways to define the manager's rules in code or connect them as a separate module. This would make it possible to compare different approaches: fixed limits, volatility-based allocation or more complex algorithms. A more complex manager will not necessarily be better. Its rules can also be overfitted to historical data.

Manual control, AI and testing the whole system

Automatic risk allocation should not turn the portfolio into a black box. The panel needs to show allocated and used risk, strategy statistics and a decision log: what changed, under which rule and from what point onward.

Users need to be able to change a limit, block new entries or return a strategy to automatic management. Blocking new entries and closing existing positions are different actions. A manual restriction must not be silently lifted the next time the orchestrator recalculates.

We are also considering an AI assistant connected through MCP: analysing the current state, explaining decisions, making suggestions and taking permitted actions. The protocol itself does not define permissions or enforce risk controls. Those require separate constraints in the execution system that the assistant cannot bypass.

The central test of the whole idea is to run the same set of strategies with different management modules, using identical data and execution conditions. The comparison needs to cover more than returns: drawdown, capital utilisation, rejected orders and sensitivity to changes in the market all matter. The manager may use only information available at the time of each decision. For AI, inputs and responses also need to be recorded. Without that record, a rerun may be testing a different process.

For now, the portfolio layer is a concept being worked out in detail. The next substantive step is to define a common strategy interface, capital-accounting rules and a verifiable joint-testing scenario. These need to come before an attractive final equity curve.

This article is not investment advice. Trading involves the risk of loss; backtest results do not guarantee future returns.