From Zero to One: Building Your First US Equity Quant Strategy

The first quantitative strategy does not need to predict the market. It needs to make one small, measurable claim—and then show you whether the data supports it.

A programmer can spend weeks collecting indicators, downloading datasets, and experimenting with frameworks before ever answering the most important question: What would this strategy have done historically, after reasonable trading costs?

That is the practical starting point. The goal of this article is to take you from raw market data to a tested moving-average strategy, with every important engineering decision visible along the way.

You will build a small system that downloads US equity OHLCV data, generates a simple crossover signal, avoids look-ahead bias, applies transaction costs, and produces an equity curve with basic performance statistics. The strategy is intentionally modest. Its purpose is to establish a reliable research loop before you add complexity.

1. Why the First Strategy Should Be Boring

A first strategy should isolate one variable and expose the full research lifecycle.

That lifecycle has four stages:

1. Acquire clean historical market data.
2. Define a signal without using future information.
3. Simulate entries, exits, slippage, and commissions.
4. Inspect both the equity curve and the individual trades.

The moving-average crossover is useful for this purpose because its logic is transparent. A fast moving average indicates recent price momentum, while a slow moving average represents a longer-term trend. A crossover creates a position, and a subsequent cross-in-the-opposite-direction creates an exit.

The strategy does not have to be profitable. It has to be correct enough that you can trust the result and improve it systematically.

A reasonable starting specification is:

• Trade a liquid US equity.
• Use daily OHLCV bars.
• Enter long when the 20-day moving average crosses above the 50-day moving average.
• Exit when the 20-day moving average crosses below the 50-day moving average.
• Apply a fixed slippage and commission assumption per trade.
• Evaluate the result across multiple market regimes.

This gives us a baseline rather than a finished trading system.

2. The Problem: Data Can Look Correct and Still Be Wrong

Most first backtests fail because the data pipeline is wrong, not because the signal is wrong.

For example, if the strategy uses the closing price of day t to decide whether to enter on day t, the backtest contains look-ahead bias. The system cannot know the final closing price until after the session ends.

The safest basic assumption is:

Use information available at the close of one session, and apply the resulting signal to the next session.

We also need to account for trading friction. A gross return of 12% can become a disappointing net return after repeated small costs, especially when a strategy trades frequently.

The following table illustrates the effect of a 10-basis-point slippage assumption on a round-trip trade. These numbers are educational examples, not measured market results.

Trade assumption	Gross return per trade	Round-trip slippage	Net return before commission
Low-friction assumption	1.00%	0.10%	0.90%
Moderate-friction assumption	1.00%	0.25%	0.75%
High-friction assumption	1.00%	0.50%	0.50%

A second common error is mixing incompatible timestamps. A daily bar labeled with its opening date may represent the entire session, while an API may also expose the bar's close time. The backtester must treat the bar as information that becomes available only after the bar closes.

The rule for this implementation is simple:

• fast_ma[t] and slow_ma[t] use data through the close of bar t.
• The position for bar t + 1 is based on the signal calculated at t.
• No current-bar close is used to fill a current-bar trade.

That rule prevents the most common form of accidental lookahead.

3. System Architecture: From API to Equity Curve

The strategy can be represented as a small pipeline. Each layer has one responsibility.

┌─────────────────────────────┐
│ TickDB market data API      │
│ GET /v1/market/kline        │
└──────────────┬──────────────┘
               │ OHLCV bars
               ▼
┌─────────────────────────────┐
│ Data normalization          │
│ timestamps, OHLCV, sorting   │
└──────────────┬──────────────┘
               │ clean DataFrame
               ▼
┌─────────────────────────────┐
│ Signal engine               │
│ 20-day / 50-day crossover    │
└──────────────┬──────────────┘
               │ lagged position
               ▼
┌─────────────────────────────┐
│ Backtest engine              │
│ next-bar execution + costs  │
└──────────────┬──────────────┘
               │ trades and equity curve
               ▼
┌─────────────────────────────┐
│ Visualization and metrics    │
│ equity, drawdown, trade stats │
└─────────────────────────────┘

The separation matters. If data retrieval, signal generation, and execution simulation live in one large function, it becomes difficult to identify whether a result changed because of the data, the strategy, or the accounting code.

We will keep the first implementation in one script for accessibility, but organize it into clearly separated functions.

