TRADING SYSTEMS
An idea becomes a rule.
The rule gets tested.
Our work connects strategy research, historical testing and trading bot development. Each stage asks a different question before a system progresses.
01 — STRATEGY SPECIFICATION
Write down the decision.
Inputs & eligibility
Define the market observations and economic information the rule can use, including timing, source and missing-data conditions.
Entry & invalidation
Specify what triggers an entry and when that signal expires or becomes invalid. Record the eligible instrument and trading hours.
Exposure & exit
Define position sizing, maximum exposure and exit conditions. An entry rule alone is not a complete trading system.
Version & configuration
Keep the rule set, model version and parameter choices together. A later change should create a separately assessable research version.
02 — STRATEGY LAB
Understand the historical behaviour.
The intended testing workflow combines eligible historical inputs, explicit execution assumptions and time-ordered evaluation.
Move forward through time.
The training history grows at each step. Evaluation always uses a later period, with preprocessing fitted only on the eligible training sample.
A workflow illustration, not a report of actual model results. Production experiments need source-specific timing rules and suitable gaps between samples.
Costs belong in the experiment.
Record spread, commission, slippage and fill assumptions. Study sensitivity to less favourable conditions instead of selecting a single optimistic estimate.
Explain the result.
Retain the evaluation dates, sample size, trade count, exposure, turnover, drawdown and net results after modelled costs. State what was changed between experiments.
03 — EXECUTION ENGINE
Research and operation have different failure modes.
Simulate the decisions
Evaluate how the rule behaves with incoming observations, late data and repeated signals before it is considered for an execution environment.
Paper trade the workflow
Assess order handling and operational behaviour using simulated orders. Check the full decision path rather than only the model output.
Review execution controls
Evaluate position checks, rejected orders, connection loss and manual stop behaviour as a separate part of development.
Retain the decision trail
The planned execution record connects each decision to its input snapshot, rule version, risk check and order outcome.
The execution features described here are development objectives. This website does not offer a live broker execution service.
04 — CONTROL DESIGN
Give a system clear boundaries.
Data freshness
Check whether the inputs are recent enough for the rule. A stale input should produce an explicit state rather than a silent trading decision.
Position limits
Evaluate order size and aggregate exposure against defined limits before an order is considered for submission.
Duplicate protection
Track the decision and order identifiers so repeated signals or retries can be distinguished from a new intended order.
Recovery behaviour
Reconcile the system’s view of positions and orders before resuming after an interruption.
Manual stop
Provide a clear operator control and record why execution was paused. Restarting requires a defined review of system state.