Cómo definir las reglas de un sistema de trading

De una idea de trading a una regla que realmente se pueda comprobar

Supongamos que alguien describe su método así:

“Compro cuando el mercado está alcista y aparece un buen retroceso.”

Suena razonable. El problema es que prácticamente cada palabra importante está abierta a interpretación.

¿Qué significa “alcista”? ¿Que el precio viene subiendo? ¿Que está por encima de una media? ¿Que ha hecho máximos y mínimos crecientes?

¿Qué es un “buen” retroceso? ¿Hasta dónde tiene que caer? ¿Durante cuánto tiempo? ¿Qué lo diferencia de un cambio de tendencia?

Y aunque resolvamos eso, todavía falta saber qué activa exactamente la entrada.

La regla empieza a ser útil cuando sustituimos adjetivos por condiciones observables.

No estoy diciendo que una media móvil, un ATR o cualquier otro criterio sea “la forma correcta” de definir esas palabras. La definición dependerá de tu hipótesis.

Lo importante es otra cosa: la condición debe poder decidirse antes de conocer el resultado de la operación.

Ese detalle separa una regla de una explicación retrospectiva.

Qué partes debes definir en las reglas de tu sistema

Cuando pensamos en las reglas de un sistema, es fácil obsesionarse con la entrada. Para mí, ese es uno de los primeros errores que conviene corregir.

Una estrategia de trading no queda definida porque sepamos cuándo comprar. También necesitamos saber dónde puede operar, bajo qué condiciones, cuánto riesgo acepta y qué hace después de abrir la posición.

Una ficha de reglas razonablemente completa debería cerrar estas decisiones:

No todos los sistemas necesitan la misma cantidad de reglas. Un sistema sencillo puede resolver varias de estas decisiones con pocas condiciones.

De hecho, yo evitaría confundir precisión con complejidad. Añadir diez filtros no convierte una metodología en mejor. A veces simplemente crea diez oportunidades nuevas para adaptar el sistema al pasado.

La función de las reglas es cerrar decisiones relevantes, no hacer que el documento parezca sofisticado.

Separa contexto, setup y trigger de entrada

Esta distinción arregla muchos sistemas que parecen definidos pero en realidad siguen siendo ambiguos.

El contexto responde: ¿cuándo tiene sentido buscar esta operación?

El setup responde: ¿qué configuración concreta estoy esperando?

El trigger responde: ¿qué debe ocurrir ahora para que efectivamente entre?

Imagina, solo como ejemplo didáctico, una metodología que intenta comprar retrocesos dentro de movimientos alcistas.

“Hay tendencia alcista” podría formar parte del contexto. “El precio retrocede hasta determinada zona” podría ser el setup. “La vela cierra de nuevo por encima de una referencia previamente definida” podría ser el trigger.

Son tres decisiones distintas.

Si las metes todas dentro de “compro buenos retrocesos”, tendrás un problema cuando hagas una operación y después intentes averiguar si realmente cumplía tu sistema.

Aquí aparece una regla mental que me gusta mucho:

Antes del trigger, observas. Cuando aparece el trigger y se cumplen las demás condiciones, decides.

Eso obliga a separar la preparación de una operación del evento que realmente autoriza ejecutarla.

Define cuándo se evalúa la regla, no solo qué debe ocurrir

Este punto parece pequeño, pero puede cambiar por completo un sistema.

Supongamos que escribes:

“Entro cuando el precio cruza por encima de la media móvil.”

¿Cuándo?

¿En cuanto cotiza un instante por encima? ¿Cuando una vela de cinco minutos cierra arriba? ¿Cuando cierra la vela de una hora? ¿Debe permanecer encima durante dos cierres?

No son versiones equivalentes.

Lo mismo ocurre con indicadores. Un RSI puede atravesar un nivel durante la formación de una vela y terminar cerrando de nuevo debajo. Una condición evaluada intrabar puede producir operaciones diferentes de otra evaluada únicamente al cierre.

