Signal Aggregator

Start with 3-5 sources for simplicity. Too few sources (1-2) don't provide enough consensus benefit. Too many (10+) can create confusion and analysis paralysis. Begin with: one trend indicator, one momentum indicator, one volume/confirmation indicator, and optionally one market context filter. Expand only after you understand how your initial sources interact.

If sources always agree, they may be too similar (correlated). This means you're not getting the diversification benefit of multiple sources. Try adding sources that look at different aspects: if you have two momentum indicators, replace one with a trend indicator or volume indicator. Check correlation between sources and aim for diversity.

Yes, mixing signal types can be valuable because they capture different information. Technical signals react to price action; fundamental signals capture underlying value. However, fundamental signals often have different timeframes (quarterly earnings vs daily price moves). Weight them appropriately and consider using fundamentals as filters rather than primary signals.

AlgoKing monitors source health and will exclude stale/offline sources from aggregation. You'll receive a notification. The aggregator continues working with remaining sources, but accuracy may decrease. Set up backup sources for critical signals. If a primary source is offline, you may want to reduce position sizes until it's restored.

Track and compare: 1) Aggregated signal win rate vs each individual source win rate, 2) Aggregated equity curve smoothness vs individual, 3) Maximum drawdown of aggregated vs individual. The aggregated approach should show fewer extreme drawdowns and smoother returns, though it may have slightly fewer total signals. If aggregate performs worse than best individual, review your weights and source selection.

If using adaptive weights: daily or weekly updates work well for active trading. If using static weights: review monthly and adjust if significant performance drift. Avoid too-frequent manual changes as this can lead to overfitting to recent data. When adjusting, limit changes to ±20% per period to maintain stability. Major weight changes should only follow sustained performance changes (20+ trades).

Two approaches: 1) Regime-based weighting - detect market regime (trending vs ranging using ADX or similar) and apply different weights. In ranging markets, reduce this source's weight to near-zero. 2) Conditional inclusion - only include this source in aggregation when a trend regime is detected. Track regime-specific performance to calibrate.

Aggregation naturally adds delay because it waits for consensus. To reduce: 1) Reduce signal timeout - don't wait as long for all sources, 2) Use hierarchical aggregation where fast primary signal triggers with slower confirmation, 3) Reduce minimum sources required, 4) Weight recent signals more heavily with time decay. Accept that some delay is the price of confirmation - it's a trade-off with accuracy.

Yes, this is cross-asset aggregation. For example, using bond yield signals to inform equity trades. Typically cross-asset signals should have lower weight (10-20%) and act as filters rather than primary signals. They provide macro context. Be careful with timing - cross-asset data may have different update frequencies. This approach works best for swing trading where macro context matters more.

Run walk-forward optimization: on historical data, find optimal weights for period 1, test on period 2, find optimal weights for periods 1-2, test on period 3, etc. Compare optimized weights performance to your current weights. If significantly different, consider adjusting. Also compare to equal weighting (1:1:1:1) as a baseline - if equal weighting beats your weights, your assignments may be hurting more than helping.

Key implementation steps: 1) Establish priors - start with 50% probability (neutral). 2) Calculate likelihood ratios for each source from historical accuracy (if source is 60% accurate, P(signal|outcome) ratios). 3) Update sequentially - each source's signal updates the posterior probability. 4) Use log-odds for computational stability. 5) Calibrate to ensure output probabilities are well-calibrated (predicted 70% should win 70%). 6) Account for correlation - correlated sources should contribute less than independent. Consider starting with simpler methods and graduating to Bayesian as you build understanding.

Recommended architecture: 1) Use Redis or similar in-memory store for current signal state, 2) Process signals asynchronously - receivers push to queue, aggregator consumes, 3) Use incremental aggregation - update weighted sums rather than full recalculation, 4) Implement time-bucketed aggregation (aggregate every 100ms) rather than on every signal to reduce computation, 5) Shard by instrument if processing many instruments, 6) Use compiled languages (C++/Rust) for aggregation engine if Python too slow, 7) Pre-compute normalization factors and weights. This architecture can handle 1000+ signals/second with <10ms aggregation latency.

Multi-layered detection: 1) Rolling accuracy monitoring - track 20-trade rolling win rate, alert if drops 15%+ from baseline, 2) Regime-adjusted monitoring - compare to expected accuracy for current regime, 3) Consecutive loss tracking - alert at 5+ losses, 4) Drift detection using CUSUM or similar statistical methods. Response: automated weight reduction (halve weight after 10% drop), automatic disabling (after 20% drop), human review trigger. Distinguish between source degradation vs market regime change vs random variance. Require statistical significance before major actions.

Hybrid approach: 1) Treat ML model output as one source in traditional aggregation (typically higher weight due to sophistication), 2) Or use ML to learn optimal combination of traditional signals, 3) Maintain interpretability - log ML feature importances and compare to traditional signal weights, 4) Use traditional signals as features for ML, 5) Implement model monitoring - track prediction accuracy, feature drift, 6) Have fallback - if ML model fails health checks, revert to traditional-only aggregation. Key insight: ML can find non-linear combinations traditional methods miss, but traditional methods provide interpretability and robustness.

Multi-latency framework: 1) Classify sources by latency tier (real-time, 15-min delay, daily), 2) Use appropriate staleness thresholds per tier, 3) Weight by latency appropriateness for strategy - intraday strategy weights real-time highly, swing strategy can weight delayed equally, 4) Implement source-specific decay rates - fast sources decay quickly, slow sources persist longer, 5) For event-driven aggregation, trigger only on real-time sources, use delayed for filters, 6) Document latency expectations and monitor for unexpected delays. The goal is getting maximum information from each source given its latency characteristics.