Building a Prop Trading Automation Stack

Automating a futures strategy isn't really about finding one magic bot.

A reliable automation setup is usually a chain of smaller systems, each responsible for a different job.

One system identifies a trade. Another decides whether that trade should actually be taken. Another handles execution. And, if you're trading multiple accounts, another may distribute that execution across them.

At Spooky Trades, I think about this as a trading automation stack.

The basic architecture looks something like this:

Understanding those layers makes it much easier to build an automation setup that you can actually understand, troubleshoot and control.

1. The Signal Layer

Everything starts with something deciding that a potential trade exists.

That could be:

• a TradingView strategy;
• a TradingView indicator with alerts;
• a custom algorithm;
• a third-party strategy;
• your own software; or
• another system capable of sending structured trade signals.

The important distinction is that the signal layer doesn't necessarily need to execute anything.

Its job can simply be:

“I found a trade that matches the strategy.”

For example, Spooky's current stack begins with Wraith, Spooky Trades' signal engine.

Wraith identifies the setup and produces the signal. Finding a valid setup doesn't automatically mean that signal should be sent blindly all the way to the trading accounts.

That's where the next layer becomes useful.

2. The Intelligence Layer

This is the layer that's missing from many basic automation setups.

A common architecture looks like:

An alert fires and an order gets sent. Simple.

But there is another option:

Instead of treating every valid strategy signal identically, middleware can inspect the trade before it reaches the execution system.

That's the idea behind Poltergeist, the tool currently being built by Spooky Trades.

Poltergeist sits between a supported webhook source and receiver:

Its job isn't to find trades. Its job is to ask:

Should this particular trade go through, and if so, how?

A middleware layer can potentially evaluate things such as account risk, position sizing, stop distance, maximum contract size, signal validity, slippage from the intended entry, trading-session restrictions, duplicate signals, account state, market conditions and strategy-specific risk rules.

That list is the job of the layer — not a claim that every item is already implemented. Poltergeist's current work is more focused: inspecting supported signals, applying configured sizing and validation, then modifying, forwarding or rejecting what it receives.

Depending on the configured rule, the signal could then be:

This separates strategy logic from execution control. That distinction is one of the most useful ideas in the whole stack.

Built by Spooky

Poltergeist

IN DEVELOPMENT

Put intelligence between your signal and execution.

Poltergeist is webhook middleware for supported sources and receivers. It does not generate signals, place orders, or guarantee fills.

Meet Poltergeist

3. Why Separate Strategy From Risk?

Imagine a strategy produces exactly the same MNQ signal for two different accounts.

The trade itself hasn't changed.

But the appropriate position size might be completely different.

One account may have substantial drawdown room. Another might be approaching its loss limit. Another might already have reached the maximum risk you're willing to accept for the day.

Without middleware, that logic often ends up buried inside the strategy itself or configured separately across multiple systems.

A dedicated decision layer allows the strategy to continue saying:

“Here's the trade.”

while another system determines:

“Here's how we're willing to trade it.”

That becomes particularly useful with prop accounts, where the headline account balance often says very little about the amount of actual drawdown room available.

None of this is a prescription for how much risk to take. It is only an argument for keeping that decision somewhere you can see it.

4. The Execution Layer

Once a signal has survived whatever checks you've placed in front of it, something still needs to turn that instruction into execution.

That's the execution layer.

In Spooky's current setup, that role is handled by QuantCrawler Ghost. Ghost is part of the QuantCrawler ecosystem — not a Spooky Trades product.

QuantCrawler link may earn Spooky Trades a commission at no extra cost to you.

The flow becomes:

Wraith generates the trade signal. Poltergeist evaluates and can modify supported fields where configured. Ghost receives the approved webhook and handles the execution workflow.

Each tool has a clearly defined responsibility. That separation also makes troubleshooting much easier.

If something goes wrong, you can ask:

1. Did the strategy generate the signal?

   ↓

2. Did the middleware accept or reject it?

   ↓

3. Did the execution system receive it?

   ↓

4. Was the order placed?

Instead of staring at one giant black box wondering what happened.

5. The Distribution Layer

The final piece becomes important when trading multiple accounts.

Rather than running independent copies of an automation system against every account, a trader may use a lead account and trade copier.

The architecture then becomes:

Spooky's current setup is:

The trade copier handles the final distribution across accounts configured within the setup.

This means the strategy doesn't need to understand the entire account topology. Neither does the middleware. Each component does one job.

