Auditamos nuestro propio EA de gestión de riesgo. Encontramos 3 fallas silenciosas — así las arreglamos.
La mayoría de los posts sobre Expert Advisors hablan de cuánto ganan. Este va a hablar de algo distinto: los errores que encontramos en nuestra propia herramienta de protección de riesgo, auditándola línea por línea, antes de dejarla correr en una cuenta real.
Si programás EAs, o corrés alguno que no escribiste vos, esto te va a interesar — porque los tres errores que vas a leer no son exóticos. Son el tipo de cosa que cualquiera de nosotros dejaría pasar sin una auditoría deliberada.
El problema que casi nadie resuelve
Pensá en una cuenta típica de alguien que ya lleva un tiempo automatizando: dos o tres EAs corriendo en paralelo, alguna posición manual abierta de vez en cuando, tal vez un cuarto símbolo que se prueba en demo. Cada uno de esos sistemas gestiona su propio riesgo — su stop loss, su tamaño de posición. Ninguno sabe nada del resto.
El día que el mercado se mueve fuerte y los cuatro pierden al mismo tiempo, no existe nada que sume el daño total y diga "basta". Cada EA individualmente está "funcionando como se diseñó" — perdiendo dentro de sus propias reglas — mientras la cuenta completa se desangra sin que ningún componente lo note.
Construimos ATX Loss Guard Shield para resolver exactamente eso: un cortacircuitos que vigila la cuenta entera — cualquier símbolo, cualquier EA, tus trades manuales — y cierra todo si se rompe un límite que vos definís. No opera, no predice nada. Solo hace cumplir la regla que ya decidiste, en el momento exacto en que más cuesta cumplirla vos mismo.
La auditoría: buscar errores, no funciones nuevas
Antes de publicarlo, en vez de agregarle más funciones, hicimos lo contrario: una revisión completa buscando específicamente qué estaba mal en lo que ya existía. La pregunta que guió todo no fue "¿compila?" — eso es trivial. Fue: ¿qué pasa en el peor momento posible, no en el mejor?
Esa pregunta es la que separa un código que "funciona en la demo" de uno que sigue funcionando cuando el terminal se reinicia a mitad de una racha perdedora, o cuando el broker desconecta un segundo en el momento exacto en que había que cerrar todo. Encontramos tres fallas reales, ninguna visible con solo compilar:
| Falla | Riesgo real | Cómo se resolvió |
|---|---|---|
| Input "Magic number" documentado pero nunca aplicado en el código | Los cierres forzados no quedaban identificables en el historial de la cuenta | Se conectó de verdad al motor de cierre |
| La racha de pérdidas se perdía al reiniciar | Si la cuenta estaba bloqueada solo por racha de pérdidas, un simple reinicio del EA borraba el contador — y el bloqueo desaparecía en silencio, justo cuando más protección hacía falta | El estado se persiste en disco; sobrevive cualquier reinicio de terminal o del EA |
| El cartel de motivo mostraba el límite equivocado en un gap | Un gap que rompía varios límites a la vez (diario, semanal, mensual) mostraba el más amplio en vez del más ajustado | Ahora siempre prioriza y muestra el límite más estricto que se rompió |
La segunda es la que más nos hizo pensar. No es un bug que aparezca en un backtest ni en una demo corriendo tranquila. Solo se manifiesta en la combinación exacta de "ya estaba bloqueada por racha" + "algo forzó un reinicio" — el tipo de escenario que solo se te ocurre buscar si te preguntás activamente qué puede fallar, no si esperás a que falle.
Una honestidad más: lo que ni auditando se puede arreglar
Por más que se corrija todo el código, hay un límite que ninguna herramienta local puede superar: si la computadora se apaga, se corta la luz, o el terminal se cae por completo, no corre ningún código — y ninguna herramienta, por bien diseñada que esté, puede avisarte o protegerte mientras no hay nada corriendo. Preferimos decir esto claramente en vez de venderte una promesa de protección 24/7 que no podemos cumplir. Para eso existe correr el terminal en un VPS, que sí se mantiene encendido independientemente de tu propia máquina.
El mismo criterio en toda la suite
Este no es un caso aislado de un solo producto. Los cinco EAs gratis de la suite comparten el mismo motor de riesgo — validación de stops según el broker, chequeo de margen antes de cada orden, cierre de emergencia anti-gap. Sin martingala, sin grid, sin hedge de recuperación:
- ATX Aurum Focus — XAUUSD, ruptura de volatilidad
- ATX Meridian Drift — EURUSD, reversión a la media
- ATX Volt Pulse — USTEC, pullback en tendencia
- ATX Chain Current — BTCUSD, seguimiento de tendencia
- ATX Little Wing — multi-activo, el generalista
Dónde lo desarrollamos y probamos
Todo esto se prueba en cuentas reales de IC Markets y Exness — dos brokers regulados que cubren perfiles distintos (spreads crudos vs. depósito mínimo bajo). Si abrís cuenta con estos enlaces, podemos recibir una comisión del bróker, sin costo adicional para vos — son exactamente las mismas condiciones que abriendo por cualquier otro canal. Los mencionamos porque son, literalmente, donde probamos lo que contamos acá, no al revés.
Si programás tu propio EA: 3 preguntas para auditarlo hoy
No hace falta tener una herramienta de riesgo dedicada para aplicar el mismo criterio al código que ya tenés corriendo. Tres preguntas, basadas en lo que encontramos nosotros:
- ¿Qué pasa si tu EA se reinicia a mitad de cualquier contador que estés llevando (rachas, límites acumulados, estados temporales)? ¿Ese contador sobrevive, o vuelve a cero en silencio?
- ¿Cada input que declarás realmente se usa en la lógica, o hay alguno que quedó documentado pero nunca conectado?
- Si dos condiciones se cumplen en el mismo tick, ¿tu código decide con criterio cuál prioriza, o gana la que se evaluó última por casualidad del orden del código?
Si querés ver el resultado
El código de ATX Loss Guard Shield está en el Market, con la auditoría completa reflejada en la versión publicada.
Gracias por leer hasta acá. Si programás tus propios sistemas, contanos qué encontraron auditando el de ustedes en los comentarios — seguro no somos los únicos con historias así.
