Saltar para o conteúdo principal
A Validação de base de dados da Didit verifica os dados de identidade de uma pessoa face à fonte oficial desse país — o registo civil nacional, a autoridade tributária, o caderno eleitoral, uma central de crédito ou o registo biométrico que emitiu originalmente o documento. Cada verificação devolve uma correspondência campo a campo (identification_number, first_name, last_name, date_of_birth e campos de morada quando o serviço os utiliza), para além de um resultado agregado e dos detalhes do registo subjacente quando disponíveis. É a defesa mais sólida contra a fraude de identidade sintética: um DNI ou CPF real roubado falhará a consulta no registo, e um número fabricado não constará de todo na base de dados oficial. A Validação de base de dados combina-se com a nossa correspondência facial biométrica em países onde o registo possui uma fotografia oficial arquivada (Argentina via RENAPER, Panamá via Tribunal Electoral SIB / SIB Plus), para que possa confirmar não apenas que um número é real, mas que a pessoa em frente à câmara é titular do mesmo.

​
Porquê a Didit

  • Preços mais baixos por chamada. Desde $0.05 por verificação (República Dominicana) até $7.00 para as fontes especializadas mais dispendiosas. O preço é definido por serviço e não por país — um registo que cobra uma tarifa grossista elevada tem o preço ajustado em conformidade (o documento de identificação nacional da Finlândia custa $2.10). Consulte sempre a tarifa para o serviço exato que planeia chamar na tabela de preços por serviço. Sem mínimos mensais, sem taxas de plataforma, sem faturação por lugar — cobram-se apenas as consultas bem-sucedidas.
  • A mais rápida de integrar. Registe-se, obtenha uma chave de API na consola e poderá chamar POST /v3/database-validation/ em poucos minutos. Sem chamadas comerciais, sem ciclos de contratação, sem burocracia de prova de conceito — a Didit funciona totalmente em regime de autosserviço.
  • Consultas diretas à fonte oficial. RENAPER, Receita Federal (SERPRO), Tribunal Electoral, RENAPO, RENAP, RNP, RNPN, Junta Central Electoral, Registraduría Nacional, SEGIP, Servicio de Registro Civil, Tribunal Supremo de Elecciones, Dirección General de la Policía — e não extrações de agregadores.
  • Correspondência facial biométrica quando o registo tem uma fotografia oficial arquivada. Confiança superior à do OCR sem trabalho adicional de integração.
  • Latência adequada para produção. p95 tipicamente abaixo de 1.5 s de ponta a ponta, 99.9% de disponibilidade trimestral.
A aula da Academy sobre a leitura de um resultado de verificação aborda a validação de base de dados às 11:05 e apresenta resultados de correspondência total, parcial e sem correspondência.

​
Cobertura global

Passe o cursor sobre qualquer país destacado para ver todos os serviços de Validação de base de dados que disponibilizamos nesse país, o domínio de dados (Identidade, Financeiro, Biométrico, Morada, Telecomunicações, …) e o preço por chamada. Os países ativos já se encontram prontos para produção hoje; os restantes são integrados a pedido assim que um cliente o solicitar.
Não encontra o seu país? Fale connosco — o nosso catálogo abrange 60+ países com centenas de serviços que ativamos a pedido assim que um cliente necessitar. Novas integrações ficam normalmente ativas em 2–3 semanas.

​
Como é executada uma Validação de base de dados

Uma Validação de base de dados nunca é acionada de forma especulativa. Só é executada quando todas as seguintes condições se verificam:
  1. A sessão determinou um país para consultar — a partir do issuing_state de uma Verificação de identidade ou, quando o fluxo de verificação (workflow) não inclui um passo de Verificação de identidade, a partir do país único para o qual o passo de Validação de base de dados está configurado.
  2. Esse país tem pelo menos um serviço de Validação de base de dados ativado no fluxo.
  3. Os passos anteriores ao passo de Validação de base de dados forneceram todos os campos obrigatórios de que o serviço escolhido necessita.
