Pular para o conteúdo principal
A Validação de banco de dados da Didit verifica os dados de identidade de uma pessoa contra a fonte oficial de cada país - o registro civil nacional, a autoridade tributária, o cadastro eleitoral, o bureau de crédito ou o registro biométrico que emitiu o documento em primeiro lugar. Cada consulta retorna uma correspondência por campo (identification_number, first_name, last_name, date_of_birth e campos de endereço quando o serviço os utiliza), além de um resultado agregado e dos detalhes do registro subjacente quando disponíveis. É a defesa mais forte contra fraude de identidade sintética: um DNI ou CPF real roubado falhará na consulta ao registro, e um número fabricado simplesmente não estará na base oficial. A Validação de banco de dados é combinada com a nossa correspondência facial biométrica nos países em que o registro guarda uma foto oficial (Argentina via RENAPER, Panamá via Tribunal Electoral SIB / SIB Plus), para que você confirme não só que o número é real, mas que a pessoa diante da câmera é a titular dele.

​
Por que a Didit

  • O menor preço por chamada. A partir de $0.05 por consulta (República Dominicana) até $7.00 para as fontes especializadas mais caras. O preço é definido por serviço, não por país - um registro que cobra uma tarifa de atacado alta tem preço proporcional (o Documento Nacional de Identidade da Finlândia custa $2.10). Consulte sempre a tarifa do serviço exato que você pretende chamar na tabela de preços por serviço. Sem mínimos mensais, sem taxas de plataforma, sem cobrança por usuário - só as consultas bem-sucedidas são cobradas.
  • A integração mais rápida. Cadastre-se, pegue uma chave de API no console e você poderá chamar POST /v3/database-validation/ em minutos. Sem ligação comercial, sem processo de compras, sem burocracia de prova de conceito - a Didit é totalmente self-service.
  • 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 - não raspagens de agregadores.
  • Correspondência facial biométrica onde o registro tem uma foto oficial. Confiança maior que a do OCR, sem nenhum trabalho extra de integração.
  • Latência pronta para produção. p95 normalmente abaixo de 1.5 s de ponta a ponta, 99.9% de disponibilidade trimestral.
A aula da Academy sobre como ler o resultado de uma verificação chega à validação de banco de dados em 11:05 e mostra os resultados de correspondência total, parcial e nenhuma correspondência.

​
Cobertura global

Passe o mouse sobre qualquer país destacado para ver todos os serviços de Validação de banco de dados que operamos ali, o domínio dos dados (Identidade, Financeiro, Biométrico, Endereço, Telecom, …) e o preço por chamada. Os países ativos estão prontos para produção hoje; os demais são conectados sob demanda quando um cliente pede.
Não encontrou o seu país? Fale conosco - nosso catálogo acompanha 60+ países com centenas de serviços que ativamos sob demanda quando um cliente precisa. As novas integrações normalmente entram no ar em 2–3 semanas.

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

Uma Validação de banco de dados nunca dispara de forma especulativa. Ela só é executada quando todas as condições abaixo são verdadeiras:
  1. A sessão definiu um país a consultar - a partir do issuing_state de uma Verificação de identidade ou, quando o fluxo não tem etapa de Verificação de identidade, do único país para o qual a etapa de Validação de banco de dados está configurada.
  2. Esse país tem pelo menos um serviço de Validação de banco de dados ativado no fluxo.
  3. As etapas anteriores à de Validação de banco de dados forneceram todos os campos obrigatórios de que o serviço escolhido precisa.
