Propagação de Blocklist: Eliminando a Rede de Abuso com um Caso Confirmado (PT-BR-1)

Há um momento específico em que a maioria dos programas de abuso perde valor: o momento depois que você vence.

Sua camada de tráfego sinaliza uma conta. Um analista investiga. A evidência é sólida, o caso é confirmado, a conta é banida. E então, horas depois, o mesmo operador está de volta com novas contas, porque a única coisa que sua aplicação de regras atingiu foi uma linha em uma tabela de usuários.

A Anthropic descreveu exatamente essa dinâmica em seu relatório de fevereiro de 2026 sobre campanhas de destilação — uma rede proxy que “gerenciava mais de 20.000 contas fraudulentas simultaneamente”, substituindo-as à medida que eram removidas. A remoção não era o gargalo. A regeneração era mais barata que a remoção.

A solução é fazer com que a aplicação de regras opere sobre identificadores em vez de contas. A API de Listas da Didit é construída em torno de um mecanismo que faz isso em uma única chamada.

Principais pontos

• A blocklisting com reference_session_id faz com que a Didit extraia automaticamente o valor correto da sessão — rosto, documento, telefone, e-mail, IP ou dispositivo — marque o modelo subjacente como blocklisted e vincule a entrada de volta à sessão de origem.
• 12 tipos de entrada: face, document, phone, email, ip_address, device_fingerprint, wallet_address, bank_account, user, business, country, key.
• As blocklists são criadas pelo sistema, uma por tipo de entrada, e imutáveis. Você não pode criá-las, o que torna a aplicação de regras uniforme.
• As entradas entram em vigor imediatamente no momento da verificação. A exclusão de uma entrada desbloqueia a correspondência.
• ip_address aceita um intervalo CIDR, para que você possa colocar na blocklist a infraestrutura em vez de um único endereço.
• As Allowlists nos mesmos 12 tipos mantêm desenvolvedores confiáveis fora de qualquer caminho de escalonamento.

Os dois tipos de lista que importam

A API possui três tipos de lista, e a distinção entre eles é deliberada.

Blocklists são criadas pelo sistema — uma por tipo de entrada — e imutáveis. Você não pode criá-las, renomeá-las ou excluí-las. Você adiciona e remove entradas. Essa restrição é um recurso: significa que “blocklisted” tem exatamente um significado em toda a sua organização, e não há como acabar com quatro blocklists de rosto concorrentes que diferentes serviços verificam de forma inconsistente.

Allowlists são suas para criar. Dispositivos conhecidos e bons, intervalos de endereços, entidades comerciais e usuários vão aqui.

Listas personalizadas são para todo o resto — suas próprias taxonomias, grupos de vigilância, grupos de revisão.

# Encontrar a blocklist de rosto
curl -X GET 'https://verification.didit.me/v3/lists/?list_type=blocklist&entry_type=face' \
  -H 'x-api-key: YOUR_API_KEY'

O mecanismo que importa

Aqui está a maneira comum de colocar algo na blocklist, e é a maneira errada em quase todas as situações reais:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "value": "203.0.113.44" }'

Isso coloca um endereço na blocklist. Enquanto isso, a sessão que você estava investigando também continha um rosto, um número de documento, um telefone, um e-mail e uma impressão digital do dispositivo — cada um deles um identificador que o operador precisa substituir antes de retornar.

A melhor chamada:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "reference_session_id": "a7f3...c19" }'

Passe reference_session_id e a Didit extrai automaticamente o valor correto para o tipo de entrada dessa lista da sessão, marca o modelo subjacente como blocklisted e vincula a entrada de volta à sessão para que o console possa mostrar de onde ela veio.

Três coisas resultam disso, e todas as três importam operacionalmente:

Nenhuma extração manual. Seu analista não lê uma impressão digital do dispositivo em uma tela e a redigita. Erros de transcrição em dados de aplicação de regras são falhas silenciosas — o banimento simplesmente não é acionado, e ninguém descobre.

A proveniência é preservada. Cada entrada se vincula à sessão que a justificou. Quando alguém pergunta em quatro meses por que este dispositivo está bloqueado, a resposta é um clique, não um projeto de arqueologia.

A aplicação de regras é repetível. A mesma chamada contra cada blocklist por tipo de entrada cobre toda a superfície de identificadores da sessão.

