Knight Capital: 45 minutos, un servidor sin actualizar y más de 460 millones de dólares

El 1 de agosto de 2012, Knight Capital perdió más de 460 millones de dólares en unos 45 minutos. Según el regulador, todo empezó con un cambio de software que se instaló en siete de ocho servidores. El octavo se quedó con un código viejo que ya no se usaba, y ese código despertó cuando abrió la Bolsa. Lo que siguió fue una cadena de controles que no estaban donde hacían falta.

Es un caso ampliamente documentado en registros públicos: la Comisión de Valores de Estados Unidos (la SEC, el regulador de los mercados de ese país) lo investigó y publicó sus hallazgos en una orden de 18 páginas [1]. Casi todo lo que sigue sale de ahí. Un matiz importante: Knight aceptó el acuerdo con la SEC sin admitir ni negar esos hallazgos [1, sección II].

Este artículo es para quien dirige una empresa o un área de tecnología. Cubre cuatro cosas:

1. Qué pasó, hora por hora.
2. Por qué no fue mala suerte, sino una cadena de decisiones pequeñas.
3. Qué se aprende para un director, en lenguaje de negocio.
4. Qué preguntar en su próximo comité y por dónde empezar esta semana.

Una aclaración antes de empezar: Hábil no participó en este caso. Lo contamos con lo que informaron públicamente la SEC y la propia Knight.

Primero, quién era Knight

Knight Capital era una de las firmas más grandes de Wall Street en la ejecución de órdenes de acciones. Según la SEC, en 2011 y 2012 su operación representaba, en general, cerca del 10 % de todas las acciones que se negociaban en los mercados listados de Estados Unidos [1]. Cuando un pequeño inversionista compraba acciones a través de su casa de bolsa, muchas veces la orden pasaba por Knight.

Para hacerlo usaba un sistema llamado SMARS: un enrutador automático de órdenes, de alta velocidad. Su trabajo es sencillo de explicar. Recibe una orden de compra o venta (la orden «madre») y, según lo que haya disponible en el mercado, envía una o más órdenes derivadas (las «hijas») a distintos centros de negociación (bolsas y otros mercados donde se compran y venden acciones) para ejecutarla [1, párr. 12]. Lo lógico es que, cuando la orden madre ya se completó, deje de enviar hijas.

Esa última idea es la que importa. Guárdela.

La cronología, hora a hora

2003: una función que nadie apaga

Knight deja de usar una función de SMARS llamada «Power Peg». La deja de usar, pero no la borra. El código sigue dentro del sistema, presente y listo para activarse [1, párr. 13–14].

En ese código había una pieza clave: un contador que sumaba cuántas acciones de la orden madre ya se habían ejecutado. Ese contador era el freno. Le decía al sistema: «ya está completa, deja de enviar».

2005: un cambio que nadie vuelve a probar

Dos años después, el equipo mueve ese contador a otra parte de SMARS para usarlo en otra función. Nadie vuelve a probar Power Peg para ver si todavía funciona sin él [1, párr. 14]. ¿Para qué, si ya nadie lo usa?

Desde ese día, Power Peg es un auto sin frenos estacionado en la cochera. Nadie lo maneja. Nadie lo revisa. Tiene las llaves puestas.

Julio de 2012: ocho servidores, siete copias

La Bolsa de Nueva York (NYSE) va a estrenar un programa para órdenes de pequeños inversionistas, el Retail Liquidity Program, que arranca el 1 de agosto [1, párr. 12]. Knight quiere que sus clientes participen desde el primer día, así que escribe código nuevo para SMARS.

Dos decisiones técnicas preparan la trampa:

• El código nuevo reemplaza al viejo Power Peg en esa parte del sistema.
• Para activarse, reutiliza la misma bandera (un interruptor dentro de cada orden) que años atrás encendía Power Peg [1, párr. 13]. La idea era borrar Power Peg, de modo que esa bandera solo pudiera encender lo nuevo.

A partir del 27 de julio, un técnico instala el código nuevo por etapas, servidor por servidor, en días sucesivos. SMARS corre en ocho servidores. En uno de ellos, el código nuevo no se copia [1, párr. 15].

