Lucitech Quant Research
Quantitative Research in Foreign Exchange Markets
This section is a living record of practical research into systematic decision rules for trading under uncertainty. The emphasis is empirical discipline, engineering rigour, telemetry, and reproducible validation — not “holy grails”, hindsight narratives, or claims of finished alpha.
Research Programme
The work is organised around the development of an Alpha Discovery Workbench: a repeatable engineering process for generating, screening, validating, and eventually promoting candidate trading configurations under controlled research conditions.
The current focus is a practical time-series problem: how to identify statistically credible, interpretable decision rules from noisy FX market data while reducing leakage, overfitting, and self-deception.
Candidate Discovery
Systematic parameter search and backtest telemetry are used to surface candidate configurations across instruments and timeframes.
SQL Diagnostics
Candidate runs are analysed through persisted trade-level data, including year, month, direction, session, spread, volatility, and outcome distributions.
Cluster & Veto Analysis
Feature-space clustering and walk-forward validation are used to test whether good or bad cohorts repeat outside the discovery window.
Execution Retest
Eligible gates or vetoes are implemented in the strategy code and retested through the execution engine before any demo-live promotion decision.
Validation Principles
To reduce false discovery in time-series research, the workflow emphasises controls that separate discovery from validation.
- Purged and embargoed walk-forward splits
- Strict separation of decision-time features from future-dependent labels
- Block bootstrap uncertainty where autocorrelation matters
- Multiple-testing discipline across large candidate spaces
- Run provenance linking parameter sets, code versions, run IDs, pass numbers, and result summaries
- Execution-engine retesting after research rules are converted into code
Where helpful, concise mathematical notation is used to make the validation problem explicit. For example, a trade-outcome label may be represented as:
yi = 1{hit +X before -Y within horizon H}
The purpose of notation is not to make the work appear more complex. It is used where it clarifies the exact object being measured.
Research Stack
The research environment is built as an auditable engineering workflow rather than an isolated spreadsheet or one-off backtest.
Strategy & Backtesting
JForex-based FX strategy development, systematic backtesting, run identifiers, pass numbers, and strategy telemetry.
Data & Persistence
PostgreSQL-backed storage for backtest runs, trade logs, trade events, summary metrics, and downstream analytical views.
Discovery & Analytics
Optuna-driven hyperparameter search, SQL diagnostics, HDBSCAN-style cluster analysis, walk-forward testing, and veto eligibility analysis.
Engineering Control
GitLab CI/CD, Docker/VPS deployment workflows, Confluence and Jira for engineering documentation, delivery management, and backlog control.
The working thesis is that durable value may come not only from any individual strategy configuration, but from the repeatable process used to generate, screen, validate, monitor, and retire candidate configurations.
Alpha Discovery Workbench
The Alpha Discovery Workbench is the name used for the emerging research and engineering system. It is not a claim that every surfaced candidate is deployable. It is a controlled pipeline for moving from broad discovery to evidence-ranked validation.
Optuna candidate run_id
→ PostgreSQL backtest summary
→ SQL diagnostic extraction
→ HDBSCAN feature-space clustering
→ walk-forward / embargo validation
→ veto eligibility scorecard
→ Java implementation
→ coded retest
→ demo-live promotion decision
The current discovery stage has produced a credible queue of candidate configurations worthy of deeper validation. Those candidates remain research-stage outputs until they survive the later validation stages.
Research Sequence
| Stage | Artefact | Purpose | Status |
|---|---|---|---|
| Methodology | White Paper Part 1 | Defines the stage-gating, walk-forward, bootstrap, and anti-overfit framework. | Published |
| Pipeline implementation | Research Note 001 | Shows how the validation framework is translated into a telemetry and promotion workflow. | Published |
| Candidate discovery | Research Note 002 | Documents Optuna candidate surfacing across FX mean-reversion strategy configurations. | Published / evolving |
| Validation and promotion | Future research notes | SQL diagnostics, cluster validation, veto eligibility, coded retests, and demo-live promotion. | In progress |
White Papers
Stage Gating for Robust FX Strategy Research: A Purged Walk-Forward + Bootstrap Framework
Status: Published living document | Version: 1.0 | Last updated: 3 February 2026
This paper defines the research framework used to evaluate candidate rules under leakage controls, purged walk-forward validation, bootstrap uncertainty, and disciplined promotion criteria.
Research Notes
Short technical updates tied to specific experiments or implementation steps. Each note is written in the form: what was tested, what held up, what failed, and what comes next.
From Framework to Pipeline: Implementing the Stage-Gating Loop
Status: Published | Format: slide research note
Shows how the research framework is implemented as a telemetry-driven pipeline for veto discovery, validation, promotion, and reproducibility.
Building an Alpha Discovery Workbench: Optuna Candidate Surfacing Across FX Mean-Reversion Strategies
Status: Published / evolving | Format: research note
Documents the discovery layer of the Alpha Discovery Workbench: Optuna candidate surfacing, persisted backtest telemetry, and database-driven screening across FX mean-reversion configurations.
Read Research Note 002
Appendix A — Optuna Dashboard Artefacts
Cluster Validation, Veto Eligibility, and Execution Retesting
Status: In progress
Future notes will document SQL diagnostics, HDBSCAN feature-space analysis, walk-forward validation, veto scorecards, coded retests, and demo-live promotion decisions.
Feedback
I welcome specific technical feedback, especially around:
- leakage controls and decision-time feature validity
- validation design and multiple-testing discipline
- cost, spread, slippage, execution assumptions, and failure modes
- candidate-scorecard design and promotion criteria
To keep this sustainable, I cannot respond to open-ended trading questions. A useful message contains one concrete critique, question, or suggestion.
Contact: research@lucitech.co.uk
Disclaimer
This material is provided for information, research, and technical discussion only. It is not financial advice, investment advice, a trading recommendation, or an invitation to invest. Foreign exchange trading carries significant risk. Past or simulated performance is not a reliable indicator of future results. Markets can change without warning, and live execution costs may materially affect outcomes.