Trading algorítmico: primeiro projeto verificável antes de enviar ordens

O primeiro projeto algorítmico pode registar sinais, calcular volume ou verificar exposição sem enviar uma única ordem. Escolha uma operação cujo resultado consiga explicar e conferir. Defina informação, regra e comportamento perante falhas antes de conceder permissão para negociar. Automatizar um procedimento não demonstra que a estratégia é rentável.

Sinal, execução, gestão e relatório são tarefas diferentes

Um programa que divide uma decisão já tomada em várias ordens tem finalidade diferente de um robot que escolhe entradas. O relatório BIS de 2020 sobre algoritmos de execução cambial analisa execução e riscos de mercado, não verifica lucros de robots de retalho. Nesse relatório, EA significa execution algorithm; no MetaTrader significa Expert Advisor. Esclareça a sigla antes de comparar exemplos.

Especifique instrumento, fonte, horários, instante de decisão, entrada, saída, volume, limite de exposição e resposta quando já existe posição. As decisões humanas permanecem nestes pressupostos e na supervisão. Um programa pode eliminar um erro manual e introduzir outro, como repetir pedido após reinício. Correção do código e valor económico da regra precisam de testes separados.

Escolha a ferramenta pela operação

Uma notificação simples pode precisar apenas de alerta. O diálogo nativo MT5 aceita comparações de preço, volume do último negócio e hora; não edita qualquer combinação de médias e ATR. Lógica personalizada pode exigir indicador ou EA. MQL5 trabalha no MT5; Python pode analisar dados ou usar ligação documentada. Não há escada obrigatória entre alertas, MQL5, Python e FIX.

Conta, dados e operação determinam ambiente. Não presuma número de linhas, tempo de construção, latência ou acesso API universal da corretora. Compare conceitos de Expert Advisor e investigação em Python conforme a tarefa. Reimplementar a mesma ideia em duas linguagens é opcional.

O terceiro preço não pode ser adivinhado

A regra requer exatamente três fechos históricos completos, x, 100 e 102, do mais antigo ao mais recente. Compare último 102 com a média dos três, sem arredondar antes. Se o preço antigo desconhecido fosse 98, a média seria 100 e 102>100. Se fosse 106, a média seria 308/3≈102,667 e 102 não seria maior.

Estes são preenchimentos alternativos do passado em falta, não preços futuros nem dados reais. Sem x, registe «dados incompletos» e suspenda avaliação. A média dos dois conhecidos, 101, muda a regra; substituir zero inventa dado. Se a recolha depois consegue três registos, confirme que pertencem às mesmas velas pretendidas. A documentação CopyRates informa quantos registos foram copiados e situações de disponibilidade parcial. O problema aqui é completude, não direção de índices.

Competências para verificar comportamento

Precisa de programação e tratamento de dados suficientes para conferir o que usa, e de dimensionamento e raciocínio estatístico para avaliar resultados. Alterar um parâmetro sem erro de sintaxe não testa execução, estado nem economia. Uma curva curta descreve a amostra, não rentabilidade futura. Prepare dados representativos, avaliação separada e verificações demo.

Latência total depende de código, alojamento, rede e execução; não é garantidamente de poucos milissegundos. Tampouco existe prazo obrigatório de doze a vinte e quatro meses ou número universal de negócios para provar vantagem. Um registo de sinais fiável pode ser o projeto completo, sem progressão inevitável para dinheiro real.

Da especificação a testes pequenos e explicáveis

Para cruzamento fictício EUR/USD H1, defina cálculo de EMA 21, SMA 55 e ATR, distância escolhida de stop/alvo e instante de avaliação. Declare se usa velas H1 completas. Comece por registar sinal, sem ordens. Teste sinal, ausência de sinal, mudança de vela, histórico em falta e posição existente. Dado ausente não é resultado válido de «não entrar».

Compare decisões manuais e automáticas nas mesmas datas e dados. Cinco anos automáticos não têm de coincidir com seis meses manuais; regimes e feeds diferem. Reconcilie discrepâncias no período comum, modele custos e congele regras antes de avaliar dados separados. Mudar a regra após consultar a avaliação incorpora esse período no desenvolvimento.

