Como funciona uma agregação de liquidez (e por que o seu preenchimento não foi o esperado)

Entre o preço que um banco Tier-1 cota e o preenchimento que o cliente da sua corretora recebe há uma cadeia de decisões técnicas que quase nunca é explicada. É aí que a qualidade de execução se ganha ou se perde, e onde vivem a maioria das discussões que terminam em "o provedor está fazendo algo estranho conosco".

Normalmente ele não está fazendo nada estranho. Está aplicando regras que ninguém explicou a você.

O que é agregar, concretamente

Agregar liquidez é construir um book sintético a partir de vários books reais.

O agregador mantém sessões simultâneas com múltiplas fontes — bancos, ECNs, market makers não bancários — e recebe de cada uma um stream de preços com os seus níveis e tamanhos. O trabalho dele é fundir tudo isso em um único book coerente sobre o qual se possa executar.

Soa trivial. Não é, por quatro razões.

1. Os preços não chegam ao mesmo tempo

Cada fonte tem a sua própria latência até o agregador. Um feed que chega 3 milissegundos mais tarde que outro está descrevendo um mercado ligeiramente diferente.

O agregador precisa decidir o que fazer com essa dessincronização: se constrói o book com o último dado recebido de cada fonte, está misturando fotos tiradas em momentos diferentes. Se espera para sincronizar, adiciona latência.

Não há resposta correta universal. Há uma decisão de projeto, e você deveria saber qual a sua contraparte tomou.

2. Os tamanhos se sobrepõem

Se três bancos cotam 1 milhão cada um a 1.0850, o seu book não tem necessariamente 3 milhões a esse preço. Pode ter. Pode ser que dois desses bancos estejam cobrindo a mesma posição e, ao tentar executar os três, um rejeite.

A profundidade agregada nominal e a profundidade executável real são números distintos. Um agregador sério mostra o segundo.

3. É preciso normalizar símbolos

Cada fonte nomeia os seus instrumentos à sua maneira. XAUUSD, GOLD, XAU/USD e Gold Spot podem ser o mesmo ativo com quatro convenções distintas, com diferenças em tamanho de contrato, dígitos de preço e horários de sessão.

O mapeamento de símbolos é tedioso e pouco glamouroso, e é onde metade das integrações quebra. Se o seu provedor não acordar o mapeamento completo do seu catálogo antes da certificação, você vai descobri-lo em produção com um instrumento cotando errado.

4. Há regras de roteamento

Com o book construído, falta decidir a quem cada ordem é enviada. E aí já não há neutralidade: há política.

As regras de roteamento são a parte que importa

Um agregador pode rotear por vários critérios, e a escolha afeta diretamente o seu preenchimento:

Por melhor preço. O óbvio: envia-se a quem cota melhor. O problema é que o melhor preço às vezes vem da fonte com pior taxa de aceitação, então você otimiza o preço nominal e piora o preenchimento real.

Por taxa de aceitação. Prioriza-se as fontes que historicamente rejeitam menos, ainda que cotem um pouco pior. Melhor preenchimento efetivo, spread nominal ligeiramente maior.

Por latência. Prioriza-se quem responde mais rápido. Relevante para estratégias sensíveis ao tempo, irrelevante para tickets grandes onde a profundidade importa mais.

Ponderado. Combinações do anterior com pesos configuráveis. É o habitual entre operadores sérios.

Aqui está o ponto: o critério que o seu provedor usa determina quais preenchimentos você recebe, e muitas corretoras nunca perguntam qual é. Se os seus clientes reclamam de slippage e o seu provedor roteia por melhor preço nominal contra fontes com Last-Look agressivo, você já sabe de onde vem.

Pergunte isto: por qual critério você roteia o meu fluxo, é configurável, e você pode me mostrar a taxa de aceitação de cada fonte upstream?

Onde a qualidade de execução se perde

Há quatro pontos concretos na cadeia onde o preenchimento se degrada:

