"Signal Aggregation: Turning Multiple Sources into One Executable Stream"

The modern trading operation is rarely one model talking to one broker. It is a TradingView strategy firing webhooks, a proprietary model emitting decisions, a subscribed CTA feed, perhaps a discretionary override arriving from a human — several sources of intent, in several formats, at unpredictable times, all pointed at one pool of capital. The unglamorous discipline of merging those streams into a single coherent, risk-checked flow of orders is signal aggregation, and it is where a remarkable share of real-world trading failures originate. Not in the signals. In the plumbing between the signals and the exchange.

The deceptively hard problem

Individually, each source is simple: a message arrives saying, in effect, go long two contracts of ES. The difficulty is entirely in the collective properties of the stream:

Formats differ. A webhook delivers JSON over HTTP; a model emits a function call; a third-party feed uses its own schema; a Telegram alert is barely structured text. Before anything can be reasoned about, every signal must be normalized into one canonical internal representation: instrument (resolved to the actual contract — "ES" is not tradable; ESU6 is), direction, size or target position, order preferences, source identity, and a timestamp assigned the instant the signal crossed your boundary.

Semantics differ more. The subtlest divergence in signal design is incremental versus target-state semantics. "Buy 2" (add to whatever exists) and "be long 2" (adjust position to +2, whatever that requires) look similar and behave catastrophically differently under retries, restarts, and missed messages. Target-state semantics are strictly more robust — a repeated or replayed target signal is harmless, while a repeated incremental signal doubles a position. Where a source insists on incremental language, the aggregation layer should convert it to target-state internally and reconcile against the actual known position, not an assumed one.

Sources conflict. Two strategies may legitimately disagree — one long ES, one short. The aggregator needs a declared policy, chosen in advance from a small set of defensible options: netting (offset internally, send only the residual to market — capital-efficient, but strategy-level attribution must be preserved in the books), isolation (each strategy holds its position independently within its own limits), or priority (a hierarchy that lets designated sources override others). Any of the three can be correct. Having none of them — resolving conflicts by accident of message ordering — is the indefensible fourth option that unmanaged setups default to.

The properties that separate infrastructure from scripts

A production-grade aggregation layer exhibits four properties that a weekend webhook script does not:

Idempotency. Networks retry; platforms re-fire; users double-click. Every signal needs an identity (explicit ID, or a content-plus-time fingerprint), and a signal already processed must be recognized and ignored. Duplicate-signal incidents — the same alert executed three times in a volatile minute — are among the most common self-inflicted wounds in automated retail-to-professional trading, and idempotency is their complete cure.

Validation and authentication at the boundary. A webhook endpoint is a door on the public internet through which orders can be caused. It must authenticate its callers, validate every field against hard bounds (instrument whitelist, maximum size, sane prices), and treat malformed input as a security event, not a parsing inconvenience.

Sequencing under concurrency. Signals arrive asynchronously; positions are shared state. The aggregator must serialize decisions per instrument or per account so that two nearly simultaneous signals both read the true position before either acts. This is elementary concurrent-systems engineering, and its absence is why "the system somehow ended up double long" appears so often in incident write-ups.

A recorded lineage. Every order the aggregator emits should carry the identity of the signal that caused it, and every signal — including the ones rejected, deduplicated, or blocked by risk — should be written to the audit trail. As we argue in our recordkeeping article, the chain must root at the signal; aggregation is the layer where that root is either captured or lost forever.

Risk checks belong after aggregation, not before

An architectural point with regulatory resonance: pre-trade risk controls must sit downstream of aggregation, at the last gate before the exchange, where the combined intent of all sources is visible. Per-strategy limits are useful, but only the aggregate view can enforce account-level position caps and loss floors — three strategies each within its own limit can jointly breach the account's. This is the structural argument for a middleware layer as such: risk enforcement requires a chokepoint, and the aggregator is the natural place to build it. (It is precisely the position GIDEON occupies — signals in from TradingView, Collective2, Telegram, or CTA feeds; one normalized, risk-checked, fully logged order stream out to CME venues.)

The quiet payoff

Done well, signal aggregation is invisible: strategies fire, positions are right, conflicts resolve by policy, duplicates die at the door, and every order can be traced to its cause years later. Done poorly, it is the layer that converts good signals into bad positions. In systematic trading, alpha gets the conference talks — but the pipeline decides whether alpha survives contact with the market.

References

• Harris, L. (2003). Trading and Exchanges: Market Microstructure for Practitioners. Oxford University Press.
• Kleppmann, M. (2017). Designing Data-Intensive Applications. O'Reilly — on idempotency, ordering, and exactly-once semantics in message systems.
• CFTC Regulation 1.31 — recordkeeping requirements relevant to signal-to-order lineage.