SpreadAtlas

Un solo fallo causó 86 % de nuestras pérdidas de trading

Publicado el 13 de octubre de 2026

Nuestro primer bot de trading automático perdió ₩5,1 millones en simulación en 190 salidas. Al desglosar las pérdidas por el motivo de cada salida, una sola ruta de código explicaba el 86,5 % de ellas. Después, el mismo error nos engañó por segunda vez.

Cómo se hizo: el código, las ejecuciones de investigación y los primeros borradores de este texto los produjo un asistente de IA bajo la dirección del operador; el operador tomó todas las decisiones y comprobó las cifras. Todas las operaciones fueron simuladas: precios reales, sin dinero real. Nada de esto es asesoramiento de inversión.

Pérdidas por motivo de salida

Motivo de salidaSalidasResultado, KRWPromedioPorcentaje de aciertosMediana de permanencia
Salida por alarma sin confirmar157−4.416.442−0,37 %10,2 %12 s
Se agotó el tiempo de permanencia18−244.623−0,26 %38,9 %2 h
Salida por alarma confirmada6−684.389−2,10 %0 %14 min
Stop dinámico5+613.519+2,33 %100 %18 min
Stop loss2−386.990−3,69 %0 %23 min
Otros2+13.194———
Libro de operaciones simulado de nuestro primer bot de trading automático, 190 salidas hasta el 14 de septiembre de 2026. Total: −₩5.105.732.

157 de las 190 salidas procedían de una sola regla: una alarma que vendía de inmediato, sin confirmación, sin tiempo mínimo de permanencia y sin comprobar que el precio se hubiera movido de verdad. Esas salidas tuvieron una mediana de permanencia de 12 segundos. Su coste mediano por operación completa (compra y venta), medido en el mismo libro, fue del 0,43 %, de modo que perdían dinero incluso cuando el precio no se movía: 97 de ellas, el 62 %, terminaron con el precio dentro de un 0,35 % del precio de entrada y aun así perdieron.

Las salidas en los 30 segundos siguientes a la entrada, 114 operaciones, causaron por sí solas el 63 % de todas las pérdidas.

Qué hacía el código

En el mismo archivo, otras dos alarmas ya exigían un paso de confirmación antes de vender. Esta se había quedado fuera. Un módulo hermano había corregido el mismo problema semanas antes; este no. Lo cambiamos para que una alarma sin confirmar solo pueda vender después de un tiempo mínimo de permanencia de 20 segundos, con una pérdida real mayor que el coste de la operación completa y tras seis segundos de confirmación, mientras que las salidas de seguridad estrictas, el stop loss y la salida por desplome, seguían activándose de inmediato.

En una reproducción (replay) con los datos del libro, la nueva regla habría bloqueado 143 de las 157 salidas por alarma. No lo presentamos como una ganancia. Bloquear una salida solo significa no pagar la operación completa en ese momento; lo que habría hecho el precio después, de haber mantenido la posición, no puede demostrarse con este libro.

Publicidad

El segundo error

La auditoría también mostró que las operaciones de la ventana de señal de 3 minutos habían perdido ₩4,42 millones mientras que la ventana de 1 hora había ganado dinero, y recomendamos operar menos con la ventana de 3 minutos. Un día después retiramos la recomendación. 157 de las 158 operaciones de la ventana de 3 minutos eran precisamente esas salidas por alarma. Sin ellas, la ventana de 3 minutos tuvo una sola operación. Habíamos comparado dos rutas de código y lo habíamos llamado una diferencia entre temporalidades.

La misma segunda auditoría encontró un fallo relacionado: seis salidas por alarma confirmada habían vendido todas antes de alcanzar su propio stop loss, con un promedio de −2,0 %, y cinco de las seis monedas estaban más altas quince minutos después. Las alarmas estaban pasando por encima del plan de riesgo. Impedimos que vendieran antes de la línea del stop.

Qué aprendimos

Corregir el error eliminó un error, no el problema de fondo: la ventaja de la estrategia por operación seguía siendo menor que sus costes. Las seis semanas completas.

Más investigación

Calculadora relacionada: Calculadora de comisiones de trading de criptomonedas