Knight Capital: 45 minutos, um servidor sem atualizar e mais de 460 milhões de dólares

Em 1º de agosto de 2012, a Knight Capital perdeu mais de 460 milhões de dólares em cerca de 45 minutos. Segundo o regulador, tudo começou com uma mudança de software instalada em sete de oito servidores. O oitavo ficou com um código antigo que já não era usado, e esse código acordou quando a Bolsa abriu. O que veio depois foi uma cadeia de controles que não estavam onde faziam falta.

É um caso amplamente documentado em registros públicos: a Comissão de Valores Mobiliários dos Estados Unidos (a SEC, o regulador dos mercados daquele país) o investigou e publicou as constatações em uma ordem de 18 páginas [1]. Quase tudo o que segue vem dali. Uma ressalva importante: a Knight aceitou o acordo com a SEC sem admitir nem negar essas constatações [1, seção II].

Este artigo é para quem dirige uma empresa ou uma área de tecnologia. Ele cobre quatro coisas:

1. O que aconteceu, hora a hora.
2. Por que não foi azar, e sim uma cadeia de pequenas decisões.
3. O que se aprende para um diretor, em linguagem de negócio.
4. O que perguntar no próximo comitê e por onde começar esta semana.

Um esclarecimento antes de começar: a Hábil não participou deste caso. Contamos o caso com o que a SEC e a própria Knight informaram publicamente.

Primeiro, quem era a Knight

A Knight Capital era uma das maiores firmas de Wall Street na execução de ordens de ações. Segundo a SEC, em 2011 e 2012 a operação da Knight representava, em geral, cerca de 10% de todas as ações negociadas nos mercados listados dos Estados Unidos [1]. Quando um pequeno investidor comprava ações por meio da corretora, muitas vezes a ordem passava pela Knight.

Para isso, ela usava um sistema chamado SMARS: um roteador automático de ordens, de alta velocidade. O trabalho dele é simples de explicar. Recebe uma ordem de compra ou de venda (a ordem «mãe») e, conforme o que houver disponível no mercado, envia uma ou mais ordens derivadas (as «filhas») a diferentes centros de negociação (bolsas e outros mercados onde se compram e vendem ações) para executá-la [1, par. 12]. O lógico é que, quando a ordem mãe já foi concluída, ele pare de enviar filhas.

Essa última ideia é a que importa. Guarde-a.

A cronologia, hora a hora

2003: uma função que ninguém desliga

A Knight deixa de usar uma função do SMARS chamada «Power Peg». Deixa de usá-la, mas não a apaga. O código continua dentro do sistema, presente e pronto para ser ativado [1, par. 13–14].

Nesse código havia uma peça-chave: um contador que somava quantas ações da ordem mãe já tinham sido executadas. Esse contador era o freio. Dizia ao sistema: «já está completa, pare de enviar».

2005: uma mudança que ninguém volta a testar

Dois anos depois, a equipe move esse contador para outra parte do SMARS, para usá-lo em outra função. Ninguém volta a testar o Power Peg para ver se ele ainda funciona sem o contador [1, par. 14]. Para quê, se ninguém mais o usa?

Desde esse dia, o Power Peg é um carro sem freios estacionado na garagem. Ninguém o dirige. Ninguém o revisa. Está com a chave na ignição.

Julho de 2012: oito servidores, sete cópias

A Bolsa de Nova York (NYSE) vai estrear um programa para ordens de pequenos investidores, o Retail Liquidity Program, que começa em 1º de agosto [1, par. 12]. A Knight quer que os clientes participem desde o primeiro dia, e por isso escreve código novo para o SMARS.

Duas decisões técnicas armam a armadilha:

• O código novo substitui o antigo Power Peg nessa parte do sistema.
• Para ser ativado, reutiliza a mesma bandeira (um interruptor dentro de cada ordem) que anos antes ligava o Power Peg [1, par. 13]. A ideia era apagar o Power Peg, de modo que essa bandeira só pudesse ligar o que é novo.

A partir de 27 de julho, um técnico instala o código novo por etapas, servidor por servidor, em dias sucessivos. O SMARS roda em oito servidores. Em um deles, o código novo não é copiado [1, par. 15].

