Knight Capital: 45 minutos que costaron USD 440 millones

La mañana

El 1 de agosto de 2012, a las 9:30 de la mañana, abrió el mercado de valores de Estados Unidos. Una hora después, Knight Capital, uno de los mayores creadores de mercado del país, había perdido más de USD 460 millones según la Comisión de Bolsa y Valores (SEC). No hubo un crash de mercado, ni una noticia catastrófica, ni un ataque. Hubo un sistema enviando órdenes equivocadas a una velocidad imposible de detener.

La SEC documentó la magnitud con precisión clínica: en los primeros 45 minutos, el router de órdenes de Knight envió más de 4 millones de órdenes al mercado intentando ejecutar apenas 212 órdenes de clientes. La firma operó más de 397 millones de acciones y terminó con varios miles de millones de dólares en posiciones que nunca quiso tener.

Vale fijar las cifras con su fuente, porque el caso se cita mal con frecuencia. La pérdida de más de USD 460 millones es la cifra oficial de la SEC. El resultado realizado de aproximadamente USD 440 millones proviene del propio reporte financiero de Knight. Otras cifras que circulan, como los USD 7.650 millones en posiciones o el detalle de las 154 acciones concentradas, son reportadas por análisis técnicos, no oficiales de la SEC, y conviene tratarles como tales.

Lo que de verdad pasó

La causa raíz fueron tres elementos pequeños que, juntos, en producción y sin red de seguridad, se volvieron una catástrofe.

Uno: código de 2005 que debía estar apagado. Años antes, Knight había retirado una función llamada "power peg", un tipo de orden de creación de mercado que ya no se usaba. La retiró del uso, pero no la borró de los servidores. Siguió ahí, dormida.

Dos: un identificador reutilizado. A fines de julio de 2012, al preparar el lanzamiento del programa de liquidez minorista de la NYSE, Knight necesitaba un nuevo indicador en su sistema. El campo disponible se había quedado sin espacio, así que se reutilizó una marca del código antiguo, y se desconectó del código retirado. El nuevo programa quedó vinculado, sin querer, a la vieja función dormida.

Tres: un servidor que no recibió la actualización. El nuevo código se desplegó, pero en una máquina el proceso falló y quedó la versión vieja. Nadie lo notó.

Ninguno de los tres, por separado, era un desastre. Juntos, el 1 de agosto, hicieron que un servidor ejecutara la función de 2005, que ya no reconocía cuándo una orden había sido ejecutada, y siguiera enviando órdenes al mercado sin freno.

El patrón del que nadie era dueño

Hay una parte del caso que suele quedarse fuera de la historia, y es la que más se parece a un problema cotidiano: el despliegue.

El proceso era manual, máquina por máquina. Estaba automatizado con un script que, si no lograba conectarse a un servidor, fallaba en silencio, seguía con los demás y reportaba éxito. Ese día, una de las máquinas estaba en mantenimiento, rechazó la conexión y volvió con la versión anterior. El script no lo detectó, y nadie revisó máquina por máquina.

Y cuando el equipo intentó revertir el sistema a una versión buena conocida, cometió el peor error posible: revirtió a la misma versión mala, la que nunca se había actualizado. El comportamiento anómalo no se detuvo. Se aceleró.

Ese es el punto del que nadie era dueño: el proceso de mover código a producción y saber, con certeza, qué quedó vivo en cada máquina.

Las ausencias que importan

Cuando la SEC sancionó a Knight, la lista de cargos es, en la práctica, la lista de lo que faltaba. Traducida a términos que cualquier director de tecnología reconoce:

• Sin control de detención automática. No existía un mecanismo que frenara el sistema cuando su propio comportamiento se salía de rango. La firma dependía de que un humano notara la anomalía y reaccionara.
• Sin verificación antes del envío de órdenes. No había controles que compararan lo que salía del sistema con lo que había entrado.
• Sin reprobar el código retirado. Nadie revisaba si el código viejo que seguía en los servidores funcionaría correctamente si alguna vez se invocaba. No se hacía porque "no debía usarse".
• Sin una segunda persona revisando el despliegue. No había un técnico adicional que verificara el despliegue ni un procedimiento escrito que lo exigiera.
• Sin alertas que alguien mirara. El sistema interno generó 97 correos automáticos que referenciaban el router e identificaban un error antes de la apertura del mercado. No se actuó sobre ellos porque no estaban diseñados como alertas de sistema. Ofrecían, en palabras de la SEC, la oportunidad de arreglar el problema antes de que abriera el mercado.

La SEC impuso a Knight una multa de USD 12 millones y la obligó a contratar un consultor independiente para revisar sus controles. Fue la primera acción de enforcement bajo la regla de acceso al mercado, y el caso terminó de forma más dura todavía: la firma fue adquirida por su rival Getco en una operación que la valoró en alrededor de USD 1.400 millones, tras un rescate de emergencia de USD 400 millones que diluyó a los accionistas originales en más del 70%.

Qué hacer concreto

La lección de Knight es sobre costuras y procesos, y aplica a cualquier empresa cuya operación depende de sistemas que se hablan entre sí. Cinco decisiones que un director de tecnología puede llevar a su equipo:

1. Inventariar el código y la configuración retirados que siguen vivos. Lo que "ya no se usa" pero sigue en los servidores es un riesgo latente. Si no se borró, puede ejecutarse.
2. Desplegar con verificación por máquina y fallo ruidoso. Un despliegue que no confirma el estado de cada destino, y que falla en silencio, es un despliegue que miente. Si algo no se actualizó, tiene que sonar.
3. Exigir una segunda persona en los cambios críticos. Una revisión humana antes de tocar producción cuesta minutos. No tenerla puede costar la empresa.
4. Diseñar alertas que alguien lea y actúe. Una alerta que nadie atiende es solo un registro. Cada aviso crítico necesita un dueño y una acción esperada.
5. Tener un control que detenga el sistema cuando se sale de rango. La última red de seguridad es un mecanismo automático que frena la operación antes de que el daño se vuelva irreversible.

El riesgo no estaba en el modelo

Knight Capital es el caso de estudio canónico de una idea incómoda: el riesgo grave no siempre vive en el algoritmo, en la estrategia o en la inteligencia artificial. Vive en las costuras entre sistemas y en el proceso que los pone en producción. Un servidor sin actualizar, un script que falla en silencio, un rollback mal calculado: nada de eso es glamoroso, y todo eso puede ser fatal.

Para una empresa de 50 a 500 empleados con TI interno, el patrón es reconocible. Sistemas que "nadie toca porque funcionan", configuraciones reutilizadas, despliegues manuales, alertas que nadie mira. No hace falta ser un creador de mercado para tener un punto ciego con la forma del de Knight.

Ese trabajo de auditar las costuras y el proceso de despliegue con responsabilidad explícita es exactamente el que Byxel firma bajo su modelo de Ingeniería de Autor: un ingeniero responde por cada decisión, incluida la que pone código en producción. Quien ordena eso no termina contando la historia de Knight. La evita.

Para seguir leyendo: el costo de mantener sistemas conectados a mano, la deuda de integración como pasivo que crece y por qué la autoría con revisión senior importa.

¿Cuánto código, configuración o conexión retirada sigue viva en sus sistemas, y quién podría detener una operación que se sale de rango? En Byxel auditamos las costuras y el proceso de despliegue con responsabilidad senior de punta a punta. Escribanos por WhatsApp y revisemos juntos dónde está su próximo punto ciego.