Un registro de decisiones permite auditar un cBot cuando une la señal, la regla que da paso o bloquea la operación, la solicitud y el evento que acaba registrando la plataforma. El resultado final de una operación no explica por sí solo por qué el cBot actuó ni por qué se quedó quieto.
Eso se nota cuando falta una entrada, aparece una orden inesperada o el cBot vuelve a arrancar. Mirar únicamente el P&L deja sin responder lo que importa: qué condición se cumplió, qué filtro intervino, con qué parámetros trabajaba la instancia y qué respuesta recibió la solicitud.
La pregunta útil no es cuánto ganó, sino qué decidió
Un diario de auditoría sirve si puede reconstruir una decisión completa. Para conseguirlo, cada línea necesita un identificador que la conecte con las demás y un motivo legible para una persona.
| Momento | Qué conservar | Para qué sirve |
|---|---|---|
| Estado inicial | hora, símbolo, identificador de ejecución, timeframe | Sitúa la evaluación en una instancia concreta. |
| Señal | condición nombrada y datos que revisó | Evita que la lógica de entrada quede supuesta. |
| Filtro | comprobación de riesgo, sesión, spread, límite de posiciones u orden duplicada | Distingue una operación permitida de una descartada. |
| Petición | lado, volumen, tipo de orden y protecciones previstas | Conserva lo que el cBot pidió ejecutar. |
| Confirmación | estado observado e identificador de orden o posición cuando exista | Permite conciliar la petición con el registro de la plataforma. |
No hace falta guardar cada cambio de precio para responder a esas preguntas. Es mejor capturar los puntos donde cambia la decisión: una señal queda habilitada, una regla la bloquea, se envía una orden o cambia el estado de esa orden.
Dónde encaja el log dentro del ciclo de un cBot
La documentación de cTrader describe manejadores de ciclo de vida como OnStart, OnTick, OnBar, OnStop y OnException, y muestra el uso de Print() para enviar mensajes al log del cBot. Esos puntos permiten anotar el estado de arranque, las condiciones evaluadas y los errores; no convierten el log en una prueba de rendimiento. Consulta la documentación del ciclo de vida de cBot.
La otra mitad de la historia está en los eventos de la plataforma. cTrader documenta eventos de posiciones y órdenes pendientes: posiciones abiertas, modificadas y cerradas, y órdenes creadas, modificadas, ejecutadas o canceladas. La misma documentación advierte que esos eventos pueden proceder de actividad manual o de un cBot. Por eso conviene marcar los registros propios, no adjudicar automáticamente cada evento a la automatización. Consulta la documentación de eventos de trading de cTrader.
La práctica es sencilla: anota la decisión antes de pedir la orden y vuelve a anotar el evento que la confirma o contradice. Si no se pueden enlazar, deja la diferencia a la vista para revisarla.
Un formato mínimo que no oculta la respuesta
Esto es la forma de un registro, no una implementación completa de un cBot. Los nombres pueden cambiar; la cadena entre ellos no debería desaparecer.
run_id: london-orb-2026-10-02-a
symbol: EURUSD
stage: guardrail
signal_id: 8f2c
result: blocked
reason_codes: session_closed, duplicate_order_check_passedEse bloque responde a una pregunta concreta: ¿por qué no hubo orden para signal_id: 8f2c? Si la lógica permite operar, arrastra el mismo signal_id a la petición y asócialo después con el identificador de orden o posición que aparezca en el evento. “La operación falló” no es un diagnóstico; es una forma de posponerlo.
Tras un reinicio, crea un identificador de ejecución nuevo y registra la conciliación antes de evaluar otra entrada. No basta con comprobar que el proceso ha vuelto. Hay que poder separar una posición, una orden pendiente o una decisión anterior de una señal que acaba de nacer. Este criterio también refuerza una prueba de reinicio de cBot y completa la revisión del símbolo antes de que opere un cBot.
Una rutina de revisión para después de la sesión
Al cerrar la sesión, recorre siempre la misma secuencia. La repetición aquí elimina suposiciones, no criterio.
- Localiza la señal y comprueba hora, símbolo e identificador de ejecución.
- Lee los filtros antes de mirar la orden. Que no haya operación puede ser el resultado correcto.
- Contrasta la petición con el evento posterior de orden o posición.
- Señala cualquier evento de plataforma que no tenga su registro de cBot correspondiente.
- Conserva la configuración de esa ejecución antes de tocar parámetros o código.
Esto no demuestra que la estrategia tenga ventaja ni vuelve segura una automatización. Sirve para algo más modesto: comprobar si el sistema siguió la regla que dice aplicar.
Lo que un log no puede demostrar
Un log puede estar incompleto, sobrescribirse, llegar tarde o ser demasiado genérico para reconstruir una decisión. Además, una línea escrita por el cBot solo refleja lo que ese cBot decidió informar; no verifica de forma independiente todo el estado externo, la plataforma o la ejecución.
Por eso hay que contrastar el diario con el historial de posiciones y órdenes pendientes de la plataforma, no sustituir uno por otro. También merece la pena limitar la retención y el acceso cuando los registros incluyen identificadores de cuenta u operaciones.
realbacktesting aplica el mismo límite al publicar investigación: que algo pueda reproducirse vale más que afirmarlo sin evidencia. La página de pruebas explica cómo revisar los supuestos de un backtest nativo de cTrader; el registro operativo responde a otra pregunta, la de qué ocurrió durante una ejecución.
Preguntas frecuentes
¿Basta con la pestaña Log de cTrader para auditar un cBot?
Puede ser el punto de partida porque cTrader documenta la salida de Print() en el log. Solo basta si el cBot escribe una cadena de decisión coherente y esa cadena se puede conciliar con los eventos de la plataforma.
¿Conviene que un cBot registre cada tick?
No necesariamente. Para revisar una decisión, los eventos que cambian el resultado y sus códigos de motivo suelen aportar más que una sucesión indiscriminada de ticks.
¿Un registro limpio prueba que el cBot será rentable?
No. Puede mostrar que se siguió el flujo documentado, pero no demuestra una ventaja, no anticipa resultados y no sustituye las pruebas con datos y costes realistas.
Si un cBot no puede explicar una decisión, esa decisión no es revisable. Guarda la cadena antes de tener que defenderla.