Nadie lo nota. Según la SEC, Knight no pedía que un segundo técnico revisara la instalación, y no tenía procedimientos escritos que lo exigieran [1, párr. 15 y 26]. El octavo servidor se queda con Power Peg adentro y sin el código nuevo.

Miércoles 1 de agosto, 8:01 de la mañana (hora de Nueva York): 97 correos que nadie lee

Falta casi hora y media para que abra el mercado. Llegan órdenes del programa nuevo marcadas para operar antes de la apertura. Hacia las 8:01, un sistema interno de Knight empieza a mandar correos automáticos a un grupo del personal. Mencionan a SMARS y señalan un error: «Power Peg disabled», Power Peg deshabilitado [1, párr. 19].

Antes de las 9:30 llegan 97 de esos correos. Nadie los atiende. No es negligencia de una persona: esos mensajes no se diseñaron como alertas, y el personal, en general, no los revisaba al recibirlos [1, párr. 19]. La SEC lo dice así: eran mensajes en tiempo real, causados por la instalación fallida, y daban una posible oportunidad de encontrar y corregir el problema antes de la apertura [1, párr. 19].

El sistema avisó. El aviso llegó a un buzón que nadie miraba.

9:30: abre el mercado

Suena la campana. Siete servidores procesan bien las órdenes del programa nuevo. El octavo, no.

Cada orden con la bandera reutilizada que llega a ese servidor despierta a Power Peg. Y Power Peg ya no tiene su contador: no sabe cuándo la orden madre está completa. Así que manda órdenes hijas sin parar, una tras otra, a toda velocidad, para cada orden que recibe [1, párr. 16].

Lo más inquietante: otra parte del sistema de Knight sí sabía que las órdenes ya se habían completado. Pero esa información no le llegaba a SMARS [1, párr. 16].

Recuerde la idea que le pedí guardar. El dato que habría servido de freno existía en otra parte del sistema; no en la que estaba enviando.

Los minutos siguientes: buscar a ciegas

Desde la apertura, personal de alto nivel de Knight ve en su herramienta de monitoreo que se acumula una posición enorme en una cuenta interna, la «Cuenta 33» [1, párr. 24–25]: acciones compradas o vendidas que quedan a cargo de Knight, con todo su riesgo. Ven el síntoma. No ven la causa.

La SEC describe por qué tardaron tanto en entender lo que pasaba:

• La herramienta de monitoreo dependía por completo de que una persona la mirara: no generaba alertas automáticas sobre la exposición de la firma, es decir, el dinero que tenía en riesgo [1, párr. 25].
• No mostraba los límites: quien la miraba tenía que saberse de memoria el límite de cada cuenta para darse cuenta de que se había rebasado [1, párr. 25].
• Con el volumen de esa mañana, se retrasaba y sus reportes salían inexactos [1, párr. 25].
• La Cuenta 33 tenía un límite de 2 millones de dólares, pero no estaba ligada a controles automáticos sobre la exposición total de Knight; y la herramienta de monitoreo tampoco detenía por sí sola el envío de órdenes [1, párr. 23–25].
• Y no había procedimientos para guiar al personal en un incidente grave; la SEC concluyó que el equipo técnico necesitaba una guía clara sobre cuándo desconectar un sistema que falla [1, párr. 27 y 42].

Mientras tanto, Knight sigue conectada al mercado. Su equipo de tecnología intenta encontrar el problema en vivo, con el sistema enviando millones de órdenes [1, párr. 10 y 27].

El remedio que empeora todo

En uno de sus intentos, el equipo hace lo que muchos haríamos: regresar al estado anterior. Desinstala el código nuevo de los siete servidores donde estaba bien instalado [1, párr. 27].

Pero en esos siete servidores, debajo del código nuevo, Power Peg seguía ahí. Al quitar lo nuevo, la bandera vuelve a encender lo viejo. Ahora son ocho servidores enviando órdenes sin freno [1, párr. 27].

La vuelta atrás, que debía ser la red de seguridad, fue el empujón final, porque nadie sabía con certeza qué había debajo.

Cerca de 45 minutos después

Cuando Knight por fin deja de enviar órdenes, la cuenta de la SEC es esta [1, párr. 1 y 17]:

