🥊 👣 👷🏼 Como não perder todo o dinheiro em alguns minutos ou gerenciamento de riscos em negociações algorítmicas 🕗 🗣️ 💃🏼

O conteúdo do artigo

Introdução

Agora a situação não é simples, tanto no mundo como na negociação de ações. Muitos comerciantes repentinamente se tornam milionários, enquanto outros perdem todo seu dinheiro instantaneamente. A alta volatilidade do mercado oferece uma boa oportunidade para os comerciantes algorítmicos ganharem. E, para dormir em paz e não sonhar, os cisnes negros precisam proteger suas contas de robôs furiosos e outros problemas do comércio algorítmico.

"O Algotrader está dormindo - o comércio está aberto! " - alguns traders gostam de dizer. Mas a realidade não é tão simples. Onde você acha que a negociação algorítmica começa? De conectar-se à troca ou escrever um algoritmo? Para um participante profissional, a negociação começa com o desenvolvimento do gerenciamento de riscos .

Acredita-se que a negociação algorítmica seja muito mais eficaz que a negociação clássica. Como os robôs não têm soluções emocionais, estão prontos para trabalhar 24 horas por dia, 7 dias por semana, sabem exatamente quando comprar e quando vender, fazem transações a uma velocidade que não é acessível a uma pessoa comum. No entanto, em virtude de suas superpotências, eles criam uma classe crescente de riscos.
Por exemplo, um caso conhecido que entrou na história como "Vingança de carros" causou perdas de US $ 460 milhões, ou um robô quebrado causou perdas de US $ 4,3 milhões ou falhas na Bolsa de Moscoulevando a paradas e perdas para os comerciantes, etc. Um desses incidentes é suficiente e as contas de negociação podem ser irremediavelmente danificadas. Isto é especialmente verdade se o comércio for marginal, quando o preço do erro aumentar várias vezes.

Um comerciante não pode saber quanto ganhará, mas deve saber exatamente quanto pode perder. De fato, qualquer negociação se resume ao controle de riscos, e o lucro é uma recompensa por observá-las.

Neste artigo, tentarei divulgar, se possível, os riscos potenciais associados à execução de algoritmos de negociação em negociações reais e medidas para proteger contra falhas no sistema de negociação. Ao mesmo tempo, não abordarei a gestão do dinheiro , a diversificação da carteira de negociação e a lógica das estratégias de negociação. Esta é uma história diferente.

1. Soluções arquitetônicas

Antes de prosseguir com a classificação de riscos, falarei um pouco sobre soluções padrão na parte comercial da negociação algorítmica.

Dos requisitos à velocidade de execução dos aplicativos, os robôs de negociação são criados de maneiras diferentes. Se esse HFT (por exemplo, arbitragem ou criação de mercado ) for sensível a atrasos, eles tentarão minimizar o caminho do aplicativo desde o algoritmo até a central e a conta em atrasos será gasta em microssegundos. Como regra, esses algoritmos têm uma arquitetura específica e são otimizados para uma estratégia específica. Nesse caso, o gerenciamento de riscos é integrado diretamente à estratégia.

Basicamente, as estratégias de negociação estão em posição de alguns minutos a várias horas e, quanto menos tempo o algoritmo estiver em posição, mais fácil é controlar os riscos. No entanto, com o aumento da frequência das transações, os custos de comissões aumentam, o que reduz a lucratividade dos algoritmos. Portanto, as estratégias de negociação tentam encontrar um equilíbrio entre risco e lucro.

Os algoritmos de negociação raramente são negociados um de cada vez. Normalmente, essas são famílias inteiras de estratégias que são coletadas em carteiras para diversificar e estabilizar a curva de Equidade . Ao mesmo tempo, os dados de troca de algoritmos de negociação podem vir de várias fontes e os aplicativos podem ser enviados para várias trocas. No cerne do sistema de negociação estão os motoresque roteiam e otimizam dados entre algoritmos e trocas (veja a Figura 1). Geralmente, existem outros mecanismos, por exemplo, para trabalhar com dados históricos ou backtesting, mas, para simplificar, não os mostro.

Figura 1. O esquema arquitetural do servidor de negociação.

2. Classificação geral de riscos

2.1 Riscos de infraestrutura
2.2 Problemas na conexão com a central / corretora
2.3 Problemas na lógica das estratégias de negociação

2.1 Riscos de infraestrutura

O principal compartilhamento de problemas nesta classe está associado aos servidores de negociação. Para negociações algorítmicas, mesmo um PC muito poderoso não é adequado por várias razões: equipamento não confiável, conexão instável à Internet, fonte de alimentação fraca, etc.

