Saltar al contingut principal
La Validació en bases de dades de Didit verifica les dades d’identitat d’una persona amb la font fidedigna d’aquell país —el registre civil nacional, l’autoritat tributària, el cens electoral, l’agència d’informació creditícia o el registre biomètric que va emetre el document originalment. Cada comprovació retorna una coincidència per camp (identification_number, first_name, last_name, date_of_birth i camps d’adreça quan el servei els utilitza), a més d’un resultat agregat i els detalls del registre subjacent quan estan disponibles. És la defensa més sòlida contra el frau d’identitat sintètica: un DNI o CPF real robat fallarà la consulta al registre, i un número inventat no figurarà en absolut a la base de dades oficial. La Validació en bases de dades es combina amb la nostra coincidència facial biomètrica en països on el registre disposa d’una foto oficial (l’Argentina mitjançant RENAPER, Panamà mitjançant Tribunal Electoral SIB / SIB Plus) perquè puguis confirmar no només que un número és real, sinó que la persona que hi ha davant de la càmera n’és la titular.

​
Per què Didit

  • Els preus més baixos per pagament per crida. Des de $0.05 per comprovació (República Dominicana) fins a $7.00 per a les fonts especialitzades més cares. El preu es fixa per servei, no per país —un registre que cobra una tarifa majorista alta té un preu ajustat en conseqüència (Finland National ID costa $2.10). Consulta sempre la tarifa del servei exacte que planegis cridar a la taula de preus per servei. Sense mínims mensuals, sense quotes de plataforma, sense facturació per plaça —només es cobren les consultes satisfactòries.
  • La integració més ràpida. Registra’t, obtén una clau d’API des de la consola i podràs cridar POST /v3/database-validation/ en pocs minuts. Sense trucades comercials, sense cicles de contractació, sense tràmits de prova de concepte —Didit és totalment d’autoservei.
  • Consultes directes a la font fidedigna. 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 pas extraccions de dades d’agregadors.
  • Coincidència facial biomètrica quan el registre disposa d’una foto oficial. Confiança superior a l’OCR sense feina d’integració addicional.
  • Latència apta per a producció. p95 generalment inferior a 1.5 s d’extrem a extrem, 99.9% de disponibilitat trimestral.
La lliçó de l’Academy sobre com llegir un resultat de verificació arriba a la validació en bases de dades al minut 11:05 i mostra resultats de coincidència total, parcial i sense coincidència.

​
Cobertura global

Passa el cursor per sobre de qualsevol país destacat per veure tots els serveis de Validació en bases de dades que hi oferim, el domini de dades (identitat, financer, biomètric, adreça, telecomunicacions, …) i el preu per crida. Els països actius estan preparats per a producció avui mateix; la resta s’integren sota demanda un cop ho sol·licita un client.
No trobes el teu país? Contacta amb nosaltres —el nostre catàleg inclou 60+ països amb centenars de serveis que activem sota demanda un cop un client els necessita. Les noves integracions solen posar-se en marxa en 2–3 setmanes.

​
Com s’executa una validació en bases de dades

Una validació en bases de dades mai no s’activa de manera especulativa. Només s’executa quan es compleixen totes les condicions següents:
  1. La sessió ha resolt un país per consultar — a partir de l’issuing_state d’una Verificació d’identitat o, quan el flux de treball no té cap pas de Verificació d’identitat, a partir de l’únic país per al qual està configurat el pas de Validació en bases de dades.
  2. Aquest país té com a mínim un servei de Validació en bases de dades activat al flux de treball.
  3. Els passos previs al pas de Validació en bases de dades han proporcionat tots els camps requerits que necessita el servei seleccionat.
Si un servei està activat però els camps requerits no s’han rebut mai (per exemple, si el CPF no s’ha pogut extreure d’un RG brasiler borrós), el servei s’omet, no se’t cobra i es genera una advertència a la sessió: DATABASE_VALIDATION_NOT_APPLICABLE quan el document simplement no conté l’identificador pel qual consulta aquest servei, o bé COULD_NOT_PERFORM_DATABASE_VALIDATION quan hauria d’haver estat disponible i no ho estava. Totes dues figuren al catàleg d’advertències. Algú del teu equip amb permís de revisió per a la sessió pot omplir el camp que falta manualment des de la pàgina de detall de la sessió a la Console, i en desar-lo es torna a activar la comprovació automàticament. Aquesta és una acció del revisor, no pas una cosa que pugui fer l’usuari final; perquè l’usuari pugui proporcionar un camp que el seu document no conté, sol·licita’l en un Qüestionari (o mitjançant una extracció de Document AI, o amb un valor que enviïs quan creïs la sessió) i assigna’l al pas de Validació en bases de dades, tal com es descriu més avall.

