Una cuenta puede mostrar un balance intacto mientras la equity ya ha cruzado el límite. Si el bot espera a que cierre el trade para reaccionar, llega tarde.
Probar un kill switch de prop firm exige recrear el estado de la cuenta, el cambio de día y las órdenes que siguen vivas. La prueba buena no pregunta si apareció un aviso: comprueba si el sistema deja de añadir riesgo y si vuelve a arrancar sin olvidar la decisión.
La idea que permanece es sencilla. La confianza no nace del mensaje “límite alcanzado”, sino de comprobar que el mismo evento produce la misma protección en todos los caminos relevantes.
El límite que realmente estás intentando vigilar
Un kill switch es un control de toda la cuenta. Detiene la estrategia cuando aparece una pérdida o una condición operativa definida. Un stop loss protege una posición concreta; el kill switch también tiene que contemplar las posiciones abiertas y las entradas pendientes que dejaron señales anteriores.
La página actual de Trading Objectives de FTMO define el Maximum Daily Loss a partir de la equity de la cuenta, con el P/L de las posiciones abiertas, swaps y comisiones, y sitúa el recálculo diario en 00:00 CE(S)T. La regla pertenece a FTMO y puede cambiar. Para una cuenta real, la fuente de referencia es siempre la documentación vigente de la firma.
cTrader ofrece Account.Balance y Account.Equity como valores distintos. La referencia IAccount de cTrader describe la equity incorporando el resultado no realizado. Ahí aparece el primer control de calidad: leer solo los trades cerrados es vigilar otra cosa.
El artículo sobre límite de pérdida diaria frente a pérdida máxima explica la diferencia entre ambas fronteras. El trabajo adicional aquí es operativo: comprobar que el bot aplica la frontera correcta al estado correcto y en el momento correcto.
Convierte la regla de la prop firm en un contrato
Antes de abrir el backtest, deja por escrito una especificación que otra persona pueda programar sin completar huecos. Como mínimo, incluye:
- el valor observado: balance, equity o la combinación exacta de la regla de la firma;
- la frontera de pérdida y el valor de referencia desde el que se calcula;
- la zona horaria de la firma y el acontecimiento que inicia el nuevo día;
- el tratamiento de nuevas entradas, órdenes pendientes y posiciones existentes;
- si el bloqueo permanece después del reinicio diario;
- la respuesta cuando falta la equity, el reloj o el estado de una orden.
No conviertas estas decisiones en diales ocultos dentro del cBot. Un test de control no sirve para buscar la configuración que deja más bonita la curva. Sirve para demostrar que la política escrita se ejecuta cuando el camino se complica.
La curva no basta: reproduce el estado de la cuenta
El caso básico es fácil de imaginar: una posición entra en pérdida, la equity atraviesa la frontera y el mercado recupera después antes del cierre. El balance final puede ocultar por completo el incumplimiento. La reproducción debe conservar ese tramo flotante.
La resolución histórica también forma parte de la evidencia. Si la regla puede incumplirse con una posición abierta, el cierre de una vela no basta. Un replay M1 puede seguir sin ver el orden exacto de varios eventos dentro de la vela; un backtest basado solo en cierres no puede afirmar que observó el recorrido intrabar.
Guarda con cada comprobación del control:
- balance y equity;
- posiciones abiertas y su P/L no realizado;
- órdenes pendientes que todavía podrían crear exposición;
- swaps, comisiones y otros ajustes que formen parte de la regla;
- la hora de la firma y la hora del servidor o de la plataforma.
La colección Positions de cTrader y la colección PendingOrders de cTrader exponen los objetos que el cBot tiene que revisar. El detalle importante no es memorizar una llamada de API. Es no dejar una vía de exposición fuera del test después de la activación.
El reloj de FTMO merece una prueba propia
El cambio de día no es simplemente la medianoche del ordenador. La página actual de FTMO sitúa el recálculo diario en 00:00 CE(S)T. Si la conversión entre la zona de la firma, el servidor y UTC queda implícita, el mismo trade puede caer en dos días distintos según dónde se mire.
Construye casos de frontera para una posición que atraviesa el cambio de día, un cierre o un coste registrado alrededor del reinicio, un reinicio del cBot antes de guardar la nueva referencia y el cambio de horario entre la zona de la firma y UTC.
Antes de ejecutar, escribe la equity de referencia esperada, el estado de bloqueo y la siguiente acción permitida. El proceso no debe reutilizar silenciosamente la referencia anterior, reiniciar porque cambió la zona del equipo ni volver a habilitar entradas solo porque el cBot se inició otra vez.
Cuando se activa, el aviso no es suficiente
Un mensaje en el log no protege una cuenta. El control tiene que demostrar una secuencia completa:
- La puerta de entrada rechaza una nueva orden de mercado y las entradas pendientes se cancelan o deshabilitan según la política escrita.
- Las posiciones abiertas reciben el tratamiento documentado; no desaparecen del alcance del control.
- Una señal que llega en el mismo instante que la activación no puede colarse entre la comprobación de riesgo y la orden.
- El evento, sus datos y el estado resultante quedan registrados y el bloqueo permanece como está definido.
Cerrar todas las posiciones, congelarlas o aplicar otra acción no tiene una respuesta universal. Depende de las reglas vigentes de la firma y del propósito del control. Lo que sí se puede exigir a la prueba es que la decisión esté declarada y que también se pruebe el fallo de la acción: una cancelación rechazada o un cierre que no llega no puede dejar la puerta abierta a nueva exposición.
Una matriz de fallos que sí merece repetirse
Una matriz corta evita que el backtest se convierta en una demostración de un solo camino favorable.
| Caso | Estado que se reproduce | Evidencia esperada |
|---|---|---|
| Datos de cuenta ausentes | No se puede confirmar equity, posiciones u órdenes | El bloqueo permanece y la incidencia queda visible |
| Entrada pendiente | Una orden puede convertirse en posición después de la activación | Se cancela o deshabilita antes de añadir riesgo |
| Posición flotante | El balance queda por encima mientras el P/L abierto lleva la equity a la frontera | No se permite otra entrada y se guarda la fotografía de equity |
| Cruce del reinicio | Una posición sigue viva cuando cambia el día de la firma | La nueva referencia y el bloqueo coinciden con el contrato |
| Carrera en la misma actualización | Llegan una señal válida y la activación juntas | El orden de ejecución es determinista |
| Reinicio del proceso | El cBot vuelve con posiciones u órdenes todavía presentes | Recupera el estado o se mantiene bloqueado de forma segura |
| Intervención externa | Cambia una posición u orden fuera del cBot | La siguiente reconciliación detecta y registra la diferencia |
El informe debe conservar la detección, la acción ejecutada, las órdenes rechazadas o perdidas, los reinicios y los casos en que no había motivo para bloquear. Un simple “pasó” no permite saber dónde se rompería el control.
Separa el control del resultado de la estrategia
El backtest de la estrategia responde a una pregunta: qué produjeron sus señales, salidas y costes bajo un modelo de mercado. El test del kill switch responde a otra: cómo se aplicaron las reglas de la cuenta al flujo de eventos. Mezclarlos facilita ajustar el guardián a una sola secuencia histórica.
Congela la estrategia, los símbolos, el sizing, la zona horaria y el modelo de ejecución. Define la matriz antes de ver los resultados. Incluye periodos ganadores y perdedores, posiciones que pasan por el reinicio y solicitudes que fallan. Mide el tiempo hasta la detección, las entradas posteriores a la activación, las órdenes que quedaron vivas y la recuperación tras un reinicio. Después repite el control en un periodo hold-out que no se haya usado para ajustar la estrategia ni el guardián.
Que el control pase sus casos no demuestra que la estrategia tenga ventaja. Que reduzca el drawdown tampoco demuestra que una cuenta real vaya a comportarse igual. La conclusión verificable es más estrecha: bajo los datos y fallos declarados, la política se ejecutó como estaba escrita.
La línea base reproducible de realbacktesting
realbacktesting es un estudio de software de trading para cTrader que construye sus pruebas para que puedan verificarse, no para que dependan de una captura de pantalla. Su metodología publicada registra ejecución intrabar M1, slippage de 1 bps, swap aplicado, spread fijo de 2-pip para la línea FTMO, comisión cargada en la ejecución y un hold-out out-of-sample del 30%.
Son condiciones de prueba, no una promesa de operativa real. La página de metodología explica los supuestos; la página de funding coloca la curva de equity dentro de las restricciones que importan en una cuenta de prop firm. El test del kill switch complementa esa base: no la sustituye.
La guía sobre drawdown de balance y equity explica por qué importa el recorrido observado. El kill switch es la capa operativa que convierte esa observación en una respuesta de cuenta que también puede probarse.
Dudas habituales al implementarlo
¿Basta con leer Account.Balance para el límite diario?
No si la regla aplicable utiliza la equity flotante. cTrader expone Account.Equity, y los Trading Objectives actuales de FTMO describen el cálculo diario con equity, P/L abierto, swaps y comisiones. La regla concreta de la cuenta se verifica antes de fijar el contrato.
¿El kill switch sustituye al stop loss?
No. El stop loss pertenece a una posición; el kill switch gobierna entradas nuevas, órdenes pendientes y el tratamiento declarado de las posiciones que ya existen. Son capas distintas del control de riesgo.
¿Tiene que cerrar todas las posiciones?
No hay una respuesta universal. La acción depende de las reglas vigentes y del objetivo del sistema. El test sí debe mostrar qué ocurre cuando una petición de cierre o cancelación es rechazada.
¿Un backtest puede demostrar que nunca habrá un incumplimiento?
No. Puede demostrar que el control respondió a los estados y fallos históricos que se especificaron. Los huecos de datos, la ejecución real, una interrupción de plataforma y un cambio de reglas quedan fuera de esa prueba.
¿Qué reinicio conviene probar primero?
Reinicia el proceso después de la activación, con posiciones u órdenes todavía vivas. El control debe reconstruir el estado de la cuenta y conservar el bloqueo definido; reiniciar el cBot no puede convertirse en un botón accidental de borrado.
La conclusión que no cambia
Un kill switch merece confianza cuando una reproducción del incumplimiento deja cero riesgo nuevo, ninguna entrada sin cancelar y ningún misterio sobre el reloj.