Self-match prevention e wash trades: como funcionam

A prevenção de self-match é uma função do matching engine que impede que duas ordens da mesma firma negociem entre si. Na entrada, as ordens recebem um identificador. Quando duas ordens com o mesmo identificador cruzariam, o engine cancela uma delas, ou ambas, antes de qualquer negócio ser registrado. A prevenção de self-match é uma configuração da infraestrutura do venue. A proibição de wash trades é uma exigência legal. As duas não cobrem exatamente a mesma situação.

Essa regra passa a ser relevante no momento em que uma segunda estratégia começa a cotar um instrumento que a primeira já cota. Um grid bot com duas escadas no mesmo símbolo está sujeito à mesma regra que uma mesa de banco.

Como funciona a prevenção de self-match no matching engine

Toda ordem recebida por um venue traz campos que o engine lê antes do matching: lado, preço, quantidade e validade. A prevenção de self-match acrescenta outros dois. O primeiro é um identificador, número ou string que informa a qual firma, conta ou grupo de estratégias a ordem pertence. O segundo é uma instrução que diz ao engine o que fazer quando duas ordens ativas com esse identificador estiverem prestes a negociar entre si.

A verificação ocorre no instante em que uma ordem agressora alcança o preço de uma ordem resting com a qual faria negócio. Quatro resultados são comuns:

• Cancelar a ordem resting. A ordem recebida continua entrando no livro e pode negociar com o que estiver atrás dela naquele preço.
• Cancelar a ordem recebida. A ordem resting mantém sua posição na fila, e a ordem agressora é removida.
• Cancelar as duas ordens. É a configuração mais rigorosa.
• Reduzir e cancelar. A ordem maior é reduzida pelo tamanho da menor, a menor é cancelada e o saldo da maior continua ativo.

Não há negócio em nenhum dos quatro casos. Nada aparece no tape, nada entra no registro de fills e chega um cancelamento não solicitado em uma das pontas, ou nas duas.

A posição na fila é o custo silencioso. Uma ordem resting cancelada pela instrução cancel-oldest perde tudo o que acumulou enquanto aguardava. Sob prioridade preço-tempo, essa perda é total: ao ser reenviada, a ordem fica atrás de todos que entraram na fila enquanto ela estava no livro. Nosso guia sobre como estimar a posição na fila explica quanto vale esse lugar.

Um instrumento, vários livros

A verificação é feita por venue. O engine compara apenas as ordens que ele próprio mantém. Duas ordens suas resting em dois livros diferentes não são visíveis uma para a outra, e nenhum mecanismo do mercado acionário americano faz essa verificação entre venues. Uma única ação americana pode ser cotada simultaneamente em vários livros. O painel abaixo conta os venues distintos que cotaram e registraram negócios em seis ações conhecidas durante uma janela de quinze minutos na manhã de 10 de junho de 2026.

SELECT
    q.ticker          AS ticker,
    q.quoting_venues  AS quoting_venues,
    t.printing_venues AS printing_venues
FROM
(
    SELECT
        ticker,
        countDistinct(bid_exchange) AS quoting_venues
    FROM global_markets.cache_stocks_quotes
    WHERE ticker IN ('AAPL', 'MSFT', 'NVDA', 'SPY', 'KO', 'JNJ')
      AND sip_timestamp >= toDateTime('2026-06-10 14:00:00', 'UTC')
      AND sip_timestamp <  toDateTime('2026-06-10 14:15:00', 'UTC')
      AND bid_price > 0
    GROUP BY ticker
) AS q
INNER JOIN
(
    SELECT
        ticker,
        countDistinct(exchange) AS printing_venues
    FROM global_markets.stocks_trades
    WHERE ticker IN ('AAPL', 'MSFT', 'NVDA', 'SPY', 'KO', 'JNJ')
      AND sip_timestamp >= toDateTime('2026-06-10 14:00:00', 'UTC')
      AND sip_timestamp <  toDateTime('2026-06-10 14:15:00', 'UTC')
    GROUP BY ticker
) AS t ON t.ticker = q.ticker
ORDER BY quoting_venues DESC, ticker

AAPL recebeu ofertas de compra de 16 venues distintos naquele intervalo, e houve prints em 17 deles. Mesmo o nome com menor liquidez do painel recebeu cotações de 11 venues. Um smart order router que, por desenho, divide ordens-filhas colocará suas duas estratégias em livros diferentes durante boa parte do tempo. Nesse caso, não se aplica nenhuma verificação no nível do engine. As firmas fecham essa lacuna upstream, na camada de gerenciamento de ordens, antes que qualquer ordem saia do prédio. Suas próprias ordens resting em lados opostos, ao mesmo preço, em dois livros também criam um mercado travado ou cruzado, sujeito a regras próprias.

