Automatização do trading: EA, scripts MQL, cBots e VPS

A automatização transfere tarefas repetitivas para um programa, mas a responsabilidade pelo seu comportamento continua a ser sua. Um Expert Advisor ou cBot precisa de um ambiente de execução definido: um terminal, um VPS ou um serviço na nuvem. Explicamos as diferenças, como diagnosticar erros e proteger a conta após uma desconexão ou reinício. Abordamos também custos de alojamento, latência de execução e verificações necessárias antes de executar um programa numa conta que negoceie com margem.

1. Onde é realmente executado um robô: EA, terminal e servidor do corretor

Um equívoco recorrente na automatização de retalho é «o meu robô negoceia no corretor». Não é assim. Um Expert Advisor no MetaTrader é um programa compilado que corre no processo do terminal. O terminal recebe o fluxo de cotações do servidor do corretor, executa o código do robô nos eventos sucessivos e envia solicitações de negociação prontas. O corretor valida-as e executa-as ou rejeita-as. Tudo o que o robô «sabe» e «recorda» reside no ambiente de execução.

A cadeia a ter presente em qualquer análise de falhas é esta:

Código do EA → terminal (ambiente de execução) → servidor do corretor → validação da ordem → execução ou rejeição → resposta do servidor → registo e estado do EA

Cada elo pode falhar independentemente e de forma diferente. Um erro de lógica afeta o primeiro. Fechar o terminal interrompe a lógica local e novas solicitações; o corretor continua a tratar as ordens já guardadas no servidor. Uma ordem rejeitada é um problema no quarto elo, embora se manifeste como «o EA não abriu uma posição». A infraestrutura real do corretor e do fornecedor de alojamento é muito mais complexa: esta cadeia é um modelo de trabalho, não um diagrama de rede.

Os eventos a que o código reage. No MT4 e MT5, um programa de negociação é orientado a eventos. OnInit() é executado no arranque: aqui devem ser validados os parâmetros de entrada e preparado o estado. OnTick() é acionado pela cotação seguinte do instrumento ao qual o robô está associado. OnDeinit() é executado quando o programa é removido do gráfico, os parâmetros mudam ou o terminal fecha. OnTimer() para ações periódicas e OnChartEvent() para interagir com o gráfico existem em ambas as linguagens; a documentação MQL4 apresenta ambas as funções com assinaturas completas, juntamente com OnInit(), OnTick() e OnDeinit() [10]. A diferença entre os ambientes está na camada de negociação: o MT5 acrescenta eventos que não existem no MQL4: OnTrade() e OnTradeTransaction() para reagir a alterações do estado da conta [14]. Separadamente, fora da camada de negociação, o MT5 dispõe também de OnBookEvent() — um evento de dados de mercado que, segundo a documentação, trata alterações na profundidade de mercado, ou seja, no livro de ordens [14]. Só funciona onde é disponibilizada profundidade de mercado: a existência do livro depende do instrumento e do corretor e, nas contas forex de retalho, muitas vezes está simplesmente ausente. Isto não é um curso de programação, mas o mínimo necessário para compreender quando o seu código tem oportunidade de agir.

A consequência prática é incómoda: OnTick() não é um relógio. O número de chamadas depende das cotações recebidas e do processamento da fila de eventos. No MQL5 não é acrescentado um novo evento NewTick enquanto outro já estiver na fila ou a ser processado[25]. Dois corretores podem fornecer números de ticks bastante diferentes para o mesmo par, porque filtram o fluxo de forma diferente e usam outras fontes de liquidez. Uma lógica que pressupõe uma frequência de chamadas «mais ou menos constante» depende, na realidade, do corretor e do tipo de conta e transfere-se entre corretores pior do que o código idêntico sugere.

O que permanece quando o terminal se desliga

Esta distinção salva contas e é, ao mesmo tempo, aquela em que reaparece a simplificação falsa «no MT4 tudo fica do lado do cliente».

Os níveis de stop loss e take profit associados a uma posição ou ordem pendente são guardados no servidor do corretor e funcionam independentemente de o terminal estar em execução. O trailing stop integrado na interface do MetaTrader funciona ao contrário: é calculado localmente com as cotações recebidas e deixa de mover o stop quando a plataforma fecha. Isto aplica-se tanto ao MT4 como ao MT5, mas cada plataforma tem uma fonte separada: a ajuda do MetaTrader 4 descreve-o como um mecanismo executado no terminal cliente e não no servidor, que deixa de funcionar quando o terminal é desligado [8], enquanto a ajuda do MetaTrader 5 repete a mesma regra: o trailing stop é executado na plataforma, não no servidor como o stop loss [11]. São necessárias duas precisões, sem as quais a afirmação se torna falsa. Primeiro, fechar o terminal interrompe o ajuste do nível, mas não cancela a última alteração que conseguiu enviar: esta permanece no servidor e continua a proteger a posição. Segundo, a descrição não deve ser alargada a todas as plataformas. No cTrader o mecanismo é diferente: a ajuda do fornecedor indica que todas as proteções funcionam nas várias aplicações e permanecem ativas após o fim da sessão [22], e a página do painel Trade Watch afirma expressamente que o trailing stop loss funciona mesmo com a aplicação cTrader fechada ou sem ligação [23]. A condição é, portanto, mantida fora da aplicação do utilizador, que não precisa de estar em execução. O mesmo nome designa dois modelos de funcionamento diferentes; por isso não se devem transportar hábitos de uma plataforma para outra. A fronteira entre ordem no servidor e função local é explicada mais amplamente no artigo 11.4 [situação em 2026-08-22; confirme as funções oferecidas pelo seu corretor concreto na documentação deste].

O terceiro caso é perigoso e recorrente em código amador: um stop loss «virtual» guardado apenas numa variável do EA. Para o corretor não existe. Se o processo do terminal terminar inesperadamente, a posição fica sem proteção além dos mecanismos da conta. Antes de presumir que tem um stop loss, verifique na janela de posições se o nível é visível no servidor, não apenas no gráfico ou no registo do robô. Os níveis permitidos e as distâncias mínimas de SL e TP dependem da especificação do instrumento em cada corretor; por isso, o mesmo código pode ser aceite numa conta e rejeitado noutra.

Automatização total e parcial

Um robô não tem de decidir a entrada para ser útil. A automatização parcial —mover o stop para break-even, gerir a dimensão da posição ou fechar parte do volume num nível definido— cobre precisamente o fragmento do processo executado de forma inconsistente à mão. O código é mais curto, há menos possibilidades de erro e o diagnóstico é mais simples. A automatização total, do sinal à execução, é um projeto de uma ordem de responsabilidade completamente diferente.

Ambas as variantes partilham uma condição: as regras têm de poder ser expressas sem ambiguidade. Se entrada, saída e risco exigirem julgar a «qualidade» de uma configuração, não tem um sistema para automatizar, mas uma opinião sobre o mercado. Um sistema automático executa uma especificação defeituosa com a mesma consistência de uma boa, apenas mais depressa e sem pausas. Se as regras têm sequer valor esperado positivo é tema do material sobre vantagem e valor esperado; aqui tratamos apenas de executar essa especificação de forma segura.