Se um serviço estiver ativado mas os campos obrigatórios nunca tiverem chegado (por exemplo, o CPF não pôde ser extraído de um RG brasileiro manchado), o serviço é ignorado, não lhe é cobrado qualquer valor e é emitido um aviso na sessão: DATABASE_VALIDATION_NOT_APPLICABLE quando o documento simplesmente não inclui o identificador pelo qual esse serviço consulta, ou COULD_NOT_PERFORM_DATABASE_VALIDATION quando o identificador deveria estar disponível, mas não estava. Ambos estão listados no catálogo de avisos. Alguém da sua equipa com acesso de revisão à sessão pode preencher manualmente o campo em falta a partir da página de detalhes da sessão na Console; guardar a alteração aciona novamente a verificação de forma automática. Esta é uma ação de revisor e não algo que o utilizador final possa fazer — para permitir que o utilizador forneça um campo que o seu documento não contém, solicite-o num Questionário (ou numa extração com o Document AI, ou num valor enviado quando cria a sessão) e mapeie-o no passo de Validação de base de dados, tal como descrito abaixo.

​
A Validação de base de dados não requer uma Verificação de identidade

Anteriormente, um passo de Validação de base de dados pressupunha a existência de um passo de Verificação de identidade antes dele, uma vez que o OCR de um documento de identificação era a única forma integrada de obter os dados do utilizador final. Já não é esse o caso: cada campo obrigatório declara que passos o podem fornecer, e um serviço fica disponível assim que o seu fluxo contiver um passo que forneça todos os campos de que necessita. Isto significa que um serviço biométrico facial pode ser executado apenas a partir de um passo de Prova de vida, sem qualquer documento de identificação no fluxo, e um serviço baseado num número de identificação fiscal, número de telefone ou e-mail pode ser satisfeito a partir da resposta a um questionário, de um passo de Verificação de telefone/e-mail ou de uma extração do Document AI. Duas regras garantem a segurança deste processo:
  • Um fluxo sem Verificação de identidade tem de configurar exatamente um país no passo de Validação de base de dados. Sem um issuing_state de um documento, esse é o único sinal inequívoco sobre qual o registo nacional a consultar, pelo que uma configuração de vários países sem Verificação de identidade não executa nada em vez de tentar adivinhar.
  • A verificação de campos obrigatórios mantém-se inalterada. Um serviço cujos campos não estejam todos presentes no momento da execução é ignorado antes de qualquer fornecedor ser consultado, pelo que nunca é faturado por uma base de dados que nunca chegou a ser consultada.

​
Mapear campos do Document AI e de questionários

Os campos de extração do Document AI e as perguntas de questionários utilizam os nomes de chave que definiu, não os da Didit. Uma chave que corresponda exatamente ao nome de entrada de uma Validação de base de dados (tax_number, date_of_birth, phone, …) é mapeada automaticamente e não requer configuração. Para qualquer outra chave, o editor de fluxos apresenta um seletor no passo de Validação de base de dados para os campos ainda por preencher, onde aponta cada um deles para a chave de campo do Document AI ou para a resposta do questionário que o fornece. Na Console, um serviço que o seu fluxo ainda não consiga executar é apresentado como desativado com o respetivo motivo — que campos estão em falta e que passo os forneceria — e o editor oferece-se para adicionar esse passo. Adicioná-lo ativa de imediato todos os serviços que desbloqueia.
Exemplo prático — um identificador que o documento não contém. O serviço de identificação nacional da Nigéria efetua consultas através do NIN de 11 dígitos, que frequentemente não se encontra impresso nos documentos que os utilizadores carregam, pelo que depender apenas do documento de identificação faz com que a verificação seja ignorada por não ser aplicável para uma grande parte dos utilizadores. Adicione um passo de Questionário antes do passo de Validação de base de dados a solicitar o NIN e, em seguida, mapeie national_id para essa pergunta no passo de Validação de base de dados. Este mesmo mapeamento permite que um identificador que nunca consta num documento — como um número de verificação bancária ou um número de registo de empresa — possa ser utilizado dentro de um fluxo.
Para serviços baseados em moradas, a Didit divide automaticamente o campo único address do documento de identificação em elementos de morada estruturados: Ao chamar a API autónoma, pode enviar um único campo address ou estes campos estruturados diretamente. Quando ambos estão presentes, os campos estruturados têm prioridade. Os serviços que exigem pesquisa de morada necessitam de address_element_1 mais pelo menos um outro elemento de morada; se a Didit não conseguir derivá-los do documento de identificação ou do Comprovativo de morada no fluxo, o serviço é ignorado e não é faturado. Se o país determinado não estiver de todo ativado, o passo é ignorado silenciosamente, sem aviso e sem custos.
Fluxo de validação de base de dados da Didit que verifica os dados do utilizador em registos de identidade governamentais

