From our research notebook

Signal EA vs Risk Manager

We explain why we give signal logic and risk management different responsibilities, even when both live inside the same Expert Advisor.

Our archive includes both full EAs and tools built to manage trades. Working on the two made their different responsibilities clear to us: recognising a setup is one decision; allowing the account to take it is another.

We want to know whether the setup existed

The signal side describes context, direction, entry timing and strategy-specific invalidation. We want it to record a valid setup even when no order follows. Otherwise, a blocked trade can be mistaken for a missed signal.

We give risk a defined authority

The risk side considers size, existing exposure, margin and the relevant account limits. Depending on its agreed scope, it can allow, reduce or block new exposure, or supervise existing positions. We need a reason and reset policy for each state.

We can examine the two roles separately

We can replay market observations to inspect signal behaviour and use controlled exposure scenarios to inspect risk decisions. They may still be delivered in one program. The useful separation is between the questions they answer, not between filenames.

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 two tools can live inside one program, but they answer different questions. A signal engine describes market opportunity. A risk manager describes permission, size, supervision, and stop authority.

The risk-focused archive cluster included both full Expert Advisors and separate trade-management tools. That split is useful because a good signal can still arrive when the account should not add exposure.

Short answer · SHORT-04

Who makes which decision

The signal module finds the opportunity. The risk module decides permission and size. The order and monitoring layers carry out and supervise the approved action.

  1. 01
    Signal EADetects context, setup, direction, trigger, and strategy invalidation.
  2. 02
    Risk managerCalculates size, checks exposure, session, equity, margin, and emergency state.
  3. 03
    Order layerActs only after permission, then verifies the broker response and protection.
  4. 04
    SupervisorMonitors open exposure and can reduce, block, or close according to mandate.

Signal responsibility

The signal EA owns the market logic: filters, setup, direction, entry timing, and strategy-specific exit conditions. It should be able to report that a setup existed even when no order was allowed.

That distinction makes evaluation honest. A blocked signal is not the same as a missing signal, and an execution failure is not the same as a strategy decision.

Risk responsibility

The risk manager owns exposure: intended loss, allowed volume, existing positions, daily or weekly state, equity, margin, and emergency conditions. Depending on its mandate, it may supervise one EA, a symbol group, or the entire account.

Its decision should be simple and auditable: allowed, reduced, blocked, or emergency action—with a recorded reason and reset policy.

Why separation helps

Separate responsibilities make testing and portfolio control easier. The signal module can be tested for behavioural accuracy, while the risk module can be stress-tested with artificial exposure and failure states.

They may still be delivered in one EA. The architectural boundary matters more than the number of files: opportunity proposes; risk disposes.

Questions you may have

Do I need a separate risk-manager EA?

Not always. The functions can be inside the signal EA, provided responsibilities and authority remain clearly separated.

Can one risk manager supervise several EAs?

Yes, if position ownership, account scope, priority, and emergency behaviour are defined carefully.

POLARIS / R10

Give each component one clear authority

Scroll the diagram horizontally or open it at full size.

Give each component one clear authority
Educational design example — values and states are not live performance.Open full diagram ↗

Evidence in practice

Give each component one clear authority

A signal is a proposal. Permission belongs to the component that sees the relevant risk. Execution confirmation belongs to the account and broker state. Mixing those authorities makes conflicts hard to reproduce.

Authority table
Decision Signal EA Risk manager Final source of truth
Create entry idea Owns Observes Versioned signal event
Set or reduce volume Proposes Owns within mandate Issued permission
Modify protective stop Proposes strategy exit May tighten or emergency-close by priority Confirmed position state
Normal exit Owns strategy reason May veto only if contract says so Confirmed deal
Emergency stop Must obey Owns Persisted account kill state

An integrated EA can enforce this hierarchy inside one process. A shared gateway can enforce it for cooperating EAs before orders are sent. A supervisor that only watches after independent EAs trade cannot guarantee prevention; it can only react, and closing may fail or add cost.

Example: signal S-104 is valid for one M15 bar. The manager vetoes it because account risk is full and persists the veto with that event ID. A restart reloads both the account state and veto. When the next tick repeats S-104, it remains blocked. Only a genuinely new source-bar event can request fresh permission.

What to verify

  • Test entry, size, stop modification, exit and emergency authority separately.
  • Repeat messages and reverse event order; the final permission and account state must match.
  • Restart after veto and after send; reconcile by IDs before accepting any re-entry.

Limits of this example

A manager has only the authority the topology gives it. A monitoring panel or after-trade watcher is not equivalent to a mandatory pre-trade gateway.

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

Related research