2. Indicador, script, EA e cBot: quatro classes diferentes de ferramentas

O pedido «procuro um script que negoceie por mim» aparece regularmente e costuma significar algo diferente do que parece. Um script no MetaTrader tem efetivamente acesso às funções de negociação e pode enviar muitas operações numa só execução; «um script que negoceia» não é uma contradição em si. A contradição está noutro ponto: um script tem um único ponto de entrada, OnStart(), e termina com essa função, pelo que não pode vigiar o mercado durante uma semana. Os três tipos de programa do MetaTrader diferem no ciclo de vida e no âmbito de acesso; no cTrader a divisão é diferente.

Separar o acesso é uma vantagem, mas a garantia resultante é mais limitada do que normalmente se afirma. Um indicador não tem acesso às funções de negociação e não envia uma ordem sozinho: é apenas isso que se pode concluir. Não significa que um erro seu seja inofensivo: se um EA ler o seu buffer e decidir com base nele, um valor mal calculado transforma-se numa operação errada enviada pelo EA. A arquitetura correta mantém-se: o indicador calcula e disponibiliza o resultado num buffer; o EA lê-o e decide. Assim, análise e execução ficam separadas e cada camada pode ser testada individualmente, desde que também se teste o conteúdo do buffer, não apenas a lógica do EA.

No cTrader a divisão é diferente e não tem correspondência direta. O equivalente de um EA é um cBot; o de um indicador, um indicador. Não existe uma categoria separada de «script»: uma operação pontual é realizada por um cBot que faz o trabalho no método de arranque e se para sozinho.

Três erros que custam tempo:

• Esperar que um indicador negoceie. Um indicador no MetaTrader não tem acesso às funções de negociação. Um produto anunciado como «indicador que negoceia sozinho» não é um indicador ou utiliza um programa separado em segundo plano; é o código desse programa que responde pelas suas ordens
• Usar um EA quando bastaria um script. Fechar todas as posições numa só execução é tarefa de um script. Um EA associado ao gráfico continuará ativo, a reagir a novas cotações e a exigir supervisão
• Um monólito em vez de módulos. Um programa que executa cinco estratégias, vigia o risco da conta, desenha e envia notificações ao mesmo tempo é mais difícil de diagnosticar. Um sistema automático por estratégia e um supervisor de risco separado permitem desligar o conjunto por partes

Antes de escrever um robô, escreva um script informativo. Não por ser um exercício de principiante, mas porque um programa deliberadamente sem qualquer chamada de negociação permite verificar se lê corretamente os dados do ambiente: símbolo, cotações, custo e fundos disponíveis. Se as leituras estiverem erradas, o robô baseará nelas todas as decisões.

O que se segue não é um programa para compilar, mas um esquema estrutural: ordem das verificações e nomes das funções MQL4 para usar na sua implementação. Não o copie e execute como um ficheiro pronto. Não foi validado por compilação nem por testes numa conta de corretor. A compilação verifica a sintaxe, mas, por si só, não confirma leituras, permissões ou comportamento no ambiente escolhido. Mantenha a sequência, escreva uma implementação completa e verifique os resultados numa conta demo; o registo desse teste permite avaliar o comportamento do programa.

ESQUEMA ESTRUTURAL – diagnóstico do ambiente antes de escrever um robô
Notação orientadora para MQL4. Não é código completo e compilável.

ponto de entrada: OnStart() – execução única, termina com a função

1. symbol   := Symbol()
   Nunca fixe o nome no código: o sufixo do corretor altera-o.

2. bid, ask := MarketInfo(symbol, MODE_BID / MODE_ASK)
   point    := MarketInfo(symbol, MODE_POINT)
   spread   := if point > 0 then (ask - bid) / point
               caso contrário: leitura por resolver
   Um ponto zero significa falha na leitura da especificação, não
   spread zero: os dois casos exigem registos diferentes.

3. lotMin   := MarketInfo(symbol, MODE_MINLOT)
   lotStep  := MarketInfo(symbol, MODE_LOTSTEP)
   Propriedades do instrumento nesse corretor, não constantes da linguagem.

4. no diário: symbol, bid, spread, lotMin, lotStep,
   OrdersTotal(), AccountFreeMargin()

5. tradePossible := IsTradeAllowed()
   Rótulo no registo: negociação possível neste momento.
   Não: trading automático autorizado; veja o parágrafo seguinte.

O que este esquema não contém nem deve conter:
   nenhuma chamada a OrderSend, OrderClose ou OrderModify.

Três elementos do esquema reaparecem em qualquer robô posterior: nome do símbolo lido do ambiente em vez de fixado no código, incremento de volume lido da especificação e verificação explícita de que é possível negociar naquele momento. O último ponto exige corrigir uma simplificação comum. IsTradeAllowed() não responde apenas à questão da autorização para automatizar: a documentação MQL4 descreve-o como uma verificação de que o Expert Advisor pode negociar e o contexto de negociação não está ocupado [15]. Um resultado false pode significar falta de autorização ou contexto ocupado, ou seja, um estado transitório que passará sozinho. Registe separadamente o resultado e a causa determinada por uma verificação adicional; caso contrário, o diagnóstico «negociação desativada» será aplicado a algo que não está desativado. A secção de falhas em produção retoma as três leituras.

3. MQL4 e MQL5: dois ambientes, não duas versões de um só

A simplificação «MQL5 é MQL4 com mais funções» é falsa precisamente onde importa na prática: no modelo de ordens e posições. Convém eliminar outro mito: MQL4 não é uma linguagem puramente procedimental; a documentação MetaQuotes descreve classes, herança, funções virtuais e templates [1]. A diferença não está, portanto, no paradigma de programação, mas na interface de negociação, na leitura de indicadores e na forma como a plataforma representa a exposição aberta.

A camada de negociação. No MQL4 uma única função, OrderSend(), abre uma posição, enquanto OrderSelect() muda o contexto para o elemento seguinte de uma lista comum a ordens pendentes e posições abertas. No MQL5 os conceitos são separados: ordem, posição e negócio histórico são distintos. Enviar uma solicitação implica preencher uma estrutura e verificar a estrutura devolvida com o código de resposta do servidor; classes da biblioteca padrão, como CTrade são uma camada conveniente sobre esse mecanismo, não um modo de funcionamento separado [2].

A camada de dados. No MQL4, uma chamada ao indicador devolve o valor da vela indicada. No MQL5 devolve um identificador de recurso criado uma vez, normalmente em OnInit(); os valores são depois copiados para um array por uma função de cópia do buffer. Uma transposição literal do código cria um novo identificador a cada cotação em vez de reutilizar o existente. O compilador não o assinala: o erro está no local de criação, não na sintaxe. É uma armadilha clássica de migração precisamente porque não surge de imediato.

