Automatización y screening en el análisis técnico: herramientas, flujo de trabajo y riesgos

Un screener debe aplicar la misma regla a toda la lista registrada de instrumentos. Por tanto, la pregunta clave tras un escaneo es: ¿un resultado vacío significa que no hay configuración o que no hay datos? Este capítulo le lleva desde la definición de una configuración operativa hasta un pseudocódigo completo, un registro de alertas y una prueba fuera de la muestra utilizada para seleccionar parámetros. Separamos la identificación de un candidato del envío de una orden. La automatización puede ahorrar trabajo, pero también repetir un error con rapidez y constancia.

1. Por qué automatizar y qué se automatiza exactamente

Las ocho monedas USD, EUR, GBP, JPY, CHF, AUD, NZD y CAD forman 8 × 7 / 2 = 28 pares sin ordenar. Es un universo seleccionado, no todo el mercado Forex ni una medición de los instrumentos «más seguidos». Un bróker puede ofrecer otra lista. Registre los símbolos, el sentido de cotización y la versión de la lista antes de escanear. Evaluamos filtros de medias móviles, osciladores y zonas de soporte y resistencia bajo el mismo contrato de datos.

No está automatizando la decisión de entrada, sino la búsqueda. Un screener no dice «compre», sino «eche un vistazo a esto». Lo que haga después depende del contexto, del marco temporal superior, de la gestión del riesgo y de su experiencia.

Un screener realiza una revisión repetible sin elegir gráficos favoritos, pero solo dentro de su configuración. Que aparezcan 28 pares en los ajustes no demuestra que todos hayan recibido datos actuales. El informe también debe contener un registro de cada par sin señal y de cada par que no pudo evaluarse.

Un RSI inferior a 30 es el resultado de una condición, no una instrucción de compra. Si un análisis adicional de acción del precio o del contexto determina la entrada, registre también los descartes. De lo contrario, la prueba del screener solo abarcará operaciones seleccionadas por conveniencia.

2. El espectro de automatización: de la alerta al algoritmo

Los cinco niveles siguientes organizan el alcance de las funciones. Son una convención del curso, no una clasificación del camino óptimo para la mayoría de operadores. Un nivel superior requiere controles adicionales, pero no necesariamente es mejor para una tarea concreta.

Un filtro o una alerta ya preparados no siempre requieren programación. Siguen necesitando configuración, una fuente de datos y una prueba operativa. La ejecución semiautomática y automática introduce un problema distinto: una condición correctamente identificada puede recibir una ejecución diferente o ninguna ejecución.

Este artículo se centra en los niveles 1 a 4. La automatización completa mediante EA aparece sobre todo al hablar de riesgos, porque allí se llega al recurrir demasiado pronto a un robot.

3. Criterios de screening en la práctica

Un screener malo no muestra pares malos, sino demasiados aparentemente buenos. Eso es peor, porque desperdicia atención y crea la falsa sensación de que «el mercado ofrece algo hoy». Los parámetros deben ser suficientemente selectivos para reducir el ruido, pero no tan estrictos como para eliminar la mayoría de configuraciones razonables. A continuación se presentan los filtros más utilizados en Forex^[3].

Lista para objetivar una regla

Antes de introducir una condición en el escáner, debe pasar del lenguaje de la intuición al de la máquina. Cada elemento siguiente que no resuelva expresamente lo resolverá el escáner por usted, normalmente de forma distinta a la que supone:

Tres medidas separadas. La duración del escaneo y la cobertura de datos miden comodidad y fiabilidad. La concordancia con un patrón de referencia etiquetado de forma independiente mide la detección de la condición. Los resultados financieros requieren toda la estrategia, incluidos candidatos descartados, precios de respuesta y costes. Alcanzar el TP no define por sí solo un resultado «correcto» del screener, y que no mejore la tasa de acierto no anula el ahorro de tiempo. Compare con la variante sin filtro sobre la misma muestra reservada de antemano.

Filtros de tendencia

• Precio respecto a EMA/SMA. Un precio por encima de una EMA de 200 ascendente en D1 puede definir un filtro direccional. Descarta candidatos que incumplen esa condición, no todas las operaciones «contra tendencia» bajo cualquier definición del mercado. El precio igual a la media o una pendiente plana requiere una decisión explícita.
• Cruce de medias móviles. La condición EMA 50 antes ≤ EMA 200 y ahora > EMA 200 detecta una transición. No es un tipo de cambio cruzado ni demuestra un cambio de dirección futura del precio. Ambos valores deben proceder de velas completas de la misma serie.
• ADX superior a un umbral. Umbrales de ejemplo de la convención establecida: ADX(14) > 25 se interpreta como mercado tendencial y < 20 como consolidación, recordando que el ADX mide la fuerza del movimiento, no su dirección. Resulta útil sobre todo como filtro negativo: por debajo del umbral, una regla tendencial descarta el instrumento conforme al parámetro elegido.

Filtros de momentum y osciladores

• RSI en zonas extremas. Los umbrales de ejemplo del RSI(14) son 30 y 70. Su frecuencia depende del instrumento, marco temporal, período y método de inicialización. La sobreventa no es una señal autónoma de compra ni la sobrecompra una de venta. Sin investigación, no atribuimos mayor valor informativo a los extremos de D1 que a los de H1.
• Divergencia. Debe definir los giros, el emparejamiento de extremos del precio y del oscilador y el momento de confirmación. Con esas definiciones puede calcularse incluso un patrón complejo. Una evaluación manual de divergencias «de varias ondas» sin reglas deja una selección discrecional difícil de reproducir de forma justa en una prueba.
• Histograma MACD: cambio de signo. El histograma cruza el cero desde abajo; en esta implementación eso significa que cambia la relación entre la línea MACD y la de señal, no que se demuestre un cambio de dirección del precio. Es fácil de programar y se utiliza con frecuencia como filtro preliminar para un análisis posterior.

Filtros de precio y estructura

