Most trading automation fails in the same place: the risk rules live in the trader's head, not in the code. "I'll cut it if it moves against me." "I won't hold more than a few positions." Under pressure, those intentions bend. So I built a trading engine where the risk rules are enforced by the software and there's no polite way around them.
It's called Apex Wallet. Here's the design idea.
Rules are code, not suggestions
Every incoming signal is checked against hard limits before anything executes:
- Max positions — the engine refuses to open beyond the cap.
- Portfolio-heat cap — total risk exposure is bounded; a trade that would breach it is rejected.
- Instant kill switch — one action halts execution entirely.
The point is that these aren't dashboards you're supposed to watch. They're gates in the execution path. A trade that violates a limit doesn't get a warning — it doesn't happen.
Pluggable brokers: paper-to-live is a config change
Execution goes through a broker abstraction with interchangeable backends — yfinance, ccxt, Alpaca. Paper trading and live trading are the same code path with a different adapter, so moving from simulation to real money is a configuration change, not a rewrite. That matters because the risk logic you tested in paper is literally the same logic running live.
Auditability by default
Every decision is journaled. When something surprising happens, you can reconstruct exactly what the engine saw and why it acted — which signal came in, which checks passed, what executed. A trading system you can't audit is a trading system you can't trust.
There's also a CLI and a local browser dashboard showing live positions and portfolio heat, so the state of the system is always visible.
The architecture lesson (beyond trading)
This pattern generalizes past finance: when a constraint really matters, encode it as a gate in the execution path, not as a guideline in a runbook. Separate the thing that decides (signals) from the thing that enforces (risk checks) from the thing that acts (brokers). Each is testable in isolation, and the enforcement layer can't be skipped because it sits between decision and action.
Takeaway
Automation you can trust comes from making the important rules unbreakable in code, keeping the risky boundary (paper vs. live) a config flag over identical logic, and journaling everything so it's auditable. That's the pattern — the trading part is just the example.
If you want me to go deeper on the portfolio-heat calculation or the broker abstraction, let me know in the comments.
Top comments (0)