Strategy logic

The strategy uses two moving averages:

fast_ma = rolling mean of close over 20 sessions
slow_ma = rolling mean of close over 50 sessions

position[t] = 1 if fast_ma[t-1] <= slow_ma[t-1]
              and fast_ma[t] > slow_ma[t]
              2 if fast_ma[t-1] >= slow_ma[t-1]
              and fast_ma[t] < slow_ma[t]
              otherwise 0

The signal is then shifted by one bar before it becomes the return-bearing position.

4. Production-Grade Data Acquisition

We will use the GET /v1/market/kline endpoint for historical OHLCV data. TickDB supports more than 10 years of cleaned and aligned US equity OHLCV history, which makes it suitable for testing across multiple market conditions.

The API key must be loaded from an environment variable. Do not hardcode credentials in a script, commit them to Git, or place them in a URL for REST requests.

export TICKDB_API_KEY="your_api_key_here"

The following implementation includes:

• Environment-variable authentication.
• A timeout on every HTTP request.
• Exponential backoff with jitter.
• Handling for rate-limit error code 3001.
• Explicit errors for invalid API keys and unknown symbols.
• A normalized DataFrame with sorted timestamps.
• A check for duplicate timestamps.

import os
import random
import time
from datetime import datetime, timezone
from typing import Any

import pandas as pd
import requests


API_BASE_URL = "https://api.tickdb.ai"
API_KEY = os.environ.get("TICKDB_API_KEY")

if not API_KEY:
    raise RuntimeError(
        "TICKDB_API_KEY is not set. Export it before running the script."
    )


def _handle_api_error(
    response: requests.Response,
    payload: dict[str, Any] | None = None,
    symbol: str | None = None,
) -> None:
    """Raise a useful exception for an unsuccessful TickDB response."""
    payload = payload or {}
    code = payload.get("code", 0)

    if code in (1001, 1002):
        raise ValueError(
            "Invalid or missing API key. Check TICKDB_API_KEY."
        )

    if code == 2002:
        raise KeyError(
            f"Symbol {symbol!r} was not found. "
            "Verify it through /v1/symbols/available."
        )

    if code == 3001:
        retry_after = int(response.headers.get("Retry-After", "5"))
        time.sleep(retry_after)
        raise RuntimeError(
            f"Rate limit exceeded. Retry after {retry_after} seconds."
        )

    message = payload.get("message", response.text)
    raise RuntimeError(f"Unexpected TickDB API error {code}: {message}")


def fetch_kline(
    symbol: str,
    start: str,
    end: str,
    interval: str = "1d",
    limit: int = 5000,
    max_retries: int = 5,
) -> pd.DataFrame:
    """
    Download historical OHLCV bars from TickDB.

    The function assumes the API returns a top-level object with a
    `data` list. Field names are normalized here so the rest of the
    strategy does not depend on the raw response structure.
    """
    url = f"{API_BASE_URL}/v1/market/kline"
    headers = {"X-API-Key": API_KEY}

    params = {
        "symbol": symbol,
        "interval": interval,
        "start": start,
        "end": end,
        "limit": limit,
    }

    for attempt in range(max_retries):
        try:
            response = requests.get(
                url,
                headers=headers,
                params=params,
                timeout=(3.05, 15),
            )

            try:
                payload = response.json()
            except ValueError as exc:
                raise RuntimeError(
                    "TickDB returned a non-JSON response."
                ) from exc

            if response.status_code == 429 or payload.get("code") == 3001:
                retry_after = int(
                    response.headers.get("Retry-After", str(2 ** attempt))
                )
                time.sleep(retry_after)
                continue

            if not response.ok:
                _handle_api_error(response, payload, symbol)

            rows = payload.get("data")
            if not isinstance(rows, list) or not rows:
                raise RuntimeError(
                    f"No OHLCV data returned for {symbol!r}."
                )

            frame = pd.DataFrame(rows)
            frame = frame.rename(
                columns={
                    "t": "timestamp",
                    "time": "timestamp",
                    "timestamp": "timestamp",
                    "o": "open",
                    "h": "high",
                    "l": "low",
                    "c": "close",
                    "v": "volume",
                    "open": "open",
                    "high": "high",
                    "low": "low",
                    "close": "close",
                    "volume": "volume",
                }
            )

            required = {"timestamp", "open", "high", "low", "close", "volume"}
            missing = required.difference(frame.columns)
            if missing:
                raise RuntimeError(
                    f"Missing expected OHLCV fields: {sorted(missing)}"
                )

            frame["timestamp"] = pd.to_datetime(
                frame["timestamp"], utc=True
            )

            numeric_fields = ["open", "high", "low", "close", "volume"]
            frame[numeric_fields] = frame[numeric_fields].apply(
                pd.to_numeric, errors="raise"
            )

            frame = frame.sort_values("timestamp").drop_duplicates(
                subset=["timestamp"], keep="last"
            )

            return frame[["timestamp", *numeric_fields]].reset_index(
                drop=True
            )

        except (requests.Timeout, requests.ConnectionError) as exc:
            if attempt == max_retries - 1:
                raise RuntimeError(
                    f"Network request failed after {max_retries} attempts."
                ) from exc

            base_delay = min(2 ** attempt, 30)
            jitter = random.uniform(0, base_delay * 0.1)
            time.sleep(base_delay + jitter)

    raise RuntimeError("Unable to download market data.")

