Saltar al contenido principal
La validación de base de datos de Didit verifica los datos de identidad de una persona con la fuente autorizada de cada país: el registro civil nacional, la autoridad tributaria, el padrón electoral, el buró de crédito o el registro biométrico que emitió el documento en primer lugar. Cada comprobación devuelve una coincidencia por campo (identification_number, first_name, last_name, date_of_birth y campos de dirección cuando el servicio los usa), un resultado agregado y los detalles del registro subyacente cuando están disponibles. Es la mejor defensa contra el fraude de identidad sintética: un DNI o CPF real robado no superará la consulta al registro, y un número inventado no figurará en la base de datos oficial. La validación de base de datos se combina con nuestra coincidencia facial biométrica en los países donde el registro guarda una foto oficial (Argentina con RENAPER, Panamá con Tribunal Electoral SIB / SIB Plus), de modo que puedes confirmar no solo que un número es real, sino que la persona que está frente a la cámara es su titular.

​
Por qué Didit

  • Los precios de pago por llamada más bajos. Desde $0.05 por comprobación (República Dominicana) hasta $7.00 para las fuentes especializadas más caras. El precio se fija por servicio, no por país: un registro que cobra una tarifa mayorista alta se cotiza en consecuencia (el documento nacional de identidad de Finlandia cuesta $2.10). Consulta siempre la tarifa del servicio exacto que vas a llamar en la tabla de precios por servicio. Sin mínimos mensuales, sin comisiones de plataforma y sin facturación por usuario: solo se cobran las consultas correctas.
  • La integración más rápida. Regístrate, obtén una clave de API en la consola y podrás llamar a POST /v3/database-validation/ en pocos minutos. Sin llamada comercial, sin proceso de compras y sin papeleo de prueba de concepto: Didit es totalmente de autoservicio.
  • Consultas directas a la fuente autorizada. 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: no son datos extraídos de agregadores.
  • Coincidencia facial biométrica cuando el registro tiene una foto oficial. Mayor confianza que el OCR sin trabajo de integración adicional.
  • Latencia lista para producción. El p95 suele ser inferior a 1.5 s de extremo a extremo y la disponibilidad trimestral es del 99.9%.
La lección de la Academy sobre cómo leer un resultado de verificación llega a la validación de base de datos en el minuto 11:05 y muestra resultados de coincidencia total, parcial y nula.

​
Cobertura global

Pasa el cursor por cualquier país resaltado para ver todos los servicios de validación de base de datos que ofrecemos allí, el dominio de datos (identidad, financiero, biométrico, dirección, telecomunicaciones, …) y el precio por llamada. Los países activos están listos para producción hoy; el resto se conectan bajo demanda cuando un cliente lo solicita.
¿No ves tu país? Escríbenos: nuestro catálogo abarca 60+ países con cientos de servicios que activamos bajo demanda cuando un cliente los necesita. Las nuevas integraciones suelen estar activas en 2-3 semanas.

​
Cómo se ejecuta una validación de base de datos

Una validación de base de datos nunca se lanza de forma especulativa. Solo se ejecuta cuando se cumplen todas estas condiciones:
  1. La sesión determinó un país que consultar: a partir del issuing_state de una verificación de identidad o, cuando el flujo no tiene un paso de verificación de identidad, del único país para el que está configurado el paso de validación de base de datos.
  2. Ese país tiene al menos un servicio de validación de base de datos habilitado en el flujo.
  3. Los pasos anteriores al de validación de base de datos aportaron todos los campos obligatorios que necesita el servicio elegido.
