Goldman Sachs Massive Trading Error carrega uma semelhança assustadora com aquele que trouxe Down Knight Capital Agora que sabemos mais sobre o erro de troca de opções de ontem, poderia custar às centenas de milhões de milhões de dólares, sabemos que se parece muito com outro grande erro comercial - Knight Capitals 450 milhões de falhas comerciais a partir de 2012. Ambos os Goldmans se equivocaram ontem - um erro de programação do sistema que estabelece limites de preço incorretos em vários símbolos de ticker - e Knights error - também um erro de programação do sistema que enviou os algoritmos comprando alto e vendendo baixo - realce o fato de que O software de computador complexo e de alta velocidade tem o poder de colocar os mercados em um tizzy. Até que ponto o Goldmans falhou o comércio, que foram enviados para trocas de opções em todo o país, alcançou ontem (da Bloomberg): a negociação pode ter afetado cerca de 400 mil contratos para empresas como JPMorgan Chase amp Co. Johnson amp Johnson e Kellogg Co. com base em Dados para os 500 maiores negócios. Nasdaq OMX PHLX está revisando uma lista de cerca de 1.225 contratos exclusivos em 51 ações subjacentes, de acordo com seu e-mail de alerta do comerciante. Cerca de 240 de setembro de 103 colocaram contratos para o iShares Russell 2000 Exchange-Traded Fund negociados em 1 às 9:32 horas da New York time hoje, abaixo de até 3.32 dois minutos antes, dados compilados pelo show Bloomberg. O próximo comércio foi executado às 3.27 às 9h33. Para o Knight Capital, um erro de programação custou à própria empresa sua própria existência. Goldman, por outro lado, diz que o erro não seria importante para a situação financeira da empresa. O banco é conhecido por ter uma tecnologia comercial mais sofisticada e poderosa na rua, mas falava em negociar alta velocidade no mercado de opções aqui. À medida que as empresas tentam construir programas para se tornarem os mais rápidos e os mais ruins, diga alguns especialistas, podem ser cometidos erros. De volta ao tempo de Knight, o Business Insider falou com Lev Lesokhin. Ele trabalha para a CAST, uma empresa que visualiza riscos inerentes em sistemas de software financeiro. Lesokhin explicou que algumas dessas empresas financeiras não estão prestando atenção suficiente ao que está sob o capô de seus programas de computador - e isso significa que coisas estranhas podem acontecer. No Knight, essa coisa bizarra era o código de Frankenstein. A maioria dos aplicativos de TI tem código morto, disseram Leskhin. Está lá, apenas saindo na base do código, mas nenhum dos módulos ao vivo está chamando. Se você não tem supervisão estrutural, então você não sabe se o seu novo código vivo pode estar chamando o código morto. No caso Knights, foi. O código vivo chamou o código morto de volta à vida e o programa começou a negociar com isso. Bem, espere para ver o que aconteceu com a Goldman. Quanto aos negócios, todos podem ser revogados (cancelados), dependendo das regras para o que constitui um erro oficial nas trocas em questão (NYSE, NASDAQ, CBOE). Mais sobre isso para vir. Testes de software lições aprendidas de Knight Capital Fiasco Levou apenas um defeito em um algoritmo de negociação para o Knight Capital perder 440 milhões em cerca de 30 minutos. Que 440 milhões são três vezes o lucro anual da empresa. O choque e a liquidação que se seguiram fizeram com que o estoque Knight Capitals perdesse 75% do seu valor em dois dias úteis. A perda de liquidez foi tão grande que o Knight Capital precisava assumir uma linha de crédito adicional de 400 milhões, o que, de acordo com o Wall Street Journal. Efetivamente transferiu o controle da empresa do grupo de gerenciamento para seus novos credores. Knight Capital foi regulado pela Securities and Exchange Commission, rotineiramente auditada e queixa PCI. Se esse erro pudesse afetar o Knight, isso poderia acontecer a qualquer empresa. Pelo menos, foi o que o CEO da Knight Capital, Thomas Joyce, pareceu implicar em uma entrevista com a Bloomberg Television. Quebras de tecnologia. Não é bom. Nós não esperamos isso, ele diz, acrescentando: era um bug de software. Aconteceu ser um bug de software muito grande. Este incidente não foi o primeiro de seu tipo. Em 2010, algo levou a Dow Jones Industrial Average a soltar 600 pontos em cerca de cinco minutos no que agora é conhecido como o flash crash. Nasdaq culpou o desastroso IPO do Facebook em uma falha técnica similar. Mistiming, Bad Orders Crash High-Frequency Trading Algorithm No início de junho de 2012, a New York Stock Exchange (NYSE) recebeu permissão da SEC para lançar o Retail Liquidity Program. O RLP, projetado para oferecer aos investidores individuais o melhor preço possível, mesmo que isso signifique desviar negócios fora da NYSE e para um chamado mercado negro, foi ajustado ao vivo no dia 1 de agosto. Isso significava que as casas comerciais tinham aproximadamente um mês e Um meio para mexer para escrever código para tirar proveito deste novo recurso. O incidente do Knight Capital aconteceu nos primeiros 30 minutos de negociação em 1º de agosto. Algo foi muito errado no código que havia sido introduzido durante a noite. O próprio código era um algoritmo de negociação de alta freqüência projetado para comprar e vender quantidades maciças de estoque em um curto período de tempo. Uma combinação de erros e ordens ruins deixa resultados desastrosos. Além de admitir um defeito de software, a equipe do Knight Capital tem relutado em discutir exatamente o que causou o defeito. Eles não sabem que a maioria dos inquéritos financeiros relacionados a este artigo levou a respostas como Não comentários, eu não posso comentar ou Não podemos comentar sobre esta história. Um tecnólogo de uma 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. Analise as declarações do Knight Capital com cuidado, diz o tecnólogo, e é possível que o programa que entrou em produção foi, na verdade, um programa de teste projetado para simular pedidos comerciais e avaliar se eles passaram corretamente. Nanex realizou uma análise dos negócios na semana passada e chegou à mesma conclusão. Rick Lane, CTO of 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 pronta para a produção e deveria ter sido desligada. Ele ressalta que esses algoritmos de negociação são desenvolvidos incrivelmente rapidamente, pois eles são projetados para perseguir oportunidades fugazes e que o bom gerenciamento de mudanças pode ter um banco traseiro para acelerar. O assustador é que isso acontece mais frequentemente do que as pessoas pensam, e não apenas pelas lojas comerciais, diz Lane. Em setembro de 2010, a Chicago Mercantile Exchange executou um programa que injetou acidentalmente ordens de teste em seu sistema de produção e o CME nem sequer tem o tipo de pressão de tempo que essas lojas comerciais têm. Adicionando Retrospectiva ao Processo de Desenvolvimento Pode Reduzir Erros Jeff Sutherland, um co-autor do Agile Manifesto que ajudou a formalizar a metodologia Scrum, acrescenta uma terceira possibilidade de que a equipe esteja usando um método de desenvolvimento propenso ao erro. Sutherland, também um ex-piloto da Força Aérea dos EUA, recomenda uma avaliação externa, bem como o processo que o Conselho Nacional de Transporte e Segurança usa para acidentes de avião. Sem alguma avaliação, ele diz, talvez nunca possamos saber o que deu errado e corremos o risco de tentar evitar o problema errado. Apenas uma avaliação minuciosa do ciclo de vida do desenvolvimento de software de Knight Capitals nos indicará o que aconteceu na Bolsa de Valores de Nova York em 1 de agosto de 2012, dizem os especialistas. (Imagem cortesia de Ryan Lawler via Wikimedia Commons) George Dinwiddie, consultor principal da 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 processo de olhar formal que considera o que realmente está acontecendo, quais são os riscos e como a equipe pode melhorar. No Exército, as retrospectivas são chamadas de avaliações pós-ação. O último pensamento em software, porém, é ter a conversa antes que o software seja implantado para pegar e resolver o problema. O Agile Retrospective Resource Wiki oferece uma série de opções. Um método eficaz que eu recomendo é perguntar o que está indo corretamente, o que está acontecendo errado eo que nós (a equipe) deveríamos fazer de maneira diferente. Os membros da equipe criam cartões para listar o que eles gostariam de falar, depois votei colocando um ponto nos cartões para decidir o que falar. A equipe discute os dois itens mais pontilhados em cada categoria. Quando há um problema, outra fonte anônima aponta, alguém na organização geralmente sabe disso, mas pode não se sentir seguro o suficiente para mostrar o problema em um grande fórum de apoio. Retrospectivas fornecem não só uma porta aberta, mas um consenso grupal também. Alguém pode criar um problema e obter apoio. Isso é difícil de fechar os olhos. 4 maneiras de melhorar o teste de software e reduzir o risco Após a retrospectiva, sua equipe pode apresentar uma lista de riscos e questões como as (teoricamente) identificadas no caso Knight Capital. Em caso afirmativo, considere estas quatro técnicas para reduzir o risco. Melhore o gerenciamento de mudanças e configurações. Manter o teste eo código de produção em diferentes caixas de areia é uma prática popular para reduzir o risco. Em Zappos. A equipe tem um processo separado, e mais rigoroso, para o código que irá afetar os dados sensíveis ao cliente e as informações financeiras. Etsy. Enquanto isso, implanta todo o código para a produção, mas mitiga esse risco com a técnica 2. Melhorar o monitoramento da produção. Lane sugere o uso de processos automatizados para detectar e enviar alertas sobre erros. Jeffery Reeves, editor da InvestorPlaceMedia, recomenda que os humanos reais vejam volumes de transações, usando julgamento pessoal. Empresas com uma grande quantidade de transações automatizadas fariam bem em ter ambos. Ver testes como um processo de gerenciamento de risco de alto nível. 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 erros não seriam encontrados por testes tradicionais, pois são riscos de configuração. O software pode ter funcionado corretamente, mas no lugar errado, na hora errada ou do código de teste que estava em produção. O tipo de testadores que clicam nisso, clicam nisso, assegure-se de que esses números correspondem, como Lane os descreve, não conseguiu encontrar esses erros. É necessário um melhor gerenciamento de riscos. A SEC pode criar regulamentos para exigir políticas de revisão de automação para software de negociação. Mas o conceito se aplica a qualquer software com risco comercial em anexo. Aumente os controles internos em transações de alto volume. É possível que a falha do Knight Capital tenha sido evitada por um único botão que um ser humano precisava clicar, especialmente quando o volume atingiu um determinado nível. Esse controle não seria no nível do programa, mas, em vez disso, no nível da API pública. Até que tais controles externos existam, faremos bem em construí-los em nossos programas de gateway. O Knight Capital talvez nunca seja transparente o suficiente para que possamos realizar uma avaliação do que deu errado ou mesmo ver um relatório retrospectivo. Isso não deve parar sua organização. Esta poderia ser uma oportunidade para examinar seus sistemas e como eles interagem enquanto determinam o valor do tempo de investimento e da energia no gerenciamento de riscos. É um trabalho árduo, e não é impressionante, mas é provável que uma boa gestão de riscos mantenha sua empresa fora da página inicial da CNN, Wall Street Journal ou Financial Times. Isso só pode revelar-se o mais excelente. Matthew Heusser é um consultor e escritor baseado em Michigan ocidental. Você pode seguir Matt no Twitter mheusser. Entre em contato com ele por email ou visite o site de sua empresa, o Excelon Development. Siga tudo a partir do CIO no Twitter CIOonline. no Facebook. E no Google. Para comentar sobre este artigo e outros conteúdos do CIO, visite-nos no Facebook. LinkedIn ou Twitter.
No comments:
Post a Comment