• Proximidad a soporte/resistencia. Defina la zona y la tolerancia en la misma unidad que el precio. Una alerta en una zona marcada manualmente puede facilitar la revisión, pero debe probarse su eficacia; esta no se deduce de la facilidad de configuración.
• Ruptura del rango de N velas. Por ejemplo, cierre de una vela terminada > máximo más alto de las 20 velas completas anteriores. La vela evaluada se excluye de la ventana del máximo; en la variante estricta, la igualdad no es ruptura. Es una convención de Donchian, no una promesa automática de beneficios.
• Fibonacci. Defina extremos de oscilación confirmados y tolerancia alrededor de un retroceso. La confirmación retrasada se describe en el artículo 5.11. Calcular un nivel no demuestra que el precio vaya a reaccionar a él.

De la intuición a la condición: la regla completa y lo que se pierde al traducir

Intuición: «comprar rebotes en soporte dentro de una tendencia alcista en D1». La misma idea escrita de modo que un escáner pueda ejecutarla:

PSEUDOCÓDIGO: CANDIDATO A «PRUEBA DE SOPORTE», NO UNA ORDEN
Configuración fijada: versión, 28 pares, flujo BID, D1, calendario,
  EMA: α=2/201, inicializada con la SMA de los primeros 200 C; ATR(14) de Wilder:
  semilla = media de los primeros 14 TR con C anterior, después α=1/14;
  un calentamiento de al menos 500 velas completas es una elección del modelo, no una garantía de convergencia.
Estado del símbolo: nivel S, ATR A, intervalo de identificación, armado/desarmado.
Al inicio de t, registrar una instantánea inmutable del contexto con datos conocidos antes de start_t:
  registra entradas para t sin cambiar el estado de armado operativo; un reintento usa esa instantánea.
  El estado anterior a t y el archivo de centros proceden de la última vela procesada previamente.
  seleccionar el último fractal inferior estricto con 2 velas a cada lado,
  confirmado y recibido antes de start_t, con una antigüedad máxima de 60 velas;
  mínimos iguales no forman un fractal estricto; si no hay ninguno = NO_LEVEL.
  Identificar el nuevo contexto por flujo y centro del fractal. Conservar los centros invalidados
  en el registro; no recrear contexto a partir del mismo centro.
  Para contexto nuevo A := ATR conocido antes de start_t; conservarlo sin cambios
  hasta el vencimiento, la invalidación o un nuevo centro confirmado.
  Tras 60 velas desde el centro, registrar EXPIRED; no emitir alerta.
  Si A ≤ 0 o falta su valor: NO_VALUE, sin señal.
  Registrar zona [S − 0.2A; S + 0.2A] e invalidación C < S − 0.5A.
  Un fractal confirmado nuevo crea contexto nuevo, armado antes de la prueba.
Después del final de t, para CADA símbolo del universo completo:
  Key := (version, feed, symbol, D1, end_UTC).
  Recuperar OHLC completos de t y known_at, y la instantánea de contexto guardada antes de start_t.
  El hash de entrada cubre OHLC, historial de indicadores, contexto, configuración y versiones de datos.
  Si existen esta clave y este hash: devolver el resultado anterior sin evaluar ni cambiar el estado.
  Si existe la clave con otro hash: añadir una revisión y ejecutar una reproducción separada
    desde el estado fijado antes de t; no evaluar t con el estado ya modificado por t.
    Corregir historia anterior a t exige reproducir desde la primera entrada modificada.
    Conservar el resultado original/known_at; marcar el resultado reproducido como corrección posterior.
    No enviar la corrección como una nueva alerta original; terminar el símbolo.
  En la primera evaluación, usar una copia del estado anterior a t y la instantánea del contexto;
    validar L ≤ min(O,C) ≤ max(O,C) ≤ H.
  Comprobar continuidad de sesiones, flujo, componente, incrementos del precio y calentamiento.
  Error de datos: registrar NO_DATA; conservar el estado; no emitir alerta.
  Si C_t < S − 0.5A: registrar INVALIDATED, retirar el contexto; terminar el símbolo.
  Si el estado estaba desarmado:
    si C_t ≥ S + A AND L_t > S + 0.2A: armar para la SIGUIENTE vela;
    registrar REARM o DISARMED; no emitir alerta en esa misma vela.
  Si el estado estaba armado:
    trend := C_t > EMA200_t AND EMA200_t > EMA200_(t−20).
    test := H_t ≥ S − 0.2A AND L_t ≤ S + 0.2A AND C_t > S.
    signal := trend AND test.
    Registrar SIGNAL o NO_SIGNAL con todos los operandos.
    Ante una señal, desarmar el contexto; nueva alerta solo tras un REARM futuro.
  Toda rama terminal registra resultado, entradas y estado anterior y posterior a t.
  Confirmar el registro y el estado una sola vez en una transacción con clave única;
    ante conflicto por reintento, devolver el registro existente sin una segunda modificación.
  Identificar la notificación con esta clave, también al reanudar su entrega.
  Procesar los finales de vela cronológicamente; un hueco de datos bloquea alertas posteriores
    hasta reconstruir el contexto; no puede convertirse en NO_SIGNAL.
Tras el escaneo, informar expected/evaluated/missing/candidates, incluso si candidates = 0.
La alerta incluye end_t, known_at, version, S, A y condiciones; no contiene función de ejecución.

Este es el coste explícito de la traducción: «un rebote» se convirtió en tocar una zona con tolerancia arbitraria de 0,2 × ATR; «soporte», en un fractal confirmado con dos velas de retraso (momento de confirmación del giro → art. 5.11); la calidad del rebote, el contexto W1 y el aspecto de la vela quedaron fuera de la regla. Además, hubo que separar el rearme de la alerta, cuando el precio se aleja de la zona, de la invalidación del soporte mismo: dos decisiones distintas que la intuición fusiona. No es un defecto de la notación, sino el precio de ser inequívoco: todo lo que no escribió no existe para el escáner. Precisamente por eso el resultado del escaneo es una lista de candidatos para analizar, no una lista de operaciones.

Contexto macro y filtros de costes: lo que ningún screener muestra por sí solo

Un filtro de calendario, spread o rollover es una regla independiente. Aquí no se establece que una ventana de 30 o 60 minutos sea óptima. Registre qué eventos cubre, de dónde proceden sus fechas y si bloquea candidatos nuevos, órdenes nuevas o también modifica la gestión de posiciones existentes.