A linha do modo de contabilização merece uma explicação porque provoca falhas inesperadas. Netting significa uma posição líquida por instrumento: uma ordem contrária não abre outra posição, mas reduz ou inverte a existente. Um robô migrado do MT4 que pressuponha várias posições independentes no mesmo símbolo começará, neste modo, a fechar as próprias entradas. O modo é definido pelo corretor; não é o «comportamento padrão do MT5», mas uma propriedade da conta concreta que deve ser verificada antes da entrada em funcionamento, de preferência lida no código.

Quando faz sentido migrar. Quando o ambiente antigo limitar realmente o trabalho: precisa de testes multimoeda, testes forward no testador, um modelo de ticks mais exato ou instrumentos que o corretor não oferece no MT4. Ser «mais nova» não basta: reescreve a camada de negociação e a leitura dos indicadores, introduzindo novos erros num código que funcionava. O tempo depende da dimensão do sistema; não há uma duração que possa ser dada honestamente para todos. Se migrar, compare os resultados operação a operação, não o total. Um total igual com uma lista de operações diferente significa que duas lógicas distintas produziram por acaso resultados semelhantes.

O MT5 também oferece otimização distribuída paga na rede de cálculo MetaQuotes. Mais capacidade significa, porém, mais combinações de parâmetros testadas e aumenta diretamente o risco de sobreajuste ao passado. A metodologia —divisão dos dados, custos e número de variantes— pertence ao artigo sobre demo, backtesting e testes forward e é aí tratada integralmente.

4. cTrader Algo: C#, Python e execução local e na nuvem

Nesta secção é especialmente fácil repetir uma descrição desatualizada: os materiais antigos chamam ao ambiente de automatização cAlgo ou cTrader Automate e apresentam-no como exclusivo de C# e de execução local. Ambas as afirmações são hoje falsas.

Segundo a documentação oficial Spotware, o ambiente chama-se cTrader Algo e permite criar algoritmos em duas linguagens: C# e Python [3]. Os cBots podem ser executados localmente ou na nuvem. A documentação da nuvem indica expressamente que um cBot corre num ambiente isolado fornecido pelo cTrader e que a aplicação do utilizador —Windows, Mac, móvel ou navegador— não precisa de permanecer aberta nem ligada à internet [4]. Isto altera todo o cálculo de alojamento tratado mais adiante neste artigo.

Limites de execução na nuvem em 2026-08-22. A documentação indica até dez instâncias simultâneas em funcionamento contínuo numa conta real e uma instância numa conta demo, que para automaticamente no máximo após sete dias. Refere ainda que as regras podem variar conforme o corretor e que os cBots com pacotes externos funcionam na nuvem se cumprirem condições adicionais [4]. Trate estes números como o estado do produto no dia da publicação e confirme-os antes de basear neles uma arquitetura.

Estrutura de um cBot. O programa herda de uma classe base de robô. O método de arranque corresponde à inicialização conhecida do MQL, o tratamento da cotação seguinte corresponde a OnTick(), e o método de paragem à desinicialização. Uma diferença útil é o suporte nativo ao evento de fecho da vela: no MetaTrader tem de o detetar comparando a hora de abertura da vela atual com a memorizada.

Open API não é REST. Convém precisar porque nas fontes secundárias circula a simplificação «o cTrader tem uma API REST». A documentação Spotware descreve a troca de dados da Open API através de objetos JSON ou Google Protocol Buffers [5]. FIX API é um serviço separado. As permissões, disponibilidade e condições de ligação dependem do corretor; planeie a integração depois de ler a documentação do fornecedor concreto, não a descrição geral da plataforma.

Escolher um ambiente não é escolher «a melhor plataforma». Se o corretor só oferece um, a decisão já está tomada. Se oferece ambos, o critério é prático: em qual consegue escrever e manter código cujo comportamento compreenda e como quer resolver a continuidade de funcionamento. A linguagem, por si só, não cria uma vantagem: altera o custo de manutenção e o número de erros que cometerá.

Um webhook como ponte para outros sistemas

A segunda via de automatização não passa por código executado dentro da plataforma: um evento externo, como um alerta de uma plataforma de gráficos, envia uma solicitação HTTP para um endereço acordado e uma aplicação intermediária converte-a numa chamada à API do corretor. A cadeia passa a ser evento → webhook → aplicação intermediária → API do corretor → validação → ordem → resposta do servidor, e o webhook cobre apenas um elo: enviar a solicitação. Entrega não significa execução: recebê-lo corretamente nada diz sobre se o volume respeitava a especificação, havia margem livre ou o servidor aceitou a ordem. Cada ponto intermédio acrescenta latência e um modo de falha próprios, incluindo a repetição da solicitação após restabelecer a ligação. O endereço do webhook deve ser protegido, mas conhecê-lo não pode substituir a autorização: o intermediário tem de validar o remetente, a atualidade da solicitação e o seu identificador único. A configuração de alertas na plataforma de gráficos pertence a um artigo separado; aqui importa apenas onde fica esta ponte na cadeia e o que não garante.

5. Permissões, compilação, registos e identificação das posições próprias

«O robô não negoceia» é uma queixa habitual na automatização de retalho e pode nada ter a ver com a estratégia. Antes de depurar as condições de entrada, verifique quatro coisas: se o programa está compilado, associado ao gráfico certo, autorizado a negociar automaticamente em todos os níveis e o que o diário registou exatamente.

Compilação e localização dos ficheiros

O código-fonte no MetaEditor tem uma extensão de texto, mas ao gráfico é associado um ficheiro compilado. Os ficheiros têm de estar na pasta de dados da plataforma, na subpasta do tipo de programa, caso contrário não serão visíveis. Abra a pasta de dados pelo menu: normalmente não é a de instalação, por isso não o pressuponha. Depois de copiar, atualize a lista no navegador. Leia os avisos do compilador: uma conversão implícita de tipos em código de negociação pode truncar o volume para zero.

Três níveis de autorização para trading automático

Autorizar o trading automático não é um único interruptor. O primeiro nível é a definição global da plataforma: o botão de negociação algorítmica na barra. O segundo são as propriedades do programa ao adicioná-lo ao gráfico. O terceiro está fora do seu controlo: a conta. O corretor pode bloquear a automatização num tipo de conta ou restringir toda a negociação, por exemplo numa conta de leitura. Um robô que não verifique estas condições apenas comunicará uma ordem falhada, sem indicar a causa.

Segue novamente um esquema estrutural, não um ficheiro para compilar, desta vez para MQL5. Mostra a sequência de permissões e normalização do volume, mas não é uma implementação validada. Compilar, por si só, não determina o comportamento numa conta concreta: verifique também as respostas do terminal, propriedades do símbolo e permissões com ligação ao corretor. Este artigo não apresenta esse teste. Use o esquema como base para as suas verificações, não como módulo pronto para negociar. Não contém qualquer chamada que envie uma ordem.

