El 22 de julio de 2026 el oro se movió 27 $ en una hora. Nuestro bróker deshabilitó el trading algorítmico durante el episodio.
Cada orden de cierre que envió nuestro sistema fue rechazada.
El fallo de razonamiento
Cuando diseñas protecciones para un sistema automático, el modelo mental por defecto es: «si pasa X, cierro». Escribes la condición, escribes la llamada de cierre, lo pruebas, funciona.
Lo que ese modelo asume sin decirlo es que la llamada de cierre siempre se puede ejecutar. Y esa suposición es exactamente la que falla en el momento en que la protección importa.
No es un caso raro. Es un caso correlacionado: el bróker restringe la ejecución precisamente cuando el mercado se mueve fuerte, que es cuando tu stop tiene que dispararse. Tu protección y su indisponibilidad tienen la misma causa.
Las tres capas, y cuál sobrevive
Cerberus tiene tres redes. Vale la pena mirarlas por dónde viven:
1. Corte por pérdida diaria — vive en nuestro código. Cierra todo y pausa. No se ejecuta si el bróker rechaza órdenes.
2. Stop por canasta — vive en nuestro código. Corta el grupo de posiciones al pasar un límite. Tampoco se ejecuta.
3. Stop replicado del lado del bróker — vive en el servidor del bróker, como una orden SL en reposo sobre cada posición. Se ejecuta.
La tercera es la única que sobrevivió a ese episodio. Las dos primeras son más listas, más configurables y más fáciles de razonar. Y ese día valieron cero.
Por qué no dejamos sólo la tercera
Una orden en reposo en el servidor es tonta: es un precio, y ya. No sabe de la pérdida acumulada del día, no sabe cuántas posiciones tienes ni cómo se relacionan, y no puede pausar el sistema hasta que tú vuelvas.
Así que las capas no son redundantes, son complementarias en su modo de fallo:
- La lógica en tu código es inteligente pero depende de que puedas actuar.
- La orden en el servidor es tonta pero se ejecuta pase lo que pase.
El error es tener sólo una de las dos. La mayoría de sistemas tienen sólo la primera, porque es la que se programa cómodamente.
El detalle que casi nos cuesta
Hay una versión sutil del mismo problema. Teníamos una salida por código que cerraba una posición cuando el beneficio retrocedía cierto margen. En un salto de tick, una posición armada en +15,8 pips cerró en −14,9. Entre que el código evaluó la condición y la orden llegó al servidor, el precio ya estaba en otro sitio.
La sustituimos por una orden que descansa en el bróker y sube con el precio. Ahora se ejecuta en el nivel, no en el nivel más el retraso.
Regla que sacamos
Si una protección sólo existe mientras tu proceso corre y tu conexión responde, entonces no cubre el escenario en que tu proceso o tu conexión son parte del problema.
Eso aplica muchísimo más allá del trading. Un reintento que vive en el cliente no te cubre si el cliente es el que cae. Un límite de gasto que evalúa tu servicio no te cubre si tu servicio se ha atascado. Un timeout en tu código no te cubre si tu código no llega a ejecutarse.
La pregunta útil no es «¿qué hace mi protección cuando pasa X?». Es «¿dónde vive mi protección, y sigue viva cuando pasa X?»
De la construcción de Cerberus, Tuurt Labs. Instrumento de alto riesgo: operar CFDs apalancados puede provocar la pérdida total del capital. Esto no es asesoría de inversión.