Se um serviço está ativado mas os campos obrigatórios nunca chegaram (por exemplo, o CPF não pôde ser extraído de um RG brasileiro manchado), o serviço é ignorado, você não é cobrado e um aviso é gerado na sessão: DATABASE_VALIDATION_NOT_APPLICABLE quando o documento simplesmente não traz o identificador pelo qual aquele serviço consulta, COULD_NOT_PERFORM_DATABASE_VALIDATION quando ele deveria estar disponível e não estava. Ambos estão listados no catálogo de avisos. Alguém da sua equipe com acesso de revisão à sessão pode então preencher o campo ausente manualmente na página de detalhes da sessão no Console, e ao salvar a verificação é reexecutada automaticamente. Essa é uma ação do revisor, não algo que o usuário final possa fazer - para que o usuário forneça um campo que o documento não traz, peça-o em um Questionário (ou em uma extração do Document AI, ou em um valor que você envia ao criar a sessão) e mapeie-o na etapa de Validação de banco de dados, como descrito abaixo.

​
A Validação de banco de dados não exige Verificação de identidade

Antes, uma etapa de Validação de banco de dados pressupunha uma etapa de Verificação de identidade antes dela, porque o OCR de um documento de identidade era a única forma ligada de obter os dados do usuário final. Isso não é mais verdade: cada campo obrigatório declara quais etapas podem fornecê-lo, e um serviço fica disponível assim que o seu fluxo contém uma etapa que fornece todos os campos de que ele precisa. Isso significa que um serviço de biometria facial pode ser executado apenas com uma etapa de Prova de vida, sem nenhum documento de identidade no fluxo, e um serviço baseado em número fiscal, telefone ou e-mail pode ser atendido por uma resposta de questionário, uma etapa de Verificação de telefone/e-mail ou uma extração do Document AI. Duas regras mantêm isso seguro:
  • Um fluxo sem Verificação de identidade deve configurar exatamente um país na etapa de Validação de banco de dados. Sem um issuing_state vindo de um documento, esse é o único sinal inequívoco de qual registro nacional consultar, então uma configuração com vários países e sem Verificação de identidade não executa nada em vez de adivinhar.
  • A verificação de campos obrigatórios não muda. Um serviço cujos campos não estão todos presentes na execução é ignorado antes de qualquer provedor ser consultado, então você nunca é cobrado por uma base que nunca foi consultada.

​
Mapeando campos do Document AI e de questionários

Os campos de extração do Document AI e as perguntas de questionário usam os seus nomes de chave, não os da Didit. Uma chave que corresponde exatamente a um nome de entrada da Validação de banco de dados (tax_number, date_of_birth, phone, …) é mapeada automaticamente e não precisa de configuração. Para qualquer outra, o editor de fluxos mostra na etapa de Validação de banco de dados um seletor para os campos ainda não preenchidos, onde você aponta cada um para a chave de campo do Document AI ou a resposta do questionário que o fornece. No Console, um serviço que o seu fluxo ainda não consegue executar aparece desativado com o motivo - quais campos faltam e qual etapa os forneceria - e o editor se oferece para adicionar essa etapa para você. Adicioná-la liga imediatamente todos os serviços que ela desbloqueia.
Exemplo prático - um identificador que o documento não traz. O serviço de Documento Nacional de Identidade da Nigéria consulta pelo NIN de 11 dígitos, que muitas vezes não está impresso nos documentos que as pessoas enviam, então depender só do documento de identidade deixa a verificação ignorada como não aplicável para uma grande parte dos usuários. Coloque uma etapa de Questionário antes da etapa de Validação de banco de dados pedindo o NIN e depois mapeie national_id para essa pergunta na etapa de Validação de banco de dados. O mesmo mapeamento é o que torna utilizável em um fluxo um identificador que nunca consta em nenhum documento - um número de verificação bancária, um número de registro de empresa.
Para serviços baseados em endereço, a Didit divide automaticamente o único address do documento de identidade em elementos de endereço estruturados: Ao chamar a API independente, você pode enviar um único address ou esses campos estruturados diretamente. Os campos estruturados prevalecem quando ambos estão presentes. Os serviços que exigem busca por endereço precisam de address_element_1 mais pelo menos outro elemento de endereço; se a Didit não conseguir derivá-los do documento de identidade ou do Comprovante de endereço do fluxo, o serviço é ignorado e não é cobrado. Se o país resolvido não está ativado, a etapa é ignorada silenciosamente, sem aviso e sem cobrança.
Fluxo de validação de banco de dados da Didit conferindo os dados do usuário em registros governamentais de identidade