ESQUEMA ESTRUTURAL – permissões e normalização do volume
Notação orientadora para MQL5. Não é código completo e compilável.

A. É PERMITIDO NEGOCIAR? Quatro leituras, cada uma com o seu registo

   TerminalInfoInteger(TERMINAL_TRADE_ALLOWED)
      false -> negociação algorítmica desativada na plataforma
   MQLInfoInteger(MQL_TRADE_ALLOWED)
      false -> negociação desativada nas propriedades do programa
   AccountInfoInteger(ACCOUNT_TRADE_ALLOWED)
      false -> negociação bloqueada na conta
   AccountInfoInteger(ACCOUNT_TRADE_EXPERT)
      false -> o corretor não permite aqui trading automático

   Só é permitido negociar se as quatro leituras forem true.
   O registo tem de indicar qual falhou; caso contrário,
   o diagnóstico termina em «o robô não negoceia».

B. NORMALIZAR O VOLUME À GRELHA DO INCREMENTO

   entrada: symbol, vol
   saída: múltiplo do incremento ou 0.0 para «não enviar»

   B1. if not MathIsValidNumber(vol) or vol <= 0.0
          -> registar o erro e devolver 0.0
       As comparações normais não rejeitam NaN com fiabilidade.
       Valide explicitamente que a entrada é finita antes
       do cálculo; caso contrário, o resultado pode continuar inválido.

   B2. ler a especificação com a variante que devolve o estado:
          SymbolInfoDouble(symbol, SYMBOL_VOLUME_MIN,  vmin)
          SymbolInfoDouble(symbol, SYMBOL_VOLUME_MAX,  vmax)
          SymbolInfoDouble(symbol, SYMBOL_VOLUME_STEP, vstep)
       qualquer leitura false ou vstep <= 0.0
          -> registar _LastError e devolver 0.0
       A variante que só devolve um número não assinala o erro
       e devolve um zero indistinguível de um zero real.

   B3. TOL   := 1e-8            tolerância da divisão binária
       steps := MathFloor(vol / vstep + TOL)
       result := NormalizeDouble(steps * vstep, 8)

       A pós-condição prometida, e apenas esta:
         o resultado é um múltiplo inteiro do incremento;
         não excede a entrada em mais de
         TOL * vstep.
       Não promete que nunca ultrapasse a entrada.

   B4. if result > vmax
          -> result := NormalizeDouble(MathFloor(vmax / vstep + TOL) * vstep, 8)
       if result < vmin
          -> devolver 0.0
       A ordem importa: mínimo e máximo só são verificados
       num valor já alinhado à grelha do incremento.

Esta segunda função parece um pormenor, mas explica toda uma classe de rejeições. O incremento, mínimo e máximo de volume são propriedades do instrumento em cada corretor e diferem entre contas. A dimensão calculada a partir do risco quase nunca coincide exatamente com o incremento permitido; o servidor rejeita um volume inválido em vez de o arredondar por si.

Dois pormenores merecem explicação: ambos pertencem à classe de erros descrita nos avisos do compilador, em que o código funciona mas o resultado difere silenciosamente do calculado. Primeiro, o volume é obtido contando incrementos inteiros e multiplicando-os pelo incremento, não arredondando para um número fixo de casas decimais. Duas casas transformariam 0,003 em zero com um incremento de 0,001, existente em contas cent e alguns CFD. Obter as casas pelo logaritmo do incremento falha quando este não é uma potência de dez: com incremento de 0,25, um volume de 1,75 é arredondado para 1,8, que não é múltiplo do incremento; o servidor rejeita-o como rejeitaria um volume não normalizado. Segundo, a divisão em vírgula flutuante pode ficar ligeiramente abaixo de um inteiro. Sem uma pequena correção, arredondar por defeito retira silenciosamente um incremento: 0,3 dividido por 0,1 fica abaixo de três e a posição é menor do que o cálculo de risco previa. O mínimo e o máximo verificam-se, por isso, apenas no fim, sobre o valor já alinhado à grelha: arredondar por defeito pode violar um mínimo antes respeitado e limitar ao máximo tem de respeitar a mesma grelha.

Essa correção tem, porém, outro lado que deve ser declarado sem prometer mais do que a função cumpre. Ao somarmos algo antes de arredondar por defeito, o resultado pode ultrapassar minimamente a entrada: com volume 0,2999999995 e incremento de 0,1 devolve 0,3, ou seja, cinco partes em dez mil milhões de um lote a mais. Para os incrementos do exemplo a diferença é desprezável, mas a garantia correta é esta: o resultado é múltiplo do incremento e não excede a entrada em mais do que a tolerância aceite. É um limite deliberado, porque sem ele o mesmo código perde um incremento inteiro com 0,3. Dois casos fáceis de esquecer têm de ser bloqueados separadamente: entrada não finita, que as comparações normais não rejeitam de forma fiável, e falha na leitura da especificação. Por isso o esquema contém MathIsValidNumber() na entrada e a variante de SymbolInfoDouble() que devolve um estado em vez de apenas um número; esta última devolve, em caso de erro, um zero indistinguível de um zero real.

Registos: rasto de diagnóstico básico após uma falha

A plataforma mantém diários separados, o que é útil: o do programa contém as saídas do código e as mensagens de inicialização e remoção; o da plataforma regista entradas, desconexões, reconexões, solicitações e respostas do servidor. O testador tem um diário próprio. As cópias guardadas na pasta de dados sobrevivem a um reinício; só assim é possível reconstruir uma falha noturna.

O robô deve registar pelo menos o momento da decisão com preço e spread, parâmetros enviados, código de resposta do servidor, preço real de execução, cada alteração dos níveis e cada ativação de uma proteção. Sem preço e código de resposta não distingue um erro lógico de uma rejeição do corretor: são problemas completamente diferentes.

Convém estabelecer uma distinção que regressa nas falhas. O diário é o rasto de diagnóstico básico: diz o que o programa fez e viu num dado momento. A fonte de verdade sobre a execução é, porém, o estado da conta e o histórico no servidor do corretor. A distinção deixa de ser académica quando faz falta: com a ligação interrompida, o registo pode terminar num erro de envio quando o servidor já executou a operação. Se houver contradição, prevalece o servidor.

Identificar as posições próprias

O robô tem de responder «esta posição é minha?». Numa conta podem coexistir operações manuais, de outro robô e da mesma estratégia noutro símbolo. Para as identificar atribui-se um identificador numérico no envio da ordem —chamado magic number nos dois ambientes MetaTrader— e usa-se o campo de comentário. A regra prática é simples: cada ciclo sobre posições filtra simultaneamente por identificador e símbolo, nunca apenas por símbolo.

Omitir o filtro custa caro: o robô fechará posições manuais e dois robôs com o mesmo identificador alterarão os níveis um do outro. Numa conta netting é mais difícil, porque uma posição líquida não tem um único dono: o robô deve registar a exposição que atribui a si próprio e reconstruí-la após um reinício pelo histórico, não pelo estado atual.

