Our Approach
Start with the problem. Engineer the solution.
Systematic trading involves more than finding a strategy that looks profitable.
Research needs to be rigorous. Data needs to be reliable. Software needs to behave as intended. Execution, risk and monitoring need to be considered from the beginning.
The challenge is connecting all these pieces into a coherent system.
Capital in the Wild applies an engineering approach to systematic trading: define the problem, establish what the evidence supports, design the boundaries, build only what is needed, and validate the result against real operating constraints.
01 — Define the problem
Before choosing technology or rebuilding code, establish what actually needs to be solved.
What are you trying to test, build or improve? What assumptions does the current approach depend on? What would a useful outcome look like? Which constraints are real and which are merely inherited from the current implementation?
A clear problem boundary prevents complexity from becoming a substitute for progress.
02 — Separate evidence from assumption
A backtest can be useful without proving what people often think it proves.
We distinguish what has been demonstrated from what is assumed, estimated or still unknown. That means examining research methodology, data quality, transaction costs, execution assumptions, robustness and the possibility of overfitting before stronger conclusions are drawn.
Sometimes better engineering strengthens an idea. Sometimes it shows that the idea is weaker than expected. Discovering that early is a useful result.
03 — Design the system before complexity grows
A systematic trading operation brings together data, research, portfolio logic, execution, risk controls and monitoring.
Those responsibilities should be explicit. Interfaces should be understandable. Research code should not quietly become production infrastructure. Data collection should not decide trading policy. Monitoring should not be an afterthought.
Good architecture makes the important decisions visible before they become expensive to change.
04 — Build for the real operating environment
Backtests live in unusually hospitable environments. Live systems do not.
Broker limitations, minimum position sizes, missing data, rejected orders, market hours, transaction costs, stale processes and software failure all matter once a system leaves research.
Reliability is therefore part of the design, not something added after the strategy works.
05 — Validate behaviour, not just output
A system can produce plausible numbers while behaving incorrectly internally.
Testing should establish not only that a result appears sensible, but that the right data was used, the intended logic ran, failure states are controlled, outputs can be reconciled and the system can explain what it did.
The goal is confidence grounded in evidence rather than confidence grounded in a clean equity curve.
06 — Keep scope and trade-offs explicit
Not every problem needs a custom platform. Not every system needs more automation. Not every weak strategy deserves further optimisation.
We define what is being solved, what will be delivered and what remains outside the engagement. Technical decisions should account for their cost, limitations and operational consequences.
Simplicity is a feature when it solves the actual problem.
The principles underneath the work
Evidence before confidence
We distinguish demonstrated facts from assumptions, estimates and unknowns.
Simplicity before unnecessary complexity
A system should be no more complicated than the problem requires.
Reliability is part of the design
Testing, data quality, execution constraints, risk controls and monitoring belong in the architecture from the beginning.
Clear scope and explicit trade-offs
Every solution has boundaries. They should be visible and deliberate.
No promises of returns
Engineering can improve research and implementation. It cannot guarantee a profitable strategy or eliminate market risk.