Si un servicio está habilitado pero los campos obligatorios nunca llegaron (por ejemplo, no se pudo extraer el CPF de un RG brasileño borroso), el servicio se omite, no se te cobra y se genera una advertencia en la sesión: DATABASE_VALIDATION_NOT_APPLICABLE cuando el documento simplemente no incluye el identificador por el que consulta ese servicio, y COULD_NOT_PERFORM_DATABASE_VALIDATION cuando debería haber estado disponible y no lo estaba. Ambas figuran en el catálogo de advertencias. Alguien de tu equipo con acceso de revisión a la sesión puede entonces completar el campo que falta a mano desde la página de detalle de la sesión en la Consola, y al guardarlo se vuelve a lanzar la comprobación automáticamente. Es una acción del revisor, no algo que pueda hacer el usuario final: para que el usuario aporte un campo que su documento no incluye, pídelo en un cuestionario (o en una extracción de Document AI, o como un valor que envíes al crear la sesión) y asígnalo en el paso de validación de base de datos, como se describe más abajo.

​
La validación de base de datos no requiere verificación de identidad

Antes, un paso de validación de base de datos implicaba un paso de verificación de identidad anterior, porque el OCR de un documento de identidad era la única forma conectada de obtener los datos del usuario final. Ya no es así: cada campo obligatorio declara qué pasos pueden aportarlo, y un servicio queda disponible en cuanto tu flujo contiene un paso que aporte todos los campos que necesita. Esto significa que un servicio de biometría facial puede ejecutarse solo con un paso de prueba de vida, sin ningún documento de identidad en el flujo, y que un servicio basado en un número fiscal, un teléfono o un correo electrónico puede satisfacerse con la respuesta de un cuestionario, un paso de verificación de teléfono o correo electrónico o una extracción de Document AI. Dos reglas lo mantienen seguro:
  • Un flujo sin verificación de identidad debe configurar exactamente un país en el paso de validación de base de datos. Sin un issuing_state procedente de un documento, esa es la única señal inequívoca de qué registro nacional consultar, así que una configuración multipaís sin verificación de identidad no ejecuta nada en lugar de adivinar.
  • La comprobación de campos obligatorios no cambia. Un servicio cuyos campos no están todos presentes en el momento de la ejecución se omite antes de consultar a ningún proveedor, de modo que nunca se te factura una base de datos que no llegó a consultarse.

​
Asignación de campos de Document AI y de cuestionarios

Los campos de extracción de Document AI y las preguntas de los cuestionarios usan tus nombres de clave, no los de Didit. Una clave que coincide exactamente con el nombre de un dato de entrada de la validación de base de datos (tax_number, date_of_birth, phone, …) se asigna automáticamente y no requiere configuración. Para cualquier otra, el editor de flujos muestra un selector en el paso de validación de base de datos para los campos que siguen sin rellenar, donde indicas la clave de campo de Document AI o la respuesta del cuestionario que lo aporta. En la Consola, un servicio que tu flujo todavía no puede ejecutar aparece deshabilitado con el motivo (qué campos faltan y qué paso los aportaría), y el editor se ofrece a añadir ese paso por ti. Al añadirlo se activan de inmediato todos los servicios que desbloquea.
Ejemplo práctico: un identificador que el documento no incluye. El servicio de documento nacional de Nigeria consulta por el NIN de 11 dígitos, que con frecuencia no está impreso en los documentos que suben las personas, así que depender solo del documento de identidad deja la comprobación omitida por no aplicable para una gran parte de los usuarios. Pon un paso de cuestionario antes del paso de validación de base de datos que pida el NIN y luego asigna national_id a esa pregunta en el paso de validación de base de datos. Esa misma asignación es la que permite usar dentro de un flujo un identificador que nunca figura en ningún documento, como un número de verificación bancaria o un número de registro mercantil.
Para los servicios basados en direcciones, Didit divide automáticamente el único address del documento de identidad en elementos de dirección estructurados: Al llamar a la API independiente, puedes enviar un único address o estos campos estructurados directamente. Los campos estructurados prevalecen cuando están presentes ambos. Los servicios que requieren búsqueda de direcciones necesitan address_element_1 más al menos otro elemento de dirección; si Didit no puede obtenerlos del documento de identidad o de la prueba de domicilio del flujo, el servicio se omite y no se factura. Si el país determinado no está habilitado en absoluto, el paso se omite en silencio, sin advertencia y sin cargo.
Flujo de validación de base de datos de Didit que comprueba los datos del usuario con registros de identidad gubernamentales