• Filtro de calendario. Un procedimiento de ejemplo puede descartar candidatos nuevos dos horas antes de un evento seleccionado. Es un parámetro que debe probarse, no una exigencia universal. Verifique la fecha con el editor y distinga la hora prevista de la publicación efectiva; «High impact» es la clasificación del proveedor del calendario.
• Filtro de spread. El umbral es explícito, con unidad y base de comparación. El doble de un nivel medido previamente para ese par y hora del día puede bloquear una instrucción nueva. No explica por qué aumentó el spread ni protege una posición existente.
• Filtro de ATR. ATR > 1,2 × la media de los N valores anteriores describe la superación de un umbral elegido. Un valor inferior no significa automáticamente «mercado poco líquido». Cambiar SL, TP y volumen requiere una regla registrada; no se deduce necesariamente del ATR por sí solo.

Un screener no aprieta el gatillo: analizar patrones gráficos, el contexto de varios marcos temporales y gestionar el riesgo sigue siendo responsabilidad suya.

El mismo nivel y estados sucesivos de alerta

Recorramos la regla sin cambiar umbrales después de ver el resultado. El soporte S = 1,1000 procede de un fractal confirmado antes del primer día evaluado. ATR A = 0,0040, equivalente a 40 pips y fijado entonces, define la zona [1,0992; 1,1008], la invalidación en C < 1,0980 y el rearme en C ≥ 1,1040 y L > 1,1008. Son parámetros del modelo, no valores recomendados para EUR/USD. El centro del fractal y A permanecen iguales durante todo el ejemplo.

Extracto hipotético del registro bid D1, evaluado tras recibir cada cierre

Paso	L / H / C	Estado anterior	Resultado
1	1,1007 / 1,1015 / 1,1010	Armado	El rango intersecta la zona, C > S: alerta y desarme
1: reintento	Misma clave y hash de entrada que en 1	Registro SIGNAL existente	Devolver el resultado anterior; sin nueva evaluación, cambio de estado ni notificación
2	1,1010 / 1,1042 / 1,1040	Desarmado	C igual al umbral de rearme, L sobre la zona: armar para el siguiente paso, sin alerta
3	1,1007 / 1,1025 / 1,1010	Armado	Nueva prueba: segunda alerta, otro final de vela y otra clave
4	1,0975 / 1,1014 / 1,0980	Desarmado	La igualdad no invalida bajo la regla estricta; sin rearme ni alerta
5	1,0974 / 1,0982 / 1,0979	Desarmado	C < 1,0980: contexto invalidado

En los pasos 1 y 3 se cumple el filtro EMA declarado: el cierre está sobre la EMA y la EMA actual sobre su valor de 20 velas antes. La tabla no reconstruye 500 velas de calentamiento; esas dos condiciones son entradas de un modelo lógico, no lecturas documentadas del mercado. Reintentar el paso 1 debe devolver el mismo SIGNAL; no debe recalcularse con el estado ya desarmado y sobrescribirse como DISARMED. Ante una revisión, reconstruimos por separado el estado anterior a esa vela y los estados dependientes posteriores, conservando la ejecución original. El paso 2 no puede armar y emitir alerta a la vez, porque su estado al empezar la evaluación era desarmado. El orden de las ramas forma parte de la definición, no es un detalle técnico.

Tras el paso 5, el fractal antiguo sigue archivado como invalidado. El escaneo del día siguiente no puede rebautizarlo «último soporte» y crear otra alerta desde el mismo centro. Hace falta un fractal confirmado nuevo. El vencimiento tras 60 velas es un estado distinto: ocurre incluso sin cruzar el nivel de invalidación. Si faltan datos entre pasos, desconocemos si hubo rearme o invalidación en el hueco; informe de la interrupción y suspenda nuevas alertas hasta reconstruir el contexto.

Una revisión del máximo/mínimo puede cambiar la calificación del fractal. Conserve la instantánea original, el resultado disponible entonces y la corrección posterior vinculada. Evaluar «cómo funcionó la regla con datos finales» y «qué habría podido enviar realmente entonces» son dos experimentos distintos. Puede realizar ambos, pero no mezclar sus registros. El CSV de estados adjunto permite comprobar una implementación sin enviar órdenes.

Abrir el diagrama a tamaño completo

4. TradingView: screener, alertas y Pine Script

Screener integrado

TradingView ofrece filtros de monedas y alertas, pero su alcance exacto depende de la herramienta y el plan actuales. Compruebe columnas, marco temporal y fuente. El «volumen» en FX al contado no es un registro central de transacciones: puede ser el número de actualizaciones de un flujo concreto. Dos fuentes pueden dar resultados diferentes; aún pueden compararse, pero se necesitan datos identificados y un método.

Un conjunto práctico de filtros iniciales: marco D1, RSI(14) inferior a 35 o superior a 65, precio sobre/bajo la EMA de 200, variación porcentual en las últimas 5 sesiones > 1%. Así configurado, el screener suele devolver unos pocos pares al día; el número exacto depende del mercado: en tendencia el filtro deja pasar más resultados y en consolidación menos.

Alertas en TradingView

Una alerta notifica una condición: puede exigir un cierre o una respuesta intravela. En ambos casos registre la hora de los datos, de detección y de recepción del mensaje. No suponemos que todos los demás algoritmos ya hayan operado ni que todas las notificaciones tengan la misma demora.

Los límites de alertas dependen del plan y cambian con el tiempo. Como orientación, con precios actuales en tradingview.com/pricing: Essential permite 20 alertas de precio + 20 técnicas, Plus 100 de cada tipo, Premium 400 y Ultimate 1.000. Una cuenta gratuita admite pocas a la vez; para quien sigue entre 10 y 15 pares, es una limitación real y un motivo frecuente para contratar un plan.

Pine Script: indicadores y estrategias propios

Pine Script es el lenguaje de TradingView. No requiere experiencia al nivel de Python: su sintaxis es más sencilla, la documentación es buena y la comunidad ha publicado miles de scripts preparados que pueden adaptarse. Permite crear:

• Un indicador propio; por ejemplo, uno que dibuje una flecha cuando RSI < 30 Y el precio esté en la zona de retroceso Fibonacci del 50 al 61,8% Y EMA 50 > EMA 200. Tres condiciones que comprobaría manualmente durante varios minutos en un gráfico: el script lo hace al instante.
• Una alerta basada en un indicador propio: el script genera la alerta automáticamente cuando coinciden las condiciones. Recibe una notificación en el teléfono y abre un gráfico preparado para analizar.
• Un backtest de estrategia: Pine Script incorpora un módulo strategy() que permite probar lógica con datos históricos. Los resultados aparecen en «Strategy Tester»: curva de patrimonio, drawdown, tasa de acierto y factor de beneficio.

