Open Interest: posições em aberto, volume e sinais sem dados futuros

Fluxo de trabalho prático

1. Leia o esquema do contratoRegistre unidades, multiplicadores e contagem unilateral ou bilateral.
2. Alinhar instantâneos disponíveisUtilize apenas as observações recebidas antes de cada limite.
3. Quantidade e valoração separadasNão confunda as variações de preço em USD com novos contratos.
4. Exigir um gatilho de preçoOs ramos de breakout e de recuperação possuem regras de invalidação distintas.
5. Teste a sensibilidade à qualidade dos dadosTeste atrasos, valores obsoletos, rolagens e mudanças de esquema.

Todo contrato tem dois lados.

Sob uma convenção unilateral de contagem de contratos, uma transação na qual ambas as contrapartes abrem novas posições aumenta o OI em um contrato. Se ambas fecharem posições existentes, o OI diminui em um. Se uma posição aberta substituir uma posição fechada, o OI permanece inalterado. O volume de negociação aumenta em todos os três casos. A CME distingue o estoque de contratos em aberto do fluxo de atividade de negociação. [1]

Preço e OI em alta podem acompanhar a criação de posições, mas todo contrato tem dois lados. Identificar quem abriu posições compradas ou vendidas exige dados adicionais classificados por posição. Preço e OI em queda podem ser compatíveis com desalavancagem; isso não prova que toda posição encerrada era uma compra liquidada à força.

As quatro combinações familiares de alta/baixa de preço e de alta/baixa de OI são descrições, não estratégias completas. Elas omitem o momento de entrada, a identidade do participante, os motivos de proteção e os custos de execução. Considere cada combinação como uma possível característica explicativa cuja relação futura deve ser estimada no mercado em questão.

As unidades e as convenções de contagem pertencem à definição da característica.

Leia o multiplicador do contrato, o tipo de produto inverso ou linear e a convenção de contagem API. A documentação da Bybit examinada aqui distingue o openInterest contabilizado em ambos os lados do singleOpenInterest contabilizado em apenas um lado; os produtos inversos usam unidades USD, enquanto os produtos lineares usam unidades de moeda. [2] Preserve o nome do campo e a versão do esquema em vez de alternar silenciosamente entre campos em dados históricos e em tempo real.

O valor de OI em USD pode subir porque o preço do ativo sobe, mesmo sem mudança na quantidade de moedas ou contratos. Para estudar criação de posições, use uma medida consistente de quantidade ou separe os efeitos de preço e quantidade. Não some quantidades de BTC às de ETH. Agregar ativos em USD exige preço de avaliação e instante de referência declarados.

Uma alteração nas especificações do contrato ou uma transição de relatórios unilaterais para bilaterais pode criar uma descontinuidade não relacionada ao comportamento de negociação. Detecte e anote essas alterações. Uma normalização visualmente suave pode ocultar a quebra, preservando um sinal falso de variação percentual; portanto, mantenha os metadados brutos do campo e da conversão.

Nos futuros com vencimento, a rolagem também importa. A queda de OI no contrato mais próximo pode refletir migração para o seguinte, em vez de menor exposição total do mercado. Defina se a variável acompanha um contrato específico ou uma agregação documentada dos vencimentos elegíveis.

Combine os snapshots disponíveis na decisão, não os mais próximos no tempo

Utilize o snapshot mais recente efetivamente recebido antes da decisão. Uma junção por tempo mais próximo pode selecionar uma observação futura e vazar informações. Limite o preenchimento futuro a uma idade máxima declarada; valores obsoletos como OI podem, caso contrário, fazer com que um mercado ativo pareça inalterado. Um conjunto de dados robusto armazena tanto o carimbo de data/hora da observação quanto o carimbo de data/hora em que o valor se tornou disponível.

Para uma comparação de horizontes, recupere a quantidade elegível mais recente no limite atual e no limite anterior. Exija uma quantidade anterior positiva, identidade de contrato consistente e idade aceitável para ambas as observações. O pseudocódigo verifica ambos os instantâneos em relação aos seus respectivos limites.

Não interpole linearmente entre um snapshot passado conhecido e outro futuro para estimar um valor intradia. Isso serve à visualização retrospectiva, mas introduz informação futura. Se faltarem os horários históricos de disponibilidade, informe a limitação e teste atrasos conservadores de publicação, em vez de presumir acesso imediato.

Calcule a variação de preço e o volume negociado ao longo do horizonte de correspondência usando suas próprias regras de disponibilidade. Salve os horários reais dos snapshots, pois atualizações irregulares podem significar que duas comparações nominais de cinco minutos podem abranger intervalos efetivos diferentes. Rejeite ou analise separadamente as observações com discrepância excessiva de alinhamento.

Meça a idade de cada instantâneo em relação ao seu próprio limite: o valor atual em relação a t e o valor anterior em relação a t−horizon. Ambos devem ter identidade de contrato, unidades, multiplicadores e convenções de contagem compatíveis; comparable_quantity_schema rejeita uma alteração não tratada. A idade usa o carimbo de data/hora da observação, enquanto received_at estabelece se o valor chegou.

at decision_time t:
    oi = latest_snapshot(received_at <= t, instrument=contract)
    prev = latest_snapshot(received_at <= t-horizon, instrument=contract)
    if missing(oi,prev): return INSUFFICIENT_DATA
    if stale(oi, asof=t, max_age=max_age): return INSUFFICIENT_DATA
    if stale(prev, asof=t-horizon, max_age=max_age): return INSUFFICIENT_DATA
    if not comparable_quantity_schema(oi,prev): return INCOMPATIBLE_DATA
    if prev.quantity <= 0 or oi.quantity < 0: return INVALID_DATA
    delta_oi = oi.quantity / prev.quantity - 1
    delta_price = last_known_price(t) / last_known_price(t-horizon) - 1
    volume = sum(trade.size for trade in contract_trades
                 if t-horizon < trade.exchange_time <= t
                 and trade.received_at <= t)
    emit_features(delta_oi,delta_price,volume,oi.schema_version)

