Interpretar los costes del backtest cuando los campos de configuración son inertes

Resumen

Esta nota de configuración distingue los parámetros que aparecen en la identidad de un backtest de los que realmente afectan a los costes de trading simulado. En el estudio de caso descrito, todas las ejecuciones registradas usan una ruta vectorizada de rentabilidad hasta el vencimiento. Los campos configurados de precio de ejecución, tasa de comisión y tasa de slippage no se pasan a esa ruta, y las ejecuciones al precio de cotización corresponden a un bróker basado en eventos que las ejecuciones vectorizadas no construyen. Los parámetros siguen en la configuración porque eliminarlos cambiaría la identidad hash de las ejecuciones existentes.

Los costes aplicados en la simulación se leen por separado de un archivo de configuración: diferenciales de entrada y salida de opciones, diferenciales estimados de cobertura en cada rebalanceo y comisiones por contrato o acción. La nota indica que el campo registrado de slippage total es nulo en toda la población indicada, aunque se cobran costes, porque esa ruta no registra los costes totales. Es una lección útil para las auditorías: un valor de configuración o una métrica de costes ausente no basta por sí solo para determinar cuánto pagó un backtest. Los hallazgos corresponden a la implementación especificada y deben revisarse si cambian el ejecutor o el sistema de gestión de costes.

Ideas clave

• Los campos de configuración pueden afectar la identidad hash de una ejecución aunque la ruta de ejecución no los utilice.
• La ruta vectorizada de rentabilidad hasta el vencimiento descrita aquí no usa los campos configurados de comisión y slippage basados en tasas.
• Los costes simulados reales proceden de componentes separados de opciones, coberturas y liquidación.
• Un campo de slippage agregado nulo no demuestra que no se hayan cobrado costes.
• La interpretación de los costes depende de rastrear el ejecutor específico y su flujo de datos.

Etiquetas

# base.yaml


```yaml
# Three fields below are inert on the path this case study runs: `execution.execution_price`,
# `commission.rate` and `slippage.rate`. Every registered backtest here is `ret_to_expiry`,
# which `case_studies/utils/backtest_runner.py` routes to `_run_htm_daily_mtm`, and that call
# is not passed `cost_spec` - the only thing that carries these rates into a run. The
# `quote_side` fill is read by the event-driven broker, which a `rebalance.mode: vectorized`
# case study never constructs. They still reach the registered `backtest_config` and so the
# hashed identity, which is why they stay: removing them would re-key 879 backtests to delete
# values nothing reads.
#
# The costs this case study actually pays come from `_htm_backtest.py`, which reads
# `config/setup.yaml::costs.components` directly - per-leg entry spread from the real option
# quotes, `hedge_spread.estimate_bps_of_notional` on every hedge rebalance,
# `commission.option_per_contract` and `commission.equity_per_share`, plus an exit spread on
# liquidation. Verified 2026-09-12; `total_slippage` is NULL on all 879 rows because the
# vectorized path records no cost totals, not because nothing was charged.
account:
  allow_short_selling: true
execution:
  execution_price: quote_side
  mark_price: price
  execution_mode: next_bar
commission:
  model: percentage
  rate: 0.0005
slippage:
  model: percentage
  rate: 0.0002
calendar:
  calendar: NYSE
  timezone: UTC
  data_frequency: daily
feed:
  timestamp_col: timestamp
  entity_col: symbol
  price_col: instr_mid
  close_col: close
  bid_col: instr_bid
  ask_col: instr_ask
  mid_col: instr_mid
metadata:
  case_study: sp500_options

```

Se muestra íntegramente con atribución según la licencia de la fuente. Licencia: MIT

Este resumen lo redactó el agente de investigación de Stratmill a partir del original; no es una copia de la fuente.