​
El resultado de la coincidencia

Cada servicio habilitado devuelve una validación por campo: El match_type agregado se resume así:
  • full_match: todos los campos solicitados coinciden con al menos una fuente.
  • partial_match: hay coincidencia parcial; envíalo a una cola de revisión según las reglas de tu flujo.
  • no_match: ninguna fuente confirmó los datos; normalmente se rechaza.

​
Cómo se obtiene la coincidencia (1×1 / 2×2)

Ya no te pedimos que elijas de antemano “1×1” o “2×2”: se derivan de cuántos servicios distintos devolvieron una coincidencia total con los datos de entrada:
  • Resultado 1×1: un servicio devolvió una coincidencia total (una única fuente autorizada confirmó los datos).
  • Resultado 2×2: dos o más servicios devolvieron una coincidencia total (corroboración independiente; la mayor confianza que podemos expresar).
Un flujo puede habilitar cualquier número de servicios por país; se te factura por cada servicio que realmente devolvió un resultado. Los servicios cuyos campos obligatorios no se pudieron extraer se omiten sin cargo. ➡️ Consulta Métodos de coincidencia para ver la lógica de decisión completa y cómo interactúa con partialMatchAction / noMatchAction.

​
Validación de base de datos biométrica

Los registros civiles de algunos países publican una plantilla biométrica (un retrato o una huella dactilar). Cuando está disponible, combinamos la consulta al registro con una coincidencia facial biométrica con el selfie del usuario:
  • Argentina (arg_renaper): coincidencia facial biométrica con la foto oficial de RENAPER. Cobertura del 100% de la población; todos los ciudadanos argentinos con DNI están en la base de datos.
  • Panamá (pan_cedula_sib, pan_cedula_sib_plus): coincidencia facial biométrica con el servicio SIB del Tribunal Electoral. SIB Plus es la variante de nivel superior, con umbrales biométricos más estrictos y metadatos de coincidencia más completos.
Para estos servicios el campo selfie es obligatorio. Dentro de un flujo de sesión reutilizamos el selfie de la prueba de vida (el de mayor calidad) y recurrimos al retrato del documento como alternativa. Fuera de una sesión, al llamar a la API independiente (POST /v3/database-validation/, modo B más arriba), tú aportas el JPEG/PNG.

​
Enriquecimiento de identidad global

glb_identity_enrichment es un servicio de validación de base de datos global y solo independiente. A partir de un correo electrónico y/o un número de teléfono, resuelve las personas asociadas (nombres, fechas de nacimiento, direcciones, teléfonos, correos electrónicos y documentos nacionales) y devuelve una puntuación de coincidencia de nombre, asignada a los códigos de resultado estándar MATCH / PARTIAL_MATCH / NO_MATCH / DOCUMENT_NOT_FOUND (con el match_type correspondiente de full_match / partial_match / no_match). Como es un servicio global (GLB) basado en correo electrónico o teléfono y no en el país emisor de un documento, no está disponible en el constructor de flujos. Llámalo directamente a través de la API independiente con issuing_state definido como GLB:
Se factura a $0.20 por solicitud (solo se cobra cuando el proveedor devuelve un resultado).

​
Configuración

La validación de base de datos se configura por flujo desde la Consola. Para cada país eliges los servicios concretos que quieres ejecutar; los campos de entrada obligatorios y opcionales se derivan de la unión de esos servicios. La acción que se aplica a los resultados partial_match y no_match se configura por separado y puede ser approve, review o decline.
Ajustes de la consola de validación de base de datos de Didit para elegir servicios de registro por país y reglas de resultado

​
Notificaciones de disponibilidad