Se uma sessão contiver várias instâncias do mesmo tipo, passe value junto com reference_session_id para desambiguar.

Você também pode aplicar regras de fora de uma sessão de verificação. reference_object_uuid junto com metadata.reference_type — transaction, vendor_user ou vendor_business — coloca na blocklist a partir de uma transação ou de um usuário ou negócio do fornecedor, e mantém o mesmo link de volta à origem.

Os 12 tipos de entrada

Tipo de entrada	Bloqueia	Notas
face	A pessoa	Também carregável diretamente via upload de rosto
document	A credencial
phone	O número	Normalizado automaticamente para E.164
email	O endereço
ip_address	O endereço ou intervalo	Aceita CIDR, por exemplo, 10.0.0.0/8
device_fingerprint	A máquina	Mínimo de 8 caracteres alfanuméricos
wallet_address	O endereço on-chain
bank_account	A conta
user	O registro do usuário
business	A entidade
country	A jurisdição
key	Uma chave personalizada

Dois merecem destaque para este problema.

ip_address aceita um intervalo CIDR. Colocar 203.0.113.0/24 na blocklist bloqueia a infraestrutura, não um endereço. Quando uma operação de "farming" é executada em uma sub-rede alugada, esta é a diferença entre uma aplicação de regras que escala e uma aplicação de regras que joga "whack-a-mole". Use com cuidado — um intervalo também cobre usuários reais, e intervalos muito amplos são a maneira de banir silenciosamente a operadora de celular de um país.

face suporta upload direto. Quando você tem uma imagem, mas nenhuma sessão, carregue-a diretamente:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/face-upload/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "image": "<base66-encoded image>" }'

A Didit extrai o dado biométrico. A partir de então, esse rosto é rastreado em cada verificação.

O que acontece depois que uma entrada é registrada

Adicionar a uma blocklist do sistema bloqueia futuras correspondências imediatamente no momento da verificação. Não há atraso de propagação nem processamento em lote.

Na próxima verificação, a aplicação de regras aparece como avisos:

• FACE_IN_BLOCKLIST — correspondência definitiva, verificação recusada. POSSIBLE_FACE_IN_BLOCKLIST é uma correspondência limítrofe abaixo do limite rígido e deve ser encaminhada para revisão, não para recusa.
• IP_ADDRESS_IN_BLOCKLIST / DEVICE_FINGERPRINT_IN_BLOCKLIST — acertos de rede e dispositivo.

Na Pesquisa Facial, uma correspondência de blocklist é a única coisa que define o status para "Declined". Cada correspondência na resposta também contém is_blocklisted, para que uma investigação mostre imediatamente quais partes de um cluster já estão sob aplicação de regras e quais ainda estão ativas.

A remoção é simétrica: a exclusão de uma entrada desbloqueia a entidade correspondente. A aplicação de regras é reversível por design, o que importa porque a aplicação de regras excessivamente ampla é um risco real e você precisa de um caminho limpo de volta.

curl -X DELETE 'https://verification.didit.me/v3/lists/{list_uuid}/entries/{entry_uuid}/' \
  -H 'x-api-key: YOUR_API_KEY'

Allowlists: protegendo os desenvolvedores que você deseja

Uma aplicação de regras que apenas escala eventualmente estrangula o produto. Os mesmos 12 tipos de entrada suportam allowlists, e eles são a válvula de escape.

Coloque na allowlist os intervalos de IP do escritório de um parceiro de design. Coloque na allowlist os dispositivos da equipe de engenharia de um cliente empresarial. Coloque na allowlist uma entidade comercial verificada para que seus usuários nunca cheguem a um caminho de escalonamento. IP_ADDRESS_IN_ALLOWLIST e DEVICE_FINGERPRINT_IN_ALLOWLIST são acionados quando ocorre uma correspondência, para que você possa confirmar que a isenção foi aplicada em vez de presumir que sim.

Este é o mecanismo que torna a aplicação de regras agressiva sustentável. Você pode ter uma política rigorosa em infraestruturas desconhecidas precisamente porque sua população conhecida e boa é explicitamente excluída.

Erros que valem a pena lidar

