Como comparar (diff) uma lista de sanções

Todo programa de triagem de sanções eventualmente faz a mesma pergunta: "algo mudou desde a última vez que baixamos esta lista?" A resposta ingênua — comparar o arquivo de hoje com o de ontem, linha por linha — falha na prática, por razões que não têm nada a ver com esforço e tudo a ver com a forma como as autoridades emissoras de fato publicam e revisam suas listas. Comparar corretamente uma lista de sanções é uma disciplina específica e aprendível, e errar nisso produz dois modos de falha opostos: novas designações não detectadas e alertas de verdadeiro-positivo desatualizados sobre pessoas ou entidades que foram removidas meses atrás.

Por que uma comparação de texto ingênua falha

Listas de sanções não são registros somente de acréscimo (append-only). Entre quaisquer dois snapshots, os registros podem:

• Ser adicionados — uma nova designação.
• Ser removidos — um delistamento, uma licença ou uma reversão judicial.
• Ser alterados no próprio registro — uma data de nascimento corrigida, um pseudônimo recém-divulgado, uma reclassificação de programa — sem que a pessoa ou entidade subjacente mude em nada.
• Ser renumerados ou reidentificados — a mesma entidade do mundo real recebe um novo ID de registro porque a autoridade emissora migrou de sistema, reestruturou sua lista ou fundiu duas listas legadas em uma só.

Uma comparação de texto linha por linha confunde essas quatro situações. Ela relata uma alteração como uma exclusão seguida de uma adição, deixa passar completamente uma renumeração (ou, pior, a relata como uma remoção e uma nova adição para uma entidade que nunca foi de fato delistada), e não dá nenhum sinal sobre quais mudanças são urgentes.

O problema do identificador é o verdadeiro problema

A parte mais difícil de comparar listas não é detectar que algo mudou — é provar que o registro A no snapshot de ontem e o registro B no snapshot de hoje são (ou não são) a mesma entidade do mundo real. A maioria das autoridades emissoras atribui um identificador persistente a cada registro justamente para que os usuários posteriores possam rastreá-lo entre revisões, mas esse identificador não tem garantia de sobreviver a uma migração de plataforma.

O Reino Unido é um exemplo ao vivo disso. As designações de sanções financeiras migraram da antiga Consolidated List da OFSI para a UK Sanctions List publicada pela FCDO em 28 January 2026, e as pessoas recém-designadas agora recebem um "Unique ID" em vez do antigo "OFSI Group ID" (orientação do GOV.UK). Um pipeline de triagem que vinculou seu histórico de correspondências ao OFSI Group ID e não considerou a mudança de esquema de identificadores corre o risco de tratar cada designação britânica pré-existente como uma entidade nova no dia em que reingerir a lista sucessora — um sinal falso exatamente no momento em que o regime subjacente não mudou de fato. O erro inverso é igualmente real: mapear silenciosamente IDs antigos para novos sem verificar a continuidade do referente pode, com a mesma facilidade, fundir duas entidades genuinamente distintas.

O que comparar — quatro categorias, não uma

Trate cada atualização de lista como algo que produz quatro saídas distintas, não um único grupo de "alterados":

1. Adições verdadeiras. Um registro sem correspondência plausível no snapshot anterior. Este é o caso para o qual todo mundo constrói suas soluções — também é o mais fácil de acertar, porque não há nada contra o que reconciliar.
2. Remoções (delistamentos). Um registro presente no snapshot anterior, ausente no atual, sem registro sucessor. Esta é a categoria que os programas de triagem mais frequentemente constroem de forma insuficiente. O nosso próprio resumo de aplicação da lei de junho abordou um exemplo concreto: a OFAC removeu um conjunto de designações da SDN relacionadas à Rússia em 24 June 2026, no mesmo mês em que adicionou novas. Um pipeline que só ingere adições e nunca processa delistamentos acumula alertas de verdadeiro-positivo desatualizados — clientes que já eliminaram sua exposição a sanções meses atrás continuam disparando alertas, o que corrói a confiança em todo o programa de triagem e enterra os alertas que ainda estão ativos.
3. Alterações no próprio registro. Mesmo identificador, mesma entidade, campos alterados — um pseudônimo corrigido, um identificador adicionado, uma mudança de tag de programa. Isso exige uma comparação em nível de campo, não em nível de registro, porque o significado varia: uma correção de pseudônimo é informativa, mas uma reclassificação de programa (digamos, de uma lista setorial para uma designação de bloqueio total) pode mudar o que é legalmente exigido de uma contraparte que tenha esse nome em sua carteira.
4. Remapeamento de identificador. O caso do Reino Unido acima — a entidade é contínua, mas seu ID persistente mudou por causa de uma mudança na plataforma de origem ou na estrutura da lista. Esta categoria é invisível tanto para uma comparação ingênua quanto para uma comparação baseada puramente na correspondência de identificadores; ela exige verificar a continuidade por meio de sinais secundários (nome, outros identificadores, data de designação) quando o ID principal muda.

Um padrão viável

A abordagem confiável trata cada lista como um corpus versionado, não como um arquivo para sobrescrever:

• Mantenha todos os snapshots históricos, cada um marcado com sua data de referência e (quando a autoridade publica um) seu próprio identificador de versão.
• Compare em nível de campo dentro de um identificador correspondente, não apenas em nível de registro, para que uma alteração seja legível como "o que mudou," em vez de uma exclusão e recriação.
• Quando um identificador desaparece, verifique ativamente se há um sucessor antes de registrá-lo como uma remoção — uma correspondência de nome e atributos contra o novo snapshot, não apenas uma verificação de ausência.
• Registre as remoções como eventos de delistamento de primeira classe, com um carimbo de data/hora, não como exclusões silenciosas — a própria remoção faz parte da trilha de auditoria de que uma equipe de compliance precisa para explicar por que um nome que costumava ser um resultado positivo deixou de ser.

Esse último ponto é o fio condutor que nos leva de volta a por que isso importa: um resultado positivo de triagem é tão defensável quanto sua linhagem — qual autoridade, qual lista, qual versão, a partir de quando. A mesma disciplina se aplica, inversamente, a um não-resultado que costumava ser um resultado positivo. Se você não consegue mostrar quando e por que um nome deixou de dar correspondência, "não fazemos mais triagem contra isso" não é uma resposta que um regulador aceitará com base na confiança.

Veja isso na prática

Nossa linha do tempo de designações recentes mostra as adições assim que ocorrem, por fonte, com datas. Várias fontes também têm sua própria visualização de linha do tempo por fonte para isolar a atividade de uma lista específica. O catálogo de fontes documenta a autoridade emissora, o formato e a cadência de atualização de cada lista — os fatos iniciais de que você precisa antes de construir um pipeline de comparação contra ela. E navegar por uma fonte diretamente mostra o estado atual contra o qual você está comparando, registro por registro.