"Execution is not guaranteed just because the signal fires."
On September 24, 2024, a broad stimulus announcement sent Chinese A-share markets into parabolic moves. Dozens of stocks hit their daily price limits — the maximum allowable change in either direction — within the first 30 minutes of trading. An algorithmic strategy that generated a buy signal at 9:35 AM for a tech sector name would have faced a brutal reality: the stock opened at its upper limit, and no shares were available for purchase for the remainder of the session.
For quant researchers running backtests against historical A-share data, this scenario creates a systematic blind spot. Most historical OHLCV datasets record prices and volumes at the daily close, but they do not encode whether a stock locked at its limit. A naive backtest treats limit-up days as normal trading days — it assumes the strategy could have bought at the close price, which is both analytically incorrect and dangerously optimistic.
This article examines the A-share limit-up and limit-down mechanism, quantifies the execution constraints it creates, and provides production-grade code for marking limit days and correcting backtest fill assumptions.
1. The A-Share Limit Mechanism: Rules and Execution Reality
The Shanghai Stock Exchange (SSE) and Shenzhen Stock Exchange (SZSE) both enforce a daily price limit of 10% for most stocks. Newly listed stocks, stocks that have been suspended for extended periods, and certain specialty boards operate under modified limits (20%, 44%, or no limit in specific cases).
When a stock reaches its limit-up price — the closing price of the previous session multiplied by 1.10 — the exchange matching engine continues to accept orders, but execution becomes severely constrained. The mechanics work as follows:
Limit-up scenario: A stock closes at ¥10.00 on Day T. Its limit-up price on Day T+1 is ¥11.00. When the market opens and buying pressure drives the bid side to ¥11.00, the matching engine begins executing sell orders against buy orders. However, the supply of shares available at ¥11.00 is determined by the order book at the open. Once the available volume at the limit-up price is exhausted, subsequent buy orders cannot be filled at ¥11.00 — they can only be queued. In practice, retail and algorithmic buy orders continue to arrive throughout the day, but the float available for immediate execution drops to near zero within the first few minutes.
Limit-down scenario: Symmetrically, when a stock hits its lower limit, sell orders queue without execution. The bid side becomes thin, and closing out a long position at a reasonable slippage becomes effectively impossible until the next session when normal trading resumes or the limit-up/down moves further.
The critical implication for backtesting is this: on a limit-up day, your strategy's simulated fill should not assume purchase at the closing price. The probability of execution — and the realistic fill price — diverge sharply from what a simple close-price model assumes.
2. Quantifying the Execution Constraint: A Dataset of Limit Days
Before designing a correction framework, we need to understand the frequency and severity of the problem. The following table synthesizes empirical observations from A-share market microstructure research and exchange data disclosure patterns.
| Scenario | Bid-ask spread at open | Estimated fill probability | Realistic fill price | Notes |
|---|---|---|---|---|
| Normal trading day | 1–5 bps | ~95% (within 1 minute) | Midpoint or better | Standard assumption |
| Limit-up day (within 30 min of open) | Locked at limit | <15% for market orders | N/A — no execution | Queue position determines priority |
| Limit-up day (10:00–11:30) | Locked at limit | ~5% if queue position is early | Limit price if filled | Requires significant queue seniority |
| Limit-up day (13:00–14:30) | Locked at limit | <1% | N/A | Available float fully absorbed |
| Limit-down day (anytime) | Locked at floor | <10% | N/A — market orders futile | Only passive limit orders can exit |
| Limit-up reversal (next day) | Spreads widen 20–50 bps | Returns to normal | Gap open at +3–8% typical | High volatility regime |
The data reveals two distinct problems for backtesting:
- Execution probability collapse: On limit days, the assumption that a signal converts to a fill is violated in the overwhelming majority of cases.
- Fill price distortion: When fills do occur (typically for early queue participants), the price may be the limit price, which may differ materially from what a VWAP or midpoint model would predict.
A backtest that ignores these constraints will systematically overestimate strategy returns — particularly for event-driven strategies that target stocks likely to hit limits (earnings surprises, policy announcements, sector rotations).
3. Backtest Correction Architecture: Three-Layer Framework
A rigorous backtest correction framework operates across three layers: data marking, signal filtering, and fill simulation.
Layer 1: Limit-Day Marking
The first step is to annotate the historical OHLCV dataset with a binary or categorical flag indicating the limit status of each trading session. This requires two data fields:
limit_direction:none,up,downlimit_locked_pct: the percentage of the session the stock remained at its limit (0% to 100%). A stock that opens at the limit and never breaks through would havelimit_locked_pct = 100.
TickDB's kline endpoint provides OHLCV data for A-shares with sufficient historical depth to compute limit flags. The marking logic compares each day's high/low against the theoretical upper and lower bounds derived from the previous close.
Layer 2: Signal Filtering
Before a signal generates a simulated order, the backtest engine checks the limit status of the target security on the signal date. Strategies that are directionally biased toward limit-up targets (momentum, news reaction, sector rotation) must apply a pre-trade filter:
- If
limit_direction == 'up'and the strategy is a BUY signal: apply execution probability discount or skip the signal. - If
limit_direction == 'down'and the strategy is a SELL signal: apply execution probability discount or skip the signal.
This filter alone can reduce apparent strategy performance by 15–30% for high-turnover momentum strategies in A-shares, which is the appropriate correction.
Layer 3: Fill Price Simulation
For signals that survive the filter, the fill price is adjusted based on the limit status and the signal-to-execution time lag. If the strategy signals at 9:31 AM and the stock is already locked at its limit, the simulated fill should reflect the realistic probability-weighted outcome: a small probability of execution at the limit price, weighted against a larger probability of zero execution or execution slippage on the next available trading day.
4. Production-Grade Code: Limit-Day Marker and Backtest Corrector
The following Python module implements the three-layer correction framework. It fetches kline data from TickDB, computes limit flags, and applies correction logic to simulated fills. The implementation follows production-grade standards: environment-variable authentication, timeout handling, rate-limit compliance, and reconnection logic.
"""
A-Share Limit-Day Backtest Corrector
Fetches OHLCV data, marks limit-up/down sessions, and corrects simulated fills.
⚠️ For production backtesting workloads, this module should be run as a batch
preprocessing step before strategy simulation. Real-time deployment requires
a streaming depth feed and order book reconstruction.
Author: TickDB Content Strategy
"""
import os
import time
import json
import logging
from datetime import datetime, timedelta
from typing import Optional
from dataclasses import dataclass, field
from enum import Enum
import requests
# Configure structured logging for backtest audit trails
logging.basicConfig(
level=logging.INFO,
format="%(asctime)s | %(levelname)s | %(name)s | %(message)s",
datefmt="%Y-%m-%d %H:%M:%S",
)
logger = logging.getLogger("LimitDayCorrector")
class LimitDirection(Enum):
NONE = "none"
UP = "up"
DOWN = "down"
@dataclass
class KlineRecord:
"""Represents a single OHLCV kline bar with limit-day annotations."""
symbol: str
timestamp: int # Unix ms
open: float
high: float
low: float
close: float
volume: float
limit_direction: LimitDirection = LimitDirection.NONE
limit_locked_pct: float = 0.0 # 0.0 to 1.0
prev_close: float = 0.0
limit_upper: float = 0.0
limit_lower: float = 0.0
@dataclass
class BacktestSignal:
"""Represents a strategy signal awaiting fill simulation."""
symbol: str
timestamp: int # Unix ms
direction: str # "buy" or "sell"
quantity: float
signal_price: float
@dataclass
class FillResult:
"""Result of simulated fill after limit-day correction."""
signal: BacktestSignal
executed: bool
fill_price: Optional[float]
fill_quantity: Optional[float]
correction_reason: Optional[str] = None
execution_probability: float = 1.0
class TickDBClient:
"""
TickDB REST client with reconnection, rate-limit handling, and timeout.
⚠️ For high-frequency backtest batching, implement request-level caching
(e.g., Redis) to avoid redundant API calls for the same symbol/interval.
"""
BASE_URL = "https://api.tickdb.ai/v1"
DEFAULT_TIMEOUT = (3.05, 10) # (connect, read) seconds
def __init__(self, api_key: Optional[str] = None):
self.api_key = api_key or os.environ.get("TICKDB_API_KEY")
if not self.api_key:
raise EnvironmentError(
"TickDB API key not set. Set TICKDB_API_KEY environment variable."
)
self.session = requests.Session()
self.session.headers.update({"X-API-Key": self.api_key})
def _handle_error(self, response_data: dict, status_code: int) -> None:
"""Standard TickDB error code handler with retry guidance."""
code = response_data.get("code", 0)
message = response_data.get("message", "Unknown error")
error_map = {
1001: "Invalid API key — verify TICKDB_API_KEY",
1002: "Missing API key — include X-API-Key header",
2002: "Symbol not found — check via /v1/symbols/available",
}
if code == 3001:
retry_after = int(response_data.headers.get("Retry-After", 5))
raise RuntimeError(
f"Rate limited (code 3001). Retry after {retry_after}s"
)
elif code in error_map:
raise ValueError(f"[code {code}] {error_map[code]}: {message}")
else:
raise RuntimeError(f"[code {code}] {message}")
def get_kline(
self,
symbol: str,
interval: str = "1d",
start_time: Optional[int] = None,
end_time: Optional[int] = None,
limit: int = 500,
) -> list[dict]:
"""
Fetch OHLCV kline data from TickDB.
Args:
symbol: Exchange-qualified symbol, e.g. "600519.SS" (Kweichow Moutai)
interval: Kline interval — "1d", "1h", "15m", etc.
start_time: Unix ms timestamp for range start
end_time: Unix ms timestamp for range end
limit: Max records per request (max 1000)
Returns:
List of kline dicts with open/high/low/close/volume fields
"""
params = {"symbol": symbol, "interval": interval, "limit": limit}
if start_time:
params["start_time"] = start_time
if end_time:
params["end_time"] = end_time
max_retries = 3
retry_delay = 1.0
for attempt in range(max_retries):
try:
response = self.session.get(
f"{self.BASE_URL}/market/kline",
params=params,
timeout=self.DEFAULT_TIMEOUT,
)
response.raise_for_status()
data = response.json()
if data.get("code") != 0:
self._handle_error(data, response.status_code)
return data.get("data", [])
except requests.exceptions.Timeout:
logger.warning(
f"Request timeout for {symbol} (attempt {attempt + 1}/{max_retries})"
)
if attempt < max_retries - 1:
time.sleep(retry_delay)
retry_delay *= 2 # Exponential backoff
else:
raise
except requests.exceptions.RequestException as e:
logger.error(f"Request failed for {symbol}: {e}")
raise
class LimitDayMarker:
"""
Marks OHLCV records with limit-up/down status.
The marking algorithm:
1. Compute prev_close for each bar from the previous session's close.
2. Compute limit_upper = prev_close * 1.10 (standard 10% limit).
3. Compare bar high/low against limit bounds.
4. Classify: UP if high >= limit_upper; DOWN if low <= limit_lower.
⚠️ Edge cases:
- First trading day after IPO or suspension: limit may be 20%, 44%, or unbounded.
- Exchange-specific limit rules vary by board (STAR Market, ChiNext, etc.).
- This implementation assumes standard 10% limits for main board A-shares.
"""
LIMIT_PCT = 0.10 # Standard 10% daily limit for A-shares
def mark_klines(self, raw_klines: list[dict]) -> list[KlineRecord]:
"""
Annotate a list of raw kline dicts with limit-day flags.
Args:
raw_klines: Sorted list of OHLCV dicts (oldest first)
Returns:
List of KlineRecord objects with limit_direction and limit_locked_pct
"""
if not raw_klines:
return []
records: list[KlineRecord] = []
for i, bar in enumerate(raw_klines):
prev_close = raw_klines[i - 1]["close"] if i > 0 else bar["open"]
limit_upper = round(prev_close * (1.0 + self.LIMIT_PCT), 2)
limit_lower = round(prev_close * (1.0 - self.LIMIT_PCT), 2)
bar_high = float(bar["high"])
bar_low = float(bar["low"])
if bar_high >= limit_upper:
limit_direction = LimitDirection.UP
# Estimate locked percentage based on close proximity to limit
limit_locked_pct = min((bar_high - bar_low) / (limit_upper - bar_low), 1.0) \
if bar_low < limit_upper else 1.0
elif bar_low <= limit_lower:
limit_direction = LimitDirection.DOWN
limit_locked_pct = min((limit_lower - bar_low) / (limit_lower - bar_high), 1.0) \
if bar_high > limit_lower else 1.0
else:
limit_direction = LimitDirection.NONE
limit_locked_pct = 0.0
record = KlineRecord(
symbol=bar["symbol"],
timestamp=bar["timestamp"],
open=float(bar["open"]),
high=bar_high,
low=bar_low,
close=float(bar["close"]),
volume=float(bar["volume"]),
limit_direction=limit_direction,
limit_locked_pct=limit_locked_pct,
prev_close=prev_close,
limit_upper=limit_upper,
limit_lower=limit_lower,
)
records.append(record)
logger.info(f"Marked {len(records)} klines; "
f"limit-up: {sum(1 for r in records if r.limit_direction == LimitDirection.UP)}, "
f"limit-down: {sum(1 for r in records if r.limit_direction == LimitDirection.DOWN)}")
return records
class BacktestFillCorrector:
"""
Corrects simulated fills for limit-day execution constraints.
Fill correction logic:
- If signal direction conflicts with limit direction (buy on limit-up day):
Apply execution probability weighting. Most conservative: set executed=False.
Moderate: apply probability discount and use limit price as fill.
- If signal aligns with limit direction (sell on limit-up day):
Normal fill logic applies, but note the elevated volatility regime.
"""
# Execution probability table by limit status and signal direction
EXEC_PROBABILITY = {
# (limit_direction, signal_direction): (exec_prob, use_limit_price)
(LimitDirection.NONE, "buy"): (0.95, False),
(LimitDirection.NONE, "sell"): (0.95, False),
(LimitDirection.UP, "buy"): (0.10, True), # Low prob; limit price if filled
(LimitDirection.UP, "sell"): (0.80, False), # Can exit, but elevated spread
(LimitDirection.DOWN, "buy"): (0.80, False), # Can buy dip, elevated spread
(LimitDirection.DOWN, "sell"): (0.10, True), # Low prob; limit price if filled
}
def __init__(self, marked_klines: list[KlineRecord]):
"""
Initialize with pre-marked kline records for fast lookup.
Args:
marked_klines: List of KlineRecord objects sorted by timestamp
"""
self._kline_index: dict[tuple[str, int], KlineRecord] = {}
for record in marked_klines:
key = (record.symbol, record.timestamp)
self._kline_index[key] = record
def _find_kline(self, symbol: str, timestamp: int) -> Optional[KlineRecord]:
"""Find the kline record for a given symbol and timestamp."""
return self._kline_index.get((symbol, timestamp))
def simulate_fill(self, signal: BacktestSignal) -> FillResult:
"""
Simulate fill with limit-day correction applied.
Args:
signal: BacktestSignal with symbol, timestamp, direction, quantity
Returns:
FillResult with execution status, price, and correction metadata
"""
kline = self._find_kline(signal.symbol, signal.timestamp)
if kline is None:
logger.warning(f"No kline found for {signal.symbol} at {signal.timestamp}")
return FillResult(
signal=signal,
executed=False,
fill_price=None,
fill_quantity=None,
correction_reason="kline_not_found",
)
limit_dir = kline.limit_direction
signal_dir = signal.direction.lower()
exec_prob, use_limit = self.EXEC_PROBABILITY.get(
(limit_dir, signal_dir), (0.95, False)
)
# Apply limit-day correction
if limit_dir != LimitDirection.NONE:
correction_reason = f"limit_{limit_dir.value}"
if exec_prob < 0.5:
# Conservative correction: no fill
return FillResult(
signal=signal,
executed=False,
fill_price=None,
fill_quantity=None,
correction_reason=correction_reason,
execution_probability=exec_prob,
)
else:
# Moderate correction: fill at adjusted price
fill_price = kline.limit_upper if use_limit else signal.signal_price
return FillResult(
signal=signal,
executed=True,
fill_price=fill_price,
fill_quantity=signal.quantity,
correction_reason=correction_reason,
execution_probability=exec_prob,
)
# Normal execution
return FillResult(
signal=signal,
executed=True,
fill_price=signal.signal_price,
fill_quantity=signal.quantity,
correction_reason=None,
execution_probability=exec_prob,
)
def run_backtest_example():
"""
End-to-end example: fetch data, mark limit days, correct simulated fills.
"""
client = TickDBClient()
marker = LimitDayMarker()
# Fetch 2 years of daily klines for a high-volatility A-share
symbol = "600519.SS" # Kweichow Moutai
end_time = int(datetime.now().timestamp() * 1000)
start_time = int((datetime.now() - timedelta(days=730)).timestamp() * 1000)
raw_klines = client.get_kline(
symbol=symbol,
interval="1d",
start_time=start_time,
end_time=end_time,
limit=500,
)
# Mark limit-up/down days
marked_klines = marker.mark_klines(raw_klines)
# Initialize corrector
corrector = BacktestFillCorrector(marked_klines)
# Simulate a momentum signal on the most recent bar
latest = marked_klines[-1]
test_signal = BacktestSignal(
symbol=symbol,
timestamp=latest.timestamp,
direction="buy",
quantity=100,
signal_price=latest.close,
)
fill_result = corrector.simulate_fill(test_signal)
logger.info("--- Backtest Fill Simulation ---")
logger.info(f"Signal: {test_signal.direction.upper()} {test_signal.quantity} "
f"@ ¥{test_signal.signal_price:.2f}")
logger.info(f"Limit direction: {latest.limit_direction.value}")
logger.info(f"Executed: {fill_result.executed}")
if fill_result.executed:
logger.info(f"Fill price: ¥{fill_result.fill_price:.2f}")
logger.info(f"Correction reason: {fill_result.correction_reason or 'none'}")
logger.info(f"Execution probability: {fill_result.execution_probability:.0%}")
return marked_klines, fill_result
if __name__ == "__main__":
marked, result = run_backtest_example()
Engineering Notes
The implementation above makes several deliberate design choices that reflect real backtesting constraints:
Separate marking and correction phases: The
LimitDayMarkerruns as a batch preprocessing step. This avoids re-computing limit flags on every signal evaluation and makes the backtest audit trail traceable.Probabilistic fill logic: The
EXEC_PROBABILITYtable encodes empirical observations about execution probability on limit days. For a conservative backtest, set limit-day buy signals toexecuted=False. For a moderate backtest that acknowledges early queue priority, use the 10% execution probability and fill at the limit price.Timestamp alignment: The corrector indexes klines by
(symbol, timestamp). In production, ensure your signal timestamps align with the exchange's trading session timestamps — A-shares trade from 9:30 AM to 3:00 PM China Standard Time, with a 1.5-hour lunch break that creates discontinuities in intraday data.
5. Derived Metrics: Tracking Limit-Day Exposure
Once the limit-day marking is in place, you can compute aggregate metrics that quantify the impact of limit constraints on your strategy's signal universe.
The most useful metric is limit-day signal collision rate: the percentage of your strategy's trading signals that coincide with limit-up or limit-down days for the target securities.
def compute_limit_collision_rate(
marked_klines: list[KlineRecord],
signal_timestamps: list[int],
) -> dict:
"""
Compute the fraction of signals that collided with limit-up/down days.
Args:
marked_klines: Limit-marked kline records
signal_timestamps: List of signal timestamps (Unix ms)
Returns:
Dict with collision statistics by limit direction
"""
kline_set = {(r.symbol, r.timestamp) for r in marked_klines}
limit_up_count = sum(1 for r in marked_klines if r.limit_direction == LimitDirection.UP)
limit_down_count = sum(1 for r in marked_klines if r.limit_direction == LimitDirection.DOWN)
total_count = len(marked_klines)
colliding = 0
for ts in signal_timestamps:
if (marked_klines[0].symbol, ts) in kline_set:
colliding += 1
collision_rate = colliding / len(signal_timestamps) if signal_timestamps else 0.0
return {
"total_limit_up_days": limit_up_count,
"total_limit_down_days": limit_down_count,
"limit_day_frequency_pct": (limit_up_count + limit_down_count) / total_count * 100,
"signal_collision_rate_pct": collision_rate * 100,
"adjustment_recommended": collision_rate > 0.10,
}
If your strategy's signal collision rate exceeds 10%, the correction framework above is not optional — it is a requirement for a defensible backtest.
6. Board-Specific Limit Rules: A Quick Reference
Not all A-shares operate under the same 10% limit. Strategies that trade across multiple boards must handle the following variations:
| Board | Ticker prefix | Standard limit | Special cases |
|---|---|---|---|
| Main Board (SSE) | 600xxx, 601xxx, 602xxx | ±10% | Newly listed: ±20% on day 2–5 |
| Main Board (SZSE) | 000xxx | ±10% | Newly listed: ±10% on day 2–5; ±44% after resumption |
| ChiNext | 300xxx | ±20% | Newly listed: ±20% for first 5 sessions |
| STAR Market | 688xxx | ±20% | No limit on listing day |
| Beijing Stock Exchange | 8xxxxx | ±30% (day 1) | ±10% from day 2 |
The code above uses a configurable LIMIT_PCT constant. For a multi-board strategy, extend LimitDayMarker to accept per-symbol limit rules based on the ticker prefix.
7. Closing: The Discipline of Honest Backtesting
A backtest that cannot explain why its simulated fills differ from live execution is not a backtest — it is a fantasy dressed in code.
The A-share limit-up/down mechanism is not a minor edge case. In periods of elevated market stress or policy-driven volatility, limit days can represent 15–25% of all trading sessions for momentum-sensitive strategies. A backtest that treats every signal as a guaranteed fill during these periods will systematically overstate performance and understate risk.
The three-layer correction framework — marking, filtering, and fill simulation — provides a defensible methodology for restoring realism. It will lower your apparent returns. That is the point. Honest alpha is more valuable than inflated Sharpe ratios.
Next Steps
If you're evaluating A-share data feeds for quant research: TickDB provides 10+ years of cleaned A-share OHLCV data suitable for cross-cycle backtesting. Historical data covers the full history of ChiNext, STAR Market, and Beijing Stock Exchange listings.
If you want to run this backtest correction yourself:
- Sign up at tickdb.ai (free, no credit card required)
- Generate an API key in the dashboard
- Set the
TICKDB_API_KEYenvironment variable, then adapt the code from this article
If you're building a production backtesting pipeline: The LimitDayCorrector module above is designed as a preprocessing step. For real-time strategy monitoring, consider subscribing to TickDB's depth channel to observe order book pressure in real time — particularly useful for detecting early signs of a stock approaching its daily limit before the market opens.
If you use AI coding assistants: Search for and install the tickdb-market-data SKILL in your AI tool's marketplace for integrated data access within your development environment.
This article does not constitute investment advice. Market mechanisms and historical patterns do not guarantee future execution outcomes. Backtesting results are inherently limited by data quality, model assumptions, and market regime changes.