| Parte del sistema | La pregunta que debe quedar respondida |
|---|---|
| Hipótesis | ¿Qué comportamiento del mercado estás intentando explotar? |
| Mercado | ¿Dónde puede aparecer esa oportunidad? |
| Temporalidad y horario | ¿Cuándo buscas operaciones? |
| Contexto o setup | ¿Qué debe estar ocurriendo antes de plantearte una entrada? |
| Trigger | ¿Qué evento exacto activa la operación? |
| Invalidación y stop | ¿Qué demostraría que la idea ya no merece seguir arriesgando capital? |
| Riesgo | ¿Cuánto puedes perder si la operación falla? |
| Salida | ¿Qué condiciones cierran la posición? |
| No operación | ¿Cuándo está prohibido entrar aunque aparezca parte del setup? |
| Costes y ejecución | ¿Qué spread, comisión, slippage u otras fricciones debes contemplar? |
| Versión | ¿Qué reglas quedan congeladas antes de empezar a probar? |
Para mí, esta tabla resume bastante bien cuándo una idea empieza a convertirse de verdad en un sistema.
Paso 1. Empieza por una hipótesis, no por un indicador
El punto de partida debería ser una explicación razonable de por qué podría existir una oportunidad repetible.
No necesitas demostrarla todavía. Precisamente vas a construir el sistema para poder comprobarla después.
Una idea como esta es demasiado vaga:
“Voy a comprar cuando vea fuerza porque normalmente el precio sigue subiendo.”
¿Qué significa fuerza? ¿Durante cuánto tiempo? ¿En cualquier mercado? ¿Dónde entras exactamente? ¿Cuándo deja de ser válida la idea?
Una hipótesis útil se parece más a esto:
“Quiero comprobar si, bajo una tendencia previamente definida, determinados retrocesos seguidos de una reanudación del movimiento presentan una relación entre ganancias y pérdidas suficientemente favorable después de costes.”
Sigue sin demostrar nada, pero ya contiene algo que puedes intentar falsar.
Eso es importante porque el edge en trading no aparece por describir una historia convincente del mercado. Primero tienes una hipótesis de ventaja. Después necesitas evidencia.
Si esta parte todavía te resulta abstracta, vuelve a la lección sobre cómo crear una hipótesis de trading. Aquí voy a asumir que ya llegas con una idea candidata y quieres convertirla en un sistema completo.
Paso 2. Define el campo de juego antes de diseñar la entrada
Uno de los errores que más complican un sistema es intentar que sirva para todo.
“Operaré cualquier activo cuando aparezca mi patrón” parece flexible. En realidad, introduce una cantidad enorme de variables: liquidez, volatilidad, horarios, spread, comportamiento overnight, tamaño mínimo de posición y forma de ejecución, entre otras.
Yo empezaría delimitando el sistema.
Si puedes mirar el mercado dos veces al día, por ejemplo, tiene poco sentido diseñar una metodología que necesite tomar decisiones cada tres minutos. El sistema tiene que ser compatible con la realidad del trader que debe ejecutarlo.
Define, como mínimo, el instrumento o universo que vas a estudiar, la temporalidad de decisión, los horarios permitidos y cualquier condición de mercado imprescindible para que tu hipótesis tenga sentido.
Hay una diferencia importante entre decir:
“Opero EUR/USD.”
y decir:
“Este sistema solo buscará oportunidades en EUR/USD utilizando velas de una hora y únicamente dentro del horario definido en sus reglas.”
La segunda versión reduce grados de libertad. Y cuantos menos huecos dejes para decidir retrospectivamente qué “querías decir”, mejor podrás evaluar después lo que realmente construiste.
Si quieres ir preparando un entorno donde más adelante practicar la ejecución, Pepperstone ofrece cuentas demo y acceso a MT4, MT5, TradingView, cTrader y su propia plataforma. No necesitas depositar dinero para hacer el trabajo que estamos haciendo ahora.
Puedes revisar Pepperstone y consultar la promoción disponible mediante nuestro enlace. La promoción y sus condiciones pueden cambiar, así que conviene comprobarlas en el momento del alta.
Paso 3. Separa el setup del trigger de entrada
Esta distinción parece pequeña, pero mejora muchísimo la claridad de un sistema.
El setup describe el entorno que debe existir para que una posible operación tenga sentido. El trigger es el evento concreto que finalmente permite entrar.
Imagina que tu lógica busca continuaciones de tendencia después de un retroceso. “Hay una tendencia alcista y el mercado retrocede” podría formar parte del setup.
Eso todavía no te dice cuándo compras.
El trigger tendría que añadir algo observable: un cierre por encima de un nivel definido, la ruptura de un máximo determinado, una señal específica de tu indicador o cualquier otra condición que hayas decidido estudiar.
| Regla ambigua | Pregunta que sigue sin responder | Lo que debería definir el sistema |
|---|---|---|
| “Comprar un buen pullback” | ¿Qué convierte un retroceso en “bueno”? | Condiciones observables del pullback |
| “Entrar cuando vuelva la fuerza” | ¿Qué significa que volvió? | Evento concreto que activa la entrada |
| “Operar tendencias claras” | ¿Qué hace que una tendencia sea clara? | Criterio previamente definido |
| “Salir si el mercado se debilita” | ¿Qué comportamiento significa debilidad? | Condición objetiva o discrecional acotada de salida |
No necesitas que todo sea matemático.
Un sistema discrecional puede contener interpretación. Pero la interpretación también necesita límites. Si dos observadores razonablemente entrenados llegan constantemente a conclusiones opuestas aplicando las mismas reglas, probablemente el sistema todavía permite demasiada libertad.
Por eso merece la pena haber trabajado antes cómo definir las reglas de un sistema de trading.
Paso 4. Diseña invalidación, riesgo y salida como un mismo problema
Muchos sistemas dedican una enorme cantidad de atención a la entrada y dejan el resto para después.
Yo lo haría al revés: no consideraría terminada una regla de entrada mientras no sepa también qué la invalida y qué riesgo genera.
Supongamos que tu hipótesis es alcista. Debes decidir qué tendría que ocurrir para aceptar que esa operación concreta ya no merece seguir abierta.
Ese nivel de invalidación puede servir para construir el stop, aunque stop e invalidación no tienen por qué ser siempre exactamente lo mismo.
Aquí aparece una relación importante:
el mercado debería ayudarte a decidir dónde deja de tener sentido el trade; tu gestión del riesgo debería ayudarte a decidir cuánto tamaño puedes permitirte en ese trade.
No conviene hacer el razonamiento al revés y colocar siempre el stop a una distancia arbitraria únicamente porque así “solo pierdes 500 pesos”. Puede que esos 500 MXN sean un límite monetario perfectamente razonable y, aun así, el nivel elegido no tenga ninguna relación con la hipótesis de mercado.
Imagina, solo como ejemplo, una cuenta de 100,000 MXN y un riesgo máximo planificado del 0.5% por operación.
El presupuesto de riesgo sería:
100,000 MXN × 0.5% = 500 MXN
Ese 0.5% no es una recomendación universal. Podría ser demasiado, demasiado poco o simplemente no tener sentido para otro sistema.
Después necesitas adaptar el tamaño de posición a la distancia entre entrada y stop:
Tamaño de posición = riesgo monetario máximo ÷ (distancia al stop × valor de cada unidad de movimiento)
Si el stop necesita estar más lejos para respetar la lógica del setup, manteniendo el mismo riesgo monetario tendrás que reducir tamaño. Si está más cerca, el tamaño teórico podría aumentar.
Y todavía queda la salida favorable.
¿Utilizarás un objetivo fijo? ¿Una relación en múltiplos de riesgo? ¿Una salida temporal? ¿Un trailing stop? ¿Una condición contraria? ¿Cerrarás toda la posición o solo una parte?
No hay una respuesta universal. La clave es que la respuesta exista antes de saber si esa operación concreta habría ganado o perdido.
Además, recuerda que la pérdida realmente ejecutada puede diferir de la pérdida planificada por gaps, slippage, liquidez o condiciones de ejecución. Un stop es una herramienta de control del riesgo, no una garantía matemática de precio de salida.
Paso 5. Escribe también cuándo NO vas a operar
Para mí, una de las mejores formas de detectar un sistema incompleto es buscar sus reglas de no operación.
Muchos traders pueden explicar cuándo quieren entrar, pero no qué situaciones invalidan un setup antes de abrir la posición.
Supongamos que una estrategia depende de movimientos relativamente pequeños. ¿Debe seguir operando cuando el spread se amplía mucho? ¿Puede abrir posiciones a cualquier hora? ¿Acepta mantenerlas overnight? ¿Funciona igual si la volatilidad cambia drásticamente?
No necesitas responder todas esas preguntas en todos los sistemas. Necesitas responder las que puedan cambiar materialmente tu resultado.
Aquí entran también los costes.
Un sistema no opera sobre un gráfico teórico. Opera pagando o sufriendo, según el producto y la cuenta utilizada, elementos como spread, comisión, slippage y financiación. Cuanto menor sea el movimiento medio que intentas capturar y mayor sea tu frecuencia de operación, más importante puede volverse esa fricción.
Un ejemplo sencillo: una estrategia que busca capturar movimientos muy pequeños puede parecer interesante antes de costes y perder completamente su atractivo cuando cada operación tiene que superar spread y comisión. Eso no significa que el sistema sea malo; significa que todavía estabas midiendo otra cosa.
Si vas a ejecutar el sistema con CFDs a través de Pepperstone, yo revisaría los costes y las condiciones de la cuenta concreta antes de fijar supuestos de ejecución. También comprobaría qué entidad legal corresponde a tu residencia, porque los documentos y condiciones de Pepperstone varían según la entidad con la que abras la cuenta. Su web para Latinoamérica recuerda además que los CFDs son productos apalancados y conllevan un riesgo elevado de pérdida.
Puedes consultar aquí las condiciones disponibles en Pepperstone antes de incorporar esos costes a tu sistema.
Paso 6. Convierte las reglas en decisiones que puedas auditar
Aquí llega una prueba muy sencilla.
Entrega tus reglas a otra persona que entienda los conceptos utilizados. Dale el mismo gráfico y la misma información que habrías tenido en ese momento.
¿Tomaría aproximadamente las mismas decisiones que tú?
Si la respuesta es “depende de cómo interprete el gráfico”, necesitas averiguar dónde aparece esa diferencia.
A veces descubrirás palabras peligrosas:
“fuerte”, “limpio”, “cerca”, “demasiado”, “bonito”, “claramente”, “buena vela”, “mucho volumen”, “tendencia sana”.
No significa que esas ideas sean inútiles. Significa que si afectan a una decisión, debes saber qué significan dentro de tu proceso.
En un sistema mecánico, normalmente podrás traducirlas a condiciones bastante exactas.
En uno discrecional quizá necesites trabajar con categorías, ejemplos válidos y no válidos, rangos aceptables o una checklist de contexto. La discreción no desaparece; queda acotada.
Y aquí hay otro matiz importante: no añadas una regla simplemente porque encuentras un gráfico donde habría evitado una pérdida.
Imagina que tu sistema pierde tres operaciones los miércoles. Revisas el historial y decides no operar los miércoles. Después descubre una pérdida a las 15:00 y también eliminas esa hora. Luego otra con determinada vela, otro indicador, otro filtro…
En poco tiempo puedes construir una máquina perfecta para explicar el pasado.
Eso nos llevará más adelante al overfitting o sobreajuste en trading. Por ahora quédate con esta regla: cada condición añadida debería tener una razón anterior al resultado que estás intentando corregir o, como mínimo, tratarse como una hipótesis nueva que tendrá que validarse aparte.
Paso 7. Congela una versión 1.0
Este paso suele recibir poca atención y para mí es fundamental.
En algún momento tienes que dejar de diseñar.
No porque el sistema sea perfecto, sino porque si cambias continuamente las reglas mientras observas sus resultados, ya no sabes qué sistema estás evaluando.
Llama a tu primera especificación “Sistema v1.0”, “Modelo A” o como quieras. Lo importante es que exista una versión identificable.
Si más adelante encuentras una razón sólida para modificarla, perfecto. Pero esa modificación debería generar una nueva versión y poder compararse con la anterior.
Una ficha mínima del sistema podría contener:
- hipótesis que quieres poner a prueba;
- mercado o universo permitido;
- temporalidad y horarios;
- condiciones necesarias del mercado;
- setup;
- trigger de entrada;
- invalidación y regla de stop;
- riesgo y cálculo del tamaño de posición;
- reglas de gestión y salida;
- situaciones en las que no puedes operar;
- costes y supuestos de ejecución;
- versión y fecha desde la que esas reglas quedan congeladas.
Si falta alguno de esos elementos, no significa automáticamente que el sistema sea inválido. Algunos sistemas no necesitan horarios específicos, otros no utilizan filtros de contexto y otros pueden tener estructuras distintas.
La pregunta es otra: ¿queda alguna decisión material que solo podrás resolver improvisando cuando ya estés dentro de la operación?
Si la respuesta es sí, vuelve a trabajar esa parte.
Ejemplo: cómo pasar de una idea a un sistema testeable
Vamos a construir un ejemplo completamente hipotético.
No pretende ser una estrategia recomendable ni estoy afirmando que tenga ventaja. Precisamente quiero que veas la diferencia entre una idea aparentemente razonable y un sistema cuya ventaja todavía tiene que comprobarse.
La idea inicial sería:
“Quiero comprar retrocesos dentro de tendencias alcistas.”
Eso no se puede evaluar de forma seria. Necesitamos convertirlo en reglas.
| Bloque | Versión hipotética del sistema |
|---|---|
| Mercado | EUR/USD |
| Temporalidad | 1 hora |
| Dirección | Solo posiciones largas |
| Contexto | Precio por encima de una media de 50 periodos y media actual por encima de su valor de cinco velas antes |
| Setup | Retroceso de al menos dos velas sin que el precio cierre por debajo de la media |
| Trigger | Cierre de una vela por encima del máximo de la vela anterior |
| Entrada | Apertura de la siguiente vela |
| Invalidación | Mínimo del retroceso |
| Stop | Por debajo del mínimo definido por la regla del sistema |
| Riesgo | 0.5% del capital como supuesto didáctico |
| Objetivo | Salida a +2R o mediante stop |
| No operación | Ninguna entrada que incumpla cualquiera de las condiciones anteriores |
| Costes | Incluir spread, comisión y slippage aplicables al entorno probado |
| Versión | 1.0; ningún parámetro cambia durante la primera prueba |
Ahora tenemos algo muy distinto.
No sabemos si funciona.
Pero podemos preguntar: ¿cuántas veces ocurrió? ¿Qué resultados habría generado siguiendo exactamente esas reglas? ¿Qué costes habría soportado? ¿Cómo se comportaron ganancias y pérdidas?
Eso ya es investigable.
La versión inicial “compro buenos retrocesos en tendencias fuertes” podía adaptarse mentalmente a prácticamente cualquier gráfico pasado. La versión definida puede equivocarse de una forma observable.
Y eso es una virtud.
Un buen sistema debe permitirte descubrir que estabas equivocado.
No intentes hacer que la primera versión sea perfecta
Hay una tentación natural cuando diseñas un sistema: añadir condiciones hasta eliminar todo lo que te incomoda.
Una media más. Otro filtro. Dos confirmaciones. Una excepción para los lunes. Una regla especial para determinados movimientos. Una salida alternativa para evitar cierta pérdida histórica.
El problema no es que un sistema complejo sea necesariamente malo. El problema es que cada grado adicional de libertad hace más fácil adaptar las reglas al ruido del pasado.
Yo empezaría con la menor cantidad de elementos capaces de expresar la hipótesis.
Después serán los datos los que te darán motivos para estudiar cambios.
No antes.
También evitaría confundir sofisticación con edge. Una regla sencilla puede carecer de ventaja y una regla compleja también. El número de indicadores no responde la pregunta importante.
Los errores que más debilitan un sistema antes de probarlo
| Error | Qué problema crea |
|---|---|
| Empezar únicamente por la entrada | Deja riesgo, salida y ejecución a la improvisación |
| Utilizar palabras que cambian de significado | Impide saber si aplicaste realmente las mismas reglas |
| Elegir el stop solo por la pérdida monetaria deseada | Puede desconectarlo de la invalidación de la hipótesis |
| Ignorar costes | Evalúa un sistema distinto del que podrías ejecutar |
| Modificar reglas después de cada pérdida | Hace imposible saber qué versión estás midiendo |
| Añadir filtros mirando primero el resultado | Aumenta el riesgo de adaptar el sistema al pasado |
| Confundir una buena racha con evidencia de ventaja | Evalúa resultados aislados en lugar del proceso |
| Buscar automatizar antes de aclarar la lógica | Codifica ambigüedad en lugar de eliminarla |
El último error merece atención.
Programar un sistema no lo vuelve sistemático por arte de magia. Si la lógica original es mala, automatizarla solo permite ejecutar esa mala lógica con más consistencia.
Primero diseña las decisiones. Después decide si quieres ejecutarlas manualmente, mediante alertas o mediante código.
¿Cuándo está listo un sistema para pasar al backtesting?
No necesitas saber si es rentable. Precisamente el test existe para investigar eso.
Lo que sí necesitas es poder mirar una operación histórica y decidir, utilizando únicamente la información disponible en ese momento, si cumplía o no las reglas.
También deberías poder explicar por qué entraste, dónde estaba la invalidación, cómo calculaste el riesgo y qué condición produjo la salida sin tener que inventar una justificación después de ver el resultado.
Ese es el punto en el que yo dejaría de añadir cosas.
Esta lección cierra la fase de construcción del primer módulo. El siguiente paso es aprender qué es el backtesting y qué puede decirte realmente sobre un sistema.
Todavía no vamos a hablar aquí de tamaño de muestra, in-sample, out-of-sample, métricas, Monte Carlo o robustez. Cada una de esas piezas tiene su lugar más adelante en el curso y desarrollarlas ahora convertiría esta lección en medio curso pegado dentro de una sola URL.
Después de la validación histórica llegará otro salto distinto: observar cómo se comporta el proceso con información nueva. Esa fase la trabajaremos en la lección de forward testing.
Cuando llegues a ese punto, una cuenta demo puede ser útil para practicar ejecución sin poner capital real en riesgo, aunque una demo no reproduce perfectamente todas las condiciones psicológicas y de ejecución de una cuenta real. Pepperstone ofrece cuentas demo en sus distintas plataformas.
Si quieres dejar preparado ese entorno, puedes abrir o revisar una cuenta de Pepperstone mediante nuestro enlace y consultar la promoción que esté disponible en ese momento.
La prueba que yo usaría antes de continuar
Me quedaría con una pregunta.
¿Podría otra persona aplicar tu sistema de una forma suficientemente parecida como para que ambos estuvieran probando la misma idea?
No tiene que tomar absolutamente cada decisión igual si el método conserva una parte discrecional. Pero no puede ocurrir que una operación sea válida únicamente porque después viste que ganó.
Si tus reglas sobreviven a esa prueba, ya has hecho algo bastante más importante que encontrar un setup atractivo: has convertido una idea en un objeto que puede medirse.
Y a partir de ahí empieza la parte incómoda y realmente interesante del trabajo: intentar demostrar que esa idea merece sobrevivir.
