Consideraciones Avanzadas para las Reglas de Salida

Qué significan las “reglas de salida” y por qué importan las consideraciones avanzadas

Las reglas de salida son las condiciones predefinidas que determinan cuándo y cómo se cierra (o se termina de otro modo) una posición. En un contexto avanzado, el objetivo no es solo elegir una regla conceptual (por ejemplo, “cerrar cuando se alcance un nivel”), sino especificar los insumos y la lógica operativa con la suficiente claridad para que otra persona pueda aplicar las mismas reglas y reproducir el razonamiento.

Las consideraciones avanzadas importan porque el resultado real de una salida rara vez está determinado únicamente por el texto de la regla. También depende de factores que pueden cambiar entre los supuestos del backtesting y la ejecución en vivo: costos de transacción, calidad de ejecución de órdenes, huecos de mercado y los supuestos de datos/proveedor utilizados para calcular los niveles de disparo. Dado que estos factores varían, la lógica de las reglas de salida debe redactarse de modo que la mecánica estable sea distinguible de las condiciones variables.

Mecanismo: mecánica de regla estable vs. condiciones variables

Una forma práctica de analizar las reglas de salida es separarlas en (1) mecánica de la regla y (2) condiciones variables.

1) Mecánica de la regla (la parte estable)

La mecánica de la regla define qué evento termina la posición. Las mecánicas comunes incluyen:

Salidas disparadas por precio: cerrar cuando el precio cruza un umbral (por ejemplo, alcanzar un nivel de “toma de ganancias” o un nivel de “stop”).
Salidas disparadas por tiempo: cerrar después de un límite de tiempo, independientemente del precio.
Salidas basadas en estado: cerrar cuando cambia algún estado de la posición (por ejemplo, una orden se vuelve inválida o una condición de nivel superior ya no es verdadera).
Salidas de gestión: cerrar parte de la posición, mover un límite protector o cambiar de una condición de cierre a otra.

Para que estas mecánicas sean verificables, las reglas avanzadas suelen especificar:

Definición del disparador: qué significa “cruzar” (toque vs. desigualdad estricta) y si el precio relevante es bid, ask, last o mid.
Supuesto del tipo de orden: si la regla espera ejecución de mercado, ejecución limitada o comportamiento de tipo stop.
Momento de evaluación: cuándo la regla verifica las condiciones (en cada tick, al cierre de la vela o en intervalos programados).

2) Condiciones de ejecución variables (la parte que puede diferir)

Incluso una mecánica escrita con precisión puede producir resultados realizados diferentes si las condiciones de ejecución difieren. Ejemplos de condiciones variables incluyen:

Estructura de spread y costos: la distancia entre los precios de ejecución y el impacto de comisiones/swaps.
Deslizamiento y liquidez: la diferencia entre los precios solicitados y los precios de llenado.
Restricciones de llenado de órdenes: ejecuciones parciales, tamaño mínimo y restricciones de margen.
Diferencias en la fuente de datos: las series de precios históricas pueden representar precios “efectivos” diferentes a los del trading en vivo.

Una especificación avanzada de reglas de salida debe nombrar estos supuestos explícitamente para cualquier cálculo o ejemplo. Sin esos supuestos, dos personas pueden aplicar la “misma” regla de salida y aun así calcular resultados diferentes.

Evidencia y pensamiento basado en ejemplos: casos límite que rompen las salidas simples

Debido a que la ejecución real es compleja, las reglas de salida avanzadas deben anticipar casos límite. La clave es probar o razonar sobre las situaciones donde la interpretación de la regla se vuelve ambigua.

Caso límite 1: Ambigüedad del disparador (toque vs. cruce, y qué precio)

Supongamos que una regla dice “cerrar cuando el precio alcance X”. La interpretación puede variar:

¿“Alcanzar” incluye el toque (igual a X) o solo el cruce (pasa de abajo a arriba)?
¿Qué precio se utiliza para la comparación: bid, ask, last o mid?

Si no se define esto, el mismo umbral puede llevar a salidas más tempranas o más tardías dependiendo del método de evaluación.