Los registros gubernamentales y otras fuentes se caen de vez en cuando. Mientras una base de datos no está disponible, las comprobaciones contra ella no devuelven respuesta y no se facturan. Dentro de un flujo, el servicio se resuelve como REGISTRY_UNAVAILABLE. En la API independiente, la misma caída llega en una de tres formas, así que lee los resultados por servicio y database_validation.errors[], nunca solo el estado HTTP:
  • 200 con outcome_code: "REGISTRY_UNAVAILABLE" en ese servicio dentro de validations, cuando Didit conservó un resultado que informar para él.
  • 200 con ese servicio en database_validation.errors[] como code: "empty_provider_response", retryable: true, cuando no produjo ninguna respuesta utilizable y otro servicio seleccionado sí. El servicio fallido no aparece entonces en validations ni en services_used, así que errors[] es el único lugar donde figura.
  • 502 con validation_errors[].code: "empty_provider_response" y retryable: true, cuando ningún servicio seleccionado devolvió un resultado utilizable (consulta entrada rechazada y resultados no disponibles).
El status general sigue a los servicios que sí respondieron, así que por sí solo no es una señal fiable de caída. Una solicitud que se queda sin nada que comparar pasa a In Review, pero una solicitud que seleccionó varios servicios puede devolver Approved por la coincidencia de otro servicio mientras una de sus fuentes no estaba disponible. Reintenta el servicio fallido indicado en errors[] en lugar de toda la solicitud. Ninguna de estas formas dice nada sobre la persona que se está verificando. Didit vigila los resultados en vivo de las comprobaciones reales, base de datos por base de datos, y envía un correo a tu organización cuando una interrupción es sostenida y no un único fallo aislado: Los avisos se envían a los miembros y contactos de facturación de cada organización que ejecutó una comprobación contra esa base de datos exacta en las 48 horas anteriores. No hace falta configurar nada y no hay suscripción voluntaria. El tráfico del sandbox nunca los activa, y tampoco los fallos causados por los datos que enviaste (entradas rechazadas o mal formadas) ni los servicios que funcionan con credenciales que tu propia organización conecta. Una comprobación respondida mediante una fuente alternativa cuenta como disponible, igual que una ausencia de coincidencia concluyente.

​
Precios: paga solo por lo que usas

La validación de base de datos se factura por consulta correcta y por servicio, a la tarifa publicada para ese servicio. Las tarifas van desde $0.05 por comprobación (República Dominicana mediante la Junta Central Electoral) hasta $7.00 para las fuentes especializadas más caras. Muchas consultas a registros gubernamentales están en la franja de USD 0.20 a USD 0.30, pero bastantes cuestan bastante más porque la propia fuente cobra más: el documento nacional de identidad de Finlandia (fin_national_id) cuesta $2.10 por consulta correcta. Calcula el precio de un país a partir de su propia fila en la tabla de precios, nunca a partir de un rango. No hay mínimos mensuales, compromisos ni comisiones de plataforma. Solo pagas cuando un servicio devuelve un resultado. Los servicios que se omiten por falta de datos de entrada no se facturan, y tampoco un servicio cuya llamada a la fuente falla: un error del registro o un registro inaccesible (REGISTRY_ERROR / REGISTRY_UNAVAILABLE) significa que la consulta nunca se respondió, así que no es un resultado facturable. Cada consulta correcta a un registro se cobra desde la primera, ya se ejecute dentro de un flujo o mediante la API independiente POST /v3/database-validation/. Se paga con el crédito de tu plan o con el saldo recargado, como cualquier otra comprobación, y el descuento de tu plan se aplica a su precio completo. Consulta la página de precios. ➡️ Precios de la validación de base de datos · Regístrate y obtén una clave de API

​
Todos los servicios

​
Sigue leyendo

  • Métodos de coincidencia: cómo se obtienen los resultados 1×1 / 2×2 y cómo reaccionar ante ellos.
  • Códigos de resultado: la lista completa de códigos de respuesta de los proveedores (fallecido, menor de edad, documento no encontrado, discrepancia biométrica, …) y cómo se asignan a las decisiones de la sesión.
  • Advertencias: lo que mostramos cuando un servicio no puede ejecutarse por falta de datos.
  • Informes: exportaciones mensuales de facturación por servicio con país, ID de servicio, uso, precio unitario y coste total.
  • Países compatibles: una vista en tabla estática de todos los países que cubrimos hoy.