• 212 órdenes minoristas (de pequeños inversionistas) detonaron todo.
• SMARS mandó millones de órdenes hijas, con más de 4 millones de ejecuciones en 154 acciones y más de 397 millones de títulos.
• Knight quedó, sin quererlo, con una posición neta de compra de unos 3,500 millones de dólares en 80 acciones y una posición neta de venta de unos 3,150 millones en 74 acciones.

El daño no se quedó en Knight. En 75 de esas acciones, sus operaciones fueron más del 20 % del volumen y contribuyeron a movimientos de precio de más de 5 %; en 37, el precio se movió más de 10 % y Knight fue más de la mitad del volumen [1, párr. 18]. Esas ejecuciones afectaron a otros participantes del mercado: algunos recibieron precios menos favorables y otros, más favorables, que los que habrían tenido sin ellas.

Los días siguientes

• Jueves 2 de agosto. Knight informa una pérdida antes de impuestos de aproximadamente 440 millones de dólares [3]. Esa mañana, según la Associated Press, su acción pierde la mitad de su valor al inicio de la jornada [5].
• Lunes 6 de agosto. Un grupo de inversionistas acuerda inyectarle 400 millones de dólares a cambio de acciones preferentes convertibles (acciones con derechos especiales que pueden cambiarse por acciones comunes) [4]. En su reporte trimestral, la propia Knight reconoce que hubo «duda sustancial» sobre su capacidad de seguir operando [6].
• 1 de julio de 2013. Knight Capital Group y GETCO se combinan para formar KCG Holdings; Knight deja de ser una empresa independiente [1, párr. 11].
• 16 de octubre de 2013. La SEC le impone una multa de 12 millones de dólares. Es el primer caso que la SEC sanciona con su regla de acceso al mercado, adoptada en 2010: la norma que exige a las firmas controles de riesgo antes de enviar órdenes al mercado [1][2]. La cifra final de la pérdida que fija la SEC es de más de 460 millones de dólares [1, párr. 1 y 10].

Una nota sobre las cifras: los 440 millones son la estimación que Knight publicó al día siguiente [3]; los más de 460 millones son lo que estableció la SEC al terminar su investigación [1]. Aquí usamos la de la SEC.

No fue mala suerte: fue una cadena

Es tentador contar esta historia como «un técnico olvidó copiar un archivo». La SEC no la cuenta así. Su orden señala fallas de control, no de una persona [1, párr. 9 y 40–44]. Cualquiera de estos eslabones, por separado, habría cortado la cadena:

Lea la tercera fila otra vez. Según el regulador, una simple doble verificación de la instalación «pudo haber identificado que se había omitido un servidor y evitado los eventos del 1 de agosto» [1, párr. 41].

Y hay un detalle que debería incomodar a cualquier comité: Knight sí tenía controles. Su interfaz con clientes, su sistema interno de órdenes y su sistema de ejecución interna tenían controles contra órdenes erróneas [1, párr. 20]. El problema es que estaban antes de SMARS. En el último tramo, el que tocaba el mercado, no había uno suficiente [1, párr. 21].

La advertencia que llegó un año antes

En octubre de 2011, Knight hizo una prueba de recuperación ante desastres un fin de semana, con datos de prueba. El lunes, uno de sus sistemas siguió usando esos datos de prueba para cotizar en el mercado real. Perdió casi 7.5 millones de dólares [1, párr. 33].

Knight corrigió ese problema: limitó el horario del sistema, cambió un control y agregó un paso a una lista de verificación. Lo que no hizo, dice la SEC, fue preguntarse si tenía controles suficientes contra órdenes erróneas sin importar qué sistema las enviara ni por qué [1, párr. 33 y 44]. Reaccionó al caso, no a la causa.

La firma que decía otra cosa

En marzo de 2012, el director general de Knight firmó la constancia anual que exige la regla de acceso al mercado. El texto no decía que los controles cumplían con la regla; decía que Knight tenía «procesos» para cumplirla. Fue un error de redacción no intencional, el director no lo notó y creía estar firmando que todo cumplía [1, párr. 34]. Para la SEC, declarar que existen «procesos» no equivale a declarar que los controles y procedimientos están razonablemente diseñados y cumplen con la regla [1, párr. 45].