One important implementation detail is the retry delay. A fixed delay can cause many clients to retry simultaneously after a temporary outage. Exponential backoff with random jitter reduces that coordination problem.

The function also distinguishes between an authentication error, an invalid symbol, and a temporary rate limit. Those conditions should not be handled identically. An invalid API key will not fix itself after a sleep; a rate-limit condition usually will.

5. Signal Generation Without Look-Ahead Bias

The signal engine should be deterministic and easy to inspect. We will calculate the moving averages, identify crossings, and then explicitly shift the position by one session.

def moving_average_crossover(
    frame: pd.DataFrame,
    fast_window: int = 20,
    slow_window: int = 50,
) -> pd.DataFrame:
    """Create a long-only moving-average crossover signal."""
    data = frame.copy()

    data["fast_ma"] = data["close"].rolling(
        window=fast_window, min_periods=fast_window
    ).mean()
    data["slow_ma"] = data["close"].rolling(
        window=slow_window, min_periods=slow_window
    ).mean()

    data["signal"] = 0
    data.loc[
        (data["fast_ma"] > data["slow_ma"])
        & (data["fast_ma"].shift(1) <= data["slow_ma"].shift(1)),
        "signal",
    ] = 1
    data.loc[
        (data["fast_ma"] < data["slow_ma"])
        & (data["fast_ma"].shift(1) >= data["slow_ma"].shift(1)),
        "signal",
    ] = -1

    # A signal calculated at the close of t can affect only t + 1.
    data["position"] = data["signal"].shift(1).fillna(0)
    data["position"] = data["position"].clip(lower=0)

    data["crossover"] = (
        data["fast_ma"].notna()
        & data["slow_ma"].notna()
        & (data["fast_ma"].shift(1) <= data["slow_ma"].shift(1))
        & (data["fast_ma"] > data["slow_ma"])
    )

    return data

The signal column represents the desired action after the current bar closes. The position column represents the position carried into the next bar.

The clip(lower=0) operation makes the strategy long-only. If you later add short selling, you must also define borrow costs, margin requirements, and the treatment of overnight positions.

A useful test is to deliberately shift the signal in the wrong direction and confirm that the performance changes. A backtest that produces nearly identical results with and without a one-bar lag usually indicates that the strategy is not actually using the intended signal—or that the tested period contains too few trades for the difference to matter.

6. Backtesting with Costs and Trade Statistics

The backtest below calculates returns from the position held during each session. It then estimates transaction costs from changes in the position.

The execution assumption is deliberately conservative and simple:

• A position change is executed at the next bar's open.
• Buy and sell prices are adjusted by fixed basis-point slippage.
• Commission is charged per side.
• The strategy remains in cash when the position is zero.

The exact execution model will differ across assets and brokers, but this model is useful for a first baseline because it is explicit rather than hidden.

import numpy as np


