08.10.2026 · Signal Titans Editorial

Knight Capital perdió 460 millones de dólares en 45 minutos. Un código que había dejado de usar en 2003 volvió a despertar.

El abarrotado parqué de la Bolsa de Nueva York en una composición editorial de estilo archivo sobre el fallo bursátil de Knight Capital en 2012.

A las 9:30 de la mañana del 1 de agosto de 2012, abrió el mercado bursátil estadounidense y una de sus mayores firmas de trading empezó a comprar y vender acciones que nunca había tenido intención de tocar. Durante unos 45 minutos, el enrutador de órdenes de Knight Capital envió millones de órdenes al mercado. Cuando todo terminó, Knight había perdido más de 460 millones de dólares.

No hubo ningún hacker de por medio. Ningún trader actuó por su cuenta. La causa, según la Comisión de Bolsa y Valores de Estados Unidos (SEC), fue un fragmento de software que llevaba nueve años desactivado, un indicador de configuración al que se le dio un nuevo significado y un servidor, de ocho, que nunca recibió una actualización.

Una firma en el centro del mercado

Knight no era un actor menor. Según la SEC, su actividad en 2011 y 2012 representaba por lo general alrededor del diez por ciento de toda la negociación de acciones cotizadas en Estados Unidos. Uno de sus sistemas clave era SMARS, un enrutador algorítmico de alta velocidad. SMARS recibía grandes órdenes "madre" de otras partes de la plataforma de Knight y las dividía en órdenes "hijas" más pequeñas que enviaba a los centros de negociación.

En el verano de 2012, Knight preparó SMARS para un nuevo programa de la Bolsa de Nueva York, el Retail Liquidity Program, cuyo inicio estaba previsto para el 1 de agosto. Eso implicaba escribir código nuevo y desplegarlo en producción en una fecha fija.

Código viejo, significado nuevo

La nueva función debía sustituir un fragmento de código que ya nadie usaba. Pertenecía a una antigua función llamada Power Peg, que Knight había dejado de utilizar en 2003. Ese código nunca se eliminó. Seguía presente en SMARS y todavía podía invocarse.

El nuevo código del Retail Liquidity Program reutilizaba además un indicador que en su día activaba Power Peg. Knight tenía previsto borrar el código antiguo, de modo que poner el indicador en "sí" activara a partir de entonces la nueva función.

Debajo se escondía un segundo problema, más antiguo. Cuando Power Peg estaba en uso, una función llevaba la cuenta de cuántas acciones de cada orden madre se habían ejecutado y le indicaba al enrutador que se detuviera una vez completada la orden. En 2005, Knight trasladó esa función de conteo a otra parte del código. Nunca volvió a probar Power Peg después. Si el código dormido llegaba a despertar, ya no sabría cuándo parar.

Siete servidores de ocho

A partir del 27 de julio, Knight desplegó el nuevo código por etapas en los ocho servidores de SMARS. En uno de ellos, el técnico no copió el código nuevo. Nadie más revisó el despliegue, y Knight no tenía ningún procedimiento escrito que exigiera que alguien lo hiciera. El octavo servidor conservó el viejo código de Power Peg y se quedó sin la nueva función.

La mañana del 1 de agosto, las señales de advertencia ya estaban llegando. Desde aproximadamente las 8:01, un sistema interno envió correos electrónicos automáticos que hacían referencia a SMARS y a un error descrito como "Power Peg disabled". Para la apertura de las 9:30, 97 de estos mensajes habían llegado a un grupo de empleados de Knight. No se habían diseñado como alertas, y nadie actuó.

Cuarenta y cinco minutos

Cuando abrió el mercado, llegaron órdenes que llevaban el indicador reutilizado. Los siete servidores actualizados las gestionaron correctamente. El octavo ejecutó Power Peg. Como la lógica de conteo de acciones se había movido años antes, siguió lanzando órdenes hijas por cada orden madre sin tener en cuenta cuántas acciones se habían comprado o vendido ya.

Las cifras de la SEC son contundentes. Por apenas 212 órdenes madre entrantes, SMARS envió millones de órdenes hijas, que produjeron más de cuatro millones de ejecuciones en 154 valores, por un total de más de 397 millones de acciones. Knight terminó con una posición larga neta de unos 3,5 mil millones de dólares en 80 valores y una posición corta neta de unos 3,15 mil millones de dólares en otros 74. En decenas de valores, las operaciones de Knight supusieron una gran parte del volumen y movieron los precios más de un cinco por ciento.

La respuesta empeoró las cosas. La herramienta de supervisión de Knight informaba de las posiciones cuando las operaciones ya se habían producido y dependía de personas mirando pantallas en lugar de disparar alarmas automáticas. Knight no tenía procedimientos de respuesta a incidentes para un caso así. Mientras los ingenieros buscaban la causa con el mercado en marcha, desinstalaron el código nuevo de los siete servidores donde se había desplegado correctamente. A partir de ese momento, esos servidores también empezaron a enrutar órdenes a través de la vieja lógica de Power Peg.

La factura

La pérdida de Knight en las posiciones no deseadas ascendió a unos 460 millones de dólares. En cuestión de días, la firma necesitó un rescate: un grupo de inversores aportó 400 millones de dólares a cambio de una amplia participación mayoritaria. Más tarde ese mismo año, Knight aceptó ser adquirida por la firma de trading Getco, y ambas se fusionaron en 2013 como KCG Holdings. En octubre de 2013, la SEC concluyó que Knight había infringido la Market Access Rule, que exige a los intermediarios contar con controles que impidan que las órdenes erróneas lleguen al mercado. Knight pagó una multa de 12 millones de dólares.

Lo que los ingenieros siguen aprendiendo de ello

Sería fácil culpar al técnico que se saltó un servidor. Las conclusiones de la SEC apuntan a un lugar más útil. Cada eslabón de la cadena fue una salvaguarda ausente, no una única mala decisión:

Código muerto que siguió siendo invocable durante nueve años.
Un indicador reutilizado con un nuevo significado mientras el comportamiento antiguo seguía existiendo.
Un despliegue sin segunda revisión y sin ninguna comprobación automática de que todos los servidores coincidieran.
Avisos que acababan en una bandeja de entrada en lugar de llegar a alguien responsable de detener el sistema.
Ningún plan establecido de antemano para detener la negociación cuando el sistema se comportara de forma anómala.

Nada de esto es exótico. La mayoría de los sistemas en producción contienen hoy al menos uno de estos fallos. El desastre de Knight muestra con qué rapidez se agravan cuando coinciden en el mismo instante, a la velocidad del mercado.

La lección duradera es fácil de enunciar y difícil de practicar: el código que ya no usas no es inofensivo solo porque ya no lo llames. Bórralo, o da por hecho que algún día algo lo hará.