Os principais riscos:

perda total / parcial do desempenho do servidor;
reinicialização de emergência do sistema operacional;
falha no servidor físico.

A qualidade da solução desses problemas, via de regra, depende do seu orçamento e dos requisitos dos seus algoritmos de negociação.

2.1.1 Opções de solução

Colocação de intercâmbio. Opção ideal e mais cara. Geralmente é usado em algoritmos HFT altamente lucrativos ou em grandes empresas, por exemplo, bancos, onde essa infraestrutura é reutilizada para outras soluções de negociação.
Aluguel de servidor virtual / dedicado. Se você não é um grande fundo de hedge ou um negociador privado, provavelmente usa esta opção. Uma solução simples, facilmente personalizável e escalável. Você sempre pode encontrar um provedor que corresponda aos parâmetros de preço / qualidade.
. . , / , .

2.1.2.

/ . TIER III uptime 99,98% . .
. , . .
A reserva de energia é de pelo menos 40-50% (CPU, RAM, SSD) em comparação com o modo de negociação usual. Como regra, em movimentos fortes do mercado, a carga nos fluxos de dados aumenta e os algoritmos começam a executar transações ativamente. Neste momento crucial, não deve haver nenhum freio em seus servidores.

2.2 Problemas de conectividade

Nas trocas e corretores, falhas técnicas ocorrem de tempos em tempos. Por exemplo, a operação da plataforma de negociação do Sberbank falhou ou foi "pouco trabalhada" na Bolsa de Moscou , a bolsa foi fechada para o almoço , a Bolsa de Moscou suspendeu as negociações devido a uma falha , etc.

Os principais riscos:

interrupções de conexão;
atrasos altos;
dados incorretos;
perda parcial de dados.

2.2.1 Quebras de conexão

As informações de quebra de conexão podem ser obtidas de várias maneiras:

API de eventos do conector - conectado , desconectado .
Usando algoritmos de verificação de conexão como Heartbeat , que geralmente estão presentes na API.
Indiretamente. Pela falta de dados nos fluxos de dados.

Você pode configurar a conexão para que, se a conexão for perdida / desconectada, a central retirará pedidos ativos ou fechará posições. No entanto, você precisa ter cuidado com essa funcionalidade, porque, em caso de intervalos curtos, um fechamento não planejado de posições provavelmente levará a perdas e mais danos do que ajuda.

Além disso, muitas vezes acontece que quando algo quebra, ele quebra completamente e as primeiras opções de aviso sobre intervalos não funcionam e apenas indiretamente conseguem descobrir que algo deu errado.

2.2.2 Problemas de dados

Para começar, considere os principais tipos de dados de estoque. Dependendo do tipo de conector e troca, esses dados não variam muito, mas basicamente os mais ou menos são os mesmos.

Alterações recebidas:

Trocar óculos / carteira de pedidos
Ofertas
Formulários
Itens de linha
Saldo

Dados enviados:

Pedidos de Registro

Os dados recebidos e enviados podem vir de uma ou de diferentes conexões. Acontece que um dos threads pode cair "silenciosamente", enquanto o restante funcionará no modo normal. Mesmo se os dados vierem da mesma fonte, você ainda precisará monitorar cada fluxo individualmente.

Os problemas de dados geralmente são resolvidos com a implementação de algoritmos de rastreamento, como o WatchDog . Todos os threads devem passar por esses módulos. Faixa de

WatchDogs :

frequência de atualizações de dados no fluxo;
atrasos nos registros de data e hora atuais;
mediante a disponibilidade dos dados determina a presença de comunicação com a central.

Se, por um determinado período, nenhum dado vier do conector ou atrasos excederem o máximo permitido, os eventos correspondentes serão gerados e as decisões serão tomadas em ações adicionais.

Para o cálculo correto dos atrasos, um sistema independente para sincronização precisa da hora do sistema deve ser implementado. Por exemplo, com servidores NTP .

2.2.3 Opções de solução

Se os problemas acima ocorrerem, o sistema deve desconectar imediatamente os fluxos de dados dos algoritmos e tentar se reconectar com a frequência e o número de tentativas fornecidos. Deve-se ter em mente que existem causas completamente justificadas e previamente imprevistas de quebras. Por exemplo, devido a uma sessão de negociação reduzida nos feriados nacionais ou a uma atualização inesperada da API e outros cenários irracionais. Em cada conexão específica, a reconexão deve ser abordada individualmente. Caso contrário, o número excessivo de tentativas de reconexão pode ser percebido pela troca como um ataque de spam e levar ao bloqueio de contas.

