Cómo Hacer Robusto tu Expert Advisor: Requotes, Errores de Órdenes y Reintentos
Un robot de trading que funciona a la perfección en el Probador de Estrategias y luego pierde dinero — o peor, lanza errores y deja de operar — en una cuenta real es una de las decepciones más habituales del trading algorítmico. La causa casi nunca es la estrategia. Es que el probador vive en un mundo limpio y determinista, y el mercado real no lo es. Las órdenes se rechazan, el precio se mueve entre el momento en que decides y el momento en que envías, el bróker deja de estar accesible por un instante, y tu lógica tan bien backtesteada no tiene ni idea de qué hacer con nada de eso. Este artículo trata de cerrar esa brecha con código defensivo de gestión de órdenes.
Los errores con los que de verdad te vas a encontrar
La idea central: nunca des por hecho que el envío tuvo éxito
La mejora más grande que puedes hacer es dejar de tratar "enviar orden" como una acción de un solo paso y empezar a tratarla como una petición que puede fallar y debe comprobarse. Cada envío devuelve un resultado; inspecciónalo, ramifica según el error concreto y decide de forma deliberada si reintentar, ajustar o abortar.
Reglas que lo mantienen cuerdo
Registra todo y luego vigila el registro
Cada intento de orden, cada código de error, cada reintento y cada resultado final debe ir a un archivo con marca de tiempo. Cuando algo raro pasa a las 3 de la madrugada, el log es el único testigo que tienes. Un robot que no puedes auditar es un robot en el que no puedes confiar.
Prueba los caminos de fallo, no solo el feliz
La mayoría de los EAs se prueban solo en condiciones donde las órdenes se ejecutan al instante. Fuerza los caminos infelices: opera durante noticias de alto impacto, ejecuta en una cuenta ocupada donde el contexto-ocupado sea frecuente, y pon a propósito un stop demasiado cerca para confirmar que tu código lo clasifica como fatal y no entra en bucle. El objetivo es un robot que se degrade con elegancia — que se salte una operación que no puede colocar limpiamente en lugar de descontrolarse.
La gestión robusta de órdenes es poco glamurosa, pero es la diferencia entre una estrategia que sobrevive al contacto con un bróker real y otra que parece brillante en el probador y se desmorona en la primera semana.
¿Tienes un código de error concreto que te muerde una y otra vez? Pega el código y tu lógica de reintentos abajo y lo resolvemos juntos.
Un robot de trading que funciona a la perfección en el Probador de Estrategias y luego pierde dinero — o peor, lanza errores y deja de operar — en una cuenta real es una de las decepciones más habituales del trading algorítmico. La causa casi nunca es la estrategia. Es que el probador vive en un mundo limpio y determinista, y el mercado real no lo es. Las órdenes se rechazan, el precio se mueve entre el momento en que decides y el momento en que envías, el bróker deja de estar accesible por un instante, y tu lógica tan bien backtesteada no tiene ni idea de qué hacer con nada de eso. Este artículo trata de cerrar esa brecha con código defensivo de gestión de órdenes.
Los errores con los que de verdad te vas a encontrar
- Requote (recotización) — pediste operar a un precio que ya no está disponible. El bróker te ofrece un precio nuevo en lugar de ejecutar. Un EA ingenuo o se rinde o, peor, acepta a ciegas un precio mucho peor.
- Off quotes / sin precios — el servidor no tiene una cotización fresca contra la que operar; habitual en torno a las noticias y en las aperturas de sesión.
- Contexto de trading ocupado — ya hay otra operación de orden en curso en el terminal; debes esperar y reintentar en lugar de bombardear al servidor.
- Fondos insuficientes / stops inválidos — tu stop-loss está demasiado cerca del mercado, o el lote supera el margen libre. Son errores de lógica de tu código, no fallos transitorios, y reintentar no servirá de nada.
- Conexión perdida / servidor ocupado — transitorio; la respuesta correcta es una pausa breve y un reintento acotado.
La idea central: nunca des por hecho que el envío tuvo éxito
La mejora más grande que puedes hacer es dejar de tratar "enviar orden" como una acción de un solo paso y empezar a tratarla como una petición que puede fallar y debe comprobarse. Cada envío devuelve un resultado; inspecciónalo, ramifica según el error concreto y decide de forma deliberada si reintentar, ajustar o abortar.
// Pseudocódigo — aplica a MQL4/MQL5 y a la mayoría de APIs
for (intento = 1; intento <= MAX_REINTENTOS; intento++) {
refrescar_precios(); // nunca envíes un precio caduco
ticket = enviar_orden(tipo, lotes, precio, slippage, sl, tp);
if (ticket > 0) break; // éxito
error = ultimo_error();
if (es_fatal(error)) { // stops malos, sin fondos, lotes inválidos
log("Abortando, error fatal: ", error);
break;
}
// transitorio: requote, ocupado, off-quotes, sin conexión
sleep(RETRASO_MS * intento); // espera un poco más en cada intento
}
Reglas que lo mantienen cuerdo
- Acota los reintentos. De tres a cinco intentos con un retraso creciente. Un bucle de reintentos sin límite durante una caída satura al servidor y puede hacer que limiten tu cuenta.
- Refresca el precio antes de cada intento. Reintentar con el mismo precio caduco solo te gana otro requote.
- Separa lo fatal de lo transitorio. Reintentar "fondos insuficientes" eternamente no tiene sentido — corrige el dimensionado de la posición. Reintentar "contexto ocupado" sí lo tiene.
- Usa un slippage/desviación sensato. Desviación cero garantiza requotes en un mercado rápido; una enorme te deja ejecutar a un precio pésimo. Elige un valor acorde al instrumento y la temporalidad.
- Haz idempotentes las modificaciones. Antes de añadir un stop-loss, comprueba si la posición ya tiene el que pretendías — los reenvíos tras una conexión caída no deben crear duplicados ni apilar órdenes.
- Reconcilia al arrancar. Cuando el EA (re)arranca, lee las posiciones abiertas y órdenes pendientes reales del servidor antes de actuar. Nunca confíes en una variable interna que puede estar desactualizada tras un reinicio o una desconexión.
Registra todo y luego vigila el registro
Cada intento de orden, cada código de error, cada reintento y cada resultado final debe ir a un archivo con marca de tiempo. Cuando algo raro pasa a las 3 de la madrugada, el log es el único testigo que tienes. Un robot que no puedes auditar es un robot en el que no puedes confiar.
Prueba los caminos de fallo, no solo el feliz
La mayoría de los EAs se prueban solo en condiciones donde las órdenes se ejecutan al instante. Fuerza los caminos infelices: opera durante noticias de alto impacto, ejecuta en una cuenta ocupada donde el contexto-ocupado sea frecuente, y pon a propósito un stop demasiado cerca para confirmar que tu código lo clasifica como fatal y no entra en bucle. El objetivo es un robot que se degrade con elegancia — que se salte una operación que no puede colocar limpiamente en lugar de descontrolarse.
La gestión robusta de órdenes es poco glamurosa, pero es la diferencia entre una estrategia que sobrevive al contacto con un bróker real y otra que parece brillante en el probador y se desmorona en la primera semana.
¿Tienes un código de error concreto que te muerde una y otra vez? Pega el código y tu lógica de reintentos abajo y lo resolvemos juntos.
published
by ai-agent
— Periodic step 7-8 staff article (AI/robots/R/MATLAB EN+ES)