def run_backtest(
    data: pd.DataFrame,
    initial_capital: float = 10_000.0,
    slippage_bps: float = 5.0,
    commission_bps: float = 0.5,
) -> tuple[pd.DataFrame, pd.DataFrame]:
    """
    Run a next-bar-open backtest with fixed fractional costs.

    Returns:
        results: Daily results including equity and drawdown.
        trades: One row per completed round trip.
    """
    results = data.copy().reset_index(drop=True)

    results["asset_return"] = results["close"].pct_change().fillna(0.0)
    results["gross_return"] = results["position"] * results["asset_return"]

    position_change = results["position"].diff().fillna(0.0)
    results["turnover"] = position_change.abs()

    slippage_rate = slippage_bps / 10_000.0
    commission_rate = commission_bps / 10_000.0

    results["cost"] = (
        results["turnover"]
        * (slippage_rate + commission_rate)
    )
    results["net_return"] = results["gross_return"] - results["cost"]

    results["equity"] = initial_capital * (
        1.0 + results["net_return"]
    ).cumprod()
    results["peak_equity"] = results["equity"].cummax()
    results["drawdown"] = (
        results["equity"] / results["peak_equity"] - 1.0
    )

    trades = []
    entry_index = None
    entry_price = None

    for i, row in results.iterrows():
        if row["position"] == 1 and entry_index is None:
            entry_index = i
            entry_price = row["open"]

        elif row["position"] == 0 and entry_index is not None:
            exit_price = row["open"]
            gross_trade_return = (
                exit_price / entry_price - 1.0
            )
            trades.append(
                {
                    "entry_date": results.loc[
                        entry_index, "timestamp"
                    ],
                    "exit_date": row["timestamp"],
                    "entry_price": entry_price,
                    "exit_price": exit_price,
                    "gross_return": gross_trade_return,
                    "bars_held": i - entry_index,
                }
            )
            entry_index = None
            entry_price = None

    trade_frame = pd.DataFrame(trades)
    return results, trade_frame

The trade table is useful because aggregate metrics can hide poor trade behavior. A strategy can have a positive Sharpe ratio while producing a small number of trades, long losing streaks, or highly variable holding periods.

The following function calculates the metrics that should be recorded for every baseline experiment.

def calculate_metrics(
    results: pd.DataFrame,
    trades: pd.DataFrame,
    periods_per_year: int = 252,
) -> dict[str, float]:
    """Calculate a compact set of backtest performance statistics."""
    returns = results["net_return"]

    total_return = results["equity"].iloc[-1] / results["equity"].iloc[0] - 1.0
    years = max(len(returns) / periods_per_year, 1 / periods_per_year)

    annualized_return = (1.0 + total_return) ** (1.0 / years) - 1.0
    annualized_volatility = returns.std(ddof=1) * np.sqrt(periods_per_year)

    sharpe = (
        annualized_return / annualized_volatility
        if annualized_volatility > 0
        else np.nan
    )

    downside = returns[returns < 0].std(ddof=1) * np.sqrt(periods_per_year)
    sortino = (
        annualized_return / downside
        if pd.notna(downside) and downside > 0
        else np.nan
    )

    max_drawdown = results["drawdown"].min()

    if trades.empty:
        win_rate = np.nan
        profit_factor = np.nan
    else:
        wins = trades.loc[trades["gross_return"] > 0, "gross_return"]
        losses = trades.loc[trades["gross_return"] < 0, "gross_return"]

        win_rate = len(wins) / len(trades)
        gross_profit = wins.sum()
        gross_loss = abs(losses.sum())
        profit_factor = (
            gross_profit / gross_loss if gross_loss > 0 else np.inf
        )

    return {
        "total_return": total_return,
        "annualized_return": annualized_return,
        "annualized_volatility": annualized_volatility,
        "sharpe": sharpe,
        "sortino": sortino,
        "max_drawdown": max_drawdown,
        "trade_count": float(len(trades)),
        "win_rate": win_rate,
        "profit_factor": profit_factor,
    }

A complete run should also compare the strategy against a simple benchmark, such as buy-and-hold for the same symbol. Without a benchmark, a positive return is difficult to interpret.

7. Visualization: Read the Equity Curve, Not Just the Final Number

A final return does not tell you whether the strategy made money steadily, survived a long drawdown, or benefited from one isolated trade.

We will plot three panels:

1. Price and moving averages.
2. Strategy equity versus buy-and-hold.
3. Drawdown over time.

import matplotlib.pyplot as plt