En una junta suena a tecnicismo. Esa diferencia no explica por sí sola lo que pasó el 1 de agosto, pero muestra una supervisión que daba por hecho que los controles bastaban sin comprobarlo.

Qué se aprende para un director

Usted no opera un enrutador de acciones. Pero si su empresa cobra, factura, aprueba créditos, emite pólizas o vende en línea, tiene sistemas que actúan solos y rápido. Estas lecciones no son de Wall Street; son de cualquier operación que no se puede detener.

1. El riesgo más caro no está en el código nuevo: está en el que nadie recuerda

Power Peg llevaba nueve años sin usarse. Nadie lo veía como un riesgo porque «no hacía nada». En los sistemas con años encima es común que queden funciones apagadas, banderas reutilizadas e integraciones sin dueño claro. Lo que no se usa y no se borra es una deuda que cobra intereses el peor día.

2. Un cambio que se instala a mano no es un cambio controlado

El problema no fue que una persona se equivocara: las personas se equivocan. El problema fue que nada estaba diseñado para detectar el error. Si instalar en ocho servidores depende de que alguien repita ocho veces lo mismo sin fallar, tarde o temprano una de esas repeticiones va a salir mal. Un camino de liberación automatizado (el proceso que lleva cada cambio hasta los servidores sin pasos a mano) reduce esa variación: instala lo mismo en todos lados y verifica que quedó igual. No elimina el riesgo, pero lo hace visible.

3. Una alerta que nadie lee es un registro, no un control

Los 97 correos son la escena que más debería quitarle el sueño a un director. El sistema sí detectó el problema, con hora y media de anticipación. Pero el aviso no estaba diseñado para que alguien actuara. Pregúntese cuántos avisos automáticos de su operación llegan hoy a un buzón compartido que nadie revisa.

4. El freno tiene que estar donde está el riesgo, y tiene que ser automático

Knight tenía controles al principio del camino y monitoreo después de los hechos. Le faltaba un freno justo antes de que el dinero saliera, y le faltaban límites que detuvieran el envío por sí solos. Un límite que depende de que una persona lo recuerde mientras mira una pantalla lenta no es un límite.

5. Volver atrás también es un cambio, y también hay que ensayarlo

El intento de regresar a la versión anterior empeoró todo, porque nadie sabía qué había debajo. Una vuelta atrás segura no es «desinstalar y rezar»: es un procedimiento probado antes, que lleva a un estado conocido.

6. En un incidente, la primera decisión es de negocio: ¿desconectamos?

Durante 45 minutos, el equipo técnico buscó la falla con el sistema conectado. La SEC señala que Knight necesitaba una guía clara sobre cuándo desconectar [1, párr. 42]. Esa decisión no debe improvisarse en medio del incendio ni depender de quien tenga el teclado: se acuerda antes, con nombre y apellido, y con un umbral claro.

7. Corregir el síntoma no es corregir la causa

La pérdida de 7.5 millones de 2011 fue un aviso. Knight arregló ese caso puntual y siguió igual. Cada incidente pequeño es la oportunidad más barata que tendrá de encontrar el grande.

Por qué esto sigue pasando

Han pasado más de catorce años y la lección sigue vigente por una razón incómoda: ninguno de estos controles requiere tecnología exótica. Una doble verificación, una alerta bien dirigida, un límite automático, un procedimiento para desconectar. Combinan proceso, tecnología y gobierno. Su dificultad real es otra: compiten con la prisa. Knight tenía una fecha fija, el arranque del programa de la Bolsa, y quería estar listo ese día [1, párr. 12].

Cuando el calendario manda, lo primero que se recorta es lo que «no se ve»: la revisión, la prueba de lo viejo, el ensayo de la vuelta atrás. Hasta que se ve.

Cinco preguntas para su próximo comité

1. ¿Cómo llega un cambio a nuestros sistemas críticos? ¿Por un camino automatizado que instala lo mismo en todos lados y lo verifica, o porque alguien lo copia a mano?
2. ¿Qué código o funciones apagadas siguen en nuestros sistemas, y quién respondería si alguien las enciende sin querer?
3. ¿Qué avisos automáticos generan hoy nuestros sistemas, a quién le llegan y quién está obligado a actuar cuando aparecen?
4. ¿Qué límites de dinero, volumen o cantidad detienen solos una operación anormal, y en qué punto exacto del camino están?
5. Si mañana un sistema empieza a hacer daño, ¿quién decide desconectarlo, con qué umbral y cuándo ensayamos por última vez la vuelta atrás?

