Case study 01
Human-Approved Trading Automation Framework
I designed a human-approved trading automation framework for strategies that need systematic monitoring without giving an automated process unlimited authority over capital.
The framework connects four jobs that are often handled separately: signal collection, strategy validation, execution control and post-trade reporting. The objective is not to make trading “hands-free.” It is to automate repetitive analysis while keeping consequential decisions visible and reversible.
This is a reusable operating pattern rather than a single strategy. I applied it across private tools for funding signals, perpetual markets and two-leg market-neutral setups.
The problem
A signal can look valid while the trade behind it is already unsafe or economically weak. Common failure points include:
- the price has moved since the signal was generated;
- liquidity is too thin for the intended exit;
- the next funding event is too close;
- available margin has changed;
- a paper-trading assumption does not match live exchange behavior;
- the bot records what it requested instead of what the venue actually executed;
- a strategy appears profitable only because the sample is small or the parameters were selected on the same data used to evaluate them.
Automating the order alone would make these problems faster, not safer.
What I built
I structured the workflow as a controlled decision pipeline:
- 1
Signal intake
Receive structured signals and collect the relevant market context.
- 2
Pre-trade filters
Check listing availability, time to funding, order-book depth, spread and other strategy-specific conditions.
- 3
Decision card
Send a compact Telegram summary showing the setup, assumptions and available actions.
- 4
Human approval
Require an explicit Approve or Skip decision where the workflow carries material risk.
- 5
Freshness recheck
Before execution, re-read price, margin, venue status and position limits instead of trusting the original card.
- 6
Execution and monitoring
Track open positions, exits, partial failures and unresolved exposure.
- 7
Post-trade reporting
Separate paper and live records, preserve cohorts after rule changes and report actual fills rather than planned prices.
Where the freshness rule came from
The freshness recheck is not a precaution I designed in advance. It is the fix for an incident.
On 21 August I approved a BTC short the system had generated the previous evening. The card had been sitting in the chat for about ten hours. The approval handler refreshed the entry price at the moment of the tap, which felt like enough. It was not: the stop and the target were still the ones calculated the night before, and price had moved far enough that the stored stop now sat on the wrong side of the current entry.
The exchange rejected the stop as invalid — and opened the market short anyway. For a while the position was live with take-profit orders attached and no stop at all. The local tracker then recorded the trade as closed by a stop-loss that had never existed on the venue. The position had to be closed by hand.
Three changes came out of it. Approval now re-scans the market at click time and requires a fresh, still-valid setup in the same direction; if there isn't one, the card is marked stale and no trade opens. Levels are validated before the entry order rather than after, and if the stop cannot be placed once the position is open, the position is closed immediately instead of being left to run. And notifications now state outright whether a card is paper or live, because in the middle of the incident that was genuinely unclear.
The uncomfortable part is that nothing in the system was broken. Every piece did what it was written to do. The failure was in the seam between a decision made at one moment and an execution that happened at another — which is precisely the gap the approval step exists to cover, and precisely the gap it was not covering.
Guardrails
Human control
The operator controls whether a setup is allowed to move from analysis to execution. Approval is not treated as permission to bypass risk checks: the system validates the setup again at the moment of action.
The framework also separates manual controls by purpose. Pausing new signals does not stop monitoring existing positions. Closing positions, skipping pending ideas and disabling a venue are distinct actions, so one control cannot silently change unrelated parts of the workflow.
Risk controls
The framework includes:
- explicit paper/live separation;
- approval-gated actions for risk-bearing workflows;
- stale-signal and changed-condition checks;
- liquidity and time-to-event filters;
- position and margin limits;
- duplicate and double-click protection;
- monitoring for partial or failed execution;
- visible unresolved-position states;
- cohort-based statistics after strategy changes;
- alerts when the system is idle for an operational reason rather than because no opportunities exist.
A core design rule is that venue state is more reliable than the bot’s internal record. Position reconciliation, actual fills and live balances take precedence over the original execution plan.
Validation and result
The framework was useful not only for executing ideas, but also for disproving them.
In one strategy review, a minute-bar simulator was reconciled against 88 live outcomes and matched 84 of them, with an average difference of approximately 0.03 percentage points per trade. That gave enough confidence to test a wider parameter space.
The broader test showed that all 72 long-side take-profit and stop-loss combinations remained unprofitable on the available sample. Changing exits did not repair the underlying signal. The correct operational decision was therefore not to optimize harder, but to question the thesis and continue with a controlled paper track rather than scaling live risk.
Additional analysis identified liquidity and proximity to funding as more useful filters than price-pattern features. Even then, the remaining positive subgroup was treated as a hypothesis, not proof, because statistical confidence was still weak.
The main result was a better decision process: strategy changes became measurable, reversible and separated into clean cohorts instead of being judged by a few recent trades.
My role
I defined the operating logic, approval UX, risk boundaries, testing questions and reporting requirements. I also reviewed live outcomes against system assumptions, identified failure modes and translated them into controls and regression tests.
My audit and ERP-testing background shaped the approach: trace the full process, reconcile records to the external source of truth and test what happens when one step fails quietly.
Stack
- Python
- Telegram Bot API
- Exchange APIs
- SQLite
- Market-data pipelines
- Statistical testing
- systemd
Proof
Private repositories — they hold live exchange keys, so the code stays closed. What is described above is the production design, not a proposal.
Key lesson
Automation does not create an edge. It creates a more reliable way to test whether an edge exists — and a safer way to stop when the evidence is not strong enough.