6. Catálogo de falhas em produção: das reconexões às alterações da especificação do símbolo

Algumas falhas da automatização dizem respeito ao ambiente de execução, não às regras da estratégia. Um backtest padrão não reproduz todas essas situações; algumas exigem testes de falha separados. A lista não reúne raridades, mas situações para as quais tem de estar preparado ao manter um robô ativo durante meses.

Cenário a reproduzir: ordem duplicada após restabelecer a ligação

Descrevemo-lo separadamente porque não pode ser provocado à vontade com um só clique. A redação não o reproduziu: o que se segue não contém resultados de medição nem um registo do ambiente em que se teria medido. Apresenta o mecanismo e instruções para o verificar por si.

Condições. O robô deteta uma condição de entrada e solicita a abertura de uma posição. Enquanto espera pela resposta, a ligação cai. A ordem chegou ao servidor e foi executada, mas a resposta não voltou ao terminal. O robô regista um erro e conclui que não existe posição.

Consequência esperada. Se a condição continuar válida ao restabelecer a ligação, o robô volta a enviar a solicitação. Numa conta hedging surgem duas posições em vez de uma e o risco real duplica o planeado. Numa conta netting os registos são diferentes, mas a exposição também aumenta: cresce a posição líquida, embora o robô continue a vê-la como uma só entrada. É uma conclusão deduzida do mecanismo descrito, não uma leitura de um ensaio realizado.

Como verificar por si. Desligar manualmente a placa de rede «logo após enviar» não é um procedimento, mas uma lotaria. Não controla se a solicitação chegou ao servidor; se não chegou, reproduz outro caso: uma ordem normalmente falhada. Em demo, uma regra da firewall ou ferramenta de diagnóstico pode interromper a ligação de forma controlada, mas confirmar o envio não prova a execução. O cenário só ocorreu se o histórico do servidor confirmar a execução enquanto o terminal não recebeu a resposta. O testador não o reproduz, por isso o ensaio é manual e tem de ser registado. Anote todos os elementos seguintes: sem qualquer um deles, o resultado nada esclarece nem pode ser comparado com um segundo ensaio:

• plataforma, versão do terminal e número de compilação, lidos na janela de informações, não de memória
• corretor, número da conta demo, servidor ligado e tipo de conta —hedging ou netting—, porque a consequência depende disso
• símbolo com o sufixo completo do corretor, volume solicitado e modo de execução do instrumento
• data e hora do ensaio na hora do servidor do corretor, não local
• como foi interrompida a ligação e quando teve efeito em relação ao envio: é o único parâmetro que determina se reproduz este caso ou outro diferente
• resultado: entrada completa do diário do robô comparada com o histórico do servidor. É o histórico que determina se a ordem chegou; o diário do terminal não basta, porque o seu desconhecimento é precisamente o fenómeno estudado
• número de repetições e quantas deram o mesmo resultado; uma só passagem nada prova

Há que corrigir outra receita repetida: o magic number identifica uma estratégia, não uma intenção individual de ordem. Duas solicitações do mesmo robô têm o mesmo número, que sozinho não responde a «esta ordem concreta já foi enviada?». É necessário um identificador persistente de cada decisão, atribuído e registado antes do envio e guardado fora da memória do processo. Só assim distingue, ao reconciliar estados, «não enviei» de «enviei e não sei o que aconteceu». O comentário é um local natural para o transportar na ordem, mas o servidor pode truncá-lo ou substituí-lo: trate-o como pista e resolva comparando os seus registos com o histórico do servidor.

A proteção. A regra é simples e incómoda: a fonte de verdade é o estado da conta, não a memória do robô. Após cada solicitação falhada ou de resultado não confirmado, antes de repetir o programa deve ler as posições atuais e negócios históricos mais recentes, filtrar pelo identificador próprio e verificar se a ordem já existe. Um bloqueio temporal entre envios no mesmo símbolo é um complemento barato, mas não basta sozinho.

O mesmo princípio evita outra classe de acidentes: um robô sem verificação da exposição envia solicitações em cada chamada num mercado rápido. O resultado é uma avalanche de ordens e, no extremo, uma restrição de acesso ao servidor pelo corretor. Verificar o estado antes do envio e limitar as operações por unidade de tempo são condições sem as quais o robô não deve sair da demo.

7. Continuidade de funcionamento: computador, VPS, alojamento da plataforma e cálculo de custos

Um sistema clássico no MetaTrader precisa de um terminal ativo. É a única razão para falar de alojamento: não a velocidade nem o «profissionalismo», mas o facto de um processo desligado nada calcular. A exceção é a via na nuvem do cTrader Algo: se um cBot cumprir as condições, pode não precisar de VPS externo. A ressalva importa porque o mesmo ecossistema permite execução local, e então a questão do alojamento regressa por inteiro. Os limites de instâncias dependem da conta e do corretor, e os pacotes externos só funcionam na nuvem mediante condições adicionais.

O que um computador doméstico acrescenta à equação. Cortes de energia, reinícios após atualizações, falhas da linha de internet, bloqueios do sistema: cada evento interrompe o ambiente e toda a lógica do robô. Não interrompe os níveis SL e TP registados no servidor do corretor. É esta fronteira que tem de conhecer para avaliar quanto perde realmente durante uma falha.

O que um VPS não faz. Não melhora a estratégia nem elimina derrapagem ou rejeições. Não protege de falhas do corretor nem da sua ligação ao fornecedor de liquidez. Não garante continuidade: uma disponibilidade declarada é um compromisso contratual, não uma lei física. Compra uma coisa: retirar o seu hardware e a sua ligação da lista de causas de falha.

Dois produtos diferentes sob um nome

A palavra «VPS» é usada para duas soluções administradas de formas completamente diferentes.

Um servidor virtual com sistema operativo completo é alugado como um computador normal num centro de dados. Liga-se por ambiente de trabalho remoto, instala a plataforma e gere atualizações, arranque automático, monitorização e cópias da configuração. Tem liberdade total para várias plataformas, scripts de supervisão e ferramentas de diagnóstico, e toda a responsabilidade pela manutenção, incluindo a segurança do acesso remoto.

O alojamento integrado na plataforma funciona de outra forma. O MetaTrader VPS é iniciado na plataforma e o ambiente migra com um só comando. Aloja sistemas automáticos ativos e subscrições de cópia de sinais sem exigir administração do Windows ou ligação por ambiente de trabalho remoto [6]. A simplicidade tem um preço: não pode instalar qualquer software e trabalha com recursos impostos.

Cálculo de infraestrutura com um exemplo explícito

Uso os preços anteriores para que o exemplo seja verificável, não apenas ilustrativo. Com pagamento anual, custa 12 × 10 USD = 120 USD por ano. Com pagamento mensal: 12 × 15 USD = 180 USD por ano.

