Zentto KYC — Resumen
Zentto KYC es la plataforma de verificación de identidad self-hosted del ecosistema Zentto: comprueba quién es una persona (KYC) y filtra contra listas de sanciones (AML) sin enviar los documentos ni las fotos de tus clientes a un tercero. Es la alternativa propia a Didit: mismo modelo de sesiones, biometría, screening y webhooks firmados, pero corriendo en tu infraestructura y sin coste por verificación.
Los datos y las fotos de los usuarios quedan bajo control de la empresa. No hay envío a un proveedor externo ni cargo por cada verificación realizada.
- URL de producción:
https://kyc.zentto.net - Consumido por las apps vía API key (prefijo
zkyc_); los operadores internos resuelven las verificaciones desde el dashboard.
Qué hace Zentto KYC
Sección titulada «Qué hace Zentto KYC»| Capacidad | Descripción |
|---|---|
| Verificación de documento | OCR del documento (anverso/reverso) y lectura de la zona MRZ (estándar ICAO 9303) |
| Liveness / anti-spoofing | Confirma que hay una persona real frente a la cámara, no una foto o pantalla |
| Face-match (1:1) | Compara el rostro del selfie con la foto del documento |
| Face-search (1:N) | Busca un rostro contra todos los ya registrados (detección de duplicados/fraude) |
| Estimación de edad | Estima la edad a partir del rostro (útil para verificar edad mínima) |
| Screening AML | Filtra el nombre contra listas de sanciones (OFAC, EU, UN, UK) |
| KYB | Verificación de empresas (Know Your Business) |
| Sesiones y workflows | Flujos reutilizables que definen qué se exige en cada verificación |
| KYC reutilizable | Compartir una verificación ya aprobada entre apps o partners, sin repetir el proceso |
| Webhooks firmados | Notifica el resultado a la app del cliente con firma HMAC-SHA256 |
Arquitectura
Sección titulada «Arquitectura»Zentto KYC se compone de cuatro piezas que corren en la propia infraestructura:
| Componente | Stack | Puerto | Para qué sirve |
|---|---|---|---|
| API backend | Node + Express | 5100 | Sesiones, documentos, AML, KYB, keys y webhooks |
| Inferencia ML | Python + FastAPI | 5200 | OCR (PaddleOCR), face-match y edad (InsightFace/ArcFace), liveness (MiniFASNet) |
| Búsqueda facial | Qdrant | — | Vector DB para face-search 1:N |
| Dashboard | Next.js | — | Consola de operadores que revisan y deciden |
| Base de datos | PostgreSQL | — | Sesiones, resultados, AML, keys y webhooks |
La API backend recibe las peticiones de las apps, delega el trabajo de visión por computadora al microservicio de inferencia ML y persiste todo en PostgreSQL. El dashboard es la cara visible para los operadores. Las apps cliente nunca hablan con el microservicio ML directamente: siempre pasan por la API.
Cómo se consume
Sección titulada «Cómo se consume»Zentto KYC es un servicio multi-tenant. Hay dos formas de interactuar con él:
- Apps y servicios (web3, hotel, medical, etc.) consumen la API con una API key
zkyc_.... Crean sesiones de verificación, redirigen al usuario y reciben el resultado por webhook o por consulta. Ver Para desarrolladores → Inicio rápido. - Operadores internos entran al dashboard para revisar las verificaciones que requieren decisión manual y resolverlas (aprobar/rechazar). Ver Guía del dashboard.
Zentto KYC vs Didit
Sección titulada «Zentto KYC vs Didit»| Aspecto | Didit | Zentto KYC |
|---|---|---|
| Modelo de despliegue | SaaS de pago (datos en el proveedor) | Self-hosted (datos propios) |
| Control de los datos | El proveedor custodia documentos y biometría | La empresa custodia todo en su infraestructura |
| Coste por verificación | Sí, por verificación | Sin coste por verificación |
| Capacidades de verificación | Documento, liveness, face-match, AML, KYB, webhooks | Las mismas |
| Código | Cerrado | Auditable |
Las capacidades funcionales son equivalentes; la diferencia es dónde viven los datos y quién paga por cada verificación.
Glosario
Sección titulada «Glosario»| Término | Significado |
|---|---|
| Sesión | Una verificación individual de una persona, con su estado y sus resultados |
| Workflow | Plantilla reutilizable que define qué se exige en una sesión (documento, liveness, face-match, AML, edad, edad mínima) |
| Liveness | Comprobación de que hay una persona real frente a la cámara (anti-spoofing) |
| Face-match | Comparación del rostro del selfie con la foto del documento (1:1) |
| AML hit | Coincidencia del nombre del usuario con una lista de sanciones; nunca se auto-aprueba |
| MRZ | Machine Readable Zone: las dos o tres líneas codificadas al pie del documento (ICAO 9303) |
| KYC reutilizable | Reutilizar una verificación ya aprobada en otra app/partner, sin repetir el proceso |
Flujo del usuario
Sección titulada «Flujo del usuario»Vista no técnica del proceso. Pensada para personal de operación, contabilidad, ventas o administración.
Editable en draw.io: descarga el SVG → en draw.io: File → Import from → Device → selecciona el SVG. Cada nodo queda editable.
Flujo técnico
Sección titulada «Flujo técnico»Vista técnica para desarrolladores: endpoints, microservicios, modelos ML y base de datos involucrados.
| Componente | Tipo | Ubicación |
|---|---|---|
POST /v1/sessions | Route Express | src/sessions/routes.ts |
POST /v1/documents/id-verification | Route Express | src/documents/routes.ts |
POST /v1/biometrics/liveness | Route Express | src/biometrics/routes.ts |
POST /v1/aml/screen | Route Express | src/aml/routes.ts |
POST /v1/kyb | Route Express | src/kyb/routes.ts |
POST /v1/webhooks | Route Express | src/webhooks/routes.ts |
POST /v1/ocr | FastAPI endpoint | inference/app/routers/ocr.py |
POST /v1/liveness | FastAPI endpoint | inference/app/routers/liveness.py |
POST /v1/face-match | FastAPI endpoint | inference/app/routers/face.py |
sessions | Tabla operativa | src/db/migrations/ |
aml_entities | Tabla sanciones | src/db/migrations/ |
webhook_endpoints | Tabla webhooks | src/db/migrations/ |
face_embeddings | Coleccion Qdrant | Qdrant vector DB |
| Dashboard Next.js | Frontend operadores | dashboard/src/ |
Editable en draw.io: descarga el SVG → File → Import from → Device.