​
La Validació en bases de dades no requereix Verificació d’identitat

Abans, un pas de Validació en bases de dades implicava tenir un pas de Verificació d’identitat al davant, perquè l’OCR d’un document d’identitat era l’única manera integrada d’obtenir les dades de l’usuari final. Aquest ja no és el cas: cada camp requerit declara quins passos el poden proporcionar, i un servei passa a estar disponible tan bon punt el teu flux de treball conté un pas que proporciona tots els camps que necessita. Això significa que un servei biomètric facial es pot executar només a partir d’un pas de Prova de vida, sense cap document d’identitat enlloc del flux de treball, i un servei basat en un número fiscal, número de telèfon o correu electrònic es pot satisfer a partir de la resposta d’un qüestionari, un pas de Verificació de telèfon/correu electrònic o una extracció de Document AI. Dues regles garanteixen la seguretat d’aquest procés:
  • Un flux de treball sense Verificació d’identitat ha de configurar exactament un país al pas de Validació en bases de dades. Sense un issuing_state d’un document, aquest és l’únic senyal inequívoc sobre quin registre nacional s’ha de consultar; per tant, una configuració multipaís sense Verificació d’identitat no executa res en lloc de fer conjectures.
  • La comprovació dels camps requerits no canvia. Un servei en què no tots els camps estiguin presents en el moment de l’execució s’omet abans de consultar cap proveïdor, de manera que mai no se’t factura per una base de dades a la qual mai no s’ha fet cap consulta.

​
Assignació de camps de Document AI i de qüestionari

Els camps d’extracció de Document AI i les preguntes del qüestionari utilitzen els teus noms de clau, no els de Didit. Una clau que coincideixi exactament amb un nom d’entrada de Validació en bases de dades (tax_number, date_of_birth, phone, …) s’assigna automàticament i no requereix cap configuració. Per a qualsevol altra cosa, l’editor del flux de treball mostra un selector al pas de Validació en bases de dades per als camps que encara estan buits, on pots enllaçar cadascun amb la clau de camp de Document AI o la resposta del qüestionari que el proporciona. A la Console, els serveis que el teu flux de treball encara no pot executar es mostren desactivats juntament amb el motiu (quins camps falten i quin pas els proporcionaria), i l’editor ofereix afegir-te aquest pas. Quan l’afegeixes, s’activen immediatament tots els serveis que desbloqueja.
Exemple pràctic: un identificador que el document no conté. El servei d’identificació nacional de Nigèria consulta mitjançant el NIN d’11 dígits, que sovint no apareix imprès als documents que els usuaris pengen; per tant, dependre exclusivament del document d’identitat fa que la comprovació s’ometi com a no aplicable per a una gran part dels usuaris. Afegeix un pas de Qüestionari davant del pas de Validació en bases de dades sol·licitant el NIN i, a continuació, assigna national_id a aquesta pregunta al pas de Validació en bases de dades. Aquesta mateixa assignació és la que permet utilitzar dins d’un flux de treball identificadors que no apareixen mai en cap document, com ara un número de verificació bancària o un número de registre d’empresa.
Per als serveis basats en adreces, Didit divideix automàticament el camp únic address del document d’identitat en elements d’adreça estructurats: Quan cridis l’API independent, pots enviar directament un únic camp address o bé aquests camps estructurats. Si tots dos són presents, prevalen els camps estructurats. Els serveis que requereixen cerca d’adreces necessiten address_element_1 i com a mínim un altre element d’adreça; si Didit no els pot derivar del document d’identitat o del Comprovant de domicili al flux de treball, el servei s’omet i no es factura. Si el país resolt no està activat, el pas s’omet silenciosament sense cap advertència ni cap cost.
Flux de validació en bases de dades de Didit que comprova les dades d'usuaris amb registres d'identitat governamentals