Ninguém percebe. Segundo a SEC, a Knight não exigia que um segundo técnico revisasse a instalação, e não tinha procedimentos escritos que o exigissem [1, par. 15 e 26]. O oitavo servidor fica com o Power Peg dentro e sem o código novo.

Quarta-feira, 1º de agosto, 8h01 da manhã (horário de Nova York): 97 e-mails que ninguém lê

Falta quase uma hora e meia para o mercado abrir. Chegam ordens do programa novo marcadas para operar antes da abertura. Por volta das 8h01, um sistema interno da Knight começa a mandar e-mails automáticos a um grupo do pessoal. Eles mencionam o SMARS e apontam um erro: «Power Peg disabled», Power Peg desabilitado [1, par. 19].

Antes das 9h30 chegam 97 desses e-mails. Ninguém age sobre eles. Não é negligência de uma pessoa: essas mensagens não foram desenhadas como alertas, e o pessoal, em geral, não as revisava ao recebê-las [1, par. 19]. A SEC diz assim: eram mensagens em tempo real, causadas pela instalação falha, e davam uma possível oportunidade de encontrar e corrigir o problema antes da abertura [1, par. 19].

O sistema avisou. O aviso chegou a uma caixa de entrada que ninguém olhava.

9h30: o mercado abre

Toca o sino. Sete servidores processam bem as ordens do programa novo. O oitavo, não.

Cada ordem com a bandeira reutilizada que chega a esse servidor acorda o Power Peg. E o Power Peg já não tem o contador: não sabe quando a ordem mãe está completa. Então manda ordens filhas sem parar, uma atrás da outra, em altíssima velocidade, para cada ordem que recebe [1, par. 16].

O mais inquietante: outra parte do sistema da Knight sabia, sim, que as ordens já tinham sido concluídas. Mas essa informação não chegava ao SMARS [1, par. 16].

Lembre-se da ideia que pedi para guardar. O dado que teria servido de freio existia em outra parte do sistema, não na que estava enviando.

Os minutos seguintes: procurar às cegas

Desde a abertura, o pessoal de alto nível da Knight vê na ferramenta de monitoramento que uma posição enorme se acumula em uma conta interna, a «Conta 33» [1, par. 24–25]: ações compradas ou vendidas que ficam a cargo da Knight, com todo o seu risco. Veem o sintoma. Não veem a causa.

A SEC descreve por que demoraram tanto a entender o que acontecia:

• A ferramenta de monitoramento dependia por completo de que uma pessoa a olhasse: não gerava alertas automáticos sobre a exposição da firma, isto é, o dinheiro que ela tinha em risco [1, par. 25].
• Não mostrava os limites: quem a olhava tinha de saber de cor o limite de cada conta para perceber que ele tinha sido ultrapassado [1, par. 25].
• Com o volume daquela manhã, ela se atrasava e os relatórios saíam imprecisos [1, par. 25].
• A Conta 33 tinha um limite de 2 milhões de dólares, mas não estava ligada a controles automáticos sobre a exposição total da Knight; e a ferramenta de monitoramento tampouco interrompia por conta própria o envio de ordens [1, par. 23–25].
• E não havia procedimentos para orientar o pessoal em um incidente grave; a SEC concluiu que a equipe técnica precisava de uma orientação clara sobre quando desconectar um sistema que falha [1, par. 27 e 42].

Enquanto isso, a Knight segue conectada ao mercado. A equipe de tecnologia tenta encontrar o problema ao vivo, com o sistema enviando milhões de ordens [1, par. 10 e 27].

O remédio que piora tudo

Em uma das tentativas, a equipe faz o que muitos de nós faríamos: voltar ao estado anterior. Desinstala o código novo dos sete servidores em que ele estava bem instalado [1, par. 27].

Mas nesses sete servidores, por baixo do código novo, o Power Peg continuava ali. Ao retirar o novo, a bandeira volta a ligar o antigo. Agora são oito servidores enviando ordens sem freio [1, par. 27].

A volta atrás, que devia ser a rede de segurança, foi o empurrão final, porque ninguém sabia com certeza o que havia por baixo.

Cerca de 45 minutos depois

Quando a Knight finalmente para de enviar ordens, a conta da SEC é esta [1, par. 1 e 17]:

• 212 ordens de varejo (de pequenos investidores) detonaram tudo.
• O SMARS mandou milhões de ordens filhas, com mais de 4 milhões de execuções em 154 ações e mais de 397 milhões de títulos.
• A Knight ficou, sem querer, com uma posição líquida de compra de cerca de 3,5 bilhões de dólares em 80 ações e uma posição líquida de venda de cerca de 3,15 bilhões em 74 ações.

O dano não ficou na Knight. Em 75 dessas ações, as operações dela foram mais de 20% do volume e contribuíram para movimentos de preço de mais de 5%; em 37, o preço se moveu mais de 10% e a Knight foi mais da metade do volume [1, par. 18]. Essas execuções afetaram outros participantes do mercado: alguns receberam preços menos favoráveis e outros, mais favoráveis, do que teriam tido sem elas.

Os dias seguintes

• Quinta-feira, 2 de agosto. A Knight informa uma perda antes dos impostos de aproximadamente 440 milhões de dólares [3]. Naquela manhã, segundo a Associated Press, a ação da Knight perde metade do valor no início do pregão [5].
• Segunda-feira, 6 de agosto. Um grupo de investidores concorda em injetar 400 milhões de dólares na Knight em troca de ações preferenciais conversíveis (ações com direitos especiais que podem ser trocadas por ações ordinárias) [4]. No relatório trimestral, a própria Knight reconhece que havia «dúvida substancial» sobre a capacidade da Knight de continuar operando [6].
• 1º de julho de 2013. A Knight Capital Group e a GETCO se combinam para formar a KCG Holdings; a Knight deixa de ser uma empresa independente [1, par. 11].
• 16 de outubro de 2013. A SEC aplica à Knight uma multa de 12 milhões de dólares. É a primeira ação de fiscalização da SEC sob a regra de acesso ao mercado, adotada em 2010: a norma que exige das firmas controles de risco antes de enviar ordens ao mercado [1][2]. O número final da perda que a SEC fixa é de mais de 460 milhões de dólares [1, par. 1 e 10].

Uma nota sobre os números: os 440 milhões são a estimativa que a Knight publicou no dia seguinte [3]; os mais de 460 milhões são o que a SEC estabeleceu ao terminar a investigação [1]. Aqui usamos o da SEC.

Não foi azar: foi uma cadeia

É tentador contar esta história como «um técnico esqueceu de copiar um arquivo». A SEC não a conta assim. A ordem dela aponta falhas de controle, não de uma pessoa [1, par. 9 e 40–44]. Qualquer um destes elos, isoladamente, teria cortado a cadeia:

Releia a terceira linha. Segundo o regulador, uma simples dupla verificação da instalação «poderia ter identificado que um servidor fora omitido e evitado os eventos de 1º de agosto» [1, par. 41].

E há um detalhe que deveria incomodar qualquer comitê: a Knight tinha, sim, controles. A interface com clientes, o sistema interno de ordens e o sistema de execução interna tinham controles contra ordens erradas [1, par. 20]. O problema é que ficavam antes do SMARS. No último trecho, o que tocava o mercado, não havia um suficiente [1, par. 21].

O aviso que chegou um ano antes

Em outubro de 2011, a Knight fez um teste de recuperação de desastres em um fim de semana, com dados de teste. Na segunda-feira, um dos sistemas da Knight continuou usando esses dados de teste para cotar no mercado real. Perdeu quase 7,5 milhões de dólares [1, par. 33].

A Knight corrigiu esse problema: limitou o horário do sistema, mudou um controle e acrescentou um passo a uma lista de verificação. O que não fez, diz a SEC, foi perguntar se tinha controles suficientes contra ordens erradas não importa qual sistema as enviasse nem por quê [1, par. 33 e 44]. Reagiu ao caso, não à causa.

A assinatura que dizia outra coisa

Em março de 2012, o diretor-presidente da Knight assinou a declaração anual exigida pela regra de acesso ao mercado. O texto não dizia que os controles cumpriam a regra; dizia que a Knight tinha «processos» para cumpri-la. Foi um erro de redação não intencional, o diretor não o notou e acreditava estar assinando que tudo cumpria [1, par. 34]. Para a SEC, declarar que existem «processos» não equivale a declarar que os controles e procedimentos estão razoavelmente desenhados e cumprem a regra [1, par. 45].