​
O resultado da correspondência

Cada serviço ativado retorna uma validação por campo: O match_type agregado resulta em:
  • full_match - todos os campos solicitados concordam com pelo menos uma fonte.
  • partial_match - alguma concordância; encaminhe para uma fila de revisão conforme as regras do seu fluxo.
  • no_match - nenhuma fonte confirmou os dados; normalmente, recuse.

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

Não pedimos mais que você escolha previamente “1×1” ou “2×2” - eles são derivados de quantos serviços distintos tiveram correspondência total com os dados de entrada:
  • Resultado 1×1 - um serviço retornou correspondência total (uma única fonte oficial confirmou os dados).
  • Resultado 2×2 - dois ou mais serviços retornaram correspondência total (corroboração independente; a maior confiança que conseguimos expressar).
Um fluxo pode ativar qualquer número de serviços por país; você é cobrado por serviço que realmente retornou um resultado. Os serviços cujos campos obrigatórios não puderam ser extraídos são ignorados, sem cobrança. ➡️ Veja Métodos de correspondência para a lógica de decisão completa e como ela interage com partialMatchAction / noMatchAction.

​
Validação de banco de dados biométrica

Os registros civis de alguns países publicam um template biométrico (um retrato ou uma impressão digital). Quando isso está disponível, combinamos a consulta ao registro com uma correspondência facial biométrica contra a selfie do usuário:
  • Argentina (arg_renaper) - correspondência facial biométrica contra a foto oficial do RENAPER. Cobertura de 100% da população; todo cidadão argentino com DNI está na base.
  • Panamá (pan_cedula_sib, pan_cedula_sib_plus) - correspondência facial biométrica contra o serviço SIB do Tribunal Electoral. O SIB Plus é a variante de nível elevado, com limites biométricos mais rigorosos e metadados de correspondência mais ricos.
Para esses serviços, o campo selfie é obrigatório. Dentro de um fluxo de sessão, reutilizamos a selfie da prova de vida (a de maior qualidade) e recorremos ao retrato do documento. Fora de uma sessão, ao chamar a API independente (POST /v3/database-validation/, Modo B acima), você mesmo fornece o JPEG/PNG.

​
Enriquecimento global de identidade

glb_identity_enrichment é um serviço de Validação de banco de dados global e exclusivo da API independente. A partir de um e-mail e/ou número de telefone, ele identifica as pessoas associadas (nomes, datas de nascimento, endereços, telefones, e-mails e documentos nacionais) e retorna 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, ele não está disponível no construtor de fluxos. Chame-o diretamente pela API independente com issuing_state definido como GLB:
Ele é cobrado a $0.20 por requisição (cobrado apenas quando o provedor retorna um resultado).

​
Configuração

A Validação de banco de dados é configurada por fluxo no Console. Para cada país, você seleciona os serviços específicos que quer executar; os campos de entrada obrigatórios e opcionais são derivados da união desses serviços. A ação tomada nos resultados partial_match e no_match é configurada separadamente e pode ser approve, review ou decline.
Configurações de validação de banco de dados da Didit no console, selecionando serviços de registro por país e regras de resultado

​
Notificações de disponibilidade