​
O resultado de correspondência

Cada serviço ativado devolve uma validação por campo: O match_type agregado resume-se a:
  • full_match — todos os campos solicitados coincidem com pelo menos uma fonte.
  • partial_match — alguma correspondência; reencaminhe para uma fila de revisão de acordo com as regras do seu fluxo.
  • no_match — nenhuma fonte confirmou os dados; geralmente recusar.

​
Como a correspondência é derivada (1×1 / 2×2)

Já não lhe pedimos que escolha previamente “1×1” ou “2×2” — esses valores são derivados de quantos serviços distintos obtiveram uma correspondência total com os dados de entrada:
  • Resultado 1×1 — um serviço devolveu uma correspondência total (uma única fonte oficial confirmou os dados).
  • Resultado 2×2 — dois ou mais serviços devolveram uma correspondência total (corroboração independente; a pontuação de confiança mais elevada que podemos expressar).
Um fluxo pode ativar qualquer número de serviços por país; a faturação é feita por serviço que efetivamente devolveu um resultado. Os serviços cujos campos obrigatórios não puderam ser extraídos são ignorados sem qualquer custo. ➡️ Consulte Métodos de Correspondência para obter a lógica de decisão completa e como esta interage com partialMatchAction / noMatchAction.

​
Validação de Base de Dados Biométrica

Os registos civis de alguns países disponibilizam um template biométrico (um retrato ou uma impressão digital). Quando disponível, associamos a consulta ao registo a uma correspondência facial biométrica com a selfie do utilizador:
  • Argentina (arg_renaper) — correspondência facial biométrica com a fotografia oficial do RENAPER em arquivo. Cobertura de 100% da população; todos os cidadãos argentinos com DNI constam da base de dados.
  • Panamá (pan_cedula_sib, pan_cedula_sib_plus) — correspondência facial biométrica com o serviço SIB do Tribunal Electoral. O SIB Plus é a variante de nível superior, com limiares biométricos mais rigorosos e metadados de correspondência mais ricos.
Para estes serviços, o campo selfie é obrigatório. Dentro de um fluxo de sessão, reutilizamos a selfie de prova de vida (qualidade mais elevada) e recorremos ao retrato do documento como alternativa. Fora de uma sessão, ao chamar a API autónoma (POST /v3/database-validation/, Modo B acima), fornece o JPEG/PNG diretamente.

​
Enriquecimento global de identidade

glb_identity_enrichment é um serviço de Validação de base de dados global e exclusivo para modo autónomo. A partir de um e-mail e/ou número de telefone, resolve pessoas associadas (nomes, datas de nascimento, moradas, telefones, e-mails e documentos de identificação nacionais) e devolve uma pontuação de correspondência de nome, mapeada para os códigos de resultado padrão MATCH / PARTIAL_MATCH / NO_MATCH / DOCUMENT_NOT_FOUND (com o match_type correspondente de full_match / partial_match / no_match). Por ser um serviço global (GLB) baseado em e-mail/telefone e não no país emissor de um documento, não está disponível no construtor de fluxos. Chame-o diretamente através da API autónoma com issuing_state definido como GLB:
A faturação é de $0.20 por pedido (cobrada apenas quando o fornecedor devolve um resultado).

​
Configuração

A Validação de base de dados é configurada por fluxo a partir da Consola. Para cada país, seleciona os serviços específicos que pretende executar; os campos de entrada obrigatórios e opcionais derivam da união desses serviços. A ação aplicada aos resultados partial_match e no_match é configurada separadamente e pode ser approve, review ou decline.
Definições da consola de validação de bases de dados da Didit para selecionar serviços de registo por país e regras de resultados

​
Notificações de disponibilidade

