La semana pasada nos pasaste el notebook: misma señal, mismo universo, los mismos 14 meses de datos del perp BTCUSDT. Lo único que cambió fue la ejecución. Dejaste de cruzar el spread y empezaste a dejar bids un tick por dentro, y el Sharpe pasó de 0.42 a 2.14. Nos preguntaste si era real o si habías roto algo.
Rompiste algo. Quiero explicarte exactamente dónde, porque el bug está en una línea y la lección que hay detrás es mucho más grande que esa línea.
Esta es tu regla de ejecución, copiada de tu motor:
if bar.low <= limit_price: fill(limit_price)
Eso dice: si el mercado registró una operación a mi precio o por debajo durante este minuto, mi orden se ejecutó a mi precio. Lo que en realidad codifica es que el precio tocó tu nivel. Tocar no es ejecutar. Entre ambas cosas hay una cola, y la has modelado como si estuviera vacía.
Lo que tienes delante
Cuando colocas un bid a 84,120.0 en el perp BTCUSDT, te pones al final de todo lo que ya está ahí. En el mejor nivel de ese contrato suele haber entre 4 y 30 BTC, según la hora del día; la mediana de tu ventana de muestra ronda los 12 BTC. Tu orden es de 0.4 BTC. Para que se ejecute, los vendedores tienen que agredir ese nivel con suficiente volumen agregado para superar a todos los que llegaron antes que tú, y deben hacerlo antes de que cancelen el nivel bajo tus pies o el mercado se aleje al alza.
Así que la pregunta de tu backtest no debería ser «¿el precio llegó a 84,120.0?», sino «¿se ejecutaron al menos 12.4 BTC en ventas a mercado a 84,120.0 mientras mi orden estaba ahí?». Son eventos muy distintos. En tus datos, la diferencia es de unas 3 veces.
3 reglas de ejecución, 3 estrategias distintas
Volví a ejecutar tu señal con las mismas entradas y 3 modelos de ejecución. La misma alpha, las mismas comisiones, el mismo funding. Solo cambió la lógica de ejecución.
| Regla de ejecución | Ejecuciones | Ventaja media a 60 s tras la ejecución | Sharpe |
|---|---|---|---|
Toque: low <= limit | 4,180 | +2.6 bp | 2.14 |
Penetración estricta: low < limit - 1 tick | 1,712 | +0.4 bp | 0.61 |
| Simulación de cola por volumen en el nivel | 1,306 | +0.9 bp | 0.77 |
La fila del medio muestra el apaño básico al que todos recurren primero: solo contar una ejecución si el mercado operó estrictamente más allá de tu precio, con la idea de que, si lo superó, tuvo que consumir tu orden. La dirección es correcta y elimina la mayor parte de la fantasía. Pero también introduce un sesgo considerable, que explicaré enseguida.
La fila de abajo es el modelo que deberías implementar. No requiere un feed L3 ni reconstruir cada orden. Ya tienes casi todo lo necesario.
Una simulación de cola que puedes construir con aggTrades
Usa el flujo de operaciones agregadas en vez de klines. Cada operación registrada incluye precio, cantidad, marca de tiempo y un indicador del lado maker, que te dice si quien agredió estaba comprando o vendiendo. Basta para simular de forma razonable tu propia orden pasiva:
- Cuando se coloca tu orden, registra el volumen que ya está en reposo a tu precio. Si solo tienes un feed del libro de órdenes de 100 ms, usa la última instantánea; el error es pequeño frente al que estás corrigiendo.
- Asigna el valor a
queue_ahead = resting_size. Sé pesimista y asume que estás al final. Así es, salvo que seas tú quien crea el nivel. - Recorre el flujo de operaciones. Cada venta agresora a tu precio o por debajo reduce
queue_aheaden la cantidad ejecutada. Cuando el valor baja de cero, tu orden se ejecuta a tu precio y en esa marca de tiempo. - Si el precio se aleja un tick, no reinicies la cola a cero. Redúcela gradualmente. Algunas órdenes por delante de ti se cancelan cuando el nivel queda obsoleto, otras no. Una reducción del 30-40% por cada segundo completo fuera del nivel coincidió mejor con mis reconstrucciones que cualquiera de los extremos.
- Si tu estrategia cancelaría y volvería a colocar la orden, modela la nueva como una orden al final de la cola del nuevo nivel. La gente suele saltarse este paso; ahí es donde se esconde el resto de la fantasía.
En el paso 2 querrás llevarme la contraria. Sí, a veces estás cerca del principio porque colocaste la orden en cuanto se formó el nivel. De acuerdo: mídelo, no lo des por hecho. Registra el volumen en reposo cuando colocas la orden y deja que los datos te indiquen qué proporción de tus órdenes llega realmente pronto. En tu estrategia era el 11%, porque tu señal se activa después de un movimiento; para entonces, el nivel al que te sumas ya existe y ya hay una multitud ahí.
Las ejecuciones que consigues son las que ojalá no hubieras conseguido
Ahora viene lo que de verdad importa y la razón por la que la regla de penetración estricta tiene sesgo.
Piensa en cuándo se consume por completo tu bid. Ocurre cuando la presión vendedora es suficiente para comerse todo el nivel. Es decir, por definición, justo cuando el mercado cae atravesando tu precio. Las ejecuciones de las que más seguro estás son aquellas en las que el mercado se mueve en tu contra de inmediato.
Separa tus ejecuciones según cómo ocurrieron y mide el mark-out a 60 segundos:
| Tipo de ejecución | Proporción de ejecuciones | Mark-out a 60 s |
|---|---|---|
| Se operó en el nivel, el precio rebotó al alza | 38% | +3.1 bp |
| Se operó en el nivel, el precio se mantuvo plano | 21% | +0.2 bp |
| El precio atravesó el nivel por 2+ ticks | 41% | −2.4 bp |
Tu backtest ingenuo te dio los 3 grupos y los valoró todos como si fueran gratis. La regla de penetración estricta te da casi exclusivamente el tercer grupo; por eso su ventaja cayó aún más que la de la simulación de cola. Ninguna de las dos reglas es correcta. La simulación de cola te da una mezcla realista, y el juego entero está en esa mezcla: la ejecución pasiva te hace ganar el spread y te cobra selección adversa; la proporción entre ambas es tu estrategia real.
La vieja forma de verlo en la mesa de renta variable sigue siendo válida: una orden maker es una opción gratuita que le vendes al mercado. Alguien la ejerce cuando le conviene. Tu backtest cobraba la prima y olvidaba que la opción también podía pagarse.
Las operaciones que no conseguiste cambian la estrategia, no solo el coste
Este es el punto sobre el que más quiero que reflexiones. Si modelas mal la ejecución taker, obtienes las operaciones correctas al precio equivocado, y corregir las comisiones resuelve casi todo. Si modelas mal la ejecución maker, obtienes un conjunto de operaciones completamente distinto. Aproximadamente 2,900 de tus 4,180 entradas nunca ocurrieron. Algunas eran tus mejores señales, en velas que se dispararon y luego revirtieron: justo el patrón en que el mercado se escapó sin ti.
Así que la rama de órdenes no ejecutadas necesita lógica real. ¿Qué hace la estrategia cuando la entrada no se ejecuta antes de que caduque la señal? ¿Persigue el precio con una orden taker y paga el spread más el impacto? ¿Vuelve a colocar la orden más abajo y acepta una base de entrada distinta? ¿Se salta la operación y se queda sin posición? Cada opción produce una curva de capital sustancialmente distinta, y ninguna equivale a «asume que se ejecutó». En nuestras pruebas, añadir una regla honesta para perseguir el precio (cruzar después de 20 segundos sin ejecución, con deslizamiento limitado a 3 bp) recuperó aproximadamente un tercio de las operaciones perdidas y cerca de la mitad de la diferencia entre los Sharpe del backtest ingenuo y la simulación de cola. Es un resultado realmente interesante, y solo aparece cuando el modelo de ejecución es lo bastante realista como para que la pregunta tenga sentido.
Una comprobación rápida, en 10 minutos: toma tu registro de paper trading en vivo y compáralo con el backtest durante la misma ventana. Compara la tasa de ejecución, no el PnL. Si el backtest ejecuta el 100% de las órdenes pasivas y el paper trading ejecuta el 34%, no estás comparando estrategias: tienes un bug en el modelo de ejecución. Corrígelo antes de mirar una sola cifra de rentabilidad.
2 detalles más, ya que te tengo aquí
Rechazos de órdenes post-only. Si usas post-only para garantizar la tarifa maker y el libro se mueve entre tu decisión y la confirmación de la plataforma, la orden se rechaza en vez de quedar en el libro. En nuestros registros de paper trading, eso ocurre en el 3-6% de los intentos con BTCUSDT en horario normal y supera el 15% durante el minuto posterior a la publicación del IPC de EE. UU. Una orden rechazada no es una orden ejecutada ni una orden pasiva sin ejecutar: es una operación que nunca existió. Si tu backtest no contempla ese estado, el recuento de operaciones se infla justo en los regímenes que más te interesan.
Prevención de autonegociación y tu propia huella. Con 0.4 BTC no mueves BTCUSDT, así que puedes ignorarlo. Pero comentaste que querías probar esto en un perp de una altcoin de capitalización media donde el valor nocional del mejor nivel suele estar por debajo de $15k. Ahí, tu orden sí representa una parte importante de la cola, y el volumen por delante que registras incluye el efecto de que tu última orden ya estaba ahí. Cuando tu tamaño supera aproximadamente el 10% del volumen en reposo, la simulación debe tener en cuenta que los demás participantes reaccionan a ti. Y, francamente, llegado ese punto confiaría más en el paper trading que en cualquier simulación que podamos escribir tú o yo.
Vuelve a ejecutarlo con la simulación de cola y envíame la tabla de mark-out desglosada por tipo de ejecución. Si el grupo del rebote sigue aportando la mayor parte de la ventaja y el grupo que atravesó el nivel no se la come entera, quizá tengas algo que valga la pena probar en paper trading. Si todo dependía de las 2,900 ejecuciones que nunca habrías conseguido, mejor descubrirlo ahora que después de 4 semanas viendo que la cuenta de paper trading no hace lo que prometía el notebook.
← Todos los artículos