Limito a conclusão a este exemplo. Numa conta da ordem de 2 000 USD, só o alojamento consome vários pontos percentuais de capital por ano antes de spread e comissões e compete com um resultado realisticamente esperado. Numa conta dez vezes maior representa um décimo dessa percentagem. Não demonstra que um VPS «compense» ou não a outra pessoa; apenas que o custo da infraestrutura deve ser calculado face ao seu capital, não ao preço na página do fornecedor.

Escolha de parâmetros e entrada em funcionamento

Um robô que apenas negoceia exige poucos recursos; a carga vem da otimização no testador, que pode ser feita noutro local. A ressalva da tabela importa mais do que o conteúdo: são valores ilustrativos, não medições deste artigo nem requisitos do fornecedor; mostram apenas o que verificar. Meça por si: execute a configuração pretendida durante alguns dias em demo, leia no gestor de tarefas os picos de memória e processador do processo da plataforma e só depois escolha a máquina com essa base.

O mercado divide-se em três categorias, diferentes em quem suporta o custo da manutenção, não no preço. O alojamento do corretor pode ter condições preferenciais com certo nível de atividade: é cómodo, mas prende a um só corretor. Os especialistas colocam servidores em centros de dados usados por corretores FX. As nuvens públicas gerais deixam toda a configuração do seu lado. Não dou nomes deliberadamente: disponibilidade, locais e condições mudam mais depressa do que um artigo e uma lista num texto educativo transforma-se demasiado facilmente numa recomendação.

Lista de verificação da entrada em funcionamento do alojamento:

1. Execute tudo em demo, não por um número fixo de dias, mas até passar por três eventos: reinício forçado, perda e recuperação da ligação, fecho e reabertura do mercado no fim de semana. Só depois mude de conta
2. Programe as atualizações fora do horário e verifique o que acontece após um reinício forçado
3. Configure o arranque automático e a reposição dos gráficos com os programas associados
4. Verifique separadamente se o trading automático está ativo após reiniciar: o arranque da plataforma não o garante
5. Monitorize de forma independente a disponibilidade da máquina e, separadamente, o processo da plataforma; o ping não deteta uma aplicação bloqueada
6. Desative o apagamento do ecrã e a suspensão, configure a rotação dos registos e vigie o espaço livre
7. Proteja o acesso remoto com palavra-passe forte e exclusiva e autenticação multifator se disponível; limite por endereço se possível
8. Guarde cópias dos modelos dos gráficos e parâmetros. Não guarde credenciais em configurações ou notas: use um gestor de palavras-passe
9. Planeie a perda da máquina: de onde restaurará e em quanto tempo

O último ponto é frequentemente ignorado. O alojamento só é uma proteção quando sabe quanto demorará a reconstruir o ambiente e já o testou uma vez com calma.

8. Latência: o que mede exatamente e o que a medição não revela

«Ping de 2 ms» não significa «ordem executada em 2 ms». Convém ler duas vezes, porque a venda de infraestrutura assenta em esbater essa diferença. A latência da cadeia tem vários segmentos, medidos separadamente com ferramentas e precisões diferentes.

As afirmações do alojamento dizem quase sempre respeito ao primeiro ou segundo segmento. Quando a MetaQuotes anuncia acesso do MetaTrader VPS a 96% dos servidores abaixo de 10 ms [6], descreve o segmento de rede. Não permite deduzir quanto demorará o corretor a concluir realmente a operação: depende da política de execução, liquidez disponível e carga do servidor nesse momento.

A única medição que diz respeito à sua conta vem dos seus dados. Registe três horas e dois preços: decisão com o preço visto pelo robô, envio da solicitação e momento e preço de execução lidos da resposta do servidor. Após uma série suficientemente longa terá uma distribuição, não um número da página do fornecedor. Observe a distribuição, não a média: execuções lentas isoladas durante dados ou liquidez escassa pesam mais do que uma mediana tranquila.

Uma ressalva determina se a medição significa algo. As duas primeiras horas vêm do seu computador e a hora da operação no histórico vem do relógio do servidor. Subtraí-las mistura dois relógios e acrescenta um desfasamento desconhecido, invisível no número. Meça a ida e volta localmente com um único contador de alta resolução, da chamada de envio ao regresso da resposta. Anote ao lado a hora do histórico como grandeza separada, não como extremo do mesmo segmento. Sem telemetria do corretor não sabe quanto tempo a solicitação passou dentro da infraestrutura: pode medir o total e comparar períodos, não dividi-lo em etapas.

Para avaliar a sensibilidade da lógica existe o testador MetaTrader 5, que permite emular latência e usar vários modelos de ticks, incluindo ticks reais do corretor [7]. Não mede a sua ligação: verifica se a estratégia sobrevive a condições de execução piores. A metodologia completa pertence ao artigo sobre testes de estratégias.

Quando importa realmente

A resposta vem da aritmética, não das convicções. Para um dado custo, o seu peso aumenta quanto menor for a operação média. Os valores são ilustrativos: assumo um custo total por operação de 2,0 pips, composto por spread, comissão convertida em pips e derrapagem habitual. O custo real obtém-se nas condições da conta e nas suas operações. A latência não entra nem pode entrar nessa soma: não é um custo em pips, mas um parâmetro do modelo de execução. A tabela, portanto, não a mede nem permite conclusões a favor ou contra.

Para um sistema que procura várias dezenas de pips, o exemplo sugere verificar se a latência afeta materialmente os resultados antes de pagar para a reduzir. Se procura poucos pips, latência e derrapagem são um problema da estratégia, não do alojamento, e nenhum servidor o resolve.

Parâmetros de proteção contra más condições de execução

Dois mecanismos pertencem ao código. O primeiro é um filtro de spread: antes de cada decisão, compare-o com um limiar e impeça novas posições se for excedido. Defina o limiar como múltiplo do spread habitual do instrumento no seu horário, não como constante fixa: o mesmo limite não fará sentido noutro símbolo ou corretor.

O segundo é frequentemente descrito como um limite universal do preço de execução, e é precisamente o que não é. O desvio máximo permitido no envio aplica-se a um só modo. A ajuda MetaTrader 4 precisa que o desvio de preço no envio só é utilizado em Instant Execution [18]. A mesma página explica o efeito real do campo, inverso à ideia de «proteção contra derrapagem»: se o desvio for inferior ou igual ao valor, executa ao novo preço sem aviso adicional; caso contrário, o corretor devolve novos preços de execução [18]. Uma alteração dentro do limite é executada ao novo preço sem aviso; a nova cotação, com preços para confirmar, só surge além do limite. No modo de mercado o campo nem existe: a ajuda MetaTrader 5 descreve-o para Instant Execution e afirma o contrário para Market Execution. O corretor decide o preço sem nova consulta e enviar a ordem implica consentir previamente na execução a esse preço [11]. Aqui o corretor fixa o preço e enviar é consentir antecipadamente; o formulário apresenta uma Fill Policy nesse lugar, não um desvio.

