O que é o Last Look, em termos mensuráveis
O Last Look no Forex é um mecanismo em que uma ordem pode ser provisoriamente aceita para execução, mas posteriormente rejeitada (ou não executada) após uma verificação rápida pelo provedor de liquidez. Para medi-lo, você traduz o conceito em eventos observáveis e campos registráveis. Essa abordagem separa mecânicas relativamente estáveis (quais decisões acontecem e quando) de condições variáveis (movimento de mercado, custos e escolhas de implementação).
Uma forma prática de defini-lo para medição é rastrear cada ordem tentada como um evento com pelo menos estes campos:
- Carimbo de data/hora da ordem (t_order): quando você acredita que a solicitação foi enviada.
- Carimbo de data/hora da cotação ou base de preço (t_quote): quando o preço usado para a solicitação foi observado.
- Resultado da decisão: aceito/executado ou rejeitado/não executado.
- Latência de decisão (Δt): o tempo entre a base de preço relevante e o resultado final.
- Preço de execução e taxas (se executado): o preço final de preenchimento e quaisquer custos diretamente atribuíveis que você possa registrar.
Se você não puder observar todos esses campos em seus próprios logs, deve medir apenas o que puder verificar e anotar explicitamente o que está faltando.
Como medir usando métricas de aceitação, tempo e qualidade de preço
Um objetivo comum de medição é quantificar tanto a frequência quanto o tempo/qualidade.
1) Taxas de aceitação e rejeição
Para uma amostra de ordens tentadas, você pode calcular:
- Taxa de aceitação = ordens executadas / total de ordens tentadas
- Taxa de rejeição = ordens rejeitadas / total de ordens tentadas
Premissa necessária: você define “tentada” de forma consistente (por exemplo, qualquer ordem que chegou ao provedor, não cancelada localmente antes do envio). Sem isso, as taxas podem ser enganosas.
2) Distribuição de latência
Para resultados executados e/ou rejeitados, calcule a latência a partir dos campos em que você confia:
- Latência de decisão (Δt) = t_resultado − t_cotação (ou − t_ordem, dependendo do que você puder justificar)
Em seguida, resuma usando percentis (por exemplo, mediana, 90º, 99º). Isso mede se as decisões se agrupam em intervalos curtos ou se estendem sob certas condições.
Premissa necessária: t_cotação e t_resultado devem vir de relógios e estágios de processamento comparáveis. Se os carimbos de data/hora forem produzidos por sistemas diferentes com atrasos diferentes, seu Δt não é uma representação precisa da verificação interna do provedor.
3) Comparação de qualidade de preço no momento da decisão
Para medir diferenças de “qualidade de preço” sem assumir previsibilidade futura, compare como o preço de execução (quando executado) se relaciona com a base de preço usada no momento da entrada da decisão.
Um exemplo de métrica é:
- Diferença de preço = preço_de_execução − preço_de_referência
Premissa necessária: preço_de_referência é definido e capturado de forma consistente (mesmo tipo de cotação, mesmo momento e mesmas regras de arredondamento). Como os mercados se movem continuamente, até uma referência correta pode estar desatualizada por milissegundos; sua métrica mede a relação entre a execução e sua referência escolhida, não o “valor justo” do provedor.
4) Comparações condicionais
Para reduzir a chance de que o movimento do mercado conduza tudo, agrupe eventos por condições observáveis que você possa medir, como:
- a janela de tempo (exemplo: antes/depois de uma sessão de mercado específica)
- proxies de volatilidade que você calcula a partir do seu próprio feed de preços
- faixas de tamanho de ordem (se você as registrar)
Requisito de similaridade: cada grupo deve ter eventos suficientes, e seus grupos devem usar as mesmas definições de tempo de referência e resultados.
Evidências e modos de falha: o que pode quebrar a medição
A medição pode falhar de várias maneiras materiais. Pelo menos uma limitação comum é carimbos de data/hora ausentes ou inconsistentes.
Limitação: você pode não observar o mesmo relógio de decisão
Se seu t_cotação é derivado de um feed e t_resultado é do seu sistema de gerenciamento de ordens, pode haver atrasos em ambas as direções. Seu Δt medido então reflete latência de pipeline e software, não o tempo de decisão do Last Look do provedor.
Limitação: “rejeição” pode ter múltiplos significados
Uma rejeição aparente pode vir de:
- a decisão do Last Look
- um cancelamento local devido a timeout
- rejeição devido a restrições de execução ou verificações de risco que você não modelou
Para tratar rejeições como resultados do Last Look, você deve separá-las usando definições dos seus próprios logs (por exemplo, códigos de status distintos). Caso contrário, as taxas de aceitação/rejeição misturam mecanismos.
Limitação: condições de mercado dominam horizontes curtos
Mesmo com carimbos de data/hora corretos e definições claras, resultados de curto prazo variam com condições de mercado, custos de negociação e plataformas de execução. Taxas de aceitação históricas e distribuições de diferença de preço não estabelecem resultados futuros.
Verificação e próxima pergunta para tornar a medição confiável
A verificação independente vem da auditoria de suas definições e da reconstrução da linha do tempo do evento.