Puedes tener cobertura de pruebas completa, revisión de código y monitorización. Nada de eso cubre el escenario en que tu proceso no está corriendo.
Nos pasó el 23 de julio de 2026. Un terminal estuvo apagado trece horas con posiciones abiertas. Nada las vigilaba. La regla de corte por pérdida diaria sólo se activó al reiniciar, con el daño ya hecho.
Por qué las pruebas no lo ven
Una prueba ejecuta tu código. Ese es el requisito previo de cualquier prueba.
Los escenarios donde tu código no se ejecuta son invisibles para el marco de pruebas por construcción. No es que se te olvide escribir el test — es que el test no se puede escribir dentro del sistema que estás probando.
La lista de esos escenarios es corta y siempre la misma:
- El proceso está caído.
- La máquina está apagada.
- La red no responde.
- El proceso está vivo pero atascado y no avanza.
- El proceso corre pero sus acciones son rechazadas por el sistema externo.
Cada uno de ellos rompe la suposición de que «si pasa X, mi código reacciona».
Lo que cambia cuando lo asumes
Al aceptar que tu proceso puede no estar, las protecciones se dividen en dos clases que antes parecían la misma:
Protecciones que requieren que estés vivo. Toda la lógica condicional: umbrales, contadores, decisiones basadas en estado acumulado. Son las inteligentes y las que puedes ajustar. Valen cero cuando no corres.
Protecciones que persisten fuera de ti. En nuestro caso, una orden de stop que descansa en el servidor del bróker. Es tonta —sólo es un precio— pero existe con la máquina apagada.
El error de diseño no fue no tener protecciones. Teníamos tres. El error fue que las tres eran de la primera clase.
El patrón, fuera del trading
Esto no es específico de sistemas financieros. Es el mismo agujero en cualquier proceso de larga duración:
- Un límite de gasto evaluado por tu servicio no te cubre si tu servicio se atasca en un bucle. El límite tiene que vivir en el proveedor.
- Un trabajo de limpieza programado en tu aplicación no se ejecuta si la aplicación no arranca. Necesita un disparador externo.
- Un timeout en tu cliente no te cubre si el cliente muere. Tiene que estar también en el servidor.
- Un reintento en el productor no te cubre si el productor es lo que cae. Necesitas durabilidad en la cola.
La pregunta útil, en cualquier revisión de diseño:
Cada mecanismo de protección: ¿dónde vive? ¿Sigue existiendo cuando el componente que lo contiene desaparece?
Si la respuesta es que no, no es una protección. Es una comodidad para el camino feliz.
Lo que hicimos
Dos cosas, ninguna sofisticada:
- Replicar el stop del lado del bróker, de forma que exista con independencia de nuestro proceso. Se coloca al abrir y se recoloca al añadir posiciones.
- Documentar el hueco que queda. Un servidor privado atendiendo el terminal es la única cobertura para «la máquina no está encendida». Eso no lo puede resolver el software: es una decisión operativa del cliente y hay que decírselo con claridad, no enterrarlo en un manual.
Esa segunda parte es la que más cuesta escribir en una página de producto. También es la que evita que alguien confíe en una garantía que no le has dado.
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.