Caso límite 2: Comportamiento tipo hueco y no llenado de la orden

Muchas reglas de salida asumen implícitamente que el mercado pasará a través del umbral de manera fluida. En la práctica, el mercado puede saltar de una región a otra entre verificaciones.

Si la regla asume un límite protector de tipo stop pero el mercado lo salta, el precio de llenado puede ser peor que el límite.
Si la regla utiliza una orden de tipo límite para salir y el precio se aleja, la orden puede no llenarse.

Esta es una limitación material: las reglas de salida pueden no ejecutarse como se pretende, dependiendo del tipo de orden y de la velocidad/estructura del movimiento del precio.

Caso límite 3: Salidas parciales e inconsistencia entre los componentes de la regla

Si una regla cierra parte de una posición y luego actualiza los límites, surgen casos límite en torno a:

cómo se rastrea la cantidad restante,
si el límite actualizado se aplica inmediatamente después del llenado parcial,
y si la siguiente evaluación utiliza el precio promedio posterior al llenado o la referencia de entrada original.

Si la implementación es inconsistente, se pueden terminar con cantidades, límites o disparadores repetidos que no coinciden.

Caso límite 4: Salidas basadas en tiempo que interactúan con disparadores de precio

Una regla combinada (salida por tiempo con protección de precio) puede entrar en conflicto:

Si el tiempo expira en el mismo momento en que ocurriría un disparador de precio, ¿qué regla gana?
¿La salida se evalúa una sola vez en ese límite de tiempo, o continuamente en el intervalo?

Las implementaciones avanzadas definen reglas de desempate: por ejemplo, el orden de evaluación, la prioridad, o si ambas condiciones se verifican antes de decidir.

Limitaciones y riesgos: qué puede salir mal y cómo reconocerlo

Las reglas de salida reducen la incertidumbre solo sobre la lógica de la terminación. No eliminan la incertidumbre sobre la ejecución.

Limitaciones materiales

Incertidumbre de ejecución: El deslizamiento y las diferencias de spread significan que los resultados realizados pueden divergir de los esperados.
Riesgo de implementación: Una regla que es correcta en papel puede aplicarse incorrectamente debido a diferencias en datos, sincronización o manejo de órdenes.
Riesgo de modelo: Las relaciones históricas no establecen resultados futuros, y los supuestos del backtesting (especialmente sobre llenados) pueden no coincidir con la realidad.
Dependencia del proveedor/datos: La evaluación del disparador depende del feed de precios elegido y de cómo representa los valores bid/ask/last.

Modos de fallo a tener en cuenta

Supuestos no especificados: Si la regla no define qué precio se verifica, las comparaciones se vuelven no reproducibles.
Órdenes que no se ejecutan: Las salidas de tipo límite pueden permanecer sin llenar; los límites protectores pueden ejecutarse a precios peores de lo esperado.
Prioridad de regla ambigua: Los conflictos entre múltiples condiciones de salida pueden producir resultados inconsistentes.

Verificación y siguientes preguntas: comprobar de forma independiente los hechos de las reglas de salida

Para verificar de forma independiente las afirmaciones sobre las reglas de salida, concéntrese en elementos reproducibles e inspeccionables.

Qué verificar

Integridad de la especificación de la regla: ¿Cada disparador define el tipo de precio evaluado y el momento de evaluación?
Transparencia de los supuestos: ¿Están claramente indicados los supuestos de costos, spreads y deslizamiento para cualquier cálculo?
Realismo en el manejo de órdenes: ¿La implementación modela el comportamiento de llenado (incluyendo llenados parciales y no llenados) de una manera que coincida con los tipos de orden previstos?
Resolución de conflictos: Si múltiples condiciones pueden dispararse, ¿la regla establece prioridad y desempate?

Preguntas útiles para continuar

¿Qué definición de precio (bid/ask/last/mid) se utiliza para los disparadores?
¿Qué cadencia de evaluación se asume (tick por tick, cierre de vela o verificaciones programadas)?
¿Qué sucede si se cumple una condición de salida pero la orden no puede llenarse?