That modularity is one of the main advantages of this kind of architecture.

6. Why Not Just Connect Everything Directly?

You absolutely can.

For simple automation, this may be all you need:

Fewer components mean fewer potential failure points.

But simplicity comes with a trade-off: there are fewer places to apply control.

As the setup becomes more sophisticated — particularly with multiple prop accounts — you may want things like dynamic sizing, signal logging, execution protection, account-specific rules, validation, duplicate protection or session restrictions.

That's when an intermediate control layer starts becoming useful.

The goal should not be to create the most complicated automation stack possible. It should be to introduce complexity only where that complexity gives you meaningful control.

7. Observability Matters More Than It Sounds

There's another part of automation that doesn't get nearly as much attention as entries and strategies: knowing what the system actually did.

If a trade doesn't appear, you should ideally be able to determine why.

• Was there no signal?
• Was it rejected?
• Was its size changed?
• Did the webhook fail?
• Did the execution platform reject it?
• Did the copier fail to distribute it?

This is why signal history exists in Poltergeist rather than treating it purely as a webhook relay.

A good automation stack shouldn't merely execute trades. It should leave enough evidence behind that you can understand its decisions later.

8. Automation Doesn't Remove Risk

This is especially important with prop firms.

Automation can make execution more consistent. It can enforce configured rules more reliably. It can remove repetitive manual work.

But it can also make mistakes much faster.

A bad configuration manually executed once is a problem. A bad configuration automatically replicated across several accounts can become a much larger problem very quickly.

Automated traders still need sensible safeguards around things such as maximum position size, daily risk limits, duplicate orders, rejected signals, unexpected execution behavior, connection failures and configuration mistakes.

Automation does not guarantee profitability, execution quality or prop-firm compliance.

For firm-specific automation rules, see Which Prop Firms Actually Allow Automated Trading?

9. Build the Stack in Layers

If you're building an automation stack from scratch, don't connect everything at once.

Build it outward.

Stage 1 — Signal generation

Verify that the strategy produces the signals you expect.

Stage 2 — Webhook delivery

Verify that the exact payload reaches its destination reliably. The companion guide How Trading Webhooks Actually Work covers that path in more detail.

Stage 3 — Decision middleware

Add risk controls and filtering while logging what the system would have done.

Stage 4 — Execution

Confirm orders, quantities, stops and targets behave as expected.

Stage 5 — Trade copying

Only after the upstream system is stable should you distribute those trades across additional accounts.

The advantage of this approach is simple: when something breaks, you have a much smaller area to investigate.

The Spooky Stack

1. Signal

   Wraith

   Find the setup.

   ↓

2. Intelligence

   Poltergeist

   Inspect, size and moderate the signal.

   ↓

3. Execution

   Ghost

   Handle downstream webhook execution.

   ↓

4. Distribution

   Trade Copier

   Distribute execution.

   ↓

5. Destination

   Trading Accounts

   Where the approved trade finally lands.

Wraith and Poltergeist are built by Spooky Trades. Ghost and Trade Copier are part of the QuantCrawler ecosystem and currently handle downstream execution and distribution in Spooky's stack.

Importantly, Poltergeist is not intended to require Wraith or Ghost.

The broader architecture is:

Wraith → Poltergeist → Ghost → Trade Copier is simply Spooky's current real-world implementation. Integrations may require adapters, schemas or configuration.

Affiliate disclosure: this QuantCrawler link may earn Spooky Trades a commission at no extra cost to you.

Where Poltergeist Is Going

The first version is deliberately focused.

Rather than trying to build another strategy platform, charting package or trade copier, Spooky Trades is exploring the small space between strategy and execution.

That's where a lot of useful information exists.

The signal knows what the strategy wants to do. Configured account risk tells us how much exposure we're willing to take. Execution tells us what actually happened.

What exists today is narrower: supported-signal validation, risk-based sizing, reject-or-forward behavior, strategy profiles, and a history of those decisions. Ideas such as slippage protection or using broader market context to decide whether an environment is appropriate for a strategy are still exploratory — not shipped.

For now, the mission is much simpler:

Your strategy finds the trade. Poltergeist decides how — or whether — it reaches execution.

And then it gets out of the way.

Keep Building the Stack

If you're interested in the individual pieces, the other Spooky Trades guides dig deeper into prop-firm automation rules, how trading webhooks work, the middleware layer and Spooky's current stack.

Poltergeist itself is still in development, and more of the architecture will be documented as it evolves.

Related Guides