O corretor define o modo por símbolo: a primeira pergunta não é «que valor introduzo?», mas «este campo aplica-se ao meu instrumento?», a verificar nas especificações. Se se aplica, escolhe entre dois custos: um limite apertado provoca mais novas cotações e solicitações que não passam à primeira; um amplo reduz novas cotações mas aumenta execuções a preços diferentes do visto na decisão. Trate-o como parte da estratégia, não como definição técnica. Se não se aplica, resta registar a diferença real entre preço da decisão e execução. Vale a pena fazê-lo em ambos os casos.

O terceiro mecanismo é temporal e o mais simples: uma janela sem novas posições. No rollover diário e nas publicações mais importantes, o spread alarga e a liquidez diminui. Bloquear entradas exige poucas linhas, desde que use a hora do servidor e não a local e tenha testado o filtro na mudança de hora.

9. Interruptor de emergência, limites e padrão mínimo de entrada em funcionamento

Um robô sem mecanismo de paragem tem potencial de perda ilimitado dentro da margem disponível. Não por estar mal escrito, mas por não existir uma condição que o pare. O interruptor de emergência não é um extra: é a condição para falar de um sistema gerido, em vez de um programa deixado à sua sorte.

Limites que qualquer sistema automático numa conta real deve ter:

1. Limite de queda do património. Ao ultrapassar uma queda definida desde o máximo do património, o robô fecha as suas posições, confirma pela leitura da conta que nenhuma resta e só então para; se restar alguma, deve manter-se ativo e alertar. O limiar decorre do plano de risco adotado: a metodologia para o fixar pertence ao material de risco; aqui importa que o limiar exista no código e seja verificado antes da lógica da estratégia
2. Limite de perda diária. Contador reiniciado a uma hora do servidor e reconstruído após reiniciar pelo histórico, não guardado apenas em memória
3. Limite do número de posições abertas. Teto rígido independente da lógica de entrada
4. Limite da dimensão de uma posição. Teto aplicado ao resultado do cálculo da dimensão da posição, para que um erro aritmético não se transforme numa ordem de volume desproporcionado
5. Filtro de spread e, se o modo do símbolo o permitir, desvio máximo de preço. Ambos descritos na secção anterior
6. Filtro horário. Janelas sem novas posições
7. Reação a problemas de ligação. Ao detetar desconexão ou cotações antigas, o robô não abre novas posições, mas também não fecha cegamente as existentes: fazê-lo com um preço obsoleto pode ser pior do que esperar

A ordem importa: as condições de segurança ficam no início do tratamento do evento, antes de qualquer entrada. Se forem violadas, o programa não deve abrir nem aumentar exposição; só pode fechar posições próprias e registar o evento. Retomar exige uma decisão humana consciente, nunca um reinício automático após uma espera.

condição de paragem: património atual < máximo patrimonial × (1 − queda permitida) → registar → fechar posições próprias → voltar a contar a exposição própria → remover o programa apenas com zero posições e zero erros de fecho → caso contrário, alertar e manter-se ativo

Segue o último esquema do artigo, o único que toca numa função de fecho. Por isso tem duas barreiras, ambas nos valores predefinidos, não num comentário. Primeiro, a simulação está ativa por defeito: não envia operações, apenas regista o que fecharia. Segundo, antes da primeira cotação lê o tipo de conta e, fora de demo, recusa inicializar até o leitor definir uma confirmação explícita separada. O MQL4 permite essa leitura através de AccountInfoInteger(ACCOUNT_TRADE_MODE), e a documentação distingue entre conta demo, de concurso e real [16]. Uma advertência num comentário não protege; protege um valor predefinido que tem de ser mudado conscientemente para algo acontecer.

ESQUEMA ESTRUTURAL – paragem por queda do património
Notação orientadora para MQL4. Não é código completo e compilável.

DEFINIÇÕES DE ENTRADA – as duas primeiras decidem a segurança

   DryRun := TRUE                            valor predefinido
      O programa não envia operações. Regista o que fecharia:
      número da ordem, volume e preço de referência.
      Para fechar algo, esta definição tem de ser
      alterada manualmente.

   LiveAccountConsent := FALSE                valor predefinido
      Sem isto recusa iniciar numa conta que não seja demo.
      Este consentimento não pode ser dado
      por acidente.

   MagicNumber    – identificador das posições próprias
   MaxDrawdownPct – queda permitida desde o máximo patrimonial
   MaxDeviation   – funciona num só modo de execução;
                    veja o parágrafo abaixo do esquema

ARRANQUE – OnInit()

   mode := AccountInfoInteger(ACCOUNT_TRADE_MODE)
   if mode != ACCOUNT_TRADE_MODE_DEMO
         and not LiveAccountConsent:
      registar: conta não demo, falta consentimento
      terminar inicialização com erro (INIT_FAILED); nada mais
   peak       := AccountEquity()
   stopped    := FALSE
   lastAlert  := 0          hora do último alerta

CADA COTAÇÃO – OnTick()

   if stopped:
      remaining := CountOwnPositions()
      if remaining > 0
            and TimeCurrent() - lastAlert >= 3600:
         registar: estado parado, remaining
         enviar alerta a uma pessoa
         lastAlert := TimeCurrent()
      terminar o tratamento desta cotação
         não repete o fecho sozinho: a tentativa seguinte
         é uma decisão humana executada manualmente
   equity := AccountEquity()
   if equity > peak: peak := equity
   threshold := peak * (1 - MaxDrawdownPct / 100)

   if equity >= threshold:
      ramo vazio: o esquema vigia apenas o limiar
      e não contém qualquer lógica de entrada

   caso contrário:
      stopped := TRUE
      registar: equity, threshold, peak, hora
      errors    := CloseOwnPositions()
      remaining := CountOwnPositions()
      if remaining == 0 and errors == 0 and not DryRun:
         ExpertRemove()          remover só após sucesso
      caso contrário:
         registar: errors, remaining
         enviar alerta a uma pessoa
         lastAlert := TimeCurrent()
         NÃO remover: mantém-se ativo, nada abre,
         repete o alerta e espera por uma pessoa

FECHO – CloseOwnPositions() devolve o número de erros

   errors := 0
   for i from OrdersTotal() - 1 down to 0:

      if not OrderSelect(i, SELECT_BY_POS, MODE_TRADES):
         errors := errors + 1
         registar: posição i, GetLastError()
         passar à seguinte             não ficar em silêncio aqui

      if OrderType() > OP_SELL: ignorar
                                     pendentes em separado
      if OrderMagicNumber() != MagicNumber
            or OrderSymbol() != Symbol(): ignorar
                                     deixar intactas alheias e manuais

      RefreshRates()
      price := MarketInfo(OrderSymbol(),
                          MODE_BID for OP_BUY, MODE_ASK for OP_SELL)
      if price <= 0:
         errors := errors + 1
         registar: sem cotação, GetLastError()
         passar à seguinte

      ticket := OrderTicket()
      volume := OrderLots()

      if DryRun:
         registar: FECHARIA ordem, volume, price
         passar à seguinte             nada vai para o servidor

      if not OrderClose(ticket, volume, price, MaxDeviation):
         errors := errors + 1
         registar: número da ordem, GetLastError()

   return errors