Numa reunião, soa como tecnicalidade. Essa diferença não explica por si só o que aconteceu em 1º de agosto, mas mostra uma supervisão que dava como certo que os controles bastavam, sem comprová-lo.

O que se aprende para um diretor

Quem dirige uma empresa não opera um roteador de ações. Mas se a empresa cobra, fatura, aprova crédito, emite apólices ou vende on-line, tem sistemas que agem sozinhos e rápido. Estas lições não são de Wall Street; são de qualquer operação que não pode parar.

1. O risco mais caro não está no código novo: está no que ninguém lembra

O Power Peg estava havia nove anos sem uso. Ninguém o via como um risco porque «não fazia nada». Em sistemas com anos de estrada é comum que sobrem funções desligadas, bandeiras reutilizadas e integrações sem dono claro. O que não se usa e não se apaga é uma dívida que cobra juros no pior dia.

2. Uma mudança instalada à mão não é uma mudança controlada

O problema não foi uma pessoa errar: as pessoas erram. O problema foi que nada estava desenhado para detectar o erro. Se instalar em oito servidores depende de alguém repetir oito vezes a mesma coisa sem falhar, mais cedo ou mais tarde uma dessas repetições vai sair errada. Um caminho de liberação automatizado (o processo que leva cada mudança até os servidores sem passos manuais) reduz essa variação: instala o mesmo em todos os lugares e verifica que ficou igual. Não elimina o risco, mas o torna visível.

3. Um alerta que ninguém lê é um registro, não um controle

Os 97 e-mails são a cena que mais deveria tirar o sono de um diretor. O sistema detectou o problema, com uma hora e meia de antecedência. Mas o aviso não foi desenhado para que alguém agisse. Pergunte-se quantos avisos automáticos da operação chegam hoje a uma caixa compartilhada que ninguém revisa.

4. O freio tem de estar onde está o risco, e tem de ser automático

A Knight tinha controles no início do caminho e monitoramento depois dos fatos. Faltava um freio logo antes de o dinheiro sair, e faltavam limites que interrompessem o envio por conta própria. Um limite que depende de alguém lembrar dele enquanto olha uma tela lenta não é um limite.

5. Voltar atrás também é uma mudança, e também é preciso ensaiá-la

A tentativa de voltar à versão anterior piorou tudo, porque ninguém sabia o que havia por baixo. Uma volta atrás segura não é «desinstalar e rezar»: é um procedimento testado antes, que leva a um estado conhecido.

6. Em um incidente, a primeira decisão é de negócio: desconectamos?

Durante 45 minutos, a equipe técnica procurou a falha com o sistema conectado. A SEC aponta que a Knight precisava de uma orientação clara sobre quando desconectar [1, par. 42]. Essa decisão não deve ser improvisada no meio do incêndio nem depender de quem esteja com o teclado: combina-se antes, com nome e sobrenome, e com um limite claro.

7. Corrigir o sintoma não é corrigir a causa

A perda de 7,5 milhões de 2011 foi um aviso. A Knight arrumou aquele caso pontual e seguiu igual. Cada pequeno incidente é a oportunidade mais barata que haverá de encontrar o grande.

Por que isto continua acontecendo

Passaram-se mais de catorze anos e a lição segue vigente por uma razão incômoda: nenhum destes controles exige tecnologia exótica. Uma dupla verificação, um alerta bem direcionado, um limite automático, um procedimento para desconectar. Combinam processo, tecnologia e governança, e a dificuldade real é outra: eles competem com a pressa. A Knight tinha uma data fixa, o início do programa da Bolsa, e queria estar pronta nesse dia [1, par. 12].

Quando o calendário manda, a primeira coisa a ser cortada é a que «não aparece»: a revisão, o teste do que é antigo, o ensaio da volta atrás. Até que aparece.

Cinco perguntas para o próximo comitê