Na construção do book. Se o agregador mostra profundidade nominal em vez de executável, a sua mesa está tomando decisões sobre um book que não existe por completo.

Na rejeição. Quando uma fonte rejeita sob Last-Look, a ordem é reroteada. Essa nova tentativa custa tempo e, em mercado em movimento, preço. Uma taxa de rejeição de 5% não significa que 5% das suas ordens falham: significa que 5% são executadas pior.

No markup. Quase todos os agregadores aplicam uma margem sobre o preço de origem. É legítimo — é o negócio deles — mas deveria ser explícito e consistente, não variável conforme o momento.

Na última milha. Entre o agregador e a sua plataforma há mais um salto, com a sua própria latência e o seu próprio comportamento na desconexão.

O que você deveria poder auditar

Uma relação de execução saudável permite reconstruir, para qualquer operação:

• O preço de referência no momento em que a ordem chegou
• Para qual fonte foi roteada e por quê
• Se houve rejeição e reroteamento
• O timestamp de cada passo
• O preço final e a diferença em relação à referência

Se o seu provedor não pode dar isso a você, não é que esteja necessariamente escondendo algo: pode ser que simplesmente não registre. Mas em qualquer discussão sobre qualidade de execução você estará em desvantagem permanente, e diante de um regulador ou de um allocator você não vai poder provar nada.

Um mal-entendido comum: agregar não é prover

Vale uma precisão, porque gera confusões caras.

Uma entidade que agrega liquidez e executa as operações dos seus clientes contra esse book está atuando como intermediária na execução. É uma atividade concreta, com uma licença concreta.

Uma entidade que entrega a você o feed agregado para que você execute contra ele no seu próprio book está fazendo algo distinto, que em várias jurisdições exige autorizações distintas.

Do lado comercial, as duas se apresentam como "damos liquidez a você". Do lado regulatório não são a mesma coisa, e a diferença importa quando alguém pergunta sob qual autorização opera cada parte da cadeia.

Na Exura Prime a relação é a primeira: corretoras, prop firms e fundos ingressam como clientes institucionais e executam através de nós. Os detalhes da licença e o link para o registro público da FSC estão em informação legal.

Como avaliar isso em uma demo

A maioria das demos mostra o book bonito e os preenchimentos perfeitos. Para que a demo signifique algo, peça especificamente:

1. Ver a profundidade executável, não a nominal, no tamanho de ticket que você realmente opera
2. Um log completo de uma operação de teste, com timestamps de cada salto
3. Executar durante uma janela de notícias, não em um mercado plano de terça à tarde
4. A taxa de aceitação por fonte dos últimos 30 dias
5. O mapeamento de símbolos do seu catálogo completo, não de uma amostra

Se o sandbox tem paridade com produção, tudo isso é possível antes de assinar qualquer coisa. Se não tem, qualquer teste que você faça descreve um sistema que não é o que você vai usar.

Para o marco geral de avaliação: como uma corretora escolhe liquidez. Para o detalhe técnico de conectividade: FIX API.

Perguntas frequentes

Mais fontes agregadas é sempre melhor? Não. Adicionar fontes com má taxa de aceitação ou alta latência piora o book efetivo mesmo que melhore o nominal. A qualidade das fontes e a política de roteamento importam mais do que o número.

Por que o meu spread abre nas notícias se o agregador tem 15 bancos? Porque os bancos ampliam simultaneamente. A agregação diversifica o risco de uma fonte falhar, não o risco de todo o mercado se mover. Nenhum agregador pode dar a você liquidez que não existe no mercado subjacente; quem prometer isso está descrevendo internalização, não agregação.

Como sei se estão aplicando markup a mim? Perguntando diretamente e pedindo que seja explícito no acordo. Um markup declarado e consistente é normal. Um variável que aparece só em certos momentos é um problema, e só se detecta comparando os seus preenchimentos com uma referência independente.

A profundidade nominal serve para alguma coisa? Para comparar provedores de forma muito grosseira, e pouco mais. Para decidir, peça sempre a executável no seu tamanho real.