• 400 — o valor falhou no validador do tipo de entrada, o list_type está incorreto para a operação (por exemplo, um upload de rosto contra uma lista não-facial), ou reference_session_id não possui dados do tipo solicitado. Esse último caso é comum e benigno: nem toda sessão captura todos os identificadores.
• 403 — {"detail": "Você não tem permissão para realizar esta ação."}

Note que um 400 de "session has no data of that type" é esperado quando você itera uma sessão por todas as blocklists por tipo de entrada. Lide com isso como uma ignorada, não uma falha.

Um fluxo de aplicação de regras trabalhado

Um analista confirmou abuso na conta acct_8842.

1. Resolva o cluster primeiro. A Pesquisa Facial no rosto da sessão retorna doze contas; a correlação de dispositivo e IP puxa mais uma dúzia. A aplicação de regras antes da resolução bane uma conta e avisa o operador.
2. Coloque na blocklist a partir da sessão confirmada — reference_session_id contra as blocklists de rosto, dispositivo, IP, e-mail, telefone e documento. Seis chamadas, sem extração manual, proveniência completa.
3. Considere o intervalo. Se a evidência de rede aponta para infraestrutura alugada, uma entrada CIDR cobre a sub-rede. Verifique o que mais vive lá primeiro.
4. Aja no cluster de acordo com sua própria política — as contas que você já identificou não se desbanem sozinhas.
5. Verifique a aplicação de regras. Execute novamente a pesquisa facial. As correspondências agora devem ter is_blocklisted: true.
6. Aguarde a tentativa de regeneração. A próxima conta criada com aquele rosto, dispositivo ou sub-rede é recusada na verificação em vez de aparecer em seu tráfego três semanas depois.

O passo 6 é o ponto principal. O custo do operador para retornar não é mais "criar um novo endereço de e-mail". É "adquirir novo hardware, nova rede e uma nova pessoa".

Casos de uso

Plataformas de API de IA convertendo um caso confirmado de destilação ou abuso em aplicação de regras em todos os identificadores que o operador tocou.

Abuso de testes e créditos onde o mesmo dispositivo e rosto continuam retornando para uma nova alocação gratuita.

Marketplaces bloqueando vendedores removidos de se registrarem novamente sob um novo negócio.

iGaming aplicando a autoexclusão, onde um jogador excluído que retorna é uma falha regulatória e a aplicação de regras em nível de rosto é o único controle confiável.

Perguntas frequentes

Posso criar minha própria blocklist?

Não. As blocklists são criadas pelo sistema, uma por tipo de entrada, e imutáveis — você adiciona e remove entradas. Você pode criar allowlists e listas personalizadas livremente. A restrição mantém "blocklisted" significando uma coisa em todos os lugares.

Com que rapidez uma entrada entra em vigor?

Imediatamente, na próxima verificação.

E se eu colocar algo na blocklist por engano?

Exclua a entrada e a entidade será desbloqueada. É por isso que a proveniência importa — cada entrada criada a partir de uma sessão se vincula a ela, para que você possa auditar para que uma entrada servia antes de removê-la.

Colocar um intervalo de IP na blocklist afeta usuários legítimos nesse intervalo?

Sim, e esse é o risco. Uma entrada CIDR bloqueia tudo dentro dela. Use intervalos quando a evidência aponta para infraestrutura dedicada, use endereços únicos caso contrário, e coloque na allowlist intervalos conhecidos e bons primeiro.

Posso colocar na blocklist a partir de algo que não é uma sessão de verificação?

Sim. reference_object_uuid mais metadata.reference_type (transaction, vendor_user ou vendor_business) cobre transações e usuários ou negócios de fornecedores.

Isso impede a extração de modelo?

Não. Impede que um ator conhecido específico retorne através dos identificadores que você aplicou, e aumenta o custo de regeneração. Detectar a extração em primeiro lugar é o trabalho da sua camada de tráfego, e limitar o que a extração produz é o trabalho da sua camada de modelo. Este é o braço de aplicação de regras de uma defesa de três camadas, não um substituto para as outras duas.

Pronto para começar?

A API de Listas está disponível em todas as contas Didit.

• Leia a documentação — Visão geral da API de Listas e o catálogo de avisos de IP e Dispositivo.
• Veja o produto — Verificação de Usuário.
• Verifique os preços — listados publicamente, pague por sucesso, sem mínimos.
• Comece grátis — business.didit.me, 500 verificações KYC por mês sem custo.