​
El resultat de la coincidència

Cada servei habilitat retorna una validació per camp: El match_type agregat es consolida en:
  • full_match — tots els camps sol·licitats coincideixen com a mínim amb una font.
  • partial_match — hi ha alguna coincidència; es deriva a una cua de revisió segons les regles del teu flux de treball.
  • no_match — cap font no ha confirmat les dades; normalment es rebutja.

​
Com es dedueix la coincidència (1×1 / 2×2)

Ja no et demanem que triïs prèviament «1×1» o «2×2»; aquests valors es dedueixen de quants serveis diferents han obtingut una coincidència total amb les dades d’entrada:
  • Resultat 1×1 — un servei ha retornat una coincidència total (una única font fidedigna ha confirmat les dades).
  • Resultat 2×2 — dos o més serveis han retornat una coincidència total (corroboració independent; la màxima confiança que podem expressar).
Un flux de treball pot habilitar qualsevol nombre de serveis per país; se’t factura per cada servei que realment hagi retornat un resultat. Els serveis dels quals no s’hagin pogut extreure els camps obligatoris s’ometen sense cap càrrec. ➡️ Consulta Mètodes de coincidència per conèixer la lògica de decisió completa i com interactua amb partialMatchAction / noMatchAction.

​
Validació biomètrica en bases de dades

Els registres civils d’alguns països publiquen una plantilla biomètrica (un retrat o una empremta dactilar). Quan està disponible, combinem la consulta al registre amb una coincidència facial biomètrica amb la selfie de l’usuari:
  • Argentina (arg_renaper) — coincidència facial biomètrica amb la foto oficial registrada al RENAPER. Cobertura del 100% de la població; tots els ciutadans argentins amb DNI són a la base de dades.
  • Panamà (pan_cedula_sib, pan_cedula_sib_plus) — coincidència facial biomètrica amb el servei SIB del Tribunal Electoral. SIB Plus és la variant de nivell superior amb llindars biomètrics més estrictes i metadades de coincidència més completes.
Per a aquests serveis, el camp selfie és obligatori. Dins d’un flux de sessió, reutilitzem la selfie de la prova de vida (màxima qualitat) i, si no n’hi ha, fem servir el retrat del document. Fora d’una sessió, quan crides l’API independent (POST /v3/database-validation/, mode B anterior), proporciones el JPEG/PNG tu mateix.

​
Enriquiment global d’identitat

glb_identity_enrichment és un servei global de Validació en bases de dades disponible únicament de manera independent. A partir d’un correu electrònic i/o número de telèfon, resol les persones associades (noms, dates de naixement, adreces, telèfons, correus electrònics i números d’identificació nacional) i retorna una puntuació de coincidència de nom, assignada als codis de resultat estàndard MATCH / PARTIAL_MATCH / NO_MATCH / DOCUMENT_NOT_FOUND (amb el corresponent match_type de full_match / partial_match / no_match). Com que és un servei global (GLB) basat en el correu electrònic o el telèfon en comptes del país emissor d’un document, no està disponible al creador de fluxos de treball. Crida’l directament a través de l’API independent establint issuing_state com a GLB:
Es factura a $0.20 per sol·licitud (només es cobra quan el proveïdor retorna un resultat).

​
Configuració

La Validació en bases de dades es configura per flux de treball des de la Console. Per a cada país, selecciones els serveis concrets que vols executar; els camps d’entrada obligatoris i opcionals es dedueixen de la unió d’aquests serveis. L’acció que cal dur a terme davant dels resultats partial_match i no_match es configura per separat i pot ser approve, review o decline.
Configuració de la validació en bases de dades a la Console de Didit seleccionant serveis de registre per país i regles de resultat

​
Notificacions de disponibilitat

