From our research notebook

Trade Managers as Portfolio Infrastructure

As we worked with several systems on one account, trade management became a question of shared risk, position ownership and clear authority.

A trade manager can begin as a convenient way to size a position or move a stop. In portfolio work, we had to consider what happened when several strategies depended on those same actions. The manager became part of the account's shared operating structure.

We asked which positions it could control

An identifier alone does not always establish ownership. Manual trades, copied positions and different account modes complicate the picture. We define whether a manager observes, supervises one strategy or has wider authority, and keep its permitted actions within that scope.

We gave strategies a common view of capacity

Two systems can each see available margin while requesting exposure at the same time. We therefore consider open risk, pending orders and operations already requested when describing the shared budget. Directional overlap and correlated positions matter alongside the number of trades.

We wanted interventions to be explainable

Daily stops, basket exits and strategy pauses need a clear priority. After a restart, the manager must reconcile confirmed positions with its saved control state. A useful record explains why a strategy was permitted or blocked and whether the intended action actually completed.

Explore the technical detailOpen the full method, worked examples and implementation questions. We have kept this material here so you can follow the reasoning as far as you need.

A trade manager is often introduced as a collection of convenient actions: calculate volume, place stops, move protection, close a basket, or pause trading. In a portfolio, those actions become infrastructure because several strategies may depend on the same account state and must not issue conflicting instructions.

The central engineering problem is authority. The manager needs to know which positions it may observe, which it may change, which limits apply across strategies, and what to do when the broker confirms a result different from the request.

Engineering note · ENG-07

One control path for many strategies

The manager rebuilds account truth before it grants or uses authority.

  1. 01
    ObserveRead confirmed positions, orders, account state, symbol rules, and execution conditions.
  2. 02
    AttributeMap every position to an owner, strategy group, and portfolio risk budget.
  3. 03
    DecideApply permissions and hard limits in one documented priority order.
  4. 04
    VerifyConfirm broker results, rebuild state, and record every intervention.

Ownership before action

Magic numbers alone are rarely a complete ownership model. Manual trades, copied positions, symbol suffixes, several EAs sharing a magic number, and netting accounts can all blur responsibility. A manager needs a declared scope: observe-only, strategy-specific, portfolio-wide, or emergency account authority. Actions outside that scope must remain impossible.

A shared risk budget

Per-trade limits do not reveal combined exposure. The manager should aggregate open risk by strategy, direction, symbol group, currency, and account. It must define how pending orders, correlated positions, floating loss, margin use, and already-requested operations affect remaining capacity.

State and priority

Daily stops, strategy pauses, basket exits, time rules, and emergency controls can trigger together. Their precedence must be explicit. State also has to survive restarts: the manager should reconstruct from confirmed platform data and persisted control state rather than trusting counters held only in memory.

Operational outcome

A mature manager gives every strategy the same answer to the same account condition. It reduces duplicated risk code, makes interventions auditable, and allows portfolio rules to evolve without rewriting each entry model.

  • Define ownership and authority separately.
  • Recalculate exposure from confirmed positions and orders.
  • Use one priority table for normal, restricted, and emergency states.
  • Verify every trade result before changing internal state.
  • Log the measured condition, decision, request, and confirmed outcome.

Questions you may have

Should one manager control every EA?

Only when its ownership rules and authority are explicit. Some portfolios need a shared risk supervisor while strategy-specific exits remain inside each EA.

Can a trade manager guarantee a drawdown cap?

No. It can enforce intended actions, but gaps, slippage, outages, and rejected requests can move the realized result beyond a configured threshold.

POLARIS / R18

Use an ownership ledger that survives netting and restart

Scroll the diagram horizontally or open it at full size.

Use an ownership ledger that survives netting and restart
Educational design example — values and states are not live performance.Open full diagram ↗

Evidence in practice

Use an ownership ledger that survives netting and restart

On a netting account, strategy A buys 1.0 lot and strategy B sells 0.4. The platform may show one net BUY position of 0.6, so the visible position alone cannot explain each strategy’s responsibility. A separate ledger must preserve proposals, confirmed deals and allocations.

Illustrative ownership ledger
Event Platform position Strategy ledger Manager action
A BUY 1.0 confirmed BUY 1.0 A +1.0 Assign deal to A
B SELL 0.4 confirmed BUY 0.6 A +1.0; B −0.4 Keep both logical shares
Manual SELL 0.2 BUY 0.4 A +1.0; B −0.4; manual −0.2 Do not invent strategy ownership
A exits Expected SELL 1.0 changes net side A 0; B −0.4; manual −0.2 Reconcile actual deals before next action

The authority cycle is propose → validate → reserve → send with a unique operation key → receive one or more execution events → reconcile → commit or release. Only confirmed account events change the platform state; the manager changes its ledger from those events, not from assumptions about one request.

Duplicate messages and reversed event order must be idempotent. If one terminal disconnects, its reservations expire only under a written lease rule and after account reconciliation. A restart rebuilds from broker state plus the persisted operation ledger before granting new risk.

What to verify

  • Repeat a deal event and reverse harmless event delivery; the final ledger must be identical.
  • Disconnect one terminal with a pending request, then confirm it late.
  • Restart with manual and strategy exposure and preserve unassigned ownership.

Limits of this example

A logical allocation ledger is an accounting model. It needs an agreed method for distributing netting-account fills and costs and cannot change the broker’s position model.

Research quality record

Editorial ownership and primary references

Reviewed by POLARIS Research

Evidence scope

This article combines official platform behaviour with recurring, anonymized implementation patterns. Exact trading rules and client material are excluded.

Primary references

These references support platform behaviour or research concepts. They do not validate POLARIS performance and do not guarantee future results.

Related research and applications

Explore the next relevant layer

Move between focused research, system engineering and portfolio construction without losing the context of this page.

Algorithmic trading portfolios →Why one profitable EA is not a portfolio →Gold spot–futures arbitrage EA →

Related research