Quantos matches um livro realiza em uma sessão

A verificação de self-match está no caminho de cada match realizado pelo engine. Em um ativo líquido, esse caminho permanece movimentado durante todo o dia. O painel abaixo divide uma sessão completa de uma ação em intervalos de quinze minutos e conta os prints em cada intervalo, mantendo aqueles que tiveram pelo menos 200.

SELECT
    formatDateTime(toStartOfInterval(toTimeZone(sip_timestamp, 'America/New_York'), INTERVAL 15 MINUTE), '%H:%i') AS et_time,
    count() AS trade_count
FROM global_markets.stocks_trades
WHERE ticker = 'AAPL'
  AND sip_timestamp >= toDateTime('2026-06-10 08:00:00', 'UTC')
  AND sip_timestamp <  toDateTime('2026-06-11 04:00:00', 'UTC')
GROUP BY et_time
HAVING count() >= 200
ORDER BY et_time

Às 04:00 ET, esse nome registrou 9402 negócios em quinze minutos. Às 19:45 ET, registrou 1345, em 64 intervalos que superaram o piso de 200 prints. Cada print corresponde a um par de ordens reunidas pelo engine. Antes de permitir o negócio, a verificação lê os identificadores dos dois lados. Toda ordem que permanece no livro pode posteriormente encontrar outra ordem da mesma conta durante o dia.

O que o tape mostra quando ocorre um self-trade

Um self-match impedido não deixa registro. O tape mostra apenas o que foi executado, e cada print chega com condition flags: códigos atribuídos pelo venue responsável pelo reporte para descrever como o negócio ocorreu. O painel abaixo divide uma sessão completa de uma ação por esses códigos.

SELECT
    condition_name,
    print_count,
    round(100 * print_count / sum(print_count) OVER (), 2) AS share_pct
FROM
(
    SELECT
        cc.id        AS condition_id,
        any(cc.name) AS condition_name,
        count()      AS print_count
    FROM
    (
        SELECT toInt32(arrayJoin(conditions)) AS condition_id
        FROM global_markets.stocks_trades
        WHERE ticker = 'AAPL'
          AND sip_timestamp >= toDateTime('2026-06-10 08:00:00', 'UTC')
          AND sip_timestamp <  toDateTime('2026-06-11 04:00:00', 'UTC')
    ) AS f
    INNER JOIN
    (
        SELECT
            toInt32(id)  AS id,
            any(name)    AS name
        FROM global_markets.stocks_condition_codes
        WHERE asset_class = 'stocks'
          AND has(data_types, 'trade')
        GROUP BY id
    ) AS cc ON cc.id = f.condition_id
    GROUP BY condition_id
)
ORDER BY print_count DESC
LIMIT 10

Odd Lot Trade representa 48.34% dos prints com flags naquela sessão, e o painel lista os 10 flags mais comuns do dia. Observe o que não aparece. Nenhum código informa que duas ordens vieram da mesma firma. Um self-trade executado se parece com qualquer outro negócio naquele preço. Por isso, a vigilância depende do tape, dos identificadores dos participantes mantidos pelo venue e dos números de conta associados às ordens.

Onde termina a prevenção de self-match e começa a lei sobre wash trades

A prevenção de self-match é um serviço do venue. Você opta por usá-lo e o configura. Se não fizer isso, o engine executará normalmente o match entre suas duas ordens. A proibição de wash trades não é opcional e não depende de nenhuma configuração.

A Section 9(a)(1) do Securities Exchange Act de 1934 alcança transações com valores mobiliários que não alteram a titularidade beneficiária e que são realizadas para criar uma aparência enganosa de atividade de negociação. O Commodity Exchange Act contém a regra equivalente para futuros, e a CME Rule 534 a reproduz no regulamento da bolsa. A FINRA Rule 5210 também se aplica a broker-dealers, e seu material suplementar trata diretamente de self-trades: negócios entre dois algoritmos não relacionados de uma mesma firma não são, por si só, uma violação. Ainda assim, espera-se que a firma mantenha políticas para analisá-los e reduzi-los.

Duas consequências decorrem disso para quem opera mais de uma estratégia. Um self-cross pode violar a proibição em um venue no qual você não tenha configurado nenhuma instrução de self-match, porque a regra se aplica à transação e à intenção por trás dela. Um self-cross bloqueado pela prevenção de self-match não configura violação: impedir o negócio é justamente o objetivo da ferramenta.

Como os operadores configuram a função: CME, ICE, LME e MiFID II

Na CME Globex, a prevenção de self-match usa um identificador enviado na entrada da ordem. As firmas registram os identificadores que utilizarão, cada ordem recebe um deles e uma instrução associada informa qual lado o engine deve cancelar quando duas ordens com o mesmo identificador se encontrarem. Ordens enviadas sem identificador seguem o matching normal. Essa é a armadilha para um operador novo: a configuração padrão é desligada.