Pine Script calcula indicadores, alertas y órdenes simuladas en el emulador de TradingView. La integración nativa con un bróker para gestionar órdenes no significa que un script de estrategia envíe sus propias operaciones al bróker. Ejecutar automáticamente tras un webhook requiere una capa separada y correctamente configurada. Debe identificar duplicados, confirmaciones y errores. El entorno depende de los datos y requisitos; sin medir, no presentamos ninguna plataforma como garantía de menor deslizamiento.

Un evento RSI en pseudocódigo. Describe lógica, no código listo para pegar ni un sistema que envíe órdenes. La implementación debe conservar el contrato de integridad y tiempos y la regla de inicialización indicados en el artículo 5.8.

PSEUDOCÓDIGO: SOLO ALERTAS, SIN ÓRDENES
Configuración: versión de regla, universo, flujo BID, marco D1,
  límites diarios, implementaciones de RSI(14) y EMA(200), al menos 500 velas históricas.
Tras cada final D1 esperado, para CADA símbolo:
  Comprobar integridad, OHLC, continuidad del calendario y hora de disponibilidad.
  Si faltan datos: registrar NO_DATA; conservar el estado del umbral; terminar el símbolo.
  Calcular RSI y EMA con el mismo método declarado sobre dos velas D1 completas consecutivas.
  Si el resultado es indefinido: registrar NO_VALUE; terminar el símbolo.
  Event := RSI anterior ≥ 30 AND RSI nuevo < 30 AND C nuevo < EMA nueva.
  Key := (version, feed, symbol, D1, end_UTC).
  Registrar el resultado incluso si event = FALSE, con hora de datos y hash.
  Si event y key aún no enviados: registrar alerta y enviar la notificación.
  Repetir con la misma clave no envía otra alerta.
  Corrección histórica: añadir una versión corregida; no sustituir la decisión original.
  Si hay un hueco de datos entre velas: no fingir que hubo un cruce continuo.
  El próximo evento requiere un nuevo par de velas completas consecutivas.

RSI = 30 en la vela anterior permite la transición, mientras que la igualdad en la actual no la cumple. Es una elección explícita de operadores. Otra vela que sigue por debajo de 30 no es una transición nueva. Por separado, deduplicamos el resultado idéntico tras repetir el escaneo. Un hueco de datos no permite inventar el RSI ausente ni aceptar un cruce no observado.

Detección y respuesta. El cierre está disponible una vez terminada y recibida la vela. Después llegan la alerta, la decisión y cualquier intento de ejecución. El emulador predeterminado de TradingView ejecuta una orden nueva como pronto en el siguiente tick; también ofrece opciones para modelar ejecución al cierre. Esa opción no demuestra que pudiera conseguirse ese precio después de recibir la alerta. Usar el cierre futuro de un marco superior antes de terminar su intervalo es anticipación de datos, sea cual sea el nombre del ajuste. La cronología se muestra en el artículo 5.11.

5. MT4/MT5: escáneres, indicadores y EA

MetaTrader sigue siendo la plataforma de ejecución dominante en muchos brókeres Forex. Su fortaleza para automatizar son MQL4/MQL5 y la posibilidad de crear asesores expertos (EA), programas capaces de abrir y cerrar posiciones automáticamente.

Indicadores y escáneres propios

En MQL4/MQL5 puede escribir, o descargar del MQL5 Market, un indicador que escanee varios instrumentos de Market Watch y muestre un panel: par, dirección de tendencia, RSI y distancia a medias importantes. Entre estas herramientas destacan «Multi-Currency Dashboard» y «Scanner RSI»; su calidad varía mucho, por lo que conviene revisar opiniones y probarlas en demo antes de depender de ellas.

Una diferencia clave frente a TradingView: los indicadores MT4/MT5 funcionan localmente, en su ordenador o un VPS, no en la nube. El escaneo depende de la velocidad de conexión al servidor del bróker y exige tener la plataforma abierta. Si cierra el portátil y sale a caminar, las alertas MT4 no se activarán, salvo que la plataforma funcione en un VPS. TradingView escanea en el servidor, por lo que sus alertas funcionan incluso con el ordenador apagado. Para un operador de swing que no quiere estar atado al escritorio, es una diferencia tangible en el uso diario.

Asesores expertos: automatización completa

Los EA son programas que operan por sí solos. Las posibilidades van desde «comprar cuando EMA 50 cruza sobre EMA 200» hasta sistemas complejos con gestión dinámica, stops móviles y análisis de varios marcos temporales.

Evaluar un EA preparado exige reglas documentadas, historial de cambios, datos, costes y resultados que incluyan períodos débiles. Una curva uniforme por sí sola no demuestra fraude ni ajuste, pero sin esa información tampoco permite descartarlos. El resto del capítulo explica qué comprobar.

MT5 frente a MT4

MT5 tiene un probador multisímbolo, mientras que el estándar de MT4 funciona sobre un símbolo seleccionado. Importa para estrategias de cartera, pero no determina la calidad de los datos ni del modelo de ejecución. Compruebe instrumentos admitidos, modos de prueba y condiciones del bróker concreto; el nombre de la plataforma no evalúa por sí solo la ejecución.

6. Flujo de trabajo: del escaneo a la lista de seguimiento

El proceso siguiente separa escaneo, verificación y respuesta. Es un ejemplo organizativo para swing trading, no el resultado de un estudio de eficacia. Cada fase deja un registro, incluidos los descartes.