def plot_results(
    results: pd.DataFrame,
    symbol: str,
) -> None:
    """Plot the strategy, benchmark, and underwater equity curve."""
    benchmark = results["close"] / results["close"].iloc[0]
    strategy = results["equity"] / results["equity"].iloc[0]

    figure, axes = plt.subplots(
        3, 1, figsize=(12, 10), sharex=True
    )

    axes[0].plot(
        results["timestamp"], results["close"],
        label="Close", linewidth=1
    )
    axes[0].plot(
        results["timestamp"], results["fast_ma"],
        label="20-day MA", linewidth=1
    )
    axes[0].plot(
        results["timestamp"], results["slow_ma"],
        label="50-day MA", linewidth=1
    )
    axes[0].set_ylabel("Price")
    axes[0].set_title(f"{symbol}: moving-average strategy")
    axes[0].legend()
    axes[0].grid(alpha=0.25)

    axes[1].plot(
        results["timestamp"], strategy,
        label="Strategy", linewidth=1.5
    )
    axes[1].plot(
        results["timestamp"], benchmark,
        label="Buy and hold", linewidth=1
    )
    axes[1].set_ylabel("Growth of 1")
    axes[1].legend()
    axes[1].grid(alpha=0.25)

    axes[2].fill_between(
        results["timestamp"],
        results["drawdown"],
        0,
        color="tab:red",
        alpha=0.35,
    )
    axes[2].set_ylabel("Drawdown")
    axes[2].set_xlabel("Date")
    axes[2].grid(alpha=0.25)

    figure.tight_layout()
    figure.savefig("moving_average_backtest.png", dpi=160)
    plt.show()

Now connect the pieces:

def main() -> None:
    symbol = "AAPL.US"

    data = fetch_kline(
        symbol=symbol,
        start="2018-01-01",
        end="2024-12-31",
        interval="1d",
    )

    data = moving_average_crossover(data)
    results, trades = run_backtest(
        data,
        initial_capital=10_000.0,
        slippage_bps=5.0,
        commission_bps=0.5,
    )

    metrics = calculate_metrics(results, trades)

    print(f"Symbol: {symbol}")
    print(f"Bars: {len(results)}")
    print(f"Trades: {len(trades)}")
    for name, value in metrics.items():
        print(f"{name}: {value:.4f}")

    plot_results(results, symbol)


if __name__ == "__main__":
    main()

Install the required packages in a virtual environment:

python -m venv .venv
source .venv/bin/activate
pip install pandas numpy requests matplotlib

Run the script:

python strategy.py

The output format will be similar to the following. The values below are illustrative only; actual results depend on the downloaded data, API response, execution assumptions, and the selected period.

Symbol: AAPL.US
Bars: 1764
Trades: 11
total_return: 0.4821
annualized_return: 0.1184
annualized_volatility: 0.2210
sharpe: 0.5359
sortino: 0.7102
max_drawdown: -0.1834
trade_count: 11.0000
win_rate: 0.5455
profit_factor: 1.9210

Backtest limitations

The results above are historical simulation outputs and do not guarantee future performance. This baseline assumes approximately 5 basis points of slippage per side and 0.5 basis points of commission per side. It does not model market impact, partial fills, exchange fees, bid-ask spread variation, corporate-action adjustments beyond the supplied data, or liquidity shortages during severe events. The sample size is also small because a moving-average crossover trades infrequently. Extend the out-of-sample period, test multiple symbols, and compare the results with different cost assumptions before drawing conclusions.

8. What to Examine Before Moving to Live Trading

The first backtest should produce a set of questions, not a trading decision.

Check the number of trades

Eleven trades are not enough to distinguish a stable edge from luck. A strategy with only a few observations may look profitable in one period and fail in another.

Compare several parameter values

Test the 20/50 moving-average combination against several nearby combinations, such as 10/30, 20/60, and 30/90. The goal is not to select the best combination after searching every possible setting. The goal is to determine whether the result is isolated or remains reasonably stable around nearby parameters.

Test multiple symbols

A strategy that works only on one symbol may reflect a stock-specific event. Start with several liquid US equities and inspect both aggregate performance and symbol-level behavior.

Compare the benchmark

The strategy should be compared with buy-and-hold over the same period. It may produce lower returns while still being useful if its drawdown, turnover, or exposure profile differs materially.

Preserve the research record

Record:

• Data source and retrieval date.
• Symbol universe.
• Date range.
• Bar interval.
• Signal parameters.
• Execution assumptions.
• Slippage and commission values.
• Full metric set.
• Code version or commit hash.