A ICE opera a Self-Trade Prevention Functionality, configurada com base no identificador da firma de trading, e não ordem a ordem, com a mesma família de resultados de cancelamento. A London Metal Exchange oferece Self-Execution Prevention na LMEselect para identificadores de trading dos membros. Na Europa, o Article 17 da MiFID II atribui a qualquer investment firm envolvida em negociação algorítmica o dever de manter sistemas e controles, incluindo testes, kill functionality e prevenção de negociação desordenada. O Article 48 atribui um dever paralelo ao próprio venue, e as ferramentas de prevenção no nível do venue tornaram-se equipamento padrão junto com essas exigências.

A configuração fica no nível da conta ou da firma, e não símbolo a símbolo. O tamanho da superfície de opções de um único ativo subjacente mostra por quê.

SELECT
    toString(date)                 AS session_date,
    countDistinct(ticker)          AS contracts_traded,
    countDistinct(strike_price)    AS strikes_traded
FROM global_markets.options_greeks
WHERE underlying_symbol = 'AAPL'
  AND date >= '2026-06-01'
  AND date <= '2026-06-30'
  AND volume > 0
  AND iv_converged = 1
GROUP BY date
ORDER BY date

Em 2026-06-01, um ativo subjacente tinha 1579 contratos negociáveis separadamente com volume, distribuídos por 112 strikes. O painel cobre 21 sessões de formato semelhante. Configurar uma regra contrato a contrato é impraticável nessa escala. O identificador é associado à conta e acompanha todas as ordens enviadas por ela.

O modo de falha que seus logs de fills não explicarão

Veja como isso ocorre na prática. Uma instrução cancel-newest elimina a ordem que você acabou de enviar, assim que ela chega, antes que possa negociar. Dentro do bot, a sequência aparece como uma nova ordem seguida de um cancelamento que nenhum código seu solicitou. Não há fill, rejeição nem mensagem de erro indicando o motivo. Por isso, operadores que encontram esse comportamento pela primeira vez costumam procurar um problema no próprio fluxo de cancelamento.

Dois hábitos tornam o evento mais claro. Registre integralmente as mensagens de status de ordens enviadas pelo venue, em vez de usar apenas um resumo normalizado. O motivo da prevenção geralmente vem em um campo dessa mensagem. Gere um alerta para qualquer cancelamento que não tenha sido originado pelo seu próprio código. Esse alerta deve ficar junto dos seus disjuntores de negociação automatizada, porque a falha pertence à mesma classe: o venue alterou o estado da sua ordem, mas o processo continuou como se nada tivesse acontecido.

Perguntas frequentes

O que é prevenção de self-match?

É uma verificação do matching engine que impede que duas ordens com o mesmo identificador de firma ou conta negociem entre si. Quando elas fariam match, o engine cancela a ordem resting, a ordem recebida ou ambas, conforme a instrução associada à ordem.

Um self-trade é a mesma coisa que um wash trade?

Não. Self-trade é qualquer execução entre duas ordens do mesmo titular beneficiário. Wash trade é um self-trade realizado sem exposição genuína ao risco de mercado e com a intenção de criar uma aparência enganosa de atividade. Self-trades não intencionais entre algoritmos não relacionados recebem tratamento diferente dos negócios combinados, mas as firmas ainda devem monitorá-los.

A prevenção de self-match funciona entre diferentes bolsas?

Não. Cada matching engine aplica a verificação apenas às ordens em seu próprio livro. Duas ordens de uma mesma firma resting em dois venues podem negociar entre si. Nesse caso, a responsabilidade passa a ser das verificações pré-trade da própria firma, acima dos venues.

Por que minha ordem foi cancelada sem fill e sem motivo?

Uma instrução cancel-newest de self-match é uma possibilidade. O venue cancelou a ordem na chegada, antes que ela pudesse negociar com uma ordem resting que carregava seu identificador. O motivo geralmente aparece como um campo na mensagem de cancelamento do venue, e não como uma rejeição.

Quais venues exigem um identificador de prevenção de self-match?

Os requisitos variam por venue e produto. A CME exige um identificador na entrada da ordem, registrado previamente. A ICE e a London Metal Exchange oferecem suas próprias configurações no nível da firma, e os venues europeus estão sujeitos aos deveres de sistemas e controles previstos na MiFID II. O regulamento do venue para o produto negociado é a referência oficial.

Cada painel traz o SQL que o produziu. Expanda qualquer um deles para consultá-lo. Para contar os venues que cotam um nome negociado por você ou dividir uma sessão por condition flags, faça a pergunta em linguagem simples no terminal Strasmore.