Registros governamentais e outras fontes saem do ar de tempos em tempos. Enquanto uma base está inacessível, as consultas a ela não retornam resposta e não são cobradas. Dentro de um fluxo, o serviço é resolvido como REGISTRY_UNAVAILABLE. Na API independente, a mesma indisponibilidade chega de uma de três formas, então leia os resultados por serviço e database_validation.errors[], nunca apenas o status HTTP:
  • 200 com outcome_code: "REGISTRY_UNAVAILABLE" naquele serviço em validations, quando a Didit manteve um resultado para informar sobre ele.
  • 200 com aquele serviço em database_validation.errors[] como code: "empty_provider_response", retryable: true, quando ele não produziu nenhuma resposta utilizável e outro serviço selecionado produziu. O serviço com falha fica então ausente de validations e de services_used, de modo que errors[] é o único lugar em que ele aparece.
  • 502 com validation_errors[].code: "empty_provider_response" e retryable: true, quando nenhum serviço selecionado retornou um resultado utilizável (veja entrada rejeitada e resultados indisponíveis).
O status geral segue os serviços que responderam, então não é, por si só, um sinal confiável de indisponibilidade. Uma requisição que fica sem nada para comparar vai para In Review, mas uma requisição que selecionou vários serviços pode voltar Approved pela correspondência de outro serviço enquanto uma de suas fontes estava indisponível. Repita o serviço com falha listado em errors[] em vez da requisição inteira. Nenhuma dessas formas diz algo sobre a pessoa que está sendo verificada. A Didit acompanha os resultados ao vivo de verificações reais, base por base, e envia um e-mail à sua organização quando uma interrupção é sustentada, e não uma única requisição com falha: Os avisos vão para os membros e contatos de cobrança de toda organização que executou uma consulta àquela base exata nas 48 horas anteriores. Nada precisa ser configurado e não há adesão (opt-in). O tráfego de sandbox nunca os aciona, nem as falhas causadas pelos dados que você enviou (entrada rejeitada ou malformada) ou por serviços que rodam com credenciais que a sua própria organização conecta. Uma consulta respondida por uma fonte alternativa conta como disponível, assim como uma ausência de correspondência conclusiva.

​
Preços - pague apenas pelo que usar

A Validação de banco de dados é cobrada por consulta bem-sucedida, por serviço, pela tarifa publicada para aquele serviço. As tarifas vão de $0.05 por consulta (República Dominicana via Junta Central Electoral) até $7.00 para as fontes especializadas mais caras. Muitas consultas a registros governamentais ficam na faixa de USD 0.20 a USD 0.30, mas um bom número custa bem mais porque a própria fonte cobra mais - o Documento Nacional de Identidade da Finlândia (fin_national_id) custa $2.10 por consulta bem-sucedida. Calcule o preço de um país pela linha dele na tabela de preços, nunca por uma faixa. Não há mínimos mensais, compromissos nem taxas de plataforma. Você só paga quando um serviço retorna um resultado. Serviços ignorados por falta de dados de entrada não são cobrados, nem um serviço cuja própria chamada à fonte falha - um erro do registro ou um registro inacessível (REGISTRY_ERROR / REGISTRY_UNAVAILABLE) significa que a consulta nunca foi respondida, então não é um resultado cobrável. Toda consulta bem-sucedida a um registro é cobrada desde a primeira, seja executada dentro de um fluxo ou pela API independente POST /v3/database-validation/. Ela é paga com o crédito do seu plano ou com o saldo de recarga, como qualquer outra verificação, e o desconto do seu plano se aplica ao preço inteiro. Veja a página de preços. ➡️ Preços da Validação de banco de dados · Cadastre-se e obtenha uma chave de API

​
Todos os serviços

​
Continue lendo

  • Métodos de correspondência - como os resultados 1×1 / 2×2 são derivados e como reagir a eles.
  • Códigos de resultado - a lista completa de códigos de resposta dos provedores (falecido, menor de idade, documento não encontrado, divergência biométrica, …) e como eles se mapeiam para as decisões de sessão.
  • Avisos - o que exibimos quando um serviço não pode ser executado por falta de dados.
  • Relatórios - exportações mensais de cobrança por serviço, com país, ID do serviço, uso, preço unitário e custo total.
  • Países compatíveis - uma visão em tabela estática de todos os países que cobrimos hoje.