Compliance
Esta seção descreve mecanismos: o que o sistema faz com os dados de identidade, em que periodicidade e com quais salvaguardas. Toda afirmação aqui foi escrita para ser verificável contra o código em execução ou a configuração.
O que esta seção não é
A Veridia não é certificada, auditada nem aprovada por nenhum padrão. Não existe relatório SOC 2, não existe certificação ISO, não existe auditoria externa de segurança e nenhum regulador revisou ou aprovou este sistema.
Estas páginas não dizem que a Veridia "está em conformidade com" o GDPR, a SEPRELAD, a LGPD ou qualquer outra coisa. Compliance é uma propriedade da sua atividade regulada, não da página de um fornecedor. O que podemos te dizer é exatamente o que o software faz, para que você e seu jurídico decidam se isso atende às suas obrigações.
Se você procura um documento para entregar a um auditor como evidência de certificação, ele não existe. Se você procura uma descrição precisa de como os dados de identidade são tratados para poder concluir sua própria avaliação, é para isso que esta seção serve.
As páginas
| Página | O que cobre |
|---|---|
| Retenção de dados | Por quanto tempo as imagens são mantidas, por jurisdição; o que é apagado e o que sobrevive para sempre; a varredura diária que faz isso |
| SEPRELAD e AML | O que o screening de sanções realmente faz, e por que a Veridia não produz nenhum reporte regulatório |
| GDPR | Quais dados pessoais fluem para onde, e quais direitos do titular não têm hoje nenhum mecanismo implementado |
| Segurança | Assinatura de webhooks, a proteção contra SSRF, tipos de chave e armazenamento, isolamento entre tenants, rate limits, e os controles que não existem |
A versão curta
Quatro coisas valem a pena saber antes de você seguir adiante.
Só as imagens são apagadas. A varredura de retenção remove do armazenamento os arquivos do documento e da selfie. A linha do banco de dados — veredito, campos de identidade extraídos, trilha de auditoria — sobrevive indefinidamente, por design, porque essa linha é o registro da verificação de identidade. Veja Retenção de dados.
Seu endpoint de webhook recebe PII de identidade. O payload inclui fieldsExtracted com nome completo, número do documento e data de nascimento. Isso torna seu endpoint — e qualquer coisa que registre os corpos das requisições dele — um repositório de dados pessoais. Planeje-se para isso.
Um hit de sanções nunca rejeita automaticamente. Uma correspondência forte contra as listas de screening força a verificação para review, para que uma pessoa decida. O sistema não vai rejeitar alguém apenas por uma coincidência de nome.
Várias coisas que você poderia supor que existem, não existem. Não há contrato de tratamento de dados disponível, não há captura de consentimento no widget, não há exclusão nem exportação self-service, não há criptografia em nível de aplicação nas colunas de identidade e não há geração de reportes para a SEPRELAD. Cada uma dessas lacunas está declarada abertamente na página correspondente, em vez de deixada para você descobrir.
Onde é necessário julgamento jurídico
Os pontos a seguir exigem orientação de um jurídico que conheça sua atividade regulada — esta documentação não substitui isso:
- Qual prazo de retenção efetivamente te obriga. Os prazos implementados aqui foram definidos pelo negócio; sua obrigação pode diferir conforme a atividade, e não apenas conforme o país.
- Se você é controlador e a Veridia é operadora, e qual contrato isso exige.
- Qual base legal você utiliza para tratar dados biométricos, e como você a obtém. O widget não captura consentimento.
- Se as listas de screening cobertas aqui são suficientes para as suas obrigações. São exclusivamente listas de sanções — sem lista de PEP, sem mídia adversa.
Reportando um problema de segurança
Se você encontrar uma vulnerabilidade, por favor reporte em privado em vez de abrir uma issue pública. Veja Suporte para os dados de contato.