Would a node-based workflow for automated trading be useful?

New comment
 
Hello everyone,
I’m currently exploring an idea for automated / quant trading.
The concept is a node-based workflow where users define:

market data → indicators/features → signal → risk rule → execution → monitoring

The framework would then handle the operational parts around it:
  • data preparation
  • backtesting
  • dry-runs / paper trading
  • execution logs
  • risk checks
  • live monitoring
I’m not asking anyone to share their strategy or alpha.

I’m mainly curious:
  1. Is the bigger pain building the strategy logic, or operating/testing it properly?
  2. Would a node-based workflow be useful, or would you prefer pure Python/code?
  3. Which part would you want automated first: data prep, backtesting, dry-run, monitoring, or execution logs?
Any feedback would be appreciated. Thank you for reading this!
 
PLUTO:
Hello everyone,
I’m currently exploring an idea for automated / quant trading.
The concept is a node-based workflow where users define:

market data → indicators/features → signal → risk rule → execution → monitoring

The framework would then handle the operational parts around it:
  • data preparation
  • backtesting
  • dry-runs / paper trading
  • execution logs
  • risk checks
  • live monitoring
I’m not asking anyone to share their strategy or alpha.

I’m mainly curious:
  1. Is the bigger pain building the strategy logic, or operating/testing it properly?
  2. Would a node-based workflow be useful, or would you prefer pure Python/code?
  3. Which part would you want automated first: data prep, backtesting, dry-run, monitoring, or execution logs?
Any feedback would be appreciated. Thank you for reading this!

"Node-Based" workflow. Never heard of that before, but what you are describing is pretty standard no matter if its MQL5, Python or any other language. 

A heads-up: Since you are using some sort of an AI, it would be much preferrable to use AI as your tool rather than asking it to come up with stuff such as "node-based". You have reference implementations, open source programs all available to guide you what you want to achieve. Using that to understand what you want is far more beneficial than coming up with "novel" approaches since this well trodden ground

 
PLUTO:
Hello everyone,
I’m currently exploring an idea for automated / quant trading.
The concept is a node-based workflow where users define:

market data → indicators/features → signal → risk rule → execution → monitoring

The framework would then handle the operational parts around it:
  • data preparation
  • backtesting
  • dry-runs / paper trading
  • execution logs
  • risk checks
  • live monitoring
I’m not asking anyone to share their strategy or alpha.

I’m mainly curious:
  1. Is the bigger pain building the strategy logic, or operating/testing it properly?
  2. Would a node-based workflow be useful, or would you prefer pure Python/code?
  3. Which part would you want automated first: data prep, backtesting, dry-run, monitoring, or execution logs?
Any feedback would be appreciated. Thank you for reading this!

Based on hands-on experience with signal-only systems, here's what I'd say:

The bigger pain is operational. Once you have a working signal (indicator/feature pipeline → entry/exit rules), the real friction isn't tweaking the logic — it's:

  • Backtesting accurately (slippage, commissions, freeze levels, order rejection rules matter way more than people think)
  • Dry-run → live gap (paper trading and live execution surface edge cases your backtest missed)
  • Monitoring & risk checks (a signal that works in 2023 can blow up in 2024; you need live dashboards + circuit breakers, not just trades)
  • Data pipelines (stale feeds, gaps, weekends, broker API quirks)

Strategy logic is maybe 20% of the work. The other 80% is getting it to run reliably in production.

Node-based vs code: depends on your audience. For quants who code (Python/C++), node-based adds friction — they'd rather define it in code. For non-coders, visual workflow is a win. My take: offer both. Start with code, let power users export node definitions, but don't force visual-first.

Automate in this order:

  1. Backtesting (biggest ROI; accurate backtest saves weeks of debugging)
  2. Dry-run (paper trading on real feeds catches the gaps backtest missed)
  3. Execution logs & monitoring (you need to see what's failing in real time)
  4. Data prep (important, but most of the pain is already in #1-3)

The systems that work best don't have fancy logic — they have rock-solid backtesting, tight risk rules, and live monitoring. Automate that, and the node-based UI becomes a nice bonus, not a necessity.

New comment