El problema no empieza cuando un cBot deja de abrir operaciones. Empieza antes: cuando sigue funcionando, pero el símbolo ya no admite exactamente el volumen, el precio o la protección que el algoritmo daba por sentados.
Tras un cambio del símbolo, no basta con repetir un backtest largo y mirar el resultado final. Guarda el contrato nuevo, somete las órdenes a sus límites y compara el rastro de ejecución con el anterior. Así sabes qué se modificó; una curva parecida no te lo dice.
Primero fija qué contrato estás probando
La especificación de un símbolo reúne las condiciones que determinan qué orden puede enviarse y cómo se expresa. La referencia oficial de Symbol en cTrader expone el volumen mínimo, máximo y su incremento, además de PipSize, TickSize y funciones para convertir y normalizar volumen.
Antes de ejecutar nada, conserva una copia fechada de lo que el cBot utiliza: símbolo, tipo de cuenta, entorno de broker o servidor, límites de volumen, incrementos de precio, reglas de protección y condiciones de coste o margen que afecten al run. La comparación necesita dos registros, el anterior y el actual; la memoria no es un registro.
Después revisa las dependencias del código. Busca lotes fijos, multiplicadores, conversiones de lotes a unidades, redondeos y cálculos de distancia en pips. La guía de operaciones avanzadas de cBots aclara que los algos trabajan por defecto con volumen en unidades y muestra la conversión explícita desde lotes.
Esto revela un fallo frecuente: una parte del cBot consulta el Symbol actual y otra conserva un supuesto antiguo. El volumen puede normalizarse bien, mientras un stop loss sigue calculándose con una unidad que ya no encaja. El algoritmo no tiene por qué estar mal; su contexto sí puede haber cambiado.
Los límites que conviene forzar
Las pruebas cortas y hostiles enseñan más que una simulación extensa cuando se trata de una regla de ejecución. Prepara casos donde cada resultado pueda comprobarse sin interpretar una curva.
| Límite o condición | Caso que debes provocar | Evidencia que guardar |
|---|---|---|
| Volumen mínimo y step | Solicitudes por debajo, en el límite y un incremento por encima | Volumen pedido, volumen normalizado y respuesta |
| Volumen máximo | Un sizing que llegue al techo y lo supere | Solicitud, validación y comportamiento del cBot |
| Tick y pip | Precios que requieren redondeo a ambos lados del incremento válido | Precio calculado, precio enviado y protección final |
| Distancia de stop loss o take profit | Órdenes justo en la distancia permitida y un incremento a cada lado | Aceptación, rechazo o modificación recibida |
| Coste y margen | Una secuencia corta con posiciones solapadas | Balance, equity, capacidad y resultado de cada orden |
No ocultes un ajuste automático. Si una normalización reduce el volumen, la operación resultante puede asumir menos riesgo; si lo eleva, puede asumir más. Son rutas distintas aunque ambas sean técnicamente válidas.
Comprueba la protección con precios reales del símbolo
El test más delicado es el de las órdenes protectoras. Construye un caso con el stop loss o el take profit en el mínimo permitido, y repítelo moviendo el precio un incremento válido hacia cada lado. Anota el precio enviado, la respuesta de la plataforma y el nivel que terminó asociado a la posición.
El modelo de símbolos de la Open API de cTrader incluye distancias mínimas para stop loss y take profit, y documenta que el tipo de medida de esas distancias puede variar. Por eso no sirve trasladar sin revisión una regla aprendida en otro par o en otra cuenta.
Un cBot sin protección válida no tiene un pequeño defecto de presentación. Tiene una diferencia en el control de riesgo. También conviene probar modificaciones posteriores, salidas parciales y reinicios si forman parte de la lógica: el primer envío aceptado no demuestra que las operaciones posteriores sigan siendo válidas.
Luego mira la ruta completa de la cuenta
Con los límites ya comprobados, ejecuta una secuencia controlada que active entradas, cambios de protección, salidas parciales y la lógica de reinicio que corresponda. Compara timestamps, volumen solicitado y ejecutado, rechazos, precios protectores, costes aplicables y el recorrido de balance y equity.
Para una cuenta de prop firm esto importa especialmente. Una entrada omitida altera la exposición posterior; un volumen reducido altera la pérdida realizada; una protección rechazada deja de ser una diferencia menor. La firma y el broker son las fuentes de sus condiciones actuales, así que conserva junto al run la especificación que usaste.
El resultado solo puede caer en tres grupos:
- La ruta coincide: los casos probados no cambiaron las órdenes registradas. Documenta el contrato y los escenarios; no lo conviertas en una promesa de paridad futura.
- Las órdenes siguen siendo válidas, pero cambian: vuelve a ejecutar el histórico con las condiciones guardadas y explica qué supuesto se modificó.
- Hay rechazos o protección distinta: el informe anterior ya no describe el contrato revisado. Corrige o limita la lógica y repite la prueba antes de comparar rendimiento.
Dos curvas pueden acabar en balances parecidos y, aun así, esconder trades omitidos, tamaños distintos o protección distinta. El registro de eventos es la prueba. El beneficio final solo es un resumen.
El estándar de una prueba que se puede discutir
realbacktesting es un estudio de software de trading para cTrader que trabaja con resultados inspeccionables. La metodología publicada deja a la vista los supuestos de datos, ejecución, costes y validación; el modelo de fondeo mantiene las restricciones de la cuenta junto a la curva de equity.
Una validación tras cambios de símbolo sigue esa misma disciplina: identifica el contrato, prueba donde la orden puede romperse y conserva el contraste. No predice la siguiente ejecución real ni elimina diferencias de liquidez o de broker. Sí deja evidencia de que el código superó las condiciones concretas que revisaste.
Si el problema está en el ciclo de una orden pendiente, consulta cómo hacer backtesting de órdenes pendientes en cTrader. Si el cuello de botella es la capacidad de la cuenta, sigue la guía para auditar el margen de un backtest de cTrader.
Preguntas habituales
¿Un cambio en el símbolo obliga a repetir todo el backtest?
Obliga a validar de nuevo la ruta de órdenes. Si cambia algo que afecte al volumen, los incrementos de precio, la distancia de protección, los costes o la capacidad de cuenta, el histórico debe repetirse con esas condiciones registradas.
¿Normalizar el volumen resuelve el problema?
No por sí solo. La normalización puede volver válida una orden, pero también modifica su tamaño y su riesgo. Debes revisar a la vez límites de volumen, redondeo de precio, protección y efecto en la cuenta.
¿Una curva de equity similar prueba que no cambió nada?
No. La curva no prueba que las órdenes, el tamaño, la protección o la exposición fueran los mismos. Antes de usarla como resumen, compara el log de eventos y órdenes.
La idea que debe quedar
Si cambia el contrato, la curva anterior describe el pasado; no certifica que la próxima orden todavía tenga sentido.