Solo bastó un defecto en el algoritmo de la negociación para que Knight Capital perdiera $440 millones de dólares en solo 30 minutos,. Esos $440 millones de dólares eran tres veces los ingresos anuales de la compañía.
La conmoción y ventas que siguieron provocaron que las acciones de Knight Capital perdieran 75% de su valor en dos días hábiles. La pérdida de liquidez fue tan grande que Knight Capital necesitó adquirir una línea de crédito adicional por 400 millones de dólares que, según el Wall Street Journal, desplazó el control de la compañía a sus nuevos acreedores.
Knight Capital fue regulada por la Comisión de Bolsa y Valores, auditada de forma rutinaria y denunciada por PCI. Si ese bicho le pudo afectar a Knight, le puede pasar a cualquier empresa. Al menos eso es lo que el CEO de Knight Capital, Thomas Joyce, parece dar a entender en una entrevista con Bloomberg Television. "La tecnología llega. No es buena. No la esperábamos", dice, y añade que "fue un error de software…. Resultó ser un error de software muy grande".
Este incidente no fue el primero de su tipo. En el año 2010 algo hizo que el Dow Jones Industrial Average cayera 600 puntos en apenas cinco minutos en lo que hoy se conoce como el "flash crash". Nasdaq culpa a una falla técnico similar por la desastrosa salida a la bolsa de Facebook.
Algoritmo de negociación a destiempo, con malas órdenes y en otra frecuencia
A principios de junio del 2012, el New York Stock Exchange (NYSE), recibió la autorización de la SEC para poner en marcha su Retail Liquid Program o RLP. El RLP -diseñado para ofrecerle a los inversores individuales el mejor precio posible, incluso si esto significa desviar las operaciones fuera de la bolsa de Nueva York en el llamado "mercado negro"- fue sacado a la luz el 1 de agosto. Esto significa que las casas de comercio tenían aproximadamente un mes y medio de lucha para escribir un código que aproveche esta nueva característica.
A principios de junio del 2012, el New York Stock Exchange (NYSE), recibió la autorización de la SEC para poner en marcha su Retail Liquid Program o RLP. El RLP -diseñado para ofrecerle a los inversores individuales el mejor precio posible, incluso si esto significa desviar las operaciones fuera de la bolsa de Nueva York en el llamado "mercado negro"- fue sacado a la luz el 1 de agosto. Esto significa que las casas de comercio tenían aproximadamente un mes y medio de lucha para escribir un código que aproveche esta nueva característica.
El incidente de Knight Capital sucedió en los primeros 30 minutos de la negociación el 1 de agosto. Algo que se introdujo durante la noche al código salió muy mal. El código en sí mismo era un algoritmo de negociación de alta frecuencia diseñado para vender y comprar grandes cantidades de stock en un corto período de tiempo. La combinación de órdenes a destiempo y malas órdenes llevaron a estos resultados desastrosos.
Más allá de admitir un defecto de software, el personal de Capital Knight se ha mostrado renuente a discutir exactamente lo qué causó el defecto. Ellos no están solos, la mayoría de consultas en este artículo relacionadas al ámbito financiero, dieron lugar a respuestas como "Sin comentarios", "no podemos comentar al respecto" o "no podemos comentar sobre esta historia".
Un técnico en una empresa de servicios financieros, que pidió permanecer en el anonimato, sugiere dos posibilidades. Podría haber sido el habitual apuro de producción sin las pruebas adecuadas. Analice las declaraciones de Knight Capital cuidadosamente, señala el técnico, y es posible que el programa que entró en producción, era en realidad una prueba de un programa diseñado para simular peticiones de comercio y evaluar si pasan correctamente. NANEX llevó a cabo un análisis de los negociados de la semana pasada y llegó a la misma conclusión.
Rick Lane, CTO de Trading Technologies en Chicago, está de acuerdo en que el problema podría ser un programa de prueba en la producción, o, posiblemente, un indicador de configuración que no estaba preparado para la producción y debió haber sido apagado. Él señala que estos algoritmos de negociación se desarrollaron muy rápidamente, ya que están diseñados para perseguir oportunidades fugaces, y ese cambio en la gestión hace que la velocidad pase a un segundo plano.
"Lo que asusta es que esto sucede más a menudo de lo que la gente piensa, y no solo en el ámbito comercial", señala Lane. "En septiembre del 2010, el Chicago Mercantile Exchange ejecutó un programa que accidentalmente introdujo órdenes de prueba a su sistema de producción -y el CME no tiene el nivel de presión sobre el tiempo como sí tienen estas áreas de comercio.
La adición de retrospectiva al proceso de desarrollo pueden reducir los errores
Jeff Sutherland, uno de los autores del Manifiesto Agile y que ayudó a formalizar la metodología Scrum, añade una tercera posibilidad, el equipo podría haber estado usando un método de desarrollo propenso al error.
Jeff Sutherland, uno de los autores del Manifiesto Agile y que ayudó a formalizar la metodología Scrum, añade una tercera posibilidad, el equipo podría haber estado usando un método de desarrollo propenso al error.
Sutherland, también ex piloto de la Fuerza Aérea de EE.UU., recomienda una evaluación externa, al igual que el proceso que utiliza la National Transportation and Safety Board para los accidentes de avión. Sin ningún tipo de evaluación, dice, puede que nunca sepamos lo que salió mal, y se corre el riesgo de tratar de evitar el problema equivocadamente.
George Dinwiddie, consultor principal en iDIA Computing, recomienda también una valoración. Cualquier empresa puede evaluar su organización usando una herramienta llamada retrospectiva, señala Dinwiddle. La retrospectiva es un proceso formal de "mirada hacia atrás", que considera lo que está pasando en la actualidad, cuáles son los riesgos y cómo puede mejorar el equipo.
En el Ejército, las retrospectivas se llaman "revisiones después de la acción". El último pensamiento en software, sin embargo, es tener la conversación antes de que el software se haya implementado con el fin de detectar y solucionar el problema. Agile Retrospective Resource Wiki proporciona una gran cantidad de opciones.
Un método eficaz que recomiendo es pedir lo que va bien, lo que está mal, y lo que nosotros (el equipo) debería hacer de forma diferente. Los integrantes del equipo crean tarjetas con listas acerca de lo que les gustaría hablar, luego votan colocando un punto en las cartas para decidir de qué hablar. El equipo discute los dos elementos más fuertemente punteados de cada categoría.
Cuando hay un problema, aparece otro punto anónimo, alguien en la organización por lo general lo sabe, pero no se siente lo suficientemente seguro como para plantear la cuestión en un gran foro. Las retrospectivas no solo proporcionan una puerta abierta, sino el consenso grupal. Alguien puede plantear un problema y obtener soporte. Es difícil hacerse de la vista gorda sobre esto.
Cuatro maneras de mejorar las pruebas de software y reducir el riesgo
Después de la retrospectiva, su equipo puede llegar a una lista de riesgos y problemas tales como los (teóricamente) identificados en el caso de Knight Capital. Si es así, considere estas cuatro técnicas para reducir el riesgo.
Después de la retrospectiva, su equipo puede llegar a una lista de riesgos y problemas tales como los (teóricamente) identificados en el caso de Knight Capital. Si es así, considere estas cuatro técnicas para reducir el riesgo.
* Mejore la gestión de los cambios y configuración. Mantener el código de prueba y de producción en dos cajas de arena separadas, es una práctica popular para reducir riesgos. En Zappos, el equipo cuenta con un proceso separado, y más riguroso, para el código que tocará los datos sensibles y la información financiera del cliente. Etsy, en tanto, despliega todo el código de producción, pero mitiga el riesgo con la técnica #2.
* Mejore el control de la producción. Lane sugiere el uso de procesos automatizados para detectar y enviar alertas con respecto a los errores. Jeffery Reeves, director de InvestorPlaceMedia, recomienda tener a seres humanos reales viendo el volumen de transacciones, con criterio personal. Las empresas con una gran cantidad de transacciones automatizadas harían bien en tener ambas cosas.
* Vea a las pruebas como un proceso de gestión de alto riesgo. "En muchos casos, las empresas de comercio sienten que no hay tiempo suficiente para hacer las pruebas tradicionales, debido al tiempo comprimido de estas oportunidades fugaces", señala Lane. Irónicamente, muchos errores no serían encontrados por las pruebas tradicionales, ya que son riesgos de configuración. El software puede haber funcionado correctamente, pero en el lugar equivocado, a la hora equivocada o desde un código de prueba que estaba en producción. El tipo de probadores que "hacen clic acá, hacen clic allá y se aseguran que los números cuadren", como los describe Lanel, no pudieron encontrar tales errores. Una mejor gestión de los riesgos es necesaria. La SEC puede crear regulaciones que exijan políticas de revisión automática para el software de comercio, pero el concepto se aplica a cualquier software con riesgo empresarial adjunto.
* Aumente los controles internos sobre transacciones de gran volumen. Es posible que la falla de Knight Capital hubiera sido evitada por un simple botón apretado por un humano, especialmente cuando el volumen alcanzó cierto nivel. Tal control no estaría al nivel del programa, sino al nivel de la API pública. Hasta que tales controles externos existan, haríamos bien si los construimos en nuestros programas de puerta de enlace.
Knight Capital puede que nunca sea lo suficientemente transparente para que podamos llevar a cabo una evaluación de qué salió mal, o incluso ver un informe retrospectivo. Eso no debe parar su organización. Esto debe ser una oportunidad para examinar sus sistemas y cómo interactuar al determinar el valor de invertir tiempo y energía en la gestión de riesgos.
Es un trabajo duro, y no es alucinante, pero una buena gestión del riesgo probablemente mantenga a su compañía al margen de las páginas de inicio de CNN, Wall Street Journal o Financial Times. Eso podría llegar a ser algo excelente.
– IDG News / CIO