O que “qualidade de execução” para acesso via API significa
Qualidade de execução é o quão bem uma ordem enviada via API resulta no resultado pretendido quando comparado ao que você esperava no momento em que a enviou. Na prática, você julga a qualidade de execução usando o comportamento observável do sistema: tempo, tratamento de ordens, a correspondência entre preenchimentos solicitados e reais, e a frequência com que erros ou eventos inesperados ocorrem.
O acesso via API muda onde os problemas de execução podem aparecer. Em vez de apenas observar o comportamento do mercado e da estratégia, você também considera o “encanamento” em torno do envio de ordens e do ciclo de vida do pedido: como a API recebe sua solicitação, como ela confirma a aceitação, como ela atualiza o status da ordem e como ela reporta as negociações de volta ao seu sistema.
Mecânica principal: o que você pode medir
Para avaliar a qualidade de execução, defina alguns termos primeiro.
- Hora da solicitação: quando seu aplicativo envia uma mensagem de ordem.
- Confirmação/aceitação: quando a API confirma que a ordem foi aceita para processamento.
- Hora do evento de execução: quando preenchimentos ou cancelamentos ocorrem (conforme relatado pela API).
- Resultados esperados vs. reais: se o preço, a quantidade ou o tempo de preenchimento executado corresponde ao que seu sistema assumiu.
Uma avaliação mensurável geralmente inclui:
- Distribuição de latência (não apenas uma média). Acompanhe o tempo desde a solicitação até a confirmação, e desde a confirmação até o primeiro preenchimento. Considere percentis (por exemplo, com que frequência é “rápido o suficiente”).
- Confiabilidade. Meça as taxas de ordens rejeitadas, timeouts, solicitações duplicadas e atualizações de status ausentes.
- Precisão do resultado da ordem. Compare preço/tamanho/restrições solicitados com o que foi finalmente executado ou confirmado (incluindo preenchimentos parciais).
- Integridade do evento. Verifique se a sequência de estados da ordem que você recebe (aceita → parcialmente preenchida → preenchida/cancelada) é consistente e completa.
- Transparência de custos. A qualidade de execução não pode ser separada dos custos totais de transação (spreads, comissões, taxas e qualquer deslize implícito nas diferenças de preenchimento). Você só pode avaliá-la usando os preços e taxas realmente aplicados.
Uma ideia-chave é comparar sua execução observada a uma referência que você controla. Sua referência pode ser um teste controlado usando ordens pequenas em condições consistentes, com carimbos de data/hora e entradas claramente registrados.
Evidência e exemplo: um teste de estilo de verificação
Suponha que você execute um teste onde envia ordens limitadas idênticas através da API e registra:
- o carimbo de data/hora exato da solicitação do seu aplicativo,
- o carimbo de data/hora da aceitação da API,
- o carimbo de data/hora do primeiro preenchimento e do preenchimento total,
- preço executado e quantidade executada,
- quaisquer códigos de erro ou atualizações ausentes.
Você então calcula alguns resumos em várias tentativas:
- Atraso de confirmação = tempo de aceitação − tempo de solicitação.
- Tempo para o primeiro preenchimento = tempo do primeiro preenchimento − tempo de solicitação (ou − tempo de aceitação, desde que você escolha uma definição).
- Desvio de preenchimento = diferença entre seu preço de restrição e o preço executado (direcionalmente e em termos absolutos).
- Integralidade do preenchimento = (quantidade preenchida ÷ quantidade solicitada) para cada ordem, e a parcela de ordens que terminam parcialmente preenchidas.
Como as condições de mercado podem mudar rapidamente, você separa duas camadas de evidência:
- Evidência de comportamento do sistema: se atrasos, rejeições e atualizações ausentes ocorrem a taxas previsíveis ou estáveis sob condições comparáveis.
- Evidência de mercado e custo: se as diferenças de preenchimento podem ser explicadas por mudanças na liquidez e nos custos de transação, em vez do tratamento da API.
Você também deve tornar as suposições explícitas. Por exemplo, se seu teste usa a mesma configuração de time-in-force ou o mesmo tipo de ordem, anote isso; caso contrário, a interpretação da aceitação e dos preenchimentos parciais se torna ambígua.
Limitações e modos de falha a serem considerados
Mesmo quando as medições parecem boas, a qualidade de execução não é totalmente previsível. Limitações materiais comuns incluem:
- Modo de falha: ordens rejeitadas ou com timeout. Um sistema pode ser rápido quando funciona, mas ainda assim ter taxas de rejeição inaceitáveis quando a carga ou a conectividade mudam. - Modo de falha: dados de mercado desatualizados ou inconsistentes. Se seu aplicativo baseia decisões em dados que ficam para trás no momento do envio da ordem, você pode ver preenchimentos piores que não são apenas um problema de “latência”. - Modo de falha: preenchimentos parciais e atualizações pós-preenchimento. Preenchimentos parciais podem ser precisos, mas se seu aplicativo rastreia incorretamente a quantidade restante ou lida mal com as sequências de status, sua “qualidade” de execução medida pode refletir erros de lógica de software. - Limitação de medição: alinhamento de carimbos de data/hora. Se você comparar seus carimbos de data/hora locais com os relatados pela API sem entender a sincronização de relógio, suas conclusões de latência podem ser tendenciosas. - Limitação de evidência: o histórico não garante o futuro.