1. W1 después de terminar la semana. Revise el contexto y las zonas previamente confirmadas de soporte y resistencia. La evaluación puede ser manual o automatizada si se define formalmente. Registre la hora de identificación y los límites de las zonas; no los mueva después para ajustarlos al resultado.
2. Lunes por la mañana: screener D1. Ejecuta el screener con criterios adaptados a su estilo, por ejemplo RSI < 35, precio cerca de EMA 200 y ADX > 25. Obtiene unos pocos pares. Abre cada uno en D1 y comprueba manualmente si encaja con el contexto de la revisión semanal y si está cerca de un nivel del marco superior.
3. Lista de seguimiento y exposición. El número de pares depende de la capacidad de revisión, no de un intervalo «ideal» de 2–5. Largo EUR/USD, largo GBP/USD y corto USD/CHF comparten una pata corta en USD, pero otras monedas distintas; no son una misma posición idéntica. Mida la correlación sobre rendimientos alineados e indique período y ventana. DXY duplica parcialmente esos tipos. COT tiene fechas distintas para posiciones y publicación. El dimensionamiento de posición pertenece únicamente al plan de operación.
4. Alertas y espera. Configura alertas para los pares seguidos: de precio al alcanzar una zona, de indicador al entrar el RSI en un extremo o sobre objetos dibujados, como el toque de una directriz. No se queda mirando el gráfico; espera la notificación.
5. Alerta → análisis → decisión. Se activa una alerta. Abre el gráfico, realiza un análisis de varios marcos temporales (D1 → H4) y busca confirmación de acción del precio. Si existe la configuración, entra; si no, la deja y sigue esperando. Que no haya configuración no es un problema, es información.

Registre el tiempo real de revisión y la cobertura. Una alerta no garantiza una evaluación contextual correcta ni una lista completa. Un cambio de datos tras una intervención o anuncio puede modificar el resultado de la regla; comprobarlo exige un registro nuevo, no sustituir la lectura anterior.

7. El lunes por la mañana: cómo es el screening de 28 pares

Revisión ilustrativa del lunes: la fuente utiliza días que terminan a las 17:00 America/New_York y cinco velas D1 completas en una semana normal. Se evalúa la última D1 completa recibida. Con UTC puede existir ya una vela dominical corta al llegar el lunes, por lo que no suponemos universalmente que no se forme D1 nueva el fin de semana.

8:15. En el screener TradingView, filtros D1 con datos del cierre de la sesión del viernes: RSI(14) < 35, precio bajo EMA 200 y ADX(14) > 20. Objetivo: pares sobrevendidos dentro de una tendencia bajista.

El filtro del modelo devuelve cuatro pares con datos completos para los 28. La revisión utiliza la misma fuente, final D1 e inicialización de indicadores:

• AUD/USD. Un RSI hipotético de 28 y un precio bajo EMA 200 cumplen el filtro. Con una zona W1 registrada previamente, el candidato pasa al análisis posterior; la proximidad al soporte no es por sí sola una instrucción de compra.
• NZD/USD. Cumple el filtro, pero una regla adicional exige proximidad a una zona W1, ausente aquí. Registro: descartado en validación, no «señal falsa» etiquetada tras una pérdida.
• EUR/GBP. En el modelo, el escáner informa ADX 21 y un segundo flujo 18 frente al umbral > 20. No es una medición coherente única. Registre fuentes y suspenda la comparación hasta verificar OHLC, límites diarios e inicialización. No atribuya toda la diferencia de tres puntos ADX únicamente al flujo sin recalcular.
• GBP/CHF. RSI 31 y ADX 27 hipotéticos cumplen el filtro. La proximidad a un retroceso del 61,8% necesita un giro conocido previamente y una tolerancia definida; la alerta de precio y el RSI siguen siendo condiciones separadas.

Modelo: 4/28 = 14,2857% de los instrumentos pasan el filtro y 2/28 = 7,1429% quedan en seguimiento. No se midió el tiempo de trabajo. Con dos conjuntos de datos ausentes, el informe correcto diría «4 candidatos entre 26 evaluados, cobertura 26/28 = 92,8571%», no «4 de 28»; se desconocen los resultados de los dos ausentes.

8. Alertas: no perder oportunidades sin mirar constantemente

Una alerta separa la espera de una condición de la revisión del gráfico. Su efecto sobre el tiempo de trabajo puede calcularse. Eso no garantiza menos operaciones impulsivas; la notificación sigue requiriendo cumplir el plan.

Orden de mercado frente a limitada: regla breve

Una orden de mercado no garantiza precio ni ejecución en cualquier circunstancia. Una limitada restringe el precio conforme a las reglas del producto, pero puede no ejecutarse. Sin datos, no suponemos que una limitada «suela ganar» en D1. La elección del tipo de orden y la activación bid/ask se explican en el artículo 2.7.

Tipos de alertas

• Precio. «Avíseme cuando EUR/USD alcance 1,0700». Se configuran en niveles de soporte/resistencia, retrocesos Fibonacci y zonas de interés. Sin programar.
• Indicador. «RSI(14) < 30 en D1» o «el histograma MACD cambió de signo». En TradingView: pulse el indicador → Crear alerta. En MT4/MT5, mediante un indicador propio con función de alerta. Atención: una alerta MT4 necesita la plataforma abierta o un VPS, porque funciona localmente.
• Sobre un objeto de dibujo. TradingView permite configurar alertas sobre directrices y zonas dibujadas: el precio toca su línea semanal y recibe una notificación en el teléfono. Combina análisis dibujado manualmente y aviso automático.
• Condición compuesta. Una alerta de varias condiciones: «precio bajo EMA 200 Y RSI < 35 Y ADX > 25». Requiere Pine Script o MQL, pero se configura una sola vez.

Cómo combinar alertas en la práctica

Basadas en zonas y en indicadores. El fin de semana dibuja zonas en W1/D1 y configura alertas de precio sobre ellas. Paralelamente añade alertas de indicador (RSI < 30) a los pares seguidos. Cuando ambas se activan aproximadamente al mismo tiempo, la condición es más selectiva, aunque no necesariamente una confirmación independiente: ambos criterios se calculan a partir del mismo precio. El enfoque de zonas encaja con el análisis de soportes y resistencias y el de indicadores con estrategias de osciladores.

Reduzca repeticiones innecesarias y condiciones vencidas. El número de alertas activas depende del proceso de revisión: puede escanear todo el universo y enviar únicamente eventos nuevos deduplicados. No necesita omitir instrumentos para reducir avisos.

Deduplicación: una condición, una alerta. La condición «RSI < 30» cumplida en seis velas consecutivas equivale a seis alertas, salvo que decida expresamente lo contrario. Distinga el evento de cruce —el RSI cruza 30 hacia abajo— del estado —el RSI está por debajo de 30—. Para alertas normalmente interesa el cruce, evaluado una vez por vela cerrada («Once Per Bar Close») y rearmado solo cuando el RSI vuelve a superar el umbral. Sin esa decisión, la máquina satura de mensajes y la fatiga de alertas acaba haciendo que ignore todo.