Após reconectar e fazer o download dos dados perdidos, é necessário notificar os algoritmos de negociação sobre a restauração do trabalho e transferir os dados perdidos para eles. Os algoritmos devem analisar as mudanças que ocorreram e decidir o que fazer em seguida. Permaneça na posição atual, altere-a ou feche-a completamente. Essa lógica deve ser implementada em todas as estratégias de negociação.

A ordem de restauração do trabalho:

reconectar;
carregar dados perdidos;
notificar algoritmos de recuperação de comunicação;
transferir dados perdidos para os algoritmos;
alternar fluxos em tempo real;
A lógica de negociação dos algoritmos deve normalizar suas posições e substituir as ordens.

Da mesma forma, no caso de dados problemáticos ou perda parcial de funcionalidade, você deve primeiro restaurar completamente a conexão e normalizar os fluxos de dados. É impossível negociar com capacidade de trabalho parcial, é óbvio que isso não terminará com nada de bom.

2.3 Problemas na lógica das estratégias de negociação

Os problemas mais perigosos, insidiosos e imprevisíveis espreitam na lógica programada das estratégias de negociação. Não importa o quão ponderados sejam os algoritmos de negociação, é impossível prever todos os cenários. Vários fatores e sua combinação podem dar origem a comportamentos inesperados. Além disso, alguns erros podem durar anos e "emergir" no momento mais inesperado.

2.3.1 Classificação de problemas

Erros nos aplicativos:
- Preço / volume negativo;
- Direção oposta;
- Tipo errado, etc.
Erros de API:
- Nem todos os campos são preenchidos na transação;
- Usando uma versão desatualizada da API;
- ..
:
- ;
- ;
- ;
- « »;
- .
:
- ;
- ;
- .
:
- ;
- .
:
- ;
- ;
- ;
- .
:
- ;
- ;
- Um grande número de aplicativos que não levam a transações.
Falta de tratamento de exceções no código do programa de estratégias de negociação

No entanto, alguns erros podem dar origem a outros. Por exemplo, interromper o algoritmo devido a um erro grave levará a uma violação da posição e, como conseqüência, a uma violação de limites.

2.3.2 Opções de solução

A solução para esses problemas se resume ao controle de aplicativos e limites das estratégias de negociação (consulte a seção 3). Além disso, qualquer exceção no código do programa deve levar à interrupção imediata do algoritmo problemático e à retirada de todos os seus aplicativos ativos.

3. Monitorando aplicativos e limites de estratégias de negociação

Talvez essas sejam as maneiras mais importantes de gerenciar os riscos do sistema de negociação. Qualquer erro acabará por levar a um desvio na posição, aplicações e dinheiro. A tarefa é observar essas alterações o mais rápido possível e tomar medidas prontamente.

Os cheques podem ser divididos em dois tipos:
3.1. Verificação básica de aplicações
3.2. Análise e controle de limites

3.1 Verificação básica de aplicativos

Todas as solicitações de saída devem ser verificadas quanto a:

erros grosseiros;
correção e suficiência de dados para a API;
conformidade com as especificações dos instrumentos negociados;
conformidade com os regulamentos de licitação, etc.

Essas verificações são realizadas antes do envio de aplicativos para a central. Quanto mais cedo um erro for encontrado, mais fácil será eliminar suas conseqüências. Não espere que erros óbvios venham do conector. É melhor resolver os problemas antes que eles apareçam. Além disso, o envio de transações erradas pode dar origem a várias sanções por parte da bolsa.

3.2 Controle de limite

Para controlar limites, é verificado o seguinte:
3.2.1. Mudança de equilíbrio e posição antes de fazer uma solicitação
3.2.2. Mudança no saldo atual e posição
3.2.3. Preço e volume de aplicação
3.2.4. Comportamento do aplicativo

3.2.1 Análise de mudanças de equilíbrio e posição antes de colocar um aplicativo

Antes de enviar um pedido de registro, é verificada uma possível alteração no saldo e na posição em caso de execução do pedido. Se houver um excesso do limite desse algoritmo, o pedido não será enviado e uma mensagem de erro será enviada para a estratégia de negociação.

3.2.2 Análise de mudanças no saldo atual e posição

Os limites são formados para alterações no volume negociado e posição nos instrumentos por períodos de tempo: 15 s, 30 s, 1 min, 5 min, 15 min, 1 hora, 1 dia. O monitoramento constante das mudanças ao longo dos períodos permitirá que você veja o desvio no comportamento e interrompa a negociação, até o momento em que o desvio se torna crítico.

