English
Deutsch
日本語
العربية
한국어
Español
Indonesia
Tiếng Việt
中文
BJF TRADING GROUP · SHARPTRADER OPTIMIZER
A maioria dos backtests publicados de arbitragem de latência parece espetacular no papel e desmorona no momento em que entra em operação ao vivo. O motivo não é uma lógica de estratégia ruim — é que backtesters padrão para varejo assumem silenciosamente execuções com latência zero. Este guia explica exatamente como o tempo de execução em nível de milissegundos muda a matemática, e o que seu backtest precisa modelar para produzir resultados que você possa realmente negociar.
A lucratividade da arbitragem de latência vive dentro de uma janela de 50–200 milissegundos. Esse é o tempo pelo qual a discrepância de preço entre um feed rápido e uma corretora lenta normalmente permanece aberta antes que a cotação da corretora lenta seja atualizada. Se o seu tempo real de execução de ida e volta — da detecção do sinal até a confirmação da execução — consumir a maior parte dessa janela, quase não resta margem. Backtesters padrão para varejo assumem que as ordens são executadas instantaneamente ao preço exibido, o que apaga todo esse problema da simulação. O resultado: um backtest que parece imprimir dinheiro e uma operação ao vivo que perde em cada trade após o spread.
Este artigo quantifica a lacuna, detalha para onde os milissegundos realmente vão e explica como modelar o tempo de execução dentro de um backtest para que os números gerados correspondam aos números que você verá em uma conta real.
Assista: como o tempo de execução muda um backtest de arbitragem de latência — a mesma estratégia com 0 ms, 50 ms e 150 ms de latência de execução, analisada tick a tick.
Em um sistema de arbitragem de latência, a estratégia compara dois feeds de preço — um feed rápido (normalmente um agregador tier-1 ou feed de LP) e um feed lento (a corretora contra a qual você está negociando). Quando o feed rápido se adianta ao lento por mais do que o spread mais um limite configurado, a estratégia dispara uma ordem no lado lento, esperando que o preço lento converja.
A oportunidade existe apenas enquanto os dois preços estão desalinhados. No momento em que o motor de cotações da corretora alcança o preço — normalmente dentro de 50 a 200 milissegundos — a vantagem desaparece. Sua ordem precisa estar no mercado antes que isso aconteça.
“Tempo de execução” nesse contexto não é um único número. É uma pilha de latências, cada uma contribuindo com alguns milissegundos:
Para uma estratégia rodando em um VPS padrão em um data center diferente do da corretora, o ida e volta realista raramente fica abaixo de 80–100ms. Para uma estratégia co-localizada com a corretora via cross-connect, pode cair para 1–5ms. Essa diferença de ordem de grandeza é o jogo inteiro.
Imagine um sinal limpo: o feed rápido salta 1.5 pips. A corretora lenta ainda não atualizou. Você tem, em média, algo entre 80 e 150 milissegundos antes que o motor de cotações da corretora lenta reflita o novo preço. Dentro dessa janela, duas coisas acontecem ao mesmo tempo:
Se seu ida e volta consome 50ms, você chega quando a discrepância ainda está ~70% intacta e captura a maior parte dela. Se seu ida e volta consome 150ms, você chega quando a discrepância já colapsou para ~10% — e após spread + slippage provavelmente estará perdendo.
A relação entre latência de ida e volta e PnL de arbitragem não é linear. Abaixo da janela de execução, a lucratividade é alta e estável. Acima dela, a lucratividade colapsa para zero ou negativo. A maioria dos traders de varejo está do lado errado desse precipício e não sabe, porque o backtest esconde isso.
Aqui está o mesmo sinal teórico de arbitragem de latência com vantagem de 1.5 pip, simulado em quatro latências diferentes de execução de ida e volta. Os números abaixo são típicos do que você verá em EUR/USD durante uma sessão de Londres com liquidez normal e spread de 0.6–0.9 pip.
| Execução de ida e volta | Vantagem capturada | Slippage na entrada | PnL líquido por trade | Veredito |
|---|---|---|---|---|
| ~5ms (co-localizado) | ~95% do sinal | 0.0–0.2 pip | +0.6 a +1.0 pip | Lucrativo |
| ~50ms (VPS próximo) | ~70% do sinal | 0.2–0.5 pip | +0.2 a +0.6 pip | Lucrativo, mais apertado |
| ~120ms (distância média) | ~30% do sinal | 0.5–1.0 pip | −0.3 a +0.1 pip | Marginal / perdedor |
| ~200ms (longa distância) | ~10% do sinal | 1.0–1.8 pip | −1.0 a −0.5 pip | Perde todo trade |
Observe o padrão: de 5ms para 50ms, a lucratividade cai moderadamente. De 50ms para 120ms, ela despenca de um precipício. Acima de 150ms, a estratégia vira um cara ou coroa com expectativa negativa após custos. Esse precipício é invisível para um backtester que assume execuções instantâneas.
Backtesters padrão para varejo foram criados para sistemas de acompanhamento de tendência e baseados em indicadores — estratégias em que os períodos de manutenção são de minutos a dias, e alguns segundos de slippage de execução são erro de arredondamento. Sua arquitetura reflete isso:
Para uma estratégia que mantém posições por horas, isso é aceitável — o custo dessas simplificações fica bem abaixo de 1% do PnL. Para uma estratégia de arbitragem de latência que ganha 1–3 pips por trade e vive ou morre dentro de uma janela de 100ms, cada uma dessas simplificações é fatal:
Uma discrepância de preço de 100ms é invisível dentro de uma barra M1 — a barra mostra OHLC, não o fluxo de ticks intrabarra. Backtesters de reprodução de barras nem conseguem detectar corretamente sinais de arbitragem de latência.
Se as ordens são executadas ao preço exibido no momento em que são enviadas, toda a janela de execução de 50–200ms colapsa para zero. O backtest captura 100% de todo sinal, sempre. A realidade captura 30%–95%, dependendo da infraestrutura.
Oportunidades reais de arbitragem se concentram em torno de notícias, rollover e janelas de baixa liquidez — exatamente quando o spread se alarga 3–5x. Backtests com spread fixo contabilizam lucros que não existiriam em condições reais.
A arbitragem de latência fecha posições tão rápido quanto as abre. Backtesters padrão ignoram completamente o slippage no lado de fechamento ou aplicam o mesmo spread fixo, dobrando o otimismo irrealista.
Para produzir um backtest que sobreviva ao contato com uma corretora ao vivo, o simulador precisa modelar explicitamente cada trecho da ida e volta. Aqui está o detalhamento que um backtest sério de arbitragem de latência precisa:
| Componente | Faixa típica | O que representa |
|---|---|---|
| 1. Latência de sinal para envio | 0.5–20 ms | Tempo desde o recebimento do tick gatilho até a emissão de uma ordem. Depende da linguagem, do caminho do código e da CPU. C++ compilado <1ms; scripts de alto nível 5–20ms. |
| 2. Ida e volta de rede (saída) | 1–80 ms | Tempo de transmissão do seu host de trading até a corretora. Co-localizado = 1–3ms; mesma região metropolitana = 5–15ms; entre regiões = 30–80ms. |
| 3. Latência de matching da corretora | 3–100 ms | Tempo gasto dentro do sistema de gerenciamento de ordens e motor de matching da corretora. Corretoras ECN tier-1: 3–15ms. Corretoras de varejo padrão: 30–100ms. Corretoras STP com tratamento manual: 100ms+. |
| 4. Ida e volta de confirmação (retorno) | 1–80 ms | Espelha o trecho de rede de saída. Até receber a confirmação da execução, você não conhece seu preço de execução — relevante para gestão de risco e timing do lado de fechamento. |
Para uma implantação típica de arbitragem de latência no varejo a partir de um VPS genérico por meio de uma corretora de varejo padrão, os quatro componentes somam aproximadamente 80–180ms — exatamente dentro da zona de perigo em que a captura de sinal cai abaixo de 50%. Para uma implantação co-localizada por meio de uma corretora ECN rápida, os mesmos componentes somam 5–20ms — bem abaixo do precipício.
Todo backtest honesto de uma estratégia de arbitragem de latência deve permitir que o trader configure essas latências e veja o impacto. SharpTrader Optimizer modela a latência de execução como um único parâmetro configurável (em milissegundos), aplicado a cada ordem no tempo de simulação, sobre dados históricos reais de ticks.
Três coisas precisam existir. Cada uma é necessária; nenhuma é suficiente sozinha.
Backtesters padrão para varejo preenchem dados de “tick” interpolando entre valores OHLC das barras. Os ticks sintéticos que produzem atingem a máxima e a mínima da barra em pontos aleatórios dentro da barra, suavemente entre a abertura e o fechamento. Mercados reais não se movem assim — eles saltam. O sinal de arbitragem de latência de 1.5 pip que você está tentando capturar é um salto que dados de tick interpolados suavizam até desaparecer.
Um backtest sério reproduz ticks bid/ask reais registrados a partir do motor de matching da corretora (ou um feed de referência limpo, como dados institucionais originados em Londres). Cada tick tem um timestamp, um bid e um ask. A estratégia os vê na mesma ordem e com o mesmo timing que veria em uma implantação ao vivo.
O trader configura o tempo de execução de ida e volta T (em milissegundos) que espera ver ao vivo. Quando a estratégia emite uma ordem, o simulador avança o relógio pela parte do trecho de solicitação — normalmente T/2, já que apenas o tempo entre o sinal e o matching do lado da corretora afeta o preço de execução (o trecho de resposta apenas informa à estratégia o que já aconteceu). Se T = 80ms, o simulador olha para o fluxo de ticks 40ms após o sinal e usa o bid/ask desse tick — não o tick que disparou o sinal — como preço de execução.
Essa única mudança — avançar o relógio entre sinal e execução — reproduz o precipício em latências realistas. Ela também torna o backtest determinístico: a mesma estratégia em T = 50ms vs T = 150ms no mesmo fluxo de ticks produz resultados mensuravelmente diferentes, e o trader pode ver exatamente onde a estratégia deixa de funcionar.
O slippage realizado em cada execução é o que o percurso dos ticks produziu — é uma saída da simulação, não um número que o trader precisa adivinhar. Algumas execuções caem favoravelmente (slippage positivo), outras pior (negativo), e a magnitude acompanha a volatilidade real dos ticks durante aqueles milissegundos. Essa é a distribuição realista que falta em todo backtester padrão para varejo.
A arbitragem de latência fecha tão rápido quanto abre. A saída acontece 200–800ms após a entrada, em um preço que está convergindo. Se o simulador aplica o mesmo spread fixo à entrada e à saída, perde duas coisas: (1) slippage de entrada da janela de latência, e (2) slippage de saída do preço derivando de volta durante a ida e volta do lado de fechamento. Um modelo real permite configurar o tempo de execução independentemente na abertura e no fechamento — refletindo o comportamento real da corretora, em que saídas frequentemente passam por uma rota de encaminhamento mais lenta — e resolve automaticamente o slippage em cada trecho a partir do fluxo de ticks.
Aqui está um resultado representativo de uma estratégia de arbitragem de latência do SharpTrader testada em 30 dias de dados de ticks de EUR/USD, com os mesmos parâmetros mas três configurações diferentes de latência de execução. Os números são típicos do que vemos em backtests do BJF Feed (London / Tokyo / NY).
| Métrica | 0ms (fictício) | 50ms (VPS próximo) | 150ms (longa distância) |
|---|---|---|---|
| Sinais disparados | 2,847 | 2,847 | 2,847 |
| Sinais executados na vantagem | 2,847 (100%) | 1,983 (70%) | 854 (30%) |
| Pip médio capturado | 1.42 | 0.98 | 0.21 |
| Slippage realizado na entrada (saída do percurso de ticks) | 0.0 pip | 0.3 pip | 0.9 pip |
| PnL líquido por trade | +0.82 pip | +0.48 pip | −0.31 pip |
| Retorno mensal (1 lote) | +233% | +137% | −88% |
A coluna de 0ms é a “fantasia do backtest” que ferramentas padrão produzem. A coluna de 50ms é como uma estratégia de arbitragem de latência bem implantada realmente se parece. A coluna de 150ms é o que a maioria dos traders de varejo executa sem querer quando coloca uma estratégia em um VPS genérico e negocia por meio de uma corretora padrão sem perceber onde seu ida e volta cai no precipício.
A mesma estratégia pode ser extremamente lucrativa, marginalmente lucrativa ou uma perda garantida — dependendo apenas de um número que nenhum backtester padrão modela.
A latência de execução é a variável menos modelada em backtests de arbitragem de latência para varejo, mas não é a única. Um backtest confiável combina três coisas, e cada uma amplifica as outras:
Revela o precipício. Mostra qual infraestrutura a estratégia realmente precisa para ser lucrativa e em que ponto sua vantagem desaparece.
Captura o fato de que oportunidades de arb se concentram exatamente quando o spread se alarga. Um backtest com spread fixo contabiliza lucros que fisicamente não podem existir nesses momentos.
Detecta estratégias que parecem boas in-sample porque o otimizador encontrou um conjunto de parâmetros que se ajusta ao ruído do período in-sample. Sem walk-forward, seu backtest é um currículo retrospectivo.
Um trade de arbitragem de latência tem dois eventos de slippage — abertura e fechamento. A maioria dos backtests modela um (ou zero) e dobra o otimismo.
Quando os quatro estão presentes, o backtest deixa de ser uma ferramenta de marketing e se torna uma ferramenta de previsão. Os números que ele produz deixam de divergir 50–200% dos resultados ao vivo e começam a ficar dentro de 10–20% — perto o suficiente para que decisões de dimensionamento de risco, alocação de capital e seleção de corretora possam realmente ser tomadas com base no backtest.
Regra prática da indústria: espere que o drawdown ao vivo seja de 1.5x a 2x o drawdown do backtest. Para estratégias de arbitragem de latência rodando em backtesters padrão, essa razão fica mais perto de 5x a 10x — porque o backtest não modelou latência de execução, spread variável ou slippage nos dois lados. Depois que esses elementos entram, a regra 1.5–2x se aplica; antes disso, o backtest não tem nenhum valor preditivo.
Execute a otimização em pelo menos três configurações de latência: 10ms (melhor caso co-localizado), 50ms (VPS próximo) e 150ms (VPS genérico, corretora distante). Se a estratégia só for lucrativa em 10ms, você tem um problema de implantação — precisa de um plano de co-localização antes de negociá-la. Se for lucrativa em 50ms mas não em 150ms, a escolha do VPS e da corretora se torna o jogo inteiro.
Três camadas: (1) faça ping no endpoint de entrada de ordens da sua corretora a partir do seu host de trading — isso dá o ida e volta bruto da rede; (2) envie uma pequena ordem de teste durante um período calmo e registre timestamp da emissão do sinal vs confirmação da execução — a diferença inclui a latência de matching da corretora; (3) repita em várias sessões — a latência varia com a carga da corretora, horário do dia e rota. O valor realista para sua implantação é a mediana de muitas medições, não o melhor ping possível.
Sim — com janelas ainda mais estreitas. Janelas de trading de notícias podem ter 10–50ms de largura. O problema da lacuna do tempo de execução é idêntico, apenas comprimido em uma janela menor. A mesma infraestrutura de backtest (ticks reais, latência de execução configurável, spread variável) é necessária, e a tolerância à latência é ainda menos permissiva.
Ambos os fenômenos têm a mesma causa: provedores de liquidez ficam incertos sobre o preço e retiram cotações. Quando o feed rápido salta, LPs que fornecem à corretora lenta alargam brevemente suas cotações para se proteger de serem explorados. Portanto, o momento em que a discrepância se abre também é o momento em que o spread para capturá-la se alarga. Um backtest com spread fixo não vê isso e superestima a vantagem líquida em 30–50%.
Para arbitragem de latência de estilo institucional contra corretoras ECN tier-1, sim — o campo de jogo se moveu para ida e volta sub-5ms, e isso exige cross-connect ou proximity hosting. Para arbitragem de latência de estilo varejo contra corretoras de varejo mais lentas, não — idas e voltas de 30–80ms ainda podem produzir vantagem, porque a janela da corretora lenta é mais larga. A pergunta certa não é “co-localização é necessária”, mas “meu ida e volta cabe dentro da janela da corretora contra a qual estou negociando.” É exatamente essa pergunta que o backtesting consciente de latência de execução responde.
Para estratégias de acompanhamento de tendência que mantêm posições por horas ou dias, algumas centenas de milissegundos de latência de execução são erro de arredondamento. Para arbitragem de latência, esses mesmos milissegundos são o sinal inteiro. A infraestrutura normal de backtesting de forex é projetada para o primeiro caso e produzirá silenciosamente resultados inúteis para o segundo. É por isso que ferramentas dedicadas de backtesting de arbitragem existem como uma categoria separada.
Eles mudam a estratégia ideal, não a análise. Corretoras que executam plugins anti-arbitragem (execução atrasada, last-look, requote em lucro, hold-then-fill) introduzem efetivamente latência de execução artificial além da natural. Um backtest com latência configurável permite simular o comportamento anti-arb da corretora e decidir se a estratégia ainda é viável contra essa corretora — ou se você precisa trocar de venue.
Para uma estratégia de arbitragem de latência com 5–8 parâmetros, uma grade típica é de 30,000–100,000 combinações — incluindo 3–5 configurações de tempo de execução como uma das dimensões varridas. O objetivo é encontrar clusters de lucratividade — faixas em que a estratégia é lucrativa em muitos valores de parâmetros, não picos “sortudos” isolados. Picos isolados são curve-fitting; clusters são robustez. Como referência realista em uma estação de trabalho de varejo típica, uma grade de 30,000 combinações contra 1 semana de dados de ticks de XAUUSD em uma CPU de 4 núcleos termina em cerca de 12 horas; a mesma grade leva cerca de 3 horas em 16 núcleos. SharpTrader Optimizer lida com 100,000+ combinações por execução em hardware multi-core.
É uma observação empírica no trading algorítmico institucional: mesmo um backtest bem modelado subestima o drawdown ao vivo em cerca de 50–100%, porque algumas fricções do mundo real (rejeições da corretora, gaps de fim de semana, mudanças de regime) não podem ser modeladas de forma limpa. A regra assume que o backtest já inclui latência de execução realista, spread variável e slippage nos dois lados. Se esses elementos estiverem ausentes, o multiplicador é muito maior — 5x a 10x especificamente para arbitragem de latência.
Conceitualmente, é idêntica. A janela de tempo de execução em arbitragem cripto entre exchanges normalmente é de 200ms–2s (mais lenta que forex porque as exchanges estão mais distantes e os livros de ordens são mais profundos, mas mais lentos para atualizar). Os mesmos três ingredientes — reprodução de ticks, latência de execução configurável, spread variável — produzem backtests honestos. As ferramentas de crypto arbitrage da BJF usam a mesma arquitetura adaptada para APIs de exchanges e profundidade de livro de ordens.
SharpTrader Optimizer é o único backtester acessível ao varejo que modela tempo de execução configurável, reprodução de ticks reais, spread variável por tick e slippage resolvido por tick nos dois lados — as quatro variáveis que decidem se uma estratégia de arbitragem de latência é real ou fictícia. A otimização em grade multi-core em 100,000+ combinações de parâmetros termina em horas, não dias.