CONFIRMAÇÃO – CountOwnPositions()

   Percorre novamente a lista e conta as posições com o
   MagicNumber próprio neste símbolo, ignorando pendentes como
   no ciclo anterior. Lê o estado da conta, não a memória
   do programa: só essa leitura decide se pode terminar.

O que o esquema não faz: é tão importante como o que faz. Não remove ordens pendentes nem trata fechos parciais. Não sobrevive a um reinício: o indicador de paragem e o máximo patrimonial estão em memória, pelo que recomeça do zero. Também não repete o fecho, por escolha, não por lacuna. Após um fecho falhado fica parado: não abre nada novo, volta a contar as posições em cada cotação e, enquanto restar alguma, repete o registo e alerta no máximo uma vez por hora. A tentativa seguinte cabe a uma pessoa, manualmente pelo terminal ou aplicação do corretor. O comportamento está completo: repetir automaticamente não pertence ao esquema e nada está por preencher. Uma decisão é obrigatória: só se remove após recontar as posições próprias, sem restar nenhuma e sem qualquer tentativa ter comunicado erro. A ordem importa: remover-se incondicionalmente após falhar deixa exposição aberta e um registo, sem ninguém no sistema para tentar fechar. Por isso, com erros ou posições restantes, mantém-se ativo e alerta.

Algo parece boa prática, mas não é. RefreshRates() devolve um valor booleano, mas tratar false como erro seria incorreto: a documentação MQL4 indica que devolve true quando os dados foram atualizados e esclarece que a única razão para não os atualizar é já serem os dados atuais do terminal cliente [17]. False significa, portanto, que os dados já estão atuais. Há que verificar outra coisa: se o preço lido após atualizar é positivo. Um preço zero indica falha na leitura da especificação ou ausência de cotação; pedir o fecho a esse preço termina em rejeição.

Resta o parâmetro de desvio; aqui uma ressalva importa mais do que o valor. MaxDeviation não é um limite universal do preço de execução: só se aplica a Instant Execution. Dentro do limite executa ao novo preço sem aviso; só além dele o servidor devolve preços para confirmar. O mecanismo e as citações estão na secção de latência, e mais amplamente no artigo sobre plataformas; aqui importa uma consequência. Copiam-se sem pensar valores da ordem de três pontos, 0,3 pips numa conta de cinco dígitos, escolhidos para entradas calmas, não fechos de emergência. Estes acontecem precisamente com spread largo e derrapagem: um limiar tão apertado leva o servidor a devolver preços em vez de executar. Se o programa não tratar novas cotações, ficam posição aberta e erro. O desvio de emergência tem de ser claramente mais amplo que o de entrada, e tem de ser chamado pelo nome: não é mais proteção, mas consentimento antecipado para fechar pior do que o preço visto, em troca de maior probabilidade de aceitação. Escolhe entre pior preço e exposição aberta, não entre segurança e risco. Com Market Execution não há campo: decide o corretor, enviar é consentir antecipadamente e resta registar quanto o fecho se afastou do preço da decisão.

Outra assimetria, independente do modo, diz respeito ao âmbito. O limiar é calculado a partir de AccountEquity(), ou seja, do património de toda a conta, mas só fecha posições do símbolo atual. Executado em três gráficos, ao ultrapassar o limiar fechará o instrumento em que chegou a cotação; as outras instâncias continuarão a contar o seu máximo. Com vários gráficos, a supervisão do risco global deve ser separada noutro programa. Cada lacuna exige uma decisão de conceção consciente antes de tocar em dinheiro real.

Três camadas de proteção

Nenhuma basta sozinha: cada uma falha num cenário diferente.

1. O código do robô. Os limites descritos só funcionam com o programa ativo
2. O servidor do corretor. Níveis SL/TP associados, chamada de margem e fecho automático no stop-out funcionam independentemente do seu ambiente; cada posição automática deve, por isso, ter proteção aí, não apenas numa variável
3. A pessoa. Notificações no telemóvel de aberturas, fechos, paragens e erros e capacidade testada de fechar manualmente pela aplicação do corretor: última camada se as duas primeiras falharem

As dependências são concretas. Uma proteção no servidor não trava uma série de pequenas perdas que respeitam individualmente o risco mas juntas esvaziam a conta: é essa a função do limite patrimonial no código. Esse limite não ajuda se a máquina do terminal falhar; então só funciona a camada do corretor. Sem as duas primeiras, as notificações apenas contam como a perda progride.

As proteções também têm de ser testadas

Uma proteção nunca acionada é uma suposição, não uma proteção. Testa-se em demo em duas fases, porque a primeira verifica a correção com menor custo. Primeiro: simulação ativa e limiar suficientemente baixo para ser ultrapassado numa hora. Nada envia, mas regista as posições que considera próprias e o que faria. Se a lista não corresponder —pode acontecer à primeira por filtros de identificador ou símbolo demasiado amplos—, saberá sem fechar nada. Só quando corresponder desative a simulação e repita. Verifique separadamente três coisas: fecho apenas das posições próprias, evento no diário e paragem só após confirmar que nada ficou aberto. Teste à parte a desconexão: corte a rede por alguns minutos e veja se, ao voltar, reconcilia com o histórico ou recomeça e abre outra posição.

O padrão mínimo de entrada em funcionamento é este: programa compilado com limites, permissões verificadas nos três níveis, decisões em ficheiro e demo no ambiente pretendido com reinício forçado, desconexão e passagem do fim de semana. Depois, só se o plano de risco permitir, conta real com volume mínimo antes de aumentar a exposição. Quantas operações e que resultados permitem avançar é outro tema: a validação de estratégias; aqui trata-se apenas de preparação operacional.

Um sistema automático pronto de terceiros

Uma observação sobre produtos comprados em mercados de software, pela segurança operacional: o ficheiro é compilado, pelo que não pode ler a lógica nem verificar limites patrimoniais, proteções no servidor ou aumento de volume após perdas. Avaliar a estratégia exige as ferramentas do material de testes. Aqui basta uma regra: não pode supervisionar com segurança um sistema cujo comportamento em falhas não consegue prever, seja qual for a curva de resultados apresentada.

Escrever o robô é muitas vezes a parte mais fácil. Mantê-lo é mais difícil: rever semanalmente os registos à procura de rejeições e tempos anormais, comparar a queda patrimonial com as hipóteses e perguntar honestamente se o mercado ainda se parece com o dos testes. Automatizar transfere a execução para código e elimina alguns erros humanos de execução. Não transfere a responsabilidade: continua a ser sua, incluindo o dever de parar o sistema a tempo.