Acontece que os problemas com o algoritmo não aparecem imediatamente. Ele pode começar a "se fundir" lentamente e sem quebrar os limites por um curto período de tempo. Você pode acordar de manhã e encontrar um rebaixamento significativo devido a um algoritmo não muito "quebrado". Nós precisamos disso? Não precisamos.

3.2.3 Análise de preço e volume

Antes de enviar o pedido de registro, o limite de exceder o volume máximo e mínimo no pedido é verificado. Infelizmente, ninguém cancelou os erros aritméticos nas fórmulas e cálculos.

É importante, se possível, verificar o desvio do preço da oferta em relação ao preço médio de mercado. Para fazer isso, verifique o preço de outras fontes para um instrumento comercial semelhante. Essas verificações são especialmente relevantes se a negociação for realizada em uma bolsa ilíquida ou se for observada uma volatilidade anormalmente alta para um instrumento negociado.

Se as alterações excederem os limites especificados, os aplicativos serão rejeitados antes de serem enviados para a central.

3.2.4 Análise de comportamento de aplicativos

Verificado aqui:

o número de aplicativos que não levam a transações;
número de aplicativos ativos;
frequência de aplicação por períodos de 1 s, 3 s, 5 s, 15 s, 30 s, 1 min.

As trocas têm seus próprios limites no número de pedidos ativos e na frequência de envio, se excederem o acesso à negociação, poderão ser suspensos. E será possível normalizar as posições apenas manualmente.

Uma das situações mais perigosas e arriscadas é quando um robô de negociação começa a comprar e vender incontrolavelmente, fazendo um grande número de pedidos por segundo. Antes de o robô pegar uma posição grande ou encerrar uma comissão, essa proteção deve funcionar. No mínimo, ela deve conceder tempo extra para que outros mecanismos de proteção possam funcionar.

Essas verificações são realizadas em vários níveis:

1. No nível do conector.A proteção do conector "desacelera" os aplicativos quando a frequência de exposição se aproxima do máximo. Isso é necessário para não perder o acesso à troca. Como essas medidas são extremas, é importante calcular corretamente a carga no conector com antecedência.

2. No nível de uma estratégia de negociação. Se o algoritmo exceder seu limite na frequência dos aplicativos de arquivamento, será forçado a parar com um erro. Nesse caso, todos os aplicativos ativos enviados anteriormente são removidos.

4. Integração do gerenciamento de riscos na solução arquitetônica

A integração do gerenciamento de riscos pode ser dividida em duas partes principais (ver Fig. 2):

O PRÉ-COMÉRCIO inclui controle básico de pedidos, controle de preço e volume do pedido, controle de alterações no saldo e posição antes do envio do pedido, o comportamento dos pedidos também é analisado aqui.
O POST-COMÉRCIO inclui verificações de interrupções de conexão e a correção dos dados de mercado, é realizado o monitoramento constante das mudanças na balança e nas posições atuais, o comportamento dos pedidos também é analisado aqui.

FIG. 2. O esquema de integração do gerenciamento de riscos na solução arquitetural do servidor de negociação.

5. Log e relatório

Não se esqueça que situações fora do padrão também ocorrem e hoje elas não podem ficar sem a intervenção humana, mesmo em sistemas altamente automatizados. Portanto, se algo der errado, você deve notificar imediatamente todas as partes interessadas (comerciantes, desenvolvedores, gerente) enviando automaticamente mensagens por correio, sms, telegramas ou de qualquer outra maneira conveniente. Idealmente, sempre deve haver um trader de serviço que monitora o desempenho do sistema de negociação.

No caso de uma falha, você precisa encontrar rapidamente o problema, corrigi-lo e retornar o sistema de negociação para o trabalho. Para fazer isso, é necessário manter registros comerciais e do sistema detalhados, especialmente em sistemas altamente carregados com um grande fluxo de aplicativos. Se as causas da falha não forem encontradas, a próxima falha poderá ser fatal. A troca, por via de regra, não perdoa erros e pune imediatamente o rublo.

Conclusão

Normalmente, o gerenciamento de riscos para os algoritmos de negociação começa a "se firmar" no último turno, quando ocorrem alguns incidentes e chegou a entender que você não pode ficar sem ele.

Assim como as precauções de segurança são escritas em sangue, o gerenciamento de riscos nas negociações algorítmicas é escrito em chamadas de margem e contas mescladas.

No entanto, se você criar corretamente um sistema de negociação e configurar o gerenciamento de riscos, poderá dormir em paz e ter certeza de que “ Algotrader está dormindo - o comércio está ativo! ” Boa negociação para

todos!

Como não perder todo o dinheiro em alguns minutos ou gerenciamento de riscos em negociações algorítmicas