Por eso una regla debería especificar el evento y el momento en el que se comprueba.

Hay además una segunda cuestión: el momento de la señal no siempre coincide con el momento de ejecución.

Si necesitas conocer el cierre completo de una vela para saber que existe señal, no deberías asumir alegremente que pudiste entrar antes de disponer de ese cierre. Al construir el backtest, esta diferencia puede terminar introduciendo información futura de forma accidental. Más adelante veremos este problema con detalle al estudiar el look-ahead bias.

Esta es una de esas zonas donde probar la mecánica en una plataforma ayuda mucho. Pepperstone ofrece cuentas demo en MT4, MT5, cTrader, TradingView y su propia plataforma; su documentación también aclara que una demo sirve para probar estrategia y ejecución, pero que no necesariamente reproduce todas las condiciones de una cuenta real.

Si quieres comprobar si las órdenes y condiciones que has escrito pueden ejecutarse como imaginas, puedes probar Pepperstone desde nuestro enlace. En esta fase yo lo utilizaría como un entorno para detectar reglas mal definidas, no como demostración de que el sistema funciona.

El stop y el riesgo son dos reglas diferentes

Otro hueco frecuente aparece cuando alguien escribe:

“Stop por debajo del último mínimo.”

Eso todavía plantea varias preguntas. ¿Qué mínimo? ¿El de la vela de entrada? ¿El último swing? ¿Cómo defines un swing? ¿Hay algún margen? ¿Qué ocurre si la distancia hasta ese nivel es enorme?

Pero incluso después de resolver todo eso, solo habremos definido dónde sale la operación si el escenario falla.

Todavía no sabemos cuánto dinero estás arriesgando.

Supongamos que dos operaciones utilizan exactamente el mismo stop de 20 puntos. En una controlas una posición pequeña y en otra una diez veces mayor. La distancia del stop es idéntica; la pérdida monetaria potencial no.

Por eso conviene separar:

Invalidación técnica: qué comportamiento del mercado invalida la operación.

Regla de tamaño: qué exposición puedes asumir para que esa invalidación produzca un riesgo compatible con tu sistema.

Imagina, como simple ejemplo, que una cuenta tiene 100,000 MXN y el sistema utiliza un riesgo máximo planificado de 0.5% en esa operación. Eso equivaldría a 500 MXN antes de considerar diferencias entre pérdida planificada y ejecución efectiva.

El 0.5% no es una recomendación universal. Lo importante es entender el mecanismo: primero defines dónde queda invalidado el trade; después ajustas el tamaño de la posición al riesgo que aceptas, no al revés.

Una salida necesita tanta precisión como una entrada

Muchos sistemas tienen entradas llenas de condiciones y salidas descritas con una frase como “cerrar cuando parezca que el movimiento se agota”.

Eso hace que una parte enorme del resultado dependa de decisiones que no están definidas.

Tu salida puede estar determinada por precio, tiempo, volatilidad, una señal contraria, un stop dinámico, un objetivo de beneficio o una combinación de varias condiciones. No hay una solución universal.

Lo que sí necesitas es saber qué evento obliga a hacer qué.

Y si existen varias salidas, hay que definir prioridad.

Imagina que tu sistema dice que cierras en un objetivo determinado, pero también que sales cuando aparece una señal contraria. ¿Qué ocurre si ambas condiciones aparecen prácticamente al mismo tiempo? ¿Cuál manda?

Esa pregunta parece exageradamente específica hasta que aparece durante una prueba. Entonces descubres que dos decisiones distintas pueden producir dos historiales de operaciones completamente diferentes.

Las reglas no solo describen situaciones normales. También tienen que resolver los conflictos razonablemente previsibles.

Las reglas de no operación importan tanto como las de entrada

Un sistema también necesita poder decir “hoy no hay trade”.

Piensa en una metodología que funciona únicamente durante determinado horario. O que no permite abrir otra posición mientras exista una anterior. O que cancela una señal cuando el spread supera cierto nivel. O que excluye determinadas condiciones de volatilidad.