Si alguna respuesta es «no sé» o «depende de quién esté», conviértala en un riesgo con responsable y fecha. Para cada una, pida cinco datos: el sistema afectado, su responsable, la evidencia que existe hoy, el impacto si falla y el siguiente control que hace falta. Con eso, su comité puede priorizar un primer sistema y decidir el siguiente paso.

Por dónde empezar esta semana

Elija un sistema que cobre, pague o mueva dinero. Pídale a quien lo libera que le cuente, paso a paso, cómo salió el último cambio: quién lo instaló, en cuántos servidores, cómo se comprobó que quedó igual en todos y qué habría pasado si hubiera fallado. Si la respuesta tiene un «normalmente» o un «él se sabe el procedimiento», ya sabe por dónde empezar.

Qué hace Hábil

Hábil es una consultora mexicana de ingeniería, fundada en 2006, que construye sistemas para operaciones que no se pueden detener. Uno de los problemas que resolvemos es justo el de esta historia: que liberar un cambio deje de dar miedo.

Diseñamos e implementamos caminos de liberación automatizados en la nube, en sus servidores o en los dos: cada cambio sale por el mismo camino, con pruebas y revisión de seguridad antes de llegar a sus clientes, ambientes de prueba y de operación que se parecen entre sí, vuelta atrás acordada y un rastro de quién aprobó qué. Empezamos por las herramientas que su equipo ya usa y por el sistema que más le duele, con la operación en marcha. Vea la página Salir a producción rápido y sin sobresaltos y, si quiere el detalle técnico, el artículo CI/CD DevSecOps en su propia infraestructura.

Si quiere contrastar estas cinco preguntas con un sistema concreto, empecemos por ahí. Pida su primera conversación, sin costo. Revisamos cómo libera hoy uno de sus sistemas prioritarios y usted se lleva un primer mapa de sus riesgos y su siguiente decisión. Escríbanos por WhatsApp.

Preguntas frecuentes

¿Knight Capital quebró?

No exactamente. Sobrevivió gracias a una inyección de 400 millones de dólares de un grupo de inversionistas, acordada cinco días después [4], pero perdió su independencia: en julio de 2013 se combinó con GETCO para formar KCG Holdings [1, párr. 11].

¿Fue culpa del técnico que no copió el código?

La SEC no lo plantea así. Su orden señala que Knight no tenía procedimientos escritos ni una segunda revisión para instalar código en ese sistema, ni controles para impedir que se activara código sin uso [1, párr. 9-D, 15 y 26]. Un error humano es previsible; lo que faltó fue un sistema que lo detectara.

¿Por qué se habla de 440 millones y también de 460?

Los 440 millones son la pérdida antes de impuestos que Knight estimó el 2 de agosto de 2012 [3]. La SEC, al cerrar su investigación en octubre de 2013, estableció una pérdida de más de 460 millones [1].

¿Esto solo aplica a empresas financieras?

No. Cualquier empresa con sistemas que actúan solos (cobros, facturación, pagos, inventarios, pedidos en línea) tiene la misma exposición: un cambio mal instalado, código olvidado y avisos que nadie atiende. Lo que cambia es la velocidad con que el error se convierte en dinero.

¿Automatizar las liberaciones elimina el riesgo?

No lo elimina; lo reduce y lo hace visible. Un camino automatizado instala lo mismo en todos lados, verifica el resultado y deja rastro, pero sigue necesitando pruebas, límites automáticos, alertas que alguien atienda y una vuelta atrás ensayada.

¿Por dónde empieza una empresa que hoy libera a mano?

Por un solo sistema, el que más dinero mueve o más duele, midiendo primero cómo se libera hoy. Desde ahí se automatiza por etapas, sin detener la operación.

Las cifras y hechos del caso provienen de documentos públicos consultados el 20 de octubre de 2026. Las citas están traducidas del inglés.