Hora del servidor y resultados del escaneo D1. Un screener D1 en un bróker con servidor GMT+2/+3 y otro con GMT+0 calcula indicadores sobre velas delimitadas de forma distinta; la misma regla devolverá listas diferentes la misma mañana. Escanee sobre el flujo con el que opera; la mecánica de límites de velas y hora del servidor se explica en el art. 5.11 y el art. 4.1.

9. Backtesting: qué probar y cómo interpretar los resultados

El backtesting comprueba cómo se habría comportado su estrategia sobre datos históricos^[1]. No le dice cuánto ganará. Solo indica si una regla se comportó conforme a sus supuestos en la historia. Es mucho, pero no equivale a una ventaja en real. La alternativa —probar directamente en una cuenta real— simplemente cuesta más.

Qué merece probarse

Una prueba histórica exige reglas reproducibles y datos disponibles en cada momento. Incluso una desigualdad sencilla está incompleta sin fuente, marco temporal, inicialización y precio de respuesta.

• Reglas de entrada mediante indicadores. «Comprar cuando RSI(14) baja de 30 en D1 y EMA 50 > EMA 200» es inequívoco y programable. No deja margen de interpretación.
• Reglas de salida y SL/TP. SL fijo de 50 pips y TP de 100 pips, o stop móvil de 2× ATR. Medible y comparable.
• Comparar variantes. ¿Funciona mejor RSI < 30 en D1 o en H4? ¿Un SL de 40 pips da mejor factor de beneficio que uno de 60? El backtest responderá, con las reservas que se explican a continuación.

Lo que se presta mal al backtesting es todo lo que requiere juicio humano:

• Acción del precio. La geometría de las velas, una zona y la hora de confirmación pueden definirse numéricamente. Un «parece convincente» discrecional exige un protocolo de evaluación separado y registrado; no suponemos que el ojo aporte una ventaja demostrada sobre la regla.
• Contexto estructural. Etiquetar manualmente la onda 2 requiere reglas, una versión del etiquetado y su hora de creación. Reetiquetar después no puede mejorar un resultado anterior de la prueba.
• Decisiones discrecionales. Los descartes pueden registrarse prospectivamente. Sin ese registro, no sabemos si la discrecionalidad mejoró el resultado o solo se eligieron los casos exitosos. No hay fundamento para afirmar que el contexto invisible al algoritmo explica por sí solo la rentabilidad.

Calidad de los datos: un tema del que se habla poco

Un backtest es tan fiable como los datos utilizados. En Forex es un problema serio. El mercado está descentralizado; los datos de su bróker pueden diferir de otros, con spreads distintos y pequeñas variaciones OHLC. OHLC pierde la información del movimiento dentro de la vela: si SL y TP eran ajustados, no permite saber cuál se tocó primero.

El modo «Every tick based on real ticks» de MT5 utiliza ticks disponibles, pero no garantiza que existan en todos los tramos. MetaQuotes describe la generación de ticks donde faltan datos y el rechazo de ticks incoherentes con los datos de minutos. Compruebe el informe. El spread histórico es distinto de la demora de ejecución. Un spread «actual» fijo utilizado en otro modo es un escenario, no siempre una estimación inferior: puede ser alto o bajo respecto a la historia probada.

Bid/ask, mid y precios del proveedor. No deduzca el tipo de precio del hecho de que una API sea gratuita. Los metadatos deben indicar bid, ask, mid, transacción u otra serie. Para un largo calculado respecto a mid, el coste del spread en pips es (spread de entrada + spread de salida)/2. Si ambos son de 1 pip y hay 200 ciclos completos, la diferencia es de 200 pips antes de costes adicionales. Con entrada ask y salida bid reales, esa diferencia ya está en los precios. Dukascopy y TrueFX son ejemplos de fuentes que comprobar; el nombre del proveedor no elimina la necesidad de revisar columnas, cobertura y huecos.

Cierre de vela e intravela son reglas distintas. Un toque puede producirse y desaparecer antes de terminar la vela. Un evento que exige cierre espera a que termine y se reciban los datos. Aquí no hay datos que respalden la anterior afirmación de un resultado un 30% mejor o de que «desaparece la mitad de las señales». Probar intravela requiere datos y un modelo del orden de movimientos; no puede reconstruirse arbitrariamente solo con OHLC.

La financiación tiene signo y unidad. El swap puede ser negativo o positivo según producto y lado de la posición; no deducimos su signo para corto USD/MXN o largo USD/TRY únicamente de las monedas. La prueba necesita especificaciones históricas y multiplicadores diarios, no solo la tabla actual. Por ejemplo, resultado de precio +80 USD, comisiones −7 USD y financiación −18 USD dan +55 USD; con financiación +18 USD, el resultado es +91 USD. El spread incluido en precios reales no vuelve a cobrarse. Las unidades y conversiones se explican en el artículo 2.8.

Una vela, dos resultados posibles

El modelo largo ya está abierto a un precio de ejecución de 1,1000. La siguiente vela tiene estos OHLC de bid: O = 1,1000, H = 1,1030, L = 1,0980, C = 1,1010. TP = 1,1020, SL ordinario = 1,0990; se supone ejecución sin huecos exactamente en el nivel y sin costes adicionales. La trayectoria O→H→L→C alcanza primero TP: +20 pips. O→L→H→C alcanza primero SL: −10 pips. Ambas tienen OHLC idénticos.

Con un nominal de 10.000 EUR, los resultados son +20 o −10 USD. No son dos resultados posibles de la misma operación real: muestran dos trayectorias compatibles con datos incompletos. Los precios de entrada y salida ya incluyen el lado del mercado, por lo que no añadimos spread otra vez. Un probador que asume un orden desde OHLC elige una convención que debe revelar en el informe. Un marco menor o ticks resuelven más casos, pero los datos ausentes siguen ausentes.

Abrir el diagrama a tamaño completo

Cómo interpretar los resultados

Principales métricas del backtesting:

Ejemplo: un backtest mal hecho y cómo corregirlo