Cada una puede ser una regla perfectamente legítima.

Pero tiene que estar definida.

“Evitar spreads altos” no sirve si nunca decides qué significa “alto”.

“No operar alrededor de noticias” tampoco sirve si después puedes llamar “alrededor” a cinco minutos, media hora o dos horas dependiendo de cómo salió la operación.

Cuando una excepción aparece después de ver una pérdida, conviene preguntarse algo incómodo: ¿esa excepción existía antes de que ocurriera el trade o la estoy creando porque ya conozco el resultado?

El segundo caso es especialmente peligroso. Una regla que siempre llega después del error puede terminar explicando perfectamente el pasado y siendo inútil para el futuro.

Define qué ocurre en las zonas grises

Los límites exactos merecen especial atención.

Si una regla exige RSI inferior a 30, ¿qué ocurre exactamente en 30.00?

Si solo puedes tener una posición, ¿qué haces cuando aparecen dos señales válidas simultáneamente?

Si una orden no se ejecuta durante tres velas, ¿sigue activa indefinidamente?

Si se produce un gap por encima de tu precio previsto de entrada, ¿entras igualmente, cancelas o recalculas?

Si el mercado está cerrado cuando aparece una condición calculada con datos externos, ¿qué referencia utilizarás al reabrir?

No necesitas escribir un manual de 80 páginas antes de hacer tu primera prueba. Pero sí debes resolver aquellas situaciones que puedan cambiar materialmente las operaciones que tu sistema genera.

Yo lo veo como programar decisiones, aunque después vayas a ejecutar manualmente: cada vez que aparezca un “depende”, tienes que decidir si ese depende puede definirse ahora o si conscientemente quieres dejarlo a juicio del trader.

Esto nos lleva directamente a la siguiente lección del curso, donde veremos la diferencia entre trading discrecional y sistemático. No hace falta resolver esa comparación aquí. Solo quédate con que una metodología discrecional también puede tener reglas muy serias.

Congela las reglas antes de mirar los resultados

Aquí entramos en una de las costumbres que más ayuda a pensar con rigor.

Cuando tengas una primera versión suficientemente completa, ponle un número.

Por ejemplo:

Sistema v1.0

A partir de ahí, esa versión se queda quieta mientras la evalúas.

¿Por qué?

Porque resulta extremadamente tentador ver una operación perdedora y decir:

“Esta no debería contar porque el movimiento previo era demasiado pequeño.”

Después aparece otra:

“Esta tampoco, porque estaba demasiado cerca de una resistencia.”

Y otra:

“Aquí había poca volatilidad.”

Quizá esas observaciones contengan información valiosa. El problema es introducirlas retroactivamente dentro del mismo experimento.

Si modificas continuamente las reglas después de observar qué habría pasado, dejas de estudiar el sistema original y empiezas a construir una metodología cada vez más adaptada a los datos que ya conoces.

Es una de las puertas de entrada al overfitting en trading.

Por eso yo separaría siempre dos momentos:

Primero definir.

Después probar.

Si durante la prueba descubres una ambigüedad real, puedes corregirla. Pero registra el cambio y considera que estás trabajando con otra versión.

Más adelante aprenderemos formalmente qué es el backtesting, su muestra, sus sesgos y cómo interpretar los resultados. Aquí todavía no necesitamos hacer nada de eso. Lo único imprescindible es llegar allí con reglas suficientemente estables como para saber qué estrategia estamos probando.

Ejemplo: así se ve una hoja de reglas mucho más difícil de reinterpretar

Vamos a construir un ejemplo exclusivamente didáctico.

No es una estrategia recomendada ni existe aquí evidencia de que tenga ventaja. Los parámetros son arbitrarios. Lo que estamos observando es la calidad de la definición.

No me interesa si esta combinación concreta es rentable. Todavía no sabemos eso.

