Um checklist dos riscos dos robôs antes de operar em conta real - página 2
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
OLá, figurelli.
Anteriormente esqueci de parabenizar pelo bom tópico. Agora fica o registro.
A fim de facilitar a leitura do tópico, começo pelo item:
O conceito compreendi, mas como tratá-lo...
Olá Elmo, obrigado, esse item 3, apesar de impactar mais na BM&FBovespa, é muito importante também no mercado Forex.
Quanto ao Forex, e quando o MT5 está roteando ordens para corretoras nesse mercado, existe um maior controle devido à arquitetura ser distribuída, ou seja, a comunicação e as decisões são diretamente no ambiente cliente (sua a plataforma MT5) e servidor MT5 na corretora.
Na BM&FBovespa ou outra bolsa qualquer habilitada para rotear ordens do MT5 e centralizar as informações, é necessário que o servidor do MT5 esteja comunicando-se com o servidor da bolsa diretamente ou através de um roteamento intermediário, utilizando um sistema chamado de OMS ou Order Management System certificado pela Bovespa. Geralmente essa comunicação se dá através de um protocolo de padrão internacional, como o FIX, UMDF, FAST, etc. A decisão das ferramentas e plataformas no nível servidor é da corretora, assim como do provedor de dados (market data), sendo que muitas vezes (principalmente no nosso país) se herda muita coisa do passado para diminuir os riscos de mudanças (o que nem sempre é a melhor decisão, pois as vezes é melhor começar do zero, principalmente quando se trada de operações financeiras).
Mas vamos abstrair essas questões muito técnicas da arquitetura de roteamento de ordens para facilitar o entendimento, até porque na prática essa é uma visão da camada bem acima, seria necessário detalhar muito mais do que acontece nas camadas abaixo, e pode ter certeza que os problemas e complexidade aumentam bastante quanto mais se entra nesses detalhes.
Nesse caso você pode olhar para seu EA rodando no MT5 como um cliente de um sistema dentro de uma caixa preta que será responsável pelo roteamento de ordens.
Suponto que o EA e a plataforma MT5 estejam 100% afinadas, se esse sistema fechado não se comportar a contento o impacto estará tipicamente na execução correta das ordens comandadas pelo EA e na leitura dos preços/volumes recebidos do provedor de market data.
No item 3 estou reforçando que a plataforma MT5 não tem como emular todas as condições de roteamento e leitura de preços/volume reais. Digamos que uma plataforma desse nível, até chega próxima da fronteira do que é possível, mas ela não pode criar facilmente um modelo genérico que atenda todas características específicas de cada mercado, com todos seus riscos intermitentes, uma vez que lá na camada de baixo o que temos é sempre um projeto de cada corretora e/ou bolsa, implantados de acordo com a vontade de seus projetistas.
Como a responsabilidade de criar mecanismos de tolerância a falhas é do desenvolvedor do EA, e a responsabilidade final por escolher ativar o EA em uma conta real é sempre do cliente final, tanto um como o outro devem estar atentos que ao fazerem backtestings ou testes em conta demo na plataforma, estão apenas testando suas estratégias, mas não as condições reais de latência de execução de ordens e precisão dos preços/volumes, algo que será apenas resultado de uma emulação feita na plataforma.
Mesmo em testes em contas reais (que deveriam ser a última etapa do processo), o tempo ainda é uma variável importante para a descoberta de problemas, e por isso sempre recomendo a clientes começarem testando com saldo em conta o mais baixo possível (por exemplo, hoje é possível operar com mini-índice com valores tão baixos quanto 1K).
Bem, espero que esse longo texto ajude a visualizar esse item do nosso checklist.
Talvez alguém lendo todo esse texto possa afirmar: puxa, isso tudo é paranoia! Mas da minha experiência com robôs e sistemas quantitativos, as vezes é melhor ser um pouco ou até muito paranoico, e depois apenas constatar que assim fomos, do que o contrário, e depois nos arrependermos por falhas e erros cometidos, que muitas vezes não conseguimos mais recuperar.
Seja como for, estamos aqui para trabalhar e explorar mais qualquer um desses pontos.
Olá Elmo, obrigado, esse item 3, apesar de impactar mais na BM&FBovespa, é muito importante também no mercado Forex.
...Mesmo em testes em contas reais (que deveriam ser a última etapa do processo), o tempo ainda é uma variável importante para a descoberta de problemas, e por isso sempre recomendo a clientes começarem testando com saldo em conta o mais baixo possível (por exemplo, hoje é possível operar com mini-índice com valores tão baixos quanto 1K)....
Bem Figurelli, na minha "santa ignorância", resumindo tudo o que vc escreveu, somente existe uma maneira prática de testar a latência de um EA em conta real... é simplesmente operando numa conta real correndo o menor risco de perda possível.
Em termos prático e para estudo de situação da funcionalidade do EA, acho que seria interessante comparar resultados referente a questão do item 3 colocando o EA para funcionar simultaneamente numa conta real e numa conta demo, na mesma configuração, iniciando a operação no mesmo horário e mesmo timeframe. Colocando também nos sinais mql5 para comparar as estatísticas (como vc já mesmo frisou em outras oportunidades, o serviço de sinais também é um excelente laboratório para testes de sistemas de negociação)
Bem Figurelli, na minha "santa ignorância", resumindo tudo o que vc escreveu, somente existe uma maneira prática de testar a latência de um EA em conta real... é simplesmente operando numa conta real correndo o menor risco de perda possível.
Em termos prático e para estudo de situação da funcionalidade do EA, acho que seria interessante comparar resultados referente a questão do item 3 colocando o EA para funcionar simultaneamente numa conta real e numa conta demo, na mesma configuração, iniciando a operação no mesmo horário e mesmo timeframe. Colocando também nos sinais mql5 para comparar as estatísticas (como vc já mesmo frisou em outras oportunidades, o serviço de sinais também é um excelente laboratório para testes de sistemas de negociação)
Olá Paulo, perfeitamente, para testar mesmo somente com a conta real, mas para criar proteções prevendo possíveis problemas reais podemos e devemos, no meu entender, pensar e fazer bem antes nos nossos EAs.
Bem, então entramos em outras questões.
Quais seriam em termos práticos estes problemas? Qual a proteção contra este problema? Para cada estratégia seria uma solução diferente? OU poderíamos criar uma função especifica padrão para todos os EA?
Exemplo: quero um EA que funcione sem Stop Loss ( estratégia de reversão muito comum com indicadores estocásticos com aumento de lote em cada reentrada de preço até o momento em que o preço alcança o TP ou um sinal para posição contrária), mas a rede de internet não é 100% estável, então pode acontecer do meu terminal ficar fora do ar e a minha conta quebrar antes de religar. Então eu crio no meuu EA um Stop Móvel ao contrário que nunca vai ser alcançado enquanto o EA estiver em funcionamento. Toda vez que o preço está próximo 200 Ticks (20 pips no meu entendimento) do Stop Loss o EA lança novo SL, de modo que ele nunca vai ser alcançado, mas esta lá e se der um problema no terminal, vou ter um prejuízo calculado.
Este é um exemplo de proteção que posso colocar em todos os EA que eu escrever e que não tenha um SL definido, ou existe o SL, porém é realizado pelo próprio EA sem aparecer para a corretora, aqui teríamos dois SLs, o da estratégia que não aparece para a corretora e o SLSecurity que aparece para a corretora e que nunca será alcançado, talvez somente em caso de pane do terminal. Este último exemplo serve também como uma proteção contra derrapagem que pode ser colocado em todos os EAs.
Será que não teria uma função de proteção universal contra a latência de uma conta real ?
Bem, então entramos em outras questões.
Quais seriam em termos práticos estes problemas? Qual a proteção contra este problema? Para cada estratégia seria uma solução diferente? OU poderíamos criar uma função especifica padrão para todos os EA?
Exemplo: quero um EA que funcione sem Stop Loss ( estratégia de reversão muito comum com indicadores estocásticos com aumento de lote em cada reentrada de preço até o momento em que o preço alcança o TP ou um sinal para posição contrária), mas a rede de internet não é 100% estável, então pode acontecer do meu terminal ficar fora do ar e a minha conta quebrar antes de religar. Então eu crio no meuu EA um Stop Móvel ao contrário que nunca vai ser alcançado enquanto o EA estiver em funcionamento. Toda vez que o preço está próximo 200 Ticks (20 pips no meu entendimento) do Stop Loss o EA lança novo SL, de modo que ele nunca vai ser alcançado, mas esta lá e se der um problema no terminal, vou ter um prejuízo calculado.
Este é um exemplo de proteção que posso colocar em todos os EA que eu escrever e que não tenha um SL definido, ou existe o SL, porém é realizado pelo próprio EA sem aparecer para a corretora, aqui teríamos dois SLs, o da estratégia que não aparece para a corretora e o SLSecurity que aparece para a corretora e que nunca será alcançado, talvez somente em caso de pane do terminal. Este último exemplo serve também como uma proteção contra derrapagem que pode ser colocado em todos os EAs.
Será que não teria uma função de proteção universal contra a latência de uma conta real ?
Oi Paulo, segurança é um processo, sempre existirá um método a mais e diferentes formas de fazer. Portanto para mim o mais importante é ter um processo e ir melhorando ele cada vez mais.
Por exemplo, um item desse processo pode ser analisar o status das posições na carteira, a cada tick se for um teste mais rigoroso e o risco maior, ou a cada minuto se o risco é menor, para ver se todos os valores batem com os definidos e desejados (ou seja, como no teu exemplo, o próprio SL).
Fazendo isso estamos criando um algoritmo de verificação das posições dentro de nosso processo de controle de latência, para garantia de qualidade de execução das operações.
Na prática não existem limites de quantas verificações de segurança a mais você pode criar no seu processo, como não existe quando se tenta proteger um carro contra roubos.
Oi Paulo, segurança é um processo, sempre existirá um método a mais e diferentes formas de fazer. Portanto para mim o mais importante é ter um processo e ir melhorando ele cada vez mais.
Por exemplo, um item desse processo pode ser analisar o status das posições na carteira, a cada tick se for um teste mais rigoroso e o risco maior, ou a cada minuto se o risco é menor, para ver se todos os valores batem com os definidos e desejados (ou seja, como no teu exemplo, o próprio SL).
Fazendo isso estamos criando um algoritmo de verificação das posições dentro de nosso processo de controle de latência, para garantia de qualidade de execução das operações.
Na prática não existem limites de quantas verificações de segurança a mais você pode criar no seu processo, como não existe quando se tenta proteger um carro contra roubos.
Complementando esse comentário anterior, outro ponto que considero importante desse processo, e que acredito que seja o maior problema na área de risco operacional com robôs, é justamente identificar o risco.
Na prática, as pessoas físicas não se preocupam o bastante com os riscos operacionais de seus robôs.
Sequer visualizam esses riscos.
A lista que foi feita até agora é na verdade uma busca de identificar pontos de risco para os Expert Advisors, e toda colaboração nesse sentido é bem-vinda.
Realmente, figurelli, you are the man.
Senti-me como um leigo apreciando um bem elaborado solo de guitarra.
Pois bem. Dando continuidade.
Abraços.
Realmente, figurelli, you are the man.
Senti-me como um leigo apreciando um bem elaborado solo de guitarra.
Pois bem. Dando continuidade.
Abraços.
Olá Elmo, obrigado pelas palavras generosas, não exagera que apesento a conta :-)
Quanto ao item 6, o que queremos verificar é o que acontece se o sistema ficar offline.
Talvez a proteção mais relevante seja nunca operar sem StopLoss (SL), pois essa já é uma forma teoricamente eficaz de se proteger contra problemas de disponibilidade, já que a execução do SL é feita no servidor. na verdade conforme a arquitetura da corretora não há garantia de que o SL fique programado no momento do trade ou apenas seja executado no momento do gatilho do preço, mas isso já é um problema para outros ítens do checklist. Para esse item recomendo também utilizar um VPS em um datacenter de alta disponibilidade, principalmente no nosso país.
Mas mesmo com SL e VPS ainda existem riscos, já que devemos sempre tratar essas situações de excessão, e conforme o tratamento isso pode impactar em perdas, e talvez algumas delas só mesmo uma estrutura com redundância resolva.
Um exemplo típico são os riscos de gaps entre dias, se você opera no intraday e não encerrou as posições por indisponibilidade, pois se, por azar isso ocorrer em uma virada de dia de alta liquidez e volatilidade, o SL não será executado no nível desejado.
Entretanto, no backtesting e operação em conta demonstração, isso dificilmente é emulado, passando a impressão ao trader de que está seguro e livre de problemas de indisponibilidade.
3: Foram feitos testes de situações de latência em conta real que não são visualizadas nas simulações em contas demonstração e no backtesting
A corretora que está trazendo o MT5 para o Brasil possui servidores no Data Centers da Alog que é do lado da BMF & Bovespa para reduzir a latência do envio de ordens e ter um ambiente estável ( sem queda de internet e falta de energia) basta contratar um cloud server público a versão com o custo mais baixo fica algo em torno de 500 reais, com isso a latência do envio de ordem ficará por volta de 5ms (milissegundo) o que já fica interessante.
4: Existe limitação de lote encaminhado por falha ou erro do EA?
Um dos maiores problemas que pode acontecer com um EA é ele sair disparando dezenas de ordens, às vezes várias no mesmo segundo e com isso o trader ter um prejuízo gigantesco, uma das formas de evitar isso é utilizar o comando Sleep após uma ordem ser enviada para o mercado, pois o EA precisa de um tempo para verificar sua nova posição no mercado essa informação é enviada do servidor da corretora, mas existe um risco nisso que o servidor demore mais que o tempo estipulado por você no comando Sleep . Por exemplo:
trade.buy
Sleep(1000) // tempo em milissegundos
return;
Se o servidor da corretora demorar menos que 1 segundo para responder sua nova posição atual para a plataforma não vai acontecer nenhum envio de ordem em duplicidade, caso demore mais tempo pode acontecer dela enviar mais de uma ordem de compra se a estratégia ainda estiver dando entrada.
Outra forma de fazer isso é travando o envio de ordem pelo próprio código dentro do EA, mas o problema é como fazer isso de forma segura?
Acho que o caminho para desenvolvermos todos esses pontos levantados no tópico é desenvolver um EA comunitário simples e colocar todas as travas necessárias para evitar os problemas elencados no tópico. Poderíamos criar um outro tópico e fazer isso.