Filter-setup-trigger-exit Architecture

What is Filter-setup-trigger-exit Architecture?

Filter-setup-trigger-exit architecture decomposes a rules-based strategy into four layered roles. The filter decides whether trading is allowed at all: regime, session, direction, for example a higher-timeframe trend filter. The setup arms a candidate trade when conditions align, such as a pullback reaching a zone. The trigger is the discrete event that actually enters, a close beyond a level or a crossover. The exit owns everything after entry: initial stop, targets, and trailing rules. In code this runs as a small state machine stepping through idle, armed, in-position, and flat.

The pattern is systems-trading folklore formalized: layered designs run through the literature (triple-screen methods filter on one timeframe and trigger on another) and through modern modular communities, whose system templates assign every indicator a single role, baseline, confirmation, entry, exit, rather than letting one condition do four jobs. The architecture names what disciplined designers were already doing and gives testing a vocabulary for it.

The value is separation of concerns. Filters answer whether to look, triggers answer when to act, and conflating the two produces systems that enter on context (chronically early) or filter on timing (chronically late). The decomposition also keeps testing honest, because layers can be swapped or removed one at a time to see which is doing the work. Setups usually carry an expiry, a bar count after which an untriggered setup disarms, so stale context cannot fire a fresh entry.

The layer boundaries are where engineering lives. Filters are typically slow classifiers (trend/range state, session windows, proximity to higher-timeframe levels); setups encode location and condition with an expiry and a re-arm rule; triggers are single bar-resolution events, precise enough to timestamp; exits are their own subsystem, not an afterthought, holding the stop logic, targets, and trails that decide the trade's arithmetic. Between the layers sits the plumbing, cooldowns, one-position limits, duplicate suppression, stated once and enforced at the boundary.

How to structure a strategy in this architecture

The exercise is assigning every rule exactly one role, then wiring the boundaries.

1. 1Write the filter first: the regime, session, and direction conditions under which the system is allowed to look, and outside which it is flat by definition.
2. 2Define the setup as a state with an expiry: what alignment arms a candidate, how many bars it stays armed, and what re-arms it after disarming.
3. 3Pin the trigger to one event: a specific close, cross, or break, precise enough that two implementations would fire on the same bar.
4. 4Build the exit as a first-class block: initial stop, target structure, and trailing rule, owned by the exit layer rather than scattered through entry logic.
5. 5Add the boundary plumbing: cooldowns after exits, one-position-at-a-time limits, and duplicate suppression between setup and trigger, the signal hygiene layer.
6. 6Test by ablation: run the system with each layer removed or replaced by a baseline, so the contribution of every role is measured instead of assumed.

How traders use it

• As a design template: writing a new system as filter, setup, trigger, exit forces explicit answers about regime, condition, timing, and management instead of one tangled entry condition that mixes all four.
• As a debugging frame: when a backtest degrades, ablating one layer at a time (run without the filter, loosen the trigger, fix the exit to a simple baseline) attributes the change to a specific role.
• As the natural home of signal hygiene: cooldowns, one-position-at-a-time limits, and duplicate suppression live between setup and trigger, where they are stated once instead of being patched into every rule.
• As the multi-timeframe skeleton: top-down systems map naturally onto the layers, filter from the higher frame, setup and trigger on the execution frame, which is the architecture behind most MTF alignment designs.
• As alert plumbing: the state machine's transitions translate directly into notification tiers via alerts and webhooks, setup-armed as the heads-up, trigger as the action alert, exit events as management calls, one alert per state change instead of indicator spam.

The architecture vs neighboring composition frameworks