1. Como uma mudança chega aos nossos sistemas críticos? Por um caminho automatizado que instala o mesmo em todos os lugares e o verifica, ou porque alguém a copia à mão?
2. Que código ou funções desligadas continuam nos nossos sistemas, e quem responderia se alguém as ligasse sem querer?
3. Que avisos automáticos os nossos sistemas geram hoje, a quem chegam e quem é obrigado a agir quando aparecem?
4. Que limites de dinheiro, volume ou quantidade interrompem sozinhos uma operação anormal, e em que ponto exato do caminho estão?
5. Se amanhã um sistema começar a causar dano, quem decide desconectá-lo, com que limite e quando foi o último ensaio da volta atrás?

Se alguma resposta for «não sei» ou «depende de quem estiver», transforme-a em um risco com responsável e data. Para cada uma, peça cinco dados: o sistema afetado, o responsável, a evidência que existe hoje, o impacto se falhar e o próximo controle necessário. Com isso, o comitê pode priorizar um primeiro sistema e decidir o passo seguinte.

Por onde começar esta semana

Escolha um sistema que cobre, pague ou movimente dinheiro. Peça a quem o libera que conte, passo a passo, como saiu a última mudança: quem a instalou, em quantos servidores, como se comprovou que ficou igual em todos e o que teria acontecido se tivesse falhado. Se a resposta tiver um «normalmente» ou um «ele sabe o procedimento», já se sabe por onde começar.

O que a Hábil faz

A Hábil é uma consultoria mexicana de engenharia, fundada em 2006, que constrói sistemas para operações que não podem parar. Um dos problemas que resolvemos é justamente o desta história: que liberar uma mudança deixe de dar medo.

Desenhamos e implementamos caminhos de liberação automatizados na nuvem, nos servidores da empresa ou nos dois: cada mudança sai pelo mesmo caminho, com testes e revisão de segurança antes de chegar aos clientes da empresa, ambientes de teste e de operação que se parecem entre si, reversão acordada e um rastro de quem aprovou o quê. Começamos pelas ferramentas que a equipe já usa e pelo sistema que mais dói, com a operação em andamento. Veja a página Ir para produção rápido e sem sustos e, para o detalhe técnico, o artigo CI/CD DevSecOps em infraestrutura própria.

Para contrastar estas cinco perguntas com um sistema concreto, comecemos por aí. Peça a primeira conversa, sem custo. Revisamos como a empresa libera hoje um dos sistemas prioritários, e a empresa leva um primeiro mapa dos riscos e da próxima decisão. Escreva para nós pelo WhatsApp.

Perguntas frequentes

A Knight Capital faliu?

Não exatamente. Sobreviveu graças a uma injeção de 400 milhões de dólares de um grupo de investidores, acertada cinco dias depois [4], mas perdeu a independência: em julho de 2013 combinou-se com a GETCO para formar a KCG Holdings [1, par. 11].

A culpa foi do técnico que não copiou o código?

A SEC não coloca assim. A ordem dela aponta que a Knight não tinha procedimentos escritos nem uma segunda revisão para instalar código nesse sistema, nem controles para impedir que código sem uso fosse ativado [1, par. 9-D, 15 e 26]. Um erro humano é previsível; o que faltou foi um sistema que o detectasse.

Por que se fala de 440 milhões e também de 460?

Os 440 milhões são a perda antes dos impostos que a Knight estimou em 2 de agosto de 2012 [3]. A SEC, ao encerrar a investigação em outubro de 2013, estabeleceu uma perda de mais de 460 milhões [1].

Isto só vale para empresas financeiras?

Não. Qualquer empresa com sistemas que agem sozinhos (cobranças, faturamento, pagamentos, estoques, pedidos on-line) tem a mesma exposição: uma mudança mal instalada, código esquecido e avisos que ninguém atende. O que muda é a velocidade com que o erro vira dinheiro.

Automatizar as liberações elimina o risco?

Não o elimina; o reduz e o torna visível. Um caminho automatizado instala o mesmo em todos os lugares, verifica o resultado e deixa rastro, mas continua precisando de testes, limites automáticos, alertas que alguém atenda e uma volta atrás ensaiada.

Por onde começa uma empresa que hoje libera à mão?

Por um único sistema, o que mais dinheiro movimenta ou mais dói, medindo primeiro como ele é liberado hoje. A partir daí, automatiza-se por etapas, sem parar a operação.

Os números e fatos do caso vêm de documentos públicos consultados em 20 de outubro de 2026. As citações foram traduzidas do inglês.