Quantidade de contratos abertos e fluxo negociado são medidas distintas

Comece com OI de 1,000 contratos sob a convenção de contagem de um só lado. Uma transação de 100 contratos em que ambas as partes abrem posições eleva OI para 1,100 e adiciona 100 ao volume. Depois, uma transação de 60 contratos em que ambas fecham posições reduz OI para 1,040 e acrescenta 60 ao volume. O volume total negociado é 160, enquanto a variação líquida de OI é apenas 40.

Para um contraexemplo de avaliação, a quantidade permanece 100 BTC enquanto o preço sobe de 50,000 para 55,000. O valor nocional em USD sobe de 5 milhões para 5.5 milhões, um aumento de 10% sem alteração na quantidade. Um filtro que classificasse isso como um aumento de 10% em novos contratos estaria atribuindo incorretamente um efeito de avaliação à criação de posições.

Em caso de falha de temporização, usar um snapshot 10:05 OI para justificar uma entrada 10:00 é inválido, mesmo que o arquivo final esteja devidamente ordenado por tempo de observação. Interpolar entre 09:55 e 10:05 também vaza o snapshot futuro para o recurso 10:00. A ordenação não corrige a disponibilidade.

O gráfico ilustra o aumento e posterior diminuição da quantidade. Ele não identifica os participantes, não distingue saídas voluntárias de liquidações forçadas nem mostra o retorno do investimento. Essas conclusões exigem outras observações e uma questão de pesquisa definida separadamente.

Duas hipóteses de preço-OI podem ser testadas separadamente.

A variante proposta de continuação após rompimento parte de um candidato baseado no preço definido de antemão e de um fechamento acima da resistência. Teste aumento de OI medido em quantidade num horizonte fixo; depois acrescente RVOL elevado como filtro. Horizonte e limiar são escolhas de pesquisa. A entrada segue a confirmação e o stop vem da estrutura do preço; OI não define sozinho um stop válido.

A variante proposta de washout-reclaim exige uma varredura abaixo de uma mínima, queda significativa na quantidade de OI e recuperação desse nível pelo preço. Espere confirmação posterior antes de entrar comprado. Cancele por invalidação estrutural ou tempo esgotado, em vez de comprar só porque OI caiu. Uma queda de 5% ou 10% não é constante universal de mercado.

Se adicionar dados de liquidações, diferencie o lado da posição liquidada do lado agressor ou taker no feed de negócios. Os rótulos podem se referir a objetos diferentes. Por exemplo, não interprete o encerramento de uma posição comprada copiando o rótulo Buy de uma API para a semântica de outra.

Separe as variantes desde o início. Um rompimento que falha enquanto OI cai não vira automaticamente um washout bem-sucedido. Um novo candidato precisa de seu próprio instante de evento, confirmação e regra de risco. Preserve o candidato original que falhou no registro de avaliação.

Valide os dados antes de avaliar o filtro.

Giagkiozis e Said examinam dados tick a tick de dois períodos de 2023 em sete bolsas e relatam inconsistências de OI e liquidações. O material lido aqui é o resumo do artigo revisado; seu conjunto de dados não foi reproduzido. [3] Isso motiva a verificação de snapshots, negócios e esquemas de dados, mas não justifica rejeitar todos os feeds atuais das bolsas.

Compare o mesmo detector de preço com e sem OI; depois adicione RVOL ou variáveis de liquidação uma de cada vez. Verifique atraso de publicação, proporção de valores obsoletos, rolagens e mudanças de API. Inclua funding, spread, slippage e empréstimo de ativos quando aplicável; teste também um atraso extra de um ciclo de snapshots.

Relate expectativa líquida, número de operações, drawdown e oportunidades rejeitadas por falta de dados. Um filtro que só funciona com valores de OI corrigidos depois não é comprovadamente executável no instante original. Um resultado útil pode ser que a qualidade dos dados ou o atraso de publicação supere qualquer benefício preditivo aparente.

Erros comuns

Lista de verificação antes de usar este método

Marque cada item após verificá-lo nos seus dados. O progresso fica salvo neste navegador; isso não certifica que a estratégia seja lucrativa.

• Anote exatamente o campo OI e a versão do esquema.
• Separe quantidade de valor nocional em USD.
• Não infira mais posições compradas do que vendidas a partir do conjunto de OI.
• Use junções com base no momento do recebimento, nunca snapshots futuros mais próximos.
• Verifique a idade dos snapshots atual e anterior.
• Trate os multiplicadores de contrato e as rolagens de vencimento.
• Incluir os custos de financiamento e execução aplicáveis.
• Compare com uma base de referência que considere apenas o preço.

Fontes de pesquisa

Cada fonte sustenta a definição ou evidência descrita ao lado. O pseudocódigo, os exemplos sintéticos e os parâmetros propostos exigem validação separada.

1. Open InterestCME Group. Definição de contratos em aberto e sua distinção em relação ao volume de negociação. Verificado em: 2026-10-11.
2. Get Open InterestBybit. Unidades de produto, campos de contagem e ressalvas de atualização; manter a versão usada na implementação. Verificado em: 2026-10-11.
3. Reconciling Open Interest with Traded Volume in Perpetual SwapsGiagkiozis e Said. O resumo revisado e seu escopo de amostra 2023 foram examinados; nenhuma reprodução independente foi realizada. Verificado em: 2026-10-11.

Métodos relacionados