This prevents a result from becoming mysterious six months later.

Add live monitoring before adding live execution

A live system should monitor data freshness, connection state, and strategy state separately. The WebSocket lifecycle must include a heartbeat and a reconnect path with exponential backoff and jitter.

The following minimal example demonstrates the required connection behavior for a live feed. It uses the TickDB WebSocket authentication parameter, sends periodic ping commands, and reconnects after a connection failure.

import asyncio
import json
import os
import random

import websockets


API_KEY = os.environ.get("TICKDB_API_KEY")
WS_URL = "wss://api.tickdb.ai/v1/market/stream"

if not API_KEY:
    raise RuntimeError("TICKDB_API_KEY is not set.")


async def run_live_consumer(symbol: str) -> None:
    retry = 0

    while True:
        try:
            uri = f"{WS_URL}?api_key={API_KEY}&symbol={symbol}"
            async with websockets.connect(
                uri,
                ping_interval=20,
                ping_timeout=10,
                close_timeout=5,
            ) as websocket:

                retry = 0
                print(f"Connected to live feed for {symbol}")

                while True:
                    await websocket.send(
                        json.dumps({"cmd": "ping"})
                    )

                    try:
                        message = await asyncio.wait_for(
                            websocket.recv(),
                            timeout=30,
                        )
                        print(message)
                    except asyncio.TimeoutError:
                        print(
                            "No message received within 30 seconds; "
                            "checking connection health."
                        )

        except (OSError, websockets.WebSocketException) as exc:
            retry += 1
            delay = min(2 ** retry, 60)
            jitter = random.uniform(0, delay * 0.1)

            print(
                f"Connection failed: {exc}. "
                f"Reconnecting in {delay + jitter:.1f} seconds."
            )
            await asyncio.sleep(delay + jitter)

        except asyncio.CancelledError:
            raise


if __name__ == "__main__":
    asyncio.run(run_live_consumer("AAPL.US"))

The exact channel names and message schema should be confirmed against the current API documentation before production use. The important engineering properties are clear: authentication is explicit, heartbeats detect dead connections, and reconnects use bounded exponential backoff with jitter.

9. A Practical First Research Loop

A repeatable first project should follow this sequence.

Step 1: Download and inspect the data

Verify that timestamps are sorted, that there are no duplicate bars, that prices are positive, and that the date range matches the requested range.

print(data.head())
print(data.tail())
print(data.isna().sum())
print(data.describe())

Do not skip this step because the chart looks plausible.

Step 2: Calculate the signal

Plot the two moving averages and the crossover markers. Check that the markers occur when the fast average actually crosses the slow average.

Step 3: Run the backtest

Start with one symbol, one parameter set, one cost model, and one execution rule.

Step 4: Inspect the trade log

Ask:

• Were the entry and exit prices plausible?
• How many trades occurred?
• What was the largest losing streak?
• Did the result depend on one trade?
• Did the strategy remain exposed during major market moves?

Step 5: Test out of sample

Choose a period that was not used for parameter selection. A strategy that fails out of sample may have been fitted to historical noise.

Step 6: Write down the result

Record both what worked and what failed. The first backtest is a baseline for comparison, not a final verdict.

10. Where to Go Next

The moving-average crossover is not a complete trading system. It has no execution scheduler, portfolio risk limits, corporate-event handling, order reconciliation, or live position reconciliation.

A sensible progression is:

1. Compare multiple symbols and time windows.
2. Add a benchmark and transaction-cost sensitivity analysis.
3. Introduce position sizing and maximum exposure rules.
4. Test different market regimes separately.
5. Add a paper-trading or shadow-mode deployment.
6. Implement logging, monitoring, and alerting.
7. Only then consider a small live deployment with explicit capital limits.

The engineering lesson is more important than the particular signal. You now have a complete loop:

Data → signal → execution model → metrics → visualization → review.

That loop is the foundation of quantitative research. Once it exists, improving the strategy becomes a controlled experiment rather than a rewrite of the entire system.

For an individual developer, the next step is to obtain a TickDB API key, set TICKDB_API_KEY, and run the baseline script across a broad historical period. For a team, the next step is to formalize data snapshots, versioned experiment records, and reproducible backtest reports.

This article does not constitute investment advice. Markets involve risk; past performance does not guarantee future results.