From our research notebook

A Grid and Hedging Risk Manager

In this composite case, we explain how recurring requests for basket protection led us to separate position measurement, risk decisions and confirmed actions.

We built this composite example from recurring risk-management requirements. The request was to preserve an existing sequence method while adding a layer that could measure the basket and restrict further exposure. We describe the architecture without revealing a client's strategy.

We first needed a trustworthy view of positions

An internal order counter was not enough when manual trades, other EAs or failed requests could alter the account. The design reconstructs the basket from confirmed platform positions and an explicit ownership rule. That gives the manager something concrete to supervise.

We made competing rules easier to resolve

A basket target, a daily limit and an emergency condition can occur together. We therefore gave the controls an order of priority and defined which positions they could affect. Measurement, permission and execution became separate steps, with the broker's result checked after an action.

We examined recovery as part of the design

We use restart, partial-close and rejected-request scenarios to inspect whether the manager returns to the right state. We also examine entry into and exit from a blocked state. These questions show what account protection requires beyond adding another parameter to an EA.

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.

The recurring request sounded simple: keep an existing sequence logic, but add a separate layer that could measure the whole basket and stop it from expanding beyond agreed limits. In practice, the manager had to understand positions opened by more than one path, calculate live exposure, and retain authority when normal exit logic was no longer enough.

The case below combines patterns from several assignments. It describes the engineering problem and public-safe lessons, not a downloadable strategy or a client specification.

Composite case · CASE-02

Composite control path

A clear supervisor observes first, decides second, and records every intervention.

  1. 01
    ObserveIdentify owned positions, directions, volume, floating result, margin, and basket age.
  2. 02
    ClassifySeparate normal operation, restricted operation, blocked expansion, and emergency state.
  3. 03
    ActAllow, reduce, stop new orders, manage a basket exit, or escalate according to mandate.
  4. 04
    RecordLog the trigger, measured state, broker response, and reset requirement.

Shared problem

The entry module knew when it wanted another order, but it did not have a reliable account-wide view. Manual positions, another EA, or failed trade requests could change the real basket. The new layer therefore had to rebuild its view from confirmed platform positions instead of trusting an internal counter.

Constraints

The supervisor could not reveal or rewrite the private entry method. It had to work with clear ownership rules, different broker symbol properties, restarts, and both normal and abnormal execution. It also needed an unambiguous priority when profit targets, basket loss, daily limits, and emergency conditions conflicted.

Composite solution

The resulting pattern separated measurement from action. One part produced a verified snapshot of positions and account conditions. A second part applied fixed thresholds and returned a simple state. The execution layer then carried out the allowed response and confirmed what the broker actually completed.

Lessons

The most valuable improvement was not another recovery rule. It was making the exposure boundary visible, testable, and independent. Tests focused on restarts, missing positions, partial close behaviour, spread shocks, rejected requests, and the transition into and out of blocked states.

Questions you may have

Was this one client project?

No. It is a composite of recurring engineering patterns and does not identify or reproduce any single assignment.

Does a risk manager guarantee the cap?

No. It can enforce intended rules, but gaps, slippage, outages, and rejected orders may exceed planned limits.

POLARIS / R14

A risk manager needs real authority, not just visibility

Scroll the diagram horizontally or open it at full size.

A risk manager needs real authority, not just visibility
Educational design example — values and states are not live performance.Open full diagram ↗

Evidence in practice

A risk manager needs real authority, not just visibility

This constructed basket assumes cooperating EAs send every request through a shared permission gateway. A manager that only watches positions after independent EAs send orders cannot guarantee prevention; at best it reacts after exposure exists.

Basket states for a $10,000 account — illustrative limits
State Gross lots / modeled loss / margin use New order Manager action
Normal 0.30 / $180 / 18% May request Reserve capacity, then send
Restricted 0.70 / $430 / 42% Only if projected loss stays ≤$500 Reduce or veto
Blocked 0.90 / $500 / 55% No expansion Cancel pending additions
Emergency 0.90 / $760 stress loss / 72% No Attempt staged exit and reconcile every result

Permission moves through proposed → reserved → sent → confirmed or released. Outstanding requests count against capacity. In an emergency, a rejected close means the position and its remaining risk stay in the ledger. A partial close reduces them by the confirmed amount only. On restart, the manager rebuilds the ledger from actual orders, deals and positions before issuing new permission.

The kill switch can prevent cooperating strategies from adding orders. It cannot stop another terminal or manual trader that bypasses the gateway. That topology limit must be visible to the client.

What to verify

  • Reject one emergency close and show the residual lots, modeled loss and next permitted action.
  • Restart with an order still being processed and reconcile it without a duplicate send.
  • Attempt a bypassing independent order and demonstrate the manager’s reactive limitation.

Limits of this example

The numerical limits illustrate state transitions, not a recommended universal risk level or observed client outcome.

Research quality record

Editorial ownership and primary references

Reviewed by POLARIS Research

Evidence scope

This is a composite case drawn from recurring implementation patterns. It is not a description of one identifiable client engagement.

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 →Trade managers as portfolio infrastructure →Gold spot–futures arbitrage EA →

Related research