Retenção de dados

Um provedor de KYC é puxado para dois lados ao mesmo tempo. As regras de AML exigem guardar a evidência de uma verificação de identidade por anos. Os princípios de proteção de dados exigem não guardar dados biométricos um dia a mais do que houver base para isso.

A única forma de satisfazer os dois é apagar segundo um cronograma. Esta página descreve esse cronograma, o que ele remove e — igualmente importante — o que ele deliberadamente não remove.

Estes prazos são uma política, não aconselhamento jurídico

Os prazos abaixo foram definidos pelo negócio e implementados em código. Eles não estabelecem a sua obrigação. A exigência exata varia conforme a atividade regulada da sua organização, e não apenas conforme o país. Confirme com o jurídico antes de se apoiar neles.

Os prazos

Jurisdição	Imagens mantidas por
Paraguai	5 anos
Resto da América Latina	8 anos
Desconhecida	8 anos

Medidos a partir de submitted_at — o momento em que a verificação foi enviada, não o momento em que ela foi concluída.

Por que "desconhecida" recebe o prazo mais longo, e não o mais curto

Esta é a parte que a maioria das pessoas espera que funcione ao contrário, então vale explicar em vez de apenas afirmar.

Os dois erros não são simétricos:

• Apagar cedo demais destrói evidência que você é legalmente obrigado a guardar. É irrecuperável. Nada falha visivelmente na hora; você descobre durante uma auditoria, quando o registro é solicitado e não está lá.
• Guardar por tempo demais é um custo e uma questão de proteção de dados. É corrigível amanhã.

Por isso, todo caso em que a jurisdição não é certa recebe o prazo mais longo.

Isso não é cautela teórica. A nacionalidade vem do OCR do documento, e em tráfego real 9 de 21 verificações não trouxeram nacionalidade nenhuma, enquanto uma leu PYG — o código da moeda paraguaia, que o modelo confundiu com uma nacionalidade. Uma política baseada nesse campo sem um padrão seguro teria apagado silenciosamente registros reais três anos antes da hora.

Pela mesma razão, várias grafias são mapeadas para o prazo paraguaio, e não apenas o código ISO alpha-2: PY, PRY, PYG, PARAGUAY, PARAGUAYA, PARAGUAYO. Qualquer outra coisa — inclusive um campo vazio — recebe o padrão de 8 anos.

O piso

Os dois prazos são lidos do ambiente (VERIDIA_RETENTION_DAYS_PY, VERIDIA_RETENTION_DAYS_DEFAULT), mas um piso rígido de 5 anos é aplicado depois da leitura do ambiente. Nenhum valor de configuração, por mais equivocado que seja, consegue fazer com que algo mais recente que isso seja apagado. Um erro de digitação numa variável de deploy não consegue destruir evidência viva.

O piso eleva; ele nunca reduz. Definir um prazo maior que 8 anos funciona. Definir um menor que 5 anos não tem efeito nenhum.

O que é apagado, e o que não é

A varredura apaga apenas os objetos de imagem: a frente do documento, o verso do documento e a selfie.

A linha do banco de dados sobrevive. Isso é deliberado — a linha é o registro da verificação de identidade, e destruí-la anularia o propósito de reter qualquer coisa. O que sobrevive, indefinidamente, é:

Categoria	Campos
Identidade	extracted_name, extracted_document_number, extracted_date_of_birth, extracted_nationality, extracted_document_type
Resultado	status, verdict, confidence, scores, flags, breakdown, errors
Vínculo	id, tenant_id, user_ref
Trilha de auditoria	submitted_at, completed_at, images_deleted_at, reviewed_by, reviewed_at, review_note
Contexto da requisição	client_ip, user_agent, latency_ms

Duas lacunas honestas nessa tabela

client_ip e user_agent são dados pessoais e não fazem parte do registro da verificação de identidade que a retenção pretende preservar. Eles são mantidos indefinidamente hoje porque nada os expurga nem os anonimiza. Não existe mecanismo para removê-los.

A caixa de saída de entrega de webhooks armazena o payload completo de cada evento, incluindo fieldsExtracted (nome, número do documento, data de nascimento). Essas linhas também não são tocadas pela varredura de retenção. Se você está montando um inventário de onde vivem os dados de identidade, inclua as duas coisas.

Como a varredura roda

Um timer do systemd no host do backend executa o varredor uma vez por dia.

Agendamento	04:30 no horário local do servidor (atualmente America/Argentina/Buenos_Aires, UTC−3)
Jitter	Até 10 minutos após o horário agendado
Execuções perdidas	Recuperadas no próximo boot (Persistent=true) — um reboot não pula um dia
Limite por lote	200 verificações por execução

A varredura funciona em dois estágios, de propósito. Um filtro SQL seleciona candidatos usando o prazo configurado mais curto, para que nada elegível seja perdido; a decisão por jurisdição é então tomada no código da aplicação, onde a política é escrita uma única vez e pode ser testada.

Para cada verificação expirada, ele apaga os objetos de imagem e, em seguida:

A linha só é marcada como apagada se todos os objetos tiverem sido efetivamente removidos. Se um único delete falhar, a marca fica sem ser definida e a varredura do dia seguinte tenta de novo.

Isso importa mais do que parece. A alternativa — marcar a linha de qualquer jeito — produz um banco de dados que certifica uma destruição que não aconteceu, enquanto o arquivo continua parado no armazenamento. Um registro falso de exclusão é pior que nenhuma exclusão, porque não pode ser detectado olhando para o banco de dados.

Estado atual

Nenhuma verificação no sistema tem idade suficiente para expirar ainda, então a varredura não apagou nada até hoje. Ela roda diariamente, em modo de exclusão, reportando zero linhas elegíveis. Foi habilitada agora, e não daqui a anos, com base no raciocínio de que um controle que alguém precisa lembrar de ligar depois não é um plano.

Exclusão sob solicitação

Não existe mecanismo implementado para apagar os dados de uma pessoa específica sob solicitação. Nenhum endpoint de API, nenhum controle no painel, nenhum caminho self-service.

Uma solicitação desse tipo hoje significa uma operação manual no banco de dados e no armazenamento, executada por um operador. Se suas obrigações incluem atender pedidos de exclusão dentro de um prazo fixo, leve isso em conta: veja GDPR para o que existe e o que não existe.

Note também que exclusão e retenção para AML puxam em direções opostas. Apagar um registro que você é legalmente obrigado a reter cria um problema diferente de mantê-lo. Qual das duas te obriga é uma questão jurídica, não técnica.

A sua própria retenção

A retenção do lado da Veridia não diz nada sobre as cópias que você guarda.

Todo webhook que você recebe contém PII de identidade. Se você armazena o payload, registra o corpo da requisição em log ou o encaminha para um serviço de analytics ou de rastreamento de erros, essas cópias são suas para inventariar e expirar. O mesmo vale para qualquer veredito que você guarde em cache a partir de GET /v1/verify/{id}.