Cómo probar una estrategia de trading: de la observación a las reglas del challenge

Empieza por una observación que puedas verificar

Por ejemplo: «En un nivel marcado de antemano, la venta agresiva aumentó mientras la siguiente vela cerrada no extendió el mínimo». Anota el instrumento, el mercado, la sesión, el tamaño de vela, la zona horaria y la cobertura disponible. Guarda las velas del entorno, no solo el momento atractivo.

El footprint agrupa las operaciones ejecutadas por precio y por lado agresor. Un heatmap de liquidez exige observaciones de profundidad aparte. Las operaciones por sí solas no muestran las órdenes que esperaron, desaparecieron o se repusieron. Una venta fuerte con poco avance a la baja puede ser una candidata a absorción; no identifica a ningún participante ni prueba la dirección siguiente.

• Disponible: precios de velas cerradas, volumen ejecutado en el bid y en el ask, marcas de tiempo y la cobertura realmente cargada.
• No establecido: reserva oculta, la intención de un participante, el precio futuro o la posición histórica en la cola.
• Control: marca el nivel con la información disponible antes de la señal. Un nivel descubierto con el perfil del día siguiente introduce sesgo de anticipación.

Pide una regla comprobable, no una respuesta ganadora

Aporta la observación y sus límites. Pide al asistente que distinga la evidencia de la explicación y que enumere los campos que necesitaría una regla. El asistente del footprint puede proponer una configuración de gráfico para que la apliques; el asistente del heatmap explica la evidencia registrada de una zona seleccionada. Sus contextos son distintos.

«Aquí tienes el instrumento, la sesión, las velas cerradas y mi nivel marcado de antemano. Describe lo observado sin atribuir intención oculta. Propón una condición de entrada determinista usando solo estos campos. Indica la ventana de lectura, la invalidación, el momento de entrada, las condiciones de salida y los datos ausentes que podrían invalidar la prueba».

Este es un prompt de ejemplo, no una respuesta de modelo registrada. Contrasta la propuesta con los datos. El asistente de Scripting puede ayudarte a editar y ejecutar un borrador, pero un borrador ejecutable no es prueba de trading rentable.

Escribe la regla completa antes de mirar los resultados

Una especificación mínima de investigación podría decir: evaluar un nivel marcado de antemano solo en vela cerrada; exigir que esa vela cierre de nuevo por encima del nivel; entrar en la apertura de la vela siguiente; usar stop y objetivo fijos; permitir una sola posición y ninguna entrada nueva tras una hora de corte definida. Fija la ventana de lectura y el umbral de señal exactos antes de probar. Es una plantilla de investigación, no una configuración recomendada.

Especificación de investigación — pseudocódigo, no una API de Senzoukria

En cada nueva vela cerrada:
  confirmar que los datos requeridos están presentes
  usar solo el nivel fijado antes de esta vela
  evaluar la señal declarada y el filtro de sesión
  si no hay posición y se cumplen todas las condiciones:
    solicitar entrada en la apertura de la vela SIGUIENTE
    adjuntar el stop, el objetivo y el tamaño declarados

Registrar cada cambio como una nueva versión de la estrategia.

Las estrategias en JavaScript y Python tienen rutas de backtest histórico en la aplicación de escritorio. Python necesita su runtime embebido. Los scripts en C++ usan un runtime WebAssembly con interfaz limitada y no tienen backtest histórico. Elige el lenguaje según la operación que necesitas; no son entornos de ejecución intercambiables.

Usa primero Run para detectar errores de sintaxis, campos ausentes y salidas inválidas sobre velas sintéticas. Después guarda una versión y pruébala en un intervalo histórico declarado. No llames backtest a esa primera ejecución sintética.

Haz visibles los costes y los límites de las reglas

Los resultados históricos dependen del modelo de ejecución. El backtest de estrategias del escritorio decide en velas cerradas, entra en la apertura siguiente y modela las salidas con los precios de la vela y los costes configurados. No reconstruye la cola del mercado. Documenta el supuesto cuando el stop y el objetivo puedan tocarse dentro de la misma vela.