Modelo de optimización: umbral RSI de 10 a 30 en pasos de 1, SL de 30 a 80 pips en pasos de 1 y TP de 80 a 200 pips en pasos de 1. La cuadrícula contiene 21 × 51 × 121 = 129.591 combinaciones, no unas decenas. Cuente también intentos abandonados y cambios manuales de reglas. Un mejor PF ilustrativo de 2,8 sobre datos 2020–2025 es un resultado de selección en ese conjunto, no prueba que RSI 22 / SL 43 / TP 167 tenga ventaja.

Un pico pronunciado alrededor de una combinación invita a comprobar sensibilidad. Por sí solo no demuestra sobreajuste: pueden importar los costes, una muestra pequeña y un cambio de régimen. Informe de toda la cuadrícula y la regla de selección, no solo del mejor punto.

Tras elegir parámetros sobre todo 2020–2025 no puede rebautizar 2024–2025 como muestra reservada. Necesita observaciones futuras nuevas u otro plan fijado de antemano. Entrenamiento, validación y prueba tienen funciones separadas; una vez utilizada la prueba, no vuelva a optimizar sobre ella.

Las diferencias entre prueba y funcionamiento pueden proceder del modelo de costes, datos, ejecución o cambios de condiciones. No toda prueba real más débil demuestra sobreajuste ni todo backtest es optimista por definición. Comparar exige las mismas reglas y un diario de señales, órdenes y ejecuciones reales.

10. Python para screening y backtesting

Python puede sostener un registro propio de datos y pruebas. Coste y dificultad dependen de la calidad de la fuente, el alcance y el mantenimiento. Un escáner propio exige gestión de errores, versiones de dependencias y supervisión; este artículo presenta un contrato lógico, no código de producción ni la promesa de un sistema barato listo para funcionar.

Qué ofrece Python que no ofrecen TradingView y MT4/MT5:

• Cualquier fuente de datos. Puede obtener datos de API de brókeres, como OANDA e Interactive Brokers, fuentes gratuitas, como yfinance para índices y ccxt para cripto, o proveedores de pago. No está limitado a la oferta de la plataforma.
• Análisis estadístico avanzado. Pruebas de significación, corrección de Bonferroni para comparaciones múltiples y visualización de distribuciones de rendimientos: tareas imposibles o muy incómodas en Pine Script. En Python con scipy y statsmodels bastan unas líneas.
• Flexibilidad de backtesting. Las bibliotecas backtrader y vectorbt permiten probar estrategias de cartera con muchos pares a la vez, asignación dinámica de capital y correlaciones entre instrumentos. Pine Script y MQL tienen limitaciones en este ámbito.
• Una cadena del screening a la ejecución. Todo el flujo —obtener datos, filtrar, generar señales, enviar alertas por correo o Telegram e incluso ejecutar órdenes mediante una API del bróker— puede funcionar en un solo script.
• Análisis de sentimiento. Algunos operadores experimentan con análisis automatizado del sentimiento de noticias e informes económicos e incorporan esa señal a la cadena de screening. Existen herramientas, desde scripts sencillos hasta API de modelos de lenguaje, pero en la práctica minorista sigue siendo más un experimento que una solución terminada.

Una cadena en pseudocódigo: datos, escaneo y archivo. No contiene tokens de API ni funciones de ejecución de órdenes. La misma lógica puede implementarse en cualquier entorno.

PSEUDOCÓDIGO DE LA CADENA: SIN FUNCIÓN DE ENVÍO DE ÓRDENES
Cargar la configuración fijada y la lista completa de símbolos con versión.
Determinar los finales de vela esperados a partir del calendario de la fuente, no del reloj del ordenador.
Para cada símbolo, recuperar datos con component, start, end, complete,
  received_at, revision e identificador de fuente.
Conservar una instantánea inmutable de datos y su suma de comprobación.
Validar OHLC, unidad del precio, continuidad de sesiones y calentamiento de indicadores.
Ante un error, registrar NO_DATA con su causa; no crear NO_SIGNAL.
Con una instantánea válida, calcular la regla completa de criterios.
Registrar un resultado para cada símbolo, incluidos los que incumplen la condición.
Deduplicar alertas por version, feed, symbol, timeframe y end_UTC.
Ante una corrección, añadir un registro nuevo vinculado a la instantánea anterior.
Resumir: expected, evaluated, missing, candidates y duración del escaneo.
Archivar por separado la decisión manual y su hora, sin sobrescribir el resultado del filtro.
Informar de fallos del proceso y símbolos ausentes, incluso con cero candidatos.

Antes de elegir una fuente, revise licencia, cobertura de instrumentos, lado del precio, marcas temporales, integridad, revisiones y bid/ask disponible. No asignamos una etiqueta única a todos los datos Yahoo ni a las API gratuitas. Una biblioteca de lectura no mejora automáticamente la calidad ni proporciona precios de ejecución.

Reintentar una petición de datos es distinto de reintentar el envío de una orden. Un escaneo puede recrear con seguridad la misma clave y devolver su resultado anterior. La capa de ejecución necesita un identificador separado de instrucción y consultar el estado antes de repetir; queda fuera del screener mostrado.

11. Riesgos de la automatización

La automatización ahorra tiempo y reduce errores emocionales, pero introduce problemas propios. Este es el mapa conjunto de riesgos del backtest; los apartados siguientes desarrollan los más importantes:

Sobreajuste: adaptación al pasado

El sobreajuste consiste en adaptar decisiones a propiedades de una muestra concreta que no persisten fuera de ella. No es sinónimo de cualquier pérdida el primer día. La sensibilidad de parámetros, el número de intentos y las nuevas observaciones ayudan a evaluar el problema.

Señales de alerta de sobreajuste:^[5]

• La estrategia tiene muchos parámetros libres respecto al número de operaciones y la historia disponible.
• Un pequeño cambio de parámetro, RSI 14 → RSI 15, modifica drásticamente los resultados: la llamada fragilidad.
• Un backtest obtiene resultados excelentes en un período y pérdidas en otro.
• Un PF o Sharpe alto exige evaluar incertidumbre, número de variantes examinadas y dependencia entre resultados. Ni una muestra inferior a 100 ni superior a 500 operaciones determina por sí sola si existe ventaja. Revise también duración, grandes pérdidas raras y rendimiento sobre datos que no se usaron para elegir la regla.