Me interesa que compares esta ficha con:

“Compro buenos retrocesos cuando la tendencia sea alcista y cierro si parece que pierde fuerza.”

En el segundo sistema cada operación permite una explicación distinta.

En el primero puedes discutir si las reglas son inteligentes, pero primero puedes identificar con bastante claridad cuándo se cumplen.

Esa diferencia es enorme.

Después, cuando recorras el proceso completo de crear un sistema de trading paso a paso, podrás integrar hipótesis, reglas, pruebas y evaluación sin confundir unas fases con otras.

Prueba la claridad de las reglas antes de probar su rentabilidad

Antes de abrir años de históricos, yo haría una prueba mucho más sencilla. Lee tu documento como si no fueras la persona que lo escribió y comprueba esto:

• ¿Dos personas con los mismos datos podrían identificar aproximadamente las mismas operaciones?
• ¿Palabras como “fuerte”, “limpio”, “cerca”, “confirmado” o “excesivo” tienen una definición concreta?
• ¿Está claro cuándo se evalúa cada condición: durante la vela, al cierre o en otro momento?
• ¿Has separado la aparición de la señal de la ejecución de la orden?
• ¿Entrada, invalidación, tamaño, gestión y salida están definidas?
• ¿Sabes qué condiciones cancelan una señal y qué regla gana cuando dos instrucciones chocan?
• ¿Puedes congelar esta versión y probarla sin inventar excepciones después de conocer los resultados?

Si alguna respuesta es no, todavía no necesitas más indicadores. Necesitas mejores reglas.

Este control no te dice si el sistema gana dinero. Solo comprueba que existe un objeto suficientemente definido como para poder evaluarlo.

Y ese es exactamente el objetivo de esta lección.

Un sistema preciso no tiene que ser complicado

Quiero cerrar con un error que aparece mucho cuando alguien intenta “sistematizar” su trading.

Después de entender que las reglas deben ser específicas, empieza a añadir condiciones:

RSI, tres medias, volumen, estructura, ATR, sesión, divergencias, dos temporalidades y cinco excepciones.

Ahora todo parece muy profesional.

Pero una cosa es que el sistema tenga reglas claras y otra que necesite muchas.

Cada condición debería existir porque responde a una razón relacionada con tu hipótesis, no porque mejora visualmente un histórico.

Si no puedes explicar qué problema resuelve un filtro, yo no lo añadiría todavía.

Primero construye una versión sencilla que sea coherente con la hipótesis. Después deja que el proceso de prueba te dé información. Un sistema no mejora acumulando decisiones; mejora cuando cada decisión tiene una función clara.

Con qué debes quedarte

Definir las reglas de un sistema consiste en convertir una hipótesis en decisiones que puedan reconocerse, ejecutarse y registrarse sin depender constantemente de la interpretación posterior.

No necesitas saber todavía si las reglas son rentables. Tampoco necesitas optimizarlas.

Necesitas poder responder, antes de ver qué hizo después el precio: qué mercado estás operando, qué contexto aceptas, qué constituye un setup, qué activa la entrada, cuándo queda invalidada, cuánto puedes arriesgar, cómo sales y qué situaciones te obligan a no operar.

Si eso está escrito con claridad, ya puedes hacer algo mucho más importante que “sentir” que tienes una estrategia: puedes empezar a comprobarla.

El siguiente paso es entender cuánto espacio puede —o debería— quedar para el juicio humano. Eso lo trabajaremos en Trading discrecional vs sistemático.

Y cuando quieras llevar tu hoja de reglas a un entorno donde puedas practicar la ejecución, puedes revisar Pepperstone y la promoción disponible mediante nuestro enlace. Comprueba siempre las condiciones de la entidad y cuenta que te correspondan; la propia documentación de Pepperstone señala que sus términos pueden variar según la entidad regulada con la que se abra la cuenta.

Primero reglas. Después evidencia. Y solo después tiene sentido pensar en operar el sistema con capital real.