Knight Capital Trading System

Goldman Sachs erro de negociação maciça carrega uma semelhança assustador para aquele que trouxe para baixo Knight Capital. f REUTERS Andrew Burton. Now que sabemos mais sobre opções ontem erro de negociação poderia custar centenas de milhões Goldman Sachs, sabemos que se parece muito com Outro erro de negociação maciça Knight Capital s 450 milhões trading glitch de 2012.Both Goldman s erro ontem um erro de programação do sistema que defina limites de preço incorreto em um número de símbolos ticker e Knight s erro também um erro de programação do sistema que enviou algoritmos de compra de alta e venda Baixo destaque o fato de que o software de computador complexo, de alta velocidade tem o poder de definir os mercados em um tizzy. Here s o quão distante Goldman s comércio defeituoso, que foram enviados para trocas de opções em todo o país, chegou ontem a partir de Bloomberg. The negociação pode ter afetado Cerca de 400.000 contratos para empresas como JPMorgan Chase Co Johnson Johnson e Kellogg Co com base em dados para os 500 maiores trades Nasdaq OMX PHL X está analisando uma lista de cerca de 1.225 contratos exclusivos em 51 ações subjacentes, de acordo com seu e-mail de alerta comerciante. Cerca de 240 setembro 103 contratos de colocar para o iShares Russell 2000 Exchange-Traded Fund negociado em 1 às 9 32 horas de Nova York hoje, para baixo De até 3 32 dois minutos antes, os dados compilados pela Bloomberg mostrar O próximo comércio foi executado em 3 27 em 9 33 a m. For Knight Capital, um erro de programação custou a empresa a sua própria existência Goldman, por outro lado, diz O erro não seria material para a condição financeira da empresa. O banco é conhecido por ter algumas das mais sofisticadas e poderosas tecnologias de negociação na rua, mas estamos falando de negociação de alta velocidade no mercado de opções aqui Como as empresas tentam Construir programas para se tornar o mais rápido e baddest, dizem alguns especialistas, os erros podem ser feitos. Cerca de tempo Knight, Business Insider falou com Lev Lesokhin Ele trabalha para CAST, uma empresa que visualiza riscos inerentes em sistemas de software financeiro Lesokhi N explicou que algumas dessas empresas financeiras não estão prestando muita atenção suficiente para o que está sob o capô de seus programas de computador e isso significa que as coisas bizarras podem acontecer. Em Knight, essa coisa bizarra foi Frankenstein código. A maioria das aplicações de TI tem código morto, disse Leskhin É lá dentro há pouco pendurando para fora na base de código, mas nenhum dos módulos ao vivo está chamando-lo Se você don t ter supervisão estrutural, então você don t saber se o seu novo código ao vivo poderia estar chamando o Código morto. No caso de Knight, era o código vivo chamado o código morto de volta à vida eo programa começou a negociar com isso. Vamos esperar para ver o que aconteceu com o Goldman Quanto aos comércios, todos eles poderiam ser cancelados, dependendo de As regras para o que constitui um erro oficial nas bolsas em questão NYSE, NASDAQ, CBOE. Mais sobre isso para vir. Get o último preço Goldman Sachs aqui here. Goldman Sachs erro de negociação massivo tem uma semelhança assustador para aquele que trouxe Down Knight Capital. Software Testando Lições Aprendidas De Knight Capital Fiasco. It tomou apenas um defeito em um algoritmo de negociação para Knight Capital perder 440 milhões em cerca de 30 minutos Que 440 milhões é três vezes o salário anual da empresa s. O choque e sell-off t A perda de liquidez foi tão grande que a Knight Capital precisou assumir uma linha de crédito adicional de 400 milhões, o que, de acordo com o Wall Street Journal efetivamente mudou Controle da empresa do grupo de gestão para os seus novos credores. Knight Capital foi regulamentado pela Comissão de Valores Mobiliários e Exchange, rotineiramente auditadas e queixa PCI Se esse bug poderia afetar Knight, poderia acontecer a qualquer empresa Pelo menos isso é o que Knight Capital CEO Thomas Joyce parecia implicar em uma entrevista com a Bloomberg Televisão Tecnologia quebra Ele ain t bom Nós don t olhar para a frente, ele diz, acrescentando: Era um bug de software Aconteceu de ser um bug de software muito grande. A tecnologia quebra É ain t bom Nós não olhamos para a frente, Knight Capital CEO Thomas Joyce diz Imagem cortesia de Bloomberg. This incidente não foi o primeiro de seu tipo Em 2010, algo causou a Dow Jones Industrial Average a cair 600 pontos em aproximadamente Cinco minutos no que é agora conhecido como o crash flash Nasdaq culpou o Facebook desastroso IPO em uma falha técnica semelhante. Mistiming, Bad ordens Crash Algoritmo de negociação de alta freqüência. No início de junho de 2012, a NYSE NYSE Bolsa de Valores recebeu permissão da SEC Para lançar seu Programa de Liquidez de Varejo O RLP, projetado para oferecer aos investidores individuais o melhor preço possível, mesmo que isso signifique desviar negócios da NYSE para um chamado mercado escuro, Cerca de um mês e meio a correr para escrever código para tirar proveito deste novo recurso. O incidente Knight Capital aconteceu nos primeiros 30 minutos de negociação em 01 de agosto Algo correu muito mal no código que h Ad foi introduzido durante a noite O código em si era um algoritmo de negociação de alta freqüência projetado para comprar e vender quantidades maciças de ações em um curto período de tempo Uma combinação de mistiming e maus ordens deixaram resultados desastrosos. Além de admitir um defeito de software, Knight Capital tem sido relutante em discutir exatamente o que causou o defeito Eles não são sozinhos a maioria das consultas relacionadas com o financiamento para este artigo levou a respostas como Nenhum comentário, eu não posso comentar ou Não podemos comentar sobre esta história. Um tecnólogo em um Empresa de serviços financeiros, que pediu para permanecer anônimo, sugere duas possibilidades poderia ter sido a corrida padrão para a produção sem testes adequados analisar as declarações de Knight Capital cuidadosamente, o tecnólogo diz, e é possível que o programa que entrou em produção foi realmente Um programa de teste projetado para simular pedidos de comércio e avaliar se eles passaram corretamente Nanex conduziu uma análise dos comércios na semana passada E chegou à mesma conclusão. Rick Lane, CTO de Trading Technologies, em Chicago, concorda que o problema pode ser um programa de teste em produção ou, possivelmente, uma bandeira de configuração que não estava pronto para a produção e deveria ter sido desligado Ele aponta Que esses algoritmos de negociação são desenvolvidos incrivelmente rapidamente, como eles são projetados para perseguir oportunidades fugaz, e que a boa gestão da mudança pode ter um banco traseiro à velocidade. A coisa assustadora é que isso acontece com mais freqüência do que as pessoas pensam, e não apenas negociando lojas, diz Lane Em setembro de 2010, a Chicago Mercantile Exchange executou um programa que acidentalmente injetado ordens de teste em seu sistema de produção eo CME doesn t mesmo ter o tipo de Jeeff Sutherland, co-autor do Manifesto Agile que ajudou a formalizar a metodologia Scrum, acrescenta uma terceira possibilidade de a equipe ter usado um método de desenvolvimento propenso a Sutherland, também ex-piloto da Força Aérea dos EUA, recomenda uma avaliação externa, muito parecida com o processo que o Conselho Nacional de Transportes e Segurança usa para acidentes com aviões. Sem alguma avaliação, diz ele, nunca saberemos o que correu mal e corremos o risco De tentar evitar o problema errado. Only uma avaliação completa de Knight Capital s desenvolvimento de software ciclo de vida vai nos dizer o que aconteceu no New York Stock Ex Dinwiddie, consultor principal na iDIA Computing, também recomenda uma avaliação Qualquer empresa pode avaliar sua organização usando uma ferramenta chamada retrospectiva, diz Dinwiddle. A retrospectiva é um Formal olhar para trás processo que considera o que está realmente acontecendo, quais são os riscos e como a equipe pode melhorar. No Exército, retrospectivas são chamados de pós-ação-opiniões O mais recente pensamento em software, porém, é ter a conversa antes do software É implantado a fim de pegar e corrigir o problema O Wiki Agile Retrospective Resource fornece uma série de opções. Um método eficaz que eu recomendo é perguntar o que está acontecendo certo, o que está errado, eo que a equipe deve fazer de forma diferente Os membros da equipe criar Cartões para listar o que eles gostariam de falar sobre, em seguida, votar, colocando um ponto sobre as cartas para decidir o que falar sobre a equipe discute os dois itens mais pontilhados em cada ca Quando há um problema, outra fonte anônima aponta, alguém na organização geralmente sabe sobre isso, mas pode não se sentir seguro o suficiente para trazer a questão em um fórum de grande apoio As retrospectivas fornecem não só uma porta aberta, mas o consenso do grupo Bem Alguém pode levantar um problema e obter apoio Isso é difícil de fechar os olhos para 4. Formas de melhorar o teste de software e reduzir o risco. Após a retrospectiva, sua equipe pode vir acima com uma lista de riscos e questões, tais como aqueles teoricamente Identificado no caso de Knight Capital Se assim for, considere estas quatro técnicas para reduzir o risco. Melhorar o gerenciamento de alterações e configurações Manter o código de teste e produção em sandboxes diferentes é uma prática popular para reduzir o risco Na Zappos a equipe tem um processo separado e mais rigoroso Para o código que irá tocar dados sensíveis ao cliente e informações financeiras Etsy entretanto, implementa todo o código para a produção, mas mitiga esse risco com a técnica 2.Improve acompanhamento da produção Lane Sugere o uso de processos automatizados para detectar e enviar alertas sobre os erros Jeffery Reeves, editor da InvestorPlaceMedia, recomenda que os seres humanos reais observando volumes de transação, usando o julgamento pessoal Empresas com uma grande quantidade de transações automatizadas faria bem em ter both. View testes como um high - Em muitos casos, as empresas comerciais sentem que não há tempo suficiente para testes tradicionais devido ao tempo comprimido dessas oportunidades fugazes, diz Lane. Ironicamente, muitos bugs não seriam encontrados por testes tradicionais, pois são riscos de configuração. O software Pode ter funcionado corretamente, mas no lugar errado, no momento errado ou do código de teste que estava em produção. O tipo de testadores que clicam nisso, clique nisso, certifique-se de que esses números correspondem, como Lane descreve, Bugs Melhor gerenciamento de risco é necessário A SEC pode criar regulamentos para exigir políticas de revisão de automação para o software de negociação, mas o conceito appl Para todos os softwares com risco de negócios anexado. Aumentar os controles internos em grandes volumes de transações É possível que a falha Capital Knight poderia ter sido evitado por um único botão que um ser humano necessário clicar, especialmente quando o volume atingiu um determinado nível Tal Controle não seria ao nível do programa, mas, em vez disso, ao nível da API pública. Até que tais controles externos existam, faremos bem em construí-los em nossos programas de gateway. O Capital de Risco talvez nunca seja transparente o suficiente para realizar uma avaliação do que foi Errado, ou até mesmo ver um relatório retrospectivo Isso não deve parar a sua organização Esta poderia ser uma oportunidade para examinar seus sistemas e como eles interoperam ao determinar o valor de investir tempo e energia na gestão de risco. É trabalho duro, e não é Eye-popping, mas o bom gerenciamento de risco é susceptível de manter sua empresa fora da CNN, Wall Street Journal ou Financial Times home page Isso só pode revelar-se uma coisa mais excelente. Mat Thew Heusser é um consultor e escritor baseado em West Michigan Você pode seguir Matt no Twitter mheusser contatá-lo por e-mail ou visite o site de sua empresa, Excelon Desenvolvimento Siga tudo no Twitter CIOonline no Facebook e no Google. Para comentar sobre este artigo e Outro conteúdo CIO, visite-nos no Facebook LinkedIn ou Twitter. Knight Capital. Following entrada é um registro no Catálogo Catástrofe de uma lista de projetos falhados e conturbados de todo o mundo. Synopsis Em uma história que nos lembra a necessidade de testes adequados , Um falha de software no Knight Capital resultou em um 400M perder em apenas 30 minutos De acordo com relatos de imprensa a perda ascendeu a 3 vezes Cavaleiro s rendimentos anuais Embora os detalhes são difíceis de chegar por um artigo CIO implica o problema foi causado por uma corrida para Cumprir um prazo para implementar mudanças para acomodar um Programa de Liquidez de Retalho RLP aprovado pela Securities and Exchange Commission SEC em meados de junho de 2012 De acordo com a revista CIO o RLP Foi concebido para oferecer aos investidores individuais o melhor preço possível, mesmo que isso significasse desviar negócios da Bolsa de Valores de Nova York e para os chamados mercados escuros. O prazo de implementação para RLP foi fixado para 1 de agosto e a falha comercial em Knight ocorreu Durante os primeiros 30 minutos de negociação em 01 de agosto. Fatores de contribuição como relatado na imprensa Pensado para ser uma falha de teste de controle de qualidade de software Edição potencialmente causada por uma corrida para cumprir a data de implementação RLP ou seja, a programação de pressão failure. Follow Calleam ligado ligado a Ser notificado das próximas aulas on-line e presenciais.