La prueba fuera de muestra solo tiene sentido si esa muestra no participó en la selección de reglas. En walk-forward, al ajuste sobre una ventana anterior le sigue la evaluación sobre otra posterior; todos los umbrales, actualizaciones y la agregación de resultados se registran previamente. Exigir resultado positivo en cada ventana no es una regla estadística universal.

Exploración sesgada de datos

Con 50 pruebas independientes de hipótesis nulas verdaderas al nivel del 5%, la probabilidad de al menos un rechazo falso es 1 − 0,95^50 = 92,3055% y el número esperado es 2,5. Es riesgo alto, no certeza. Las variantes sobre los mismos datos suelen ser dependientes, por lo que ese cálculo de independencia no puede tratarse como su probabilidad medida.

Registre la familia de intentos antes de elegir al ganador. Con 50 pruebas y nivel familiar del 5%, Bonferroni da un umbral de 0,05/50 = 0,001 para cada valor p válido. Controla el riesgo de al menos un rechazo falso sin exigir independencia. FDR responde otra pregunta; el ejemplo siguiente distingue ambas. Ninguna corrección de valores p establece la rentabilidad de una estrategia.

Precisión, sensibilidad y costes de omisión

Modelo de 100 casos etiquetados independientemente: el patrón de referencia es positivo en 20 y negativo en 80. El screener emite 15 alertas: 12 coinciden con la referencia y 3 son falsas; omite 8 positivos. Precisión = 12/15 = 80%, sensibilidad = 12/20 = 60%, especificidad = 77/80 = 96,25%. De estas tres métricas no se deriva rendimiento financiero. Las etiquetas deben ser independientes del filtro; no etiquetamos como positivo todo beneficio posterior seleccionado manualmente.

Si la referencia usa un resultado futuro, su etiqueta solo está disponible al final del horizonte. No puede influir en una señal anterior ni entrar prematuramente en entrenamiento. Descargue los modelos recalculados; todas las cifras de este bloque son hipotéticas.

Abrir el diagrama a tamaño completo

Sesgo de supervivencia en EA preparados

Mirar solo sistemas aún vendidos y publicados omite intentos retirados. Comparar exige una población conocida y un registro de versiones fallidas. Desconocemos cuántos «miles» de EA se retiraron o los resultados de ejemplo de influencers; no utilizamos esas cifras como prueba.

La ilusión de control

Automatizar exige supervisar estado del proceso, actualidad de datos y errores no gestionados. Funcionar de noche no determina por sí solo el deslizamiento ni el número de pérdidas. Las alertas deben informar de datos ausentes o escaneos detenidos, además de configuraciones cumplidas.

La caja negra

La falta de documentación dificulta saber si un cambio de resultados proviene de datos, regla o ejecución. Un sistema puede dejar de rendir según lo esperado; necesita una condición de parada y un procedimiento de evaluación. «Hasta ahora ha funcionado» no basta.

Indicadores que repintan

Distinga lectura cambiante en una vela abierta, confirmación retrasada de un giro, corrección de datos y reescritura de una señal anterior. Conserve una instantánea del valor con su hora de evaluación y compárela con la historia posterior. Que se llame ZigZag no determina todo uso; el problema es usar un punto antes de confirmarse u ocultar cambios.

Firmas prop y automatización

Las reglas prop son contractuales y varían por programa y fase. No afirmamos que muchas firmas prohíban toda automatización. Por ejemplo, FTMO describe permitir algoritmos y EA sujetos a restricciones del programa. Compruebe las normas actuales, naturaleza de la cuenta —incluidas las simuladas—, límites y prácticas prohibidas; aceptar un screener no equivale a aceptar cualquier método de ejecución.

12. Qué no automatizar al principio

Antes de automatizar ejecución, debe describir también actividades ajenas a la señal. La lista identifica tareas que requieren una regla y prueba separadas; no suponemos que ejecutar manualmente sea siempre más eficaz.

• Gestión de posiciones. Tamaño, mover el SL, cierres parciales: son decisiones que requieren contexto y juicio. Un EA hará exactamente lo que le diga, pero «lo que le diga» y «lo que debería hacer ahora» suelen ser cosas distintas. Aprenda a gestionar manualmente antes de automatizar.
• Calendario macro. Un screener puede tener en cuenta las NFP si recibe un horario correcto y una regla de bloqueo. No puede predecir el spread ni el contenido de un anuncio no publicado. No tener calendario es una limitación explícita, no una propiedad de todo sistema automático.
• Selección del universo. Defina y versione la lista antes de probar. Excluir pares con malos resultados después de examinarlos es otro intento de selección. Mida características sobre datos especificados en vez de atribuirles propiedades fijas.
• Fines de semana y pausas. Un filtro de spread puede suspender órdenes nuevas, pero no limita la pérdida por hueco de una posición existente. Reducir exposición nominal disminuye sensibilidad al precio; un stop ordinario no garantiza precio. Una cobertura con opciones requiere acuerdo y cuenta separados, no solo una etiqueta «cobertura». El riesgo de pausa se explica en el artículo 4.4.
• Estado de la cuenta. Compruebe producto, modo cobertura/compensación, margen para una instrucción nueva y reglas de cierre por garantías insuficientes. El orden de liquidación depende del proveedor; no suponemos universal cerrar primero la mayor pérdida. Margen y protección se tratan por separado en el artículo 2.6. Poder aceptar una orden en un momento no garantiza mantener después la posición.

Automatice actividades claras y repetibles y conserve su rastro. Escaneo, alertas, decisiones y ejecución son etapas sucesivas con errores y límites propios. Repetir más rápido una regla no mejora su calidad; solo permite implementarla y probarla de forma constante.

13. Comparación de herramientas

La tabla describe funciones, no una clasificación de calidad. Licencias, acceso a datos, VPS y costes de transacción son partidas separadas. Compruebe límites y precios en la documentación actual.

Tamaño de posición: fuera del alcance de este artículo

Elegir una configuración sin tamaño adecuado es hacer la mitad del trabajo, pero fórmulas, tratamiento de costes dentro del presupuesto de riesgo y ejemplos numéricos corresponden a la sección 9. La calculadora de tamaño de posición interactiva y el simulador Monte Carlo están en Herramientas.