Els registres governamentals i altres fonts cauen de tant en tant. Mentre una base de dades és inaccessible, les comprovacions que s’hi fan no retornen cap resposta i no es facturen. Dins d’un flux de treball, el servei es resol com a REGISTRY_UNAVAILABLE. A l’API independent, la mateixa caiguda es manifesta d’una de tres maneres, de manera que has de llegir els resultats per servei i database_validation.errors[], mai l’estat HTTP per si sol:
  • 200 amb outcome_code: "REGISTRY_UNAVAILABLE" en aquell servei dins de validations, quan Didit ha conservat un resultat per informar-ne.
  • 200 amb aquell servei a database_validation.errors[] com a code: "empty_provider_response", retryable: true, quan no ha generat cap resposta utilitzable i un altre servei seleccionat sí que ho ha fet. El servei que ha fallat no apareix aleshores ni a validations ni a services_used, de manera que errors[] és l’únic lloc on surt.
  • 502 amb validation_errors[].code: "empty_provider_response" i retryable: true, quan cap dels serveis seleccionats ha retornat un resultat utilitzable (consulta entrades rebutjades i resultats no disponibles).
L’status global segueix els serveis que sí que han respost, de manera que no és un senyal fiable d’interrupció per si sol. Una sol·licitud que es queda sense res amb què comparar passa a In Review, però una sol·licitud en què s’han seleccionat diversos serveis pot retornar Approved gràcies a la coincidència d’un altre servei mentre una de les seves fonts no estava disponible. Reintenta el servei fallit a partir d’errors[] en lloc de tota la sol·licitud. Cap d’aquestes situacions indica res sobre la persona que s’està verificant. Didit monitora els resultats en directe de comprovacions reals, base de dades per base de dades, i envia un correu electrònic a la teva organització quan una interrupció és sostinguda i no pas una sola sol·licitud fallida: Els avisos s’envien als membres i als contactes de facturació de cada organització que hagi executat una comprovació contra aquesta base de dades exacta en les darreres 48 hores. No cal configurar res i no cal subscriure-s’hi. El trànsit de sandbox mai no els activa, i tampoc ho fan les fallades causades per les dades enviades (entrades rebutjades o mal formades) o per serveis que s’executen amb credencials que connecta la teva pròpia organització. Una comprovació que s’ha respost mitjançant una font de reserva compta com a disponible, igual que una no-coincidència concloent.

​
Preus: paga només pel que utilitzis

La Validació en bases de dades es factura per consulta satisfactòria, per servei, a la tarifa publicada per a aquest servei. Les tarifes van des de $0.05 per comprovació (República Dominicana a través de la Junta Central Electoral) fins a $7.00 per a les fonts especialitzades més cares. Moltes consultes de registres governamentals se situen a la franja de USD 0.20 a USD 0.30, però un bon nombre costen considerablement més perquè la mateixa font cobra més: el document d’identitat nacional de Finlàndia (fin_national_id) costa $2.10 per consulta satisfactòria. Consulta el preu d’un país a la seva pròpia fila de la taula de preus, mai a partir d’un rang. No hi ha mínims mensuals, compromisos ni quotes de plataforma. Només pagues quan un servei retorna un resultat. Els serveis que s’ometen per falta de dades d’entrada no es facturen, i tampoc no es factura un servei si falla la seva crida a la font: un error de registre o un registre inaccessible (REGISTRY_ERROR / REGISTRY_UNAVAILABLE) significa que la consulta no s’ha respost mai, de manera que no és un resultat facturable. Cada consulta satisfactòria a un registre es cobra des de la primera, tant si s’executa dins d’un flux de treball com mitjançant l’API independent POST /v3/database-validation/. Es paga amb el crèdit del teu pla o amb el teu saldo de recàrrega com qualsevol altra comprovació, i el descompte del teu pla s’aplica al preu total. Consulta la pàgina de preus. ➡️ Preus de Validació en bases de dades · Registra’t i obtén una clau d’API

​
Tots els serveis

​
Continua llegint

  • Mètodes de coincidència: com es deriven els resultats 1×1 / 2×2 i com reaccionar-hi.
  • Codis de resultat: la llista completa de codis de resposta dels proveïdors (defunció, menor d’edat, document no trobat, no-coincidència biomètrica, …) i com es tradueixen en decisions de sessió.
  • Advertències: què mostrem quan un servei no es pot executar per falta de dades.
  • Informes: exportacions mensuals de facturació per servei amb país, ID de servei, ús, preu unitari i cost total.
  • Països admesos: una taula estàtica de cada país que cobrim actualment.
Darrera modificació el 7 de novembre del 2026