Os registos governamentais e outras fontes ficam indisponíveis de tempos a tempos. Enquanto uma base de dados estiver inacessível, as verificações efetuadas contra a mesma não devolvem qualquer resposta e não são faturadas. Dentro de um fluxo, o serviço resulta em REGISTRY_UNAVAILABLE. Na API autónoma, a mesma interrupção manifesta-se de três formas possíveis, pelo que deve ler os resultados por serviço e database_validation.errors[], nunca o estado HTTP isoladamente:
  • 200 com outcome_code: "REGISTRY_UNAVAILABLE" nesse serviço em validations, quando a Didit guardou um resultado para reportar sobre o mesmo.
  • 200 com esse serviço em database_validation.errors[] como code: "empty_provider_response", retryable: true, quando não produziu nenhuma resposta utilizável e outro serviço selecionado o fez. O serviço com falha fica ausente de validations e de services_used, pelo que errors[] é o único local onde surge.
  • 502 com validation_errors[].code: "empty_provider_response" e retryable: true, quando nenhum serviço selecionado devolveu um resultado utilizável (consulte dados de entrada rejeitados e resultados indisponíveis).
O status geral segue os serviços que responderam, pelo que não constitui um sinal fiável de indisponibilidade por si só. Um pedido que fique sem nada para comparar passa para In Review, mas um pedido que tenha selecionado vários serviços pode regressar como Approved com base na correspondência de outro serviço enquanto uma das suas fontes esteve indisponível. Tente novamente o serviço que falhou a partir de errors[], em vez de repetir o pedido completo. Nenhuma destas situações diz o que quer que seja sobre a pessoa que está a ser verificada. A Didit monitoriza os resultados em tempo real das verificações reais, base de dados por base de dados, e envia um e-mail à sua organização quando uma interrupção é prolongada e não apenas um único pedido com falha: As notificações são enviadas para os membros e contactos de faturação de todas as organizações que executaram uma verificação nessa mesma base de dados nas 48 horas anteriores. Não é necessário configurar nada e não há adesão voluntária (opt-in). O tráfego de sandbox nunca as aciona, tal como as falhas provocadas pelos dados enviados (dados rejeitados ou mal formatados) ou por serviços que funcionam com credenciais cuja ligação é feita pela sua própria organização. Uma verificação respondida através de uma fonte alternativa conta como disponível, assim como uma não correspondência conclusiva.

​
Preços — pague apenas pelo que utilizar

A Validação de base de dados é faturada por consulta bem-sucedida, por serviço, à tarifa publicada para esse serviço. As tarifas variam entre $0.05 por verificação (República Dominicana através da Junta Central Electoral) até $7.00 para as fontes especializadas mais caras. Muitas consultas a registos governamentais situam-se na faixa de USD 0.20 a USD 0.30, mas um número considerável custa bastante mais porque a própria fonte cobra mais — o Finland National ID (fin_national_id) custa $2.10 por consulta bem-sucedida. Consulte o preço de um país na sua respetiva linha da tabela de preços, nunca a partir de um intervalo. Não existem consumos mínimos mensais, compromissos nem taxas de plataforma. Apenas paga quando um serviço devolve um resultado. Os serviços ignorados devido a dados de entrada em falta não são faturados, e o mesmo se aplica a um serviço cuja chamada à fonte falhe - um erro do registo ou um registo inacessível (REGISTRY_ERROR / REGISTRY_UNAVAILABLE) significa que a consulta nunca foi respondida, pelo que não constitui um resultado passível de cobrança. Cada consulta bem-sucedida a um registo é cobrada logo a partir da primeira, quer seja executada dentro de um fluxo ou através da API autónoma POST /v3/database-validation/. É paga a partir do crédito do seu plano ou do saldo carregado, como qualquer outra verificação, e o desconto do seu plano aplica-se ao preço total. Consulte a página de preços. ➡️ Preços da Validação de base de dados · Registe-se e obtenha uma chave de API

​
Todos os serviços

​
Continue a ler

  • Métodos de correspondência — como os resultados 1×1 / 2×2 são calculados e como reagir aos mesmos.
  • Códigos de resultado — a lista completa de códigos de resposta do fornecedor (falecido, menor de idade, documento não encontrado, discrepância biométrica, …) e como correspondem às decisões da sessão.
  • Avisos — o que apresentamos quando um serviço não pode ser executado devido a dados em falta.
  • Relatórios — exportações mensais de faturação por serviço com país, ID do serviço, utilização, preço unitário e custo total.
  • Países suportados — uma visualização estática em tabela de todos os países que cobrimos atualmente.
Última modificação em 7 de novembro de 2026