El ejemplo siguiente aísla la pregunta siguiente: ¿qué ocurre cuando los resultados diarios se encuentran con las restricciones de una cuenta? Sus ocho días fueron inventados a propósito. No los genera la regla anterior ni proceden de una cuenta real.

Tres experimentos para ejecutar

1. Reinicia y baja el drawdown máximo a 600 $. El día 3 cruza el suelo móvil por cierres. Cambia a un suelo fijo: esos mismos tres primeros días quedan por encima. Cambió la regla, no los resultados del mercado.
2. Reinicia y aumenta los contratos. Crecen a la vez los resultados brutos y los costes por contrato. Una posición mayor puede alcanzar un umbral de pérdida antes de llegar al objetivo.
3. Reinicia y cambia el orden de los días. Una reordenación puede mover el primer incumplimiento o el día de aprobación. Es una prueba de sensibilidad sobre resultados existentes, no un pronóstico ni una probabilidad calibrada.

Comprueba la aritmética

Con un contrato y 10 $ por ida y vuelta, cada día de dos operaciones cuesta 20 $. Los tres primeros días netos son 480 $, 430 $ y −670 $. El saldo llega a 50 910 $ y luego a 50 240 $: un drawdown máximo de cierre a cierre de 670 $. Con una tolerancia móvil de 600 $ el suelo está en 50 310 $ y el tercer día lo incumple. Un suelo fijo de 49 400 $ no se incumple.

Un modelo por cierres diarios no puede detectar un incumplimiento intradía recuperado antes del cierre. Una regla real puede usar el capital no realizado, un tope del suelo móvil, otros límites de sesión, actividad mínima, cláusulas de consistencia o restricciones de cobro. Introduce solo reglas verificadas y señala cada cláusula ausente antes de interpretar un informe de challenge del escritorio.

Cuestiona el resultado antes de cambiar la regla

• Reserva los datos más recientes. Elige los periodos de desarrollo y de evaluación antes de ajustar parámetros. Optimizar una y otra vez sobre el periodo reservado lo convierte en datos de entrenamiento.
• Cambia un supuesto cada vez. Sube los costes, altera el filtro de sesión, examina valores de parámetros vecinos e inspecciona las operaciones perdedoras.
• Conserva el denominador. Anota cuántas variantes de estrategia probaste, no solo la que te quedaste. Un resultado llamativo tras muchos intentos exige evidencia más fuerte.
• Separa el saldo del flujo de caja. Las cuotas de evaluación, los resets, las fases fondeadas y los plazos de cobro tienen sus propias reglas. El pequeño modelo didáctico anterior no las modela.

La aplicación de escritorio incluye búsqueda de parámetros, walk-forward e informes de robustez para las pruebas históricas admitidas, además de un simulador de challenge con ciclo de vida y costes modelados. Esos informes resumen su protocolo y los datos suministrados. Una etiqueta favorable no certifica una ventaja futura.

Elige la ejecución de forma deliberada

Usa el replay para inspeccionar las decisiones y el comportamiento simulado de la cuenta antes de decidir si una estrategia debe entrar en una cuenta conectada. Solo análisis, ejecución manual y estrategia armada son decisiones operativas distintas.

Senzoukria admite enrutamiento de órdenes y automatización opcional de estrategias mediante una cuenta Rithmic compatible. El piloto automático exige armado explícito, permisos de la cuenta, límites configurados, un gráfico montado y la aplicación de escritorio en marcha. Confirma las reglas vigentes de tu firma y de tu cuenta. El agente de IA general no puede armarlo por ti. Los flujos de análisis cripto no implican enrutamiento de órdenes en Binance o Bybit.

STOP desarma la estrategia y solicita el cierre de posiciones; comprueba la respuesta del bróker y las posiciones reales. Una solicitud no es una ejecución garantizada, y los límites de la aplicación no eliminan el slippage ni el riesgo de conexión. Mantén un procedimiento escrito para desconexiones y órdenes rechazadas.