Orçamento de perda não é nocional nem margem

Modelo original: equity 10 000 USD, orçamento escolhido 0,5%, stop 25 pips, pip EUR/USD 0,0001 e contrato 100 000 EUR/lote. Valor do pip 10 USD/lote; orçamento 50 USD. Volume antes de custos=50/(25 × 10)=0,20 lotes, ou 20 000 EUR de nocional. Não são parâmetros universais recomendados.

Inclua comissão e pressupostos de execução antes de ajustar ao passo de volume. Stop comum pode executar de forma diferente numa lacuna; 50 USD não é máximo incondicional. Margem requer outra verificação. Num modelo adicional de conta EUR, orçamento 50 EUR, custo fixo previsto 2 EUR e pip 9 EUR por lote, mesmo stop 25 pips: preço pode usar 48 EUR, volume teórico 48/225≈0,2133 lotes. Com passo 0,01, arredondar para baixo dá 0,21; perda de preço 47,25 mais 2=49,25 EUR. São inputs próprios, não conversão automática do exemplo USD nem comissão real fixa de qualquer corretora.

Duas cotações corretas podem criar spread falso

Fluxo fictício: t1 tem Bid/Ask 1,1000/1,1002; t2 tem 1,1010/1,1012. Ambos dão 2 pips, pip 0,0001. Misturar Ask t1 com Bid t2 produz (1,1002−1,1010)/0,0001=−8 pips. Um filtro spread<2,5 aceitaria esse número construído, que não é spread negativo observado no mercado.

SymbolInfoTick devolve preços e hora de atualização na estrutura MqlTick. Confira sucesso da função e calcule a partir dos campos da mesma estrutura guardada. Acrescente um teste que mistura deliberadamente leituras válidas de momentos diferentes, para verificar rejeição. Cotação coerente é controlo de dados, não garantia de liquidez ou preço futuro.

Investigue regra, dados, código, execução e operação

Não reduza falhas a duas causas numa ordem universal. Código incorreto pode invalidar backtest ou criar exposição. Após resposta ambígua, consulte ordens, negócios e posições antes de repetir. OrderSend devolver true não prova execução concluída: analise resultado e estado das transações. Uma chamada pode corresponder a vários eventos.

Registe versão, instante dos inputs e motivo de atuar ou não. Mantenha tentativas sem sucesso e razão de alterações. O estudo da vantagem estatística discute avaliação, sem prometer aumentar probabilidades por automatizar. Um resultado favorável em dados usados para escolher regra pode refletir seleção.

Num modelo fixo de 100 negócios, 40 ganhos de 2 R e 60 perdas de 1 R dão 80−60=20 R; média 0,2 R antes de custos. Profit factor 80/60≈1,33. Taxa de acerto 40%, expectativa e profit factor respondem a perguntas diferentes. Estes pagamentos e frequências são escolhidos, não estratégia testada nem frequência garantida na próxima amostra.

Registe custos de dados, alojamento, licenças e tempo, mesmo quando linguagem não tem licença paga. Preços, permissões e recuperação dependem do ambiente. Teste reinício e indisponibilidade. VPS não elimina supervisão nem toda a falha. Desligar AutoTrading local não fecha posições; proteção aceite no servidor e regras geridas pelo programa têm dependências diferentes.

Três ações para o primeiro projeto

1. Escreva uma operação reproduzível: dados, instante, regra, saída e situações de suspensão por informação incompleta.
2. Teste completude e coerência em casos pequenos. Se precisa de ordens, use demo identificado e teste aceitação, rejeição, reinício e resposta ambígua com consulta do estado.
3. Congele regras para avaliação separada, inclua custos e procedimento de pausa/reinício/atualização. Investigue diferenças por decisão, não apenas lucro final.

Um prazo de calendário não obriga a ativar dinheiro real. Observação demo não garante execução real idêntica. A possibilidade de rejeitar ou parar o projeto faz parte da especificação.