Entrada larga en 84,120. Stop en 84,036, objetivo en 84,271. Llega la vela del minuto siguiente: apertura 84,118, máximo 84,290, mínimo 84,010, cierre 84,240.
Los dos niveles están dentro de esa vela. Se tocó el stop y se tocó el objetivo, pero esos cuatro números OHLC no contienen ninguna información sobre cuál se alcanzó primero. Aun así, tu backtest devolvió un resultado. En algún punto del bucle, una línea decidió qué pasó; seguramente una línea que no consideraste un supuesto de modelado cuando la escribiste.
Es la mayor fuente de rendimiento ficticio que veo en estrategias de horizonte corto, por delante de las comisiones y del deslizamiento, porque no parece un supuesto. Parece simple infraestructura.
Primera forma de equivocarse: dejar que decida la cadena de if
La estructura habitual:
if bar.high >= target:
exit(target, "tp")
elif bar.low <= stop:
exit(stop, "sl")Nadie eligió «los objetivos se resuelven antes que los stops». La comprobación del objetivo simplemente se escribió primero porque es el caso favorable y era el que tenías en mente. Invierte el orden de las dos ramas y cambia la curva de capital; eso debería bastar para mostrarte que parte del P&L de la estrategia depende de tu editor.
Probé un scalper de reversión a la media deliberadamente corriente en el perp BTCUSDT: 3 meses de velas de 1 minuto, 4,812 operaciones, stop a 0.10% y objetivo a 0.18% de la entrada. Las mismas señales, las mismas comisiones; solo cambié el criterio para resolver los empates.
Una octava parte de las operaciones determina todo el resultado. Así funciona un par de stop y objetivo ajustados: las operaciones ambiguas son aquellas en las que el precio se movió en ambas direcciones, que son la mayoría de las interesantes, y cada una vale toda la distancia entre el stop y el objetivo, según el azar. El 12.6% de las operaciones × 0.28% de recorrido equivale al 3.5% del volumen nocional bruto por unidad de muestra, muy por encima de la ventaja real de la estrategia.
La tasa depende del tamaño de las velas en relación con la distancia entre niveles y empeora rápido al usar velas más largas. Mismos stop y objetivo, mismas señales, con distintas agregaciones:
| Intervalo de la vela | Operaciones con ambos niveles dentro de una vela | Sharpe (objetivo primero) |
|---|---|---|
| 1s | 0.3% | 0.91 |
| 1m | 12.6% | 2.31 |
| 5m | 34% | 3.60 |
| 15m | 49% | 4.42 |
| 1h | 71% | 5.88 |
Fíjate en lo que realmente dice esa tabla. Con velas más amplias, el backtest mejora. Cualquier investigador diría que las velas horarias son la opción conservadora: menos ruido y menos sobreajuste a la microestructura. Pero si el criterio intravela resuelve a tu favor, una vela más amplia es simplemente una caja mayor en la que puedes suponer que tuviste suerte. Con velas de 1h, 7 de cada 10 operaciones dependen exclusivamente del criterio elegido. Ese backtest no pone a prueba una estrategia: pone a prueba el orden de dos instrucciones `if` 3,400 veces.
Segunda forma de equivocarse: asumir que el stop se ejecutó al precio del stop
Supongamos que corriges el orden. El stop se resuelve primero, contabilizas una pérdida exacta de 0.10% más la comisión taker y te parece riguroso. Pero siguen habiendo dos errores distintos.
El primero es que un stop es un disparador, no una ejecución. En Binance USDⓈ-M, una orden STOP_MARKET se convierte en una orden de mercado en cuanto se cumple la condición de activación y consume lo que haya en el libro. En un minuto tranquilo, eso supone uno o dos ticks de deslizamiento. En el minuto que de verdad activó tu stop —el de una vela con cuerpo de 40 puntos y una cascada de liquidaciones debajo—, el libro está poco profundo justo en el lado que estás cruzando. En mi muestra, al comparar los disparos de stop con los datos tick a tick, la ejecución mediana quedó 1.4 bps más allá del disparador y el percentil 95, 11 bps. Con un stop de 10 bps, ese extremo te cuesta una décima adicional del riesgo que creías haber definido.
El segundo es más sutil y específico de los perps: qué precio lo activa. Binance configura por defecto las órdenes stop para que se activen con el precio mark, que se calcula a partir del índice y una base suavizada, no del último trade en esa plataforma. Tu serie OHLCV usa el último precio. Son series distintas y divergen más justo durante los eventos que activan los stops.
| Último precio (tus klines) | Precio mark (disparador predeterminado) | |
|---|---|---|
| Origen | trades en esta plataforma | índice de varias plataformas + base |
| Comportamiento de las mechas | recorrido completo | muy suavizado |
| Divergencia típica | 1–3 bps en calma, 20–35 bps durante un minuto de cascada | |
| Consecuencia para el backtest | stops que se activaron sin que debieran, y viceversa | |
Así que una mecha de 25 bps en los datos del último precio te saca de la posición en el backtest, aunque el precio mark en vivo nunca se acercara a menos de 10 bps del disparador. O puede ocurrir lo contrario, el día que se mueve el índice y tu plataforma va rezagada. Si configuras workingType como CONTRACT_PRICE, al menos alineas el comportamiento en vivo con tus datos; suele ser lo más adecuado para investigar, porque simular con rigor un disparador basado en el precio mark implica mantener una segunda serie en todo el motor de ejecución.
La versión que mejor recuerdo: alguien de nuestro equipo «mejoró» una estrategia al subir el take-profit de 0.18% a 0.21%. El Sharpe pasó de 2.3 a 3.1. No había ninguna ventaja nueva. El objetivo simplemente se había alejado de la zona más densa de la distribución de mechas de 1 minuto, así que menos operaciones caían en la categoría ambigua donde el código les concedía la victoria en silencio. Habían optimizado el desempate.
Tercera forma de equivocarse: asumir siempre lo peor y llamarlo conservador
La solución instintiva es el pesimismo. Si se tocan ambos niveles, aplica el stop. Listo, se acabó el optimismo; a producción.
Yo solía hacerlo. Es mejor que la alternativa y sigue estando mal, por dos motivos.
Elimina estrategias que sí funcionan. Resolver pesimistamente el 12.6% de las operaciones le costó a esta estrategia 2.1 puntos de Sharpe frente a 0.94 al resolver con datos tick a tick. Si el valor real es 0.94 y tu criterio da 0.18, descartas la idea y te pones a trabajar en algo peor. Un conservadurismo que se equivoca por 2 puntos de Sharpe no es conservadurismo: es ruido con pose moral.
Peor aún, corrompe la optimización. Dale a un barrido de parámetros un criterio pesimista para los empates y el optimizador aprenderá a evitar la ambigüedad, porque ahora supone una penalización pura. Se inclinará por stops amplios y objetivos cercanos, o por velas lentas en las que rara vez coinciden ambos niveles, y presentará parámetros seleccionados en función de tu criterio de ejecución y no del mercado. Es el mismo fallo que con el criterio generoso, pero con el signo opuesto, e igual de invisible en el tearsheet.
Regla práctica que aplicamos antes que nada: si stop_distance + target_distance es menor que el rango del percentil 75 de tu intervalo de vela, tu supuesto intravela influye más en el P&L que tu señal. Calcula ambos valores. Son 4 líneas y han puesto fin a más revisiones de estrategias que cualquier otra comprobación individual.
Qué funciona de verdad
El recorrido dentro de la vela es un dato. Consíguelo o acota lo que no puedas obtener.
- Resuelve con la serie más granular que tengas. Los aggTrades de Binance de los minutos pertinentes son unos cientos de filas y resuelven la cuestión sin ambigüedades: qué nivel se tocó primero y a qué precio se ejecutó el barrido. No necesitas datos tick a tick para todo el backtest, solo para las velas ambiguas. En mi muestra fueron 606 minutos de un total de 129,600. Es una descarga pequeña, no un proyecto de infraestructura.
- Si no tienes datos tick a tick, baja uno o dos intervalos temporales solo para resolver las salidas. Señales en 15m y salidas resueltas con velas de 1s o 1m. La ambigüedad baja del 49% a una fracción de punto porcentual, y el residuo es lo bastante pequeño como para ignorarlo con honestidad.
- Informa siempre el intervalo de resultados. Ejecuta cada backtest 2 veces, con una resolución optimista y otra pesimista, e imprime ambos Sharpes junto al valor resuelto. Esa diferencia es tu incertidumbre intravela y debe figurar en el tearsheet junto al intervalo de confianza que incluirías para el propio Sharpe. Si el intervalo va de 0.2 a 2.3, ninguna conclusión dentro de ese rango es fiable.
- Haz que la tasa de ambigüedad sea una métrica de primer nivel. Nosotros la mostramos arriba en cada ficha de estrategia, junto al número de operaciones y el volumen negociado. Una tasa superior a aproximadamente el 5% significa que lo que se está poniendo a prueba es la lógica de salida, no la de entrada.
- Modela el disparador por separado de la ejecución. Activa la orden con la serie de precios que usa realmente la plataforma; ejecuta al precio del disparador más un deslizamiento calibrado con los datos de mercado, no al precio del disparador.
En la renta variable ocurre lo mismo, con otra apariencia. Un stop en 62.00 para una acción que abre con un gap nocturno en 58.40 no se ejecuta a 62.00: se ejecuta por debajo del precio de apertura. Un backtest con barras diarias que contabiliza −$0.00 de deslizamiento cuando el precio salta el stop te dirá encantado que una capa de stop-loss mejoró la caída máxima. No fue así. Simplemente nunca se puso a prueba en los días que importan. Las suspensiones de cotización producen el mismo problema: tu stop se ejecuta en la subasta de reapertura, a un precio que el mínimo de la vela ni siquiera muestra.
Nada de esto es exótico. Se trata de reconocer que una vela es un resumen y que una estrategia con stop y objetivo apuesta por el orden de los eventos que ese resumen descartó. Cuando el motor de paper trading finalmente ejecuta la estrategia contra un flujo de mercado en vivo, ese flujo tiene una opinión sobre el orden de los eventos y nunca le ha importado cuál rama de la instrucción if escribiste primero.
← Todos los artículos
