Saltar al contenido principal
Didit recauda 7,5M $ para construir la infraestructura para identidad y fraude
Didit
KYC reutilizable · eIDAS 2 de la UE

Verifica una vez. Reutiliza en cualquier lugar.

Haz un único KYC de $0.33. El usuario verificado comparte esa verificación de Didit con cualquier otra app que use Didit, con divulgación selectiva y gratis en cada reutilización. Cinco eID nacionales ya están activas y la aceptación de la cartera EUDI llegará próximamente.

Respaldado por
Y CombinatorRobinhood Ventures
Firecrawl
Slash
Crnogorski Telekom
UCSF Neuroscape
Bit2Me

Con la confianza de más de 3.000 organizaciones en todo el mundo.

Lo que la identidad reutilizable te permite hacer

Identidad en el bolsillo del usuario. Gratis para todos los que la acepten.

Cada KYC de Didit se puede compartir como una verificación KYC reutilizable firmada con otras apps que usen Didit. Cada plataforma receptora lo lee gratis. Una verificación para cualquier negocio que acepte Didit. Empieza gratis.

Cómo funciona

De registro a usuario verificado en cuatro pasos.

Paso 01 / 04

Crea el flujo de trabajo

Elige las comprobaciones que quieras: ID, prueba de vida, coincidencia facial, sanciones, dirección, edad, teléfono, correo electrónico, preguntas personalizadas. Arrástralas a un flujo en el panel de control, o publica el mismo flujo en nuestra API. Crea ramificaciones condicionales, ejecuta pruebas A/B, sin necesidad de código.

Diseñado para identidad reutilizable · Precio de infraestructura

Un KYC. Cada plataforma después, gratis.

Una identidad reutilizable real no es una característica, es un sistema. Emisión, tenencia, presentación, divulgación selectiva, actualización, revocación. Todo bajo una única sesión /v3/.
01 · Verifica una vez

Un KYC. Una credencial emitida.

La primera vez, el usuario completa el paquete estándar de $0.33: documento de identidad, prueba de vida pasiva, comparación facial y análisis de dispositivo e IP. Al terminar, Didit firma la verificación para que el usuario pueda compartirla con otras apps que usan Didit.
Módulo de Verificación de Usuario
02 · Divulgación selectiva

Revela solo lo que el verificador necesita.

Demuestra que eres mayor de 18 sin revelar tu fecha de nacimiento. Demuestra tu país sin revelar tu dirección. La app receptora solo lee los campos que solicita, firmados por Didit.
Módulo KYC reutilizable
03 · eID nacionales

Cinco eID nacionales, activas hoy.

MitID, BankID Suecia, Finnish Trust Network, Smart-ID y Mobile-ID ya funcionan en el mismo flujo. Quien no tiene eID sigue la ruta del documento con lectura del chip NFC, liveness y face match. La aceptación de la cartera EUDI llegará próximamente.
Verificación eID
04 · Emisor · Titular · Verificador

Tres roles. Una credencial.

El emisor firma la credencial después del KYC. El usuario la guarda en su wallet. El verificador valida la firma del emisor solo en los campos divulgados. Triángulo de confianza estándar de credenciales verificables.
Seguridad y cumplimiento
05 · Vigencia de la credencial

Vigencia de la credencial, automática.

El AML continuo vuelve a examinar al usuario diariamente. La caducidad del documento, el cambio de nombre, las sanciones, todo aparece automáticamente en la credencial. Las credenciales obsoletas se rechazan en el momento de la presentación.
Módulo de Detección AML
06 · Recepción gratuita

Gratis para cada plataforma receptora.

La emisión está incluida con cada KYC. El almacenamiento en la wallet está en el dispositivo del usuario. La presentación, la divulgación selectiva y la validación de la firma son gratuitas, para siempre. Actualización continua de AML a $0.07 por usuario al año en cuentas de gran volumen.
Módulo KYC reutilizable
Integra

Dos llamadas. Una verificación, compartida.

Comparte una sesión finalizada desde una aplicación de Didit e impórtala en otra. La parte receptora lee la decisión completa sin pedir a la persona que se verifique de nuevo.
POST /v3/session/{id}/share/Compartir
curl -X POST https://verification.didit.me/v3/session/$SESSION_ID/share/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "for_application_id": "<receiving-application-id>",
    "ttl_in_seconds": 3600
  }'
200OK{ "share_token": "eyJ…" }
Funciona con una sesión finalizada. Solo la aplicación que indiques puede canjear el token.docs →
POST /v3/session/import-shared/Importar
curl -X POST https://verification.didit.me/v3/session/import-shared/ \
  -H "x-api-key: $RECEIVING_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "share_token": "<share-token>",
    "trust_review": false,
    "workflow_id": "<receiving-workflow-uuid>",
    "vendor_data": "user-42"
  }'
201Creado{ "shared_from_session": "…" }
Devuelve la decisión completa con un nuevo id de sesión. Pon trust_review en false para enviarla a In Review.docs →
Integración lista para agentes

Lanza un flujo de identidad reutilizable con un solo prompt.

Pégalo en Claude Code, Cursor, Codex, Devin, Aider o Replit Agent. Rellena tu stack. El agente crea el flujo de trabajo, la sesión, las llamadas para compartir e importar y el webhook firmado.
didit-integration-prompt.md
# Didit Reusable KYC: verify a person once, share the finished session with another application

You are adding Reusable KYC to my_stack. A person completes one identity
verification; the finished session is then shared with a second Didit
application, which imports the full decision without running the checks
again. Every URL, header and enum value below is canonical. Do not paraphrase
or "improve" them.

## 0. What exists, and what does not
- Reuse is server to server, between two Didit applications: the source
  application mints a share token for a finished session, the receiving
  application redeems it. Both sides use their own x-api-key.
- There is NO reusable_identity object on the webhook or the decision, NO
  metadata.request_fields or other selective-disclosure parameter, NO
  workflow setting that "accepts" a credential, and NO revocation event. Do
  not invent them. metadata on a session is free-form JSON that Didit echoes
  back, nothing more. The receiving application gets the whole decision.
- This is not an EU Digital Identity (EUDI) Wallet integration. Didit does
  not issue or accept EUDI Wallet credentials through these calls.

## 1. Provision
- Sign up: https://business.didit.me
- Source application: its API key. Receiving application: its API key and its
  application id (a UUID: shown in the console, and sent as application_id
  on every webhook that application receives). They are different
  applications; sharing a session with the application that owns it is
  refused.

## 2. Create the workflow for the first verification
POST https://verification.didit.me/v3/workflows/
  -H "x-api-key: <source-api-key>"
  -H "Content-Type: application/json"

{
  "workflow_label": "KYC onboarding",
  "features": [
    { "feature": "OCR" },
    { "feature": "LIVENESS" },
    { "feature": "FACE_MATCH" },
    { "feature": "IP_ANALYSIS" }
  ]
}

OCR is the ID Verification feature (uppercase, strict: ID_VERIFICATION is
rejected). Add { "feature": "AML" } for sanctions and PEP screening; it is
priced separately. Response: 201. The workflow id is uuid (workflow_id carries
the same value) and features comes back as one string, "OCR + LIVENESS + ...".
Create the workflow once and keep the id: every call makes a new one.
Prices: https://didit.me/pricing

## 3. Create a session
POST https://verification.didit.me/v3/session/
  -H "x-api-key: <source-api-key>"
  -H "Content-Type: application/json"
  -d '{ "workflow_id": "<uuid from step 2>", "vendor_data": "<your user id>" }'

Response: 201 with session_id, session_token, url and status "Not Started".
Redirect the user to url (hosted flow) or open it in the Web, iOS, Android,
React Native or Flutter SDK. The field is named url on this response.
One unfinished session exists per workflow_id and vendor_data pair: calling
create again with the same pair answers 201 again with that same session.
Optional: callback, a URL the user's browser is sent back to when the flow
ends. It is a browser redirect, not a webhook: never trust its query string.

## 4. Webhook
Register a destination in the console (API & Webhooks), or over the API:

POST https://verification.didit.me/v3/webhook/destinations/
  -H "x-api-key: <your-api-key>"
  -H "Content-Type: application/json"
  -d '{
    "label": "Verification webhooks",
    "url": "https://<your-public-host>/webhooks/didit",
    "webhook_version": "v3",
    "subscribed_events": ["status.updated", "data.updated"]
  }'

label, url and subscribed_events are required. url must be a public HTTPS
address: Didit does not deliver to localhost or private addresses. Response:
201 with uuid and secret_shared_key. Store secret_shared_key as the webhook
secret (DIDIT_WEBHOOK_SECRET); it is unique to this destination. Remove a
destination with DELETE /v3/webhook/destinations/{uuid}/ (204).

What arrives:
  - webhook_type is "status.updated" (the session changed status) or
    "data.updated" (verification data was corrected after the fact)
  - a destination receives the events of every session of the application,
    so filter on workflow_id or vendor_data when several flows share it
  - creating a session already sends status.updated with status
    "Not Started". The decision key is present only when status is Approved,
    Declined, In Review or Abandoned.

Verify every delivery:

  Header:      X-Signature-V2 (not X-Signature, not X-Signature-Simple)
  Algorithm:   HMAC-SHA256, hex digest, over the canonical JSON of the payload
               (Python json.dumps(sort_keys=True, separators=(",", ":"),
               ensure_ascii=False) after whole-valued floats become ints).
               Never hash the raw request bytes under this header: that is
               the older X-Signature.
  Freshness:   the signed body field timestamp is the dispatch time (Unix
               seconds). Reject when abs(now - timestamp) > 300 seconds, and
               reject when the X-Timestamp header does not equal it.
  Idempotency: event_id is the same on every retry of one event, so store it
               and skip a delivery you already processed. One session can
               still send the same status under two event ids, and the
               console's Try Webhook test deliveries carry no event_id, so
               also make the handler safe to run twice for one
               (session_id, status, webhook_type).
  Compare:     constant-time (crypto.timingSafeEqual)

Reference handler (Express). Keep the verification lines as written.
The handler is a fragment. Put this above it and app.listen(process.env.PORT)
below it. It needs Express and Node 21 or newer (an older Node rejects
every delivery). It expects a JSON body: answer 400 yourself if you accept
anything else on this route, and refuse to start without the secret.

const express = require("express");
const app = express();
const SECRET = process.env.DIDIT_WEBHOOK_SECRET; // secret_shared_key of the destination

// Your endpoint receives a signed payload
const crypto = require("node:crypto"); // ESM: import crypto from "node:crypto"
// X-Signature-V2 = HMAC over the canonical JSON, never the raw bytes. Match the sender byte for
// byte: keys sorted by code point, integers digit for digit, floats in Python's repr.
class Num { constructor(src) { this.src = src; } } // a number as written on the wire, not a double
const num = (s) => { if (/^-?\d+$/.test(s)) return BigInt(s).toString(); const n = +s; // ints stay exact
  if (Number.isInteger(n)) return BigInt(n).toString(); const [m, e] = n.toExponential().split("e"); // 27.0 -> 27
  return +e >= -4 ? String(n) : `${m}e-${String(-e).padStart(2, "0")}`; }; // 1e-05, not 0.00001
const byCodePoint = (a, b) => Buffer.compare(Buffer.from(a), Buffer.from(b)); // UTF-8 order = Python's
const canon = (v) => Array.isArray(v) ? `[${v.map(canon)}]` : v instanceof Num ? num(v.src)
  : v && typeof v === "object" ? `{${Object.keys(v).sort(byCodePoint).map((k) => `${JSON.stringify(k)}:${canon(v[k])}`)}}`
  : JSON.stringify(v);
// Read the body as text: express.json() would round 1000000000000000129 to a double first.
// Register this route ABOVE any global app.use(express.json()): the first parser to run
// consumes the stream, and a body it already parsed has lost the digits the signature covers.
app.post("/webhooks/didit", express.text({ type: "application/json" }), (req, res) => {
  const exact = JSON.parse(req.body, (k, v, c) => typeof v === "number" ? new Num(c.source) : v); // Node 21+
  const body = JSON.parse(req.body);
  const mac = crypto.createHmac("sha256", SECRET).update(canon(exact), "utf8").digest("hex");
  const sig = Buffer.from(String(req.headers["x-signature-v2"] ?? ""));
  // Freshness comes from the signed body timestamp; the header alone is unsigned and replayable.
  const ts = body.timestamp, fresh = String(ts) === req.headers["x-timestamp"]
    && Math.abs(Date.now() / 1000 - ts) <= 300;
  if (!fresh || sig.length !== mac.length
    || !crypto.timingSafeEqual(sig, Buffer.from(mac))) return res.sendStatus(401);
  const { session_id, status, webhook_type, vendor_data, decision } = body;
  // decision is present on Approved, Declined, In Review and Abandoned.
  res.sendStatus(200);
});

Status values (exact strings): Not Started, In Progress, Approved, Declined,
In Review, Resubmitted, Expired, Abandoned, Kyc Expired. Awaiting User only
appears on business verification sessions.

## 5. Read the decision
The same V3 decision reaches you two ways:
  - webhook body: body.decision.id_verifications[]
  - GET https://verification.didit.me/v3/session/{session_id}/decision/
      -H "x-api-key: <your-api-key>"
    This response IS the decision object. Read id_verifications at the top
    level: there is no decision wrapper here.
Until the user finishes the ID step, status is "Not Started" or "In Progress"
and id_verifications is null, not an empty array. Guard for it.
The other feature results sit next to it as plural arrays: liveness_checks[],
face_matches[], ip_analyses[], aml_screenings[]. shared_from_session is null
on a session the person completed here.

## 6. Share the finished session (source application)
Only a session whose status is Approved, Declined or In Review can be shared.

POST https://verification.didit.me/v3/session/{session_id}/share/
  -H "x-api-key: <source-api-key>"
  -H "Content-Type: application/json"
  -d '{ "for_application_id": "<receiving application id>", "ttl_in_seconds": 3600 }'

Response: 200 with share_token, for_application_id and session_kind ("user").
ttl_in_seconds: 60 to 86400, default 3600. Each call mints a new token; a
token cannot be revoked, it only expires. Send it to the receiving
application's backend, never to a browser.

## 7. Import it (receiving application)
POST https://verification.didit.me/v3/session/import-shared/
  -H "x-api-key: <receiving-api-key>"
  -H "Content-Type: application/json"
  -d '{
    "share_token": "<share_token from step 6>",
    "trust_review": false,
    "workflow_id": "<a workflow id of the receiving application>",
    "vendor_data": "<user id on the receiving side>"
  }'

share_token, trust_review and workflow_id are required. trust_review true
keeps the source status (Approved stays Approved); false puts the imported
session In Review so the receiving team decides. Response: 201 with the same
decision shape as step 5, a new session_id, and shared_from_session pointing
at the source session.

## 8. Errors to handle
The message is under detail for some errors and under the field name
(for_application_id, share_token) for others: read both.
  - share, 400: "Cannot share a session with the same application."
  - share, 400: "Target application does not exist."
  - share, 400: "Only finished sessions ("Approved", "Declined", "In Review")
    can be shared."
  - import, 400 on share_token: "Invalid share token.", "Share token has
    expired.", "This token is not valid for this application."
  - import, 400: share_token, trust_review or workflow_id missing
  - import, 403: "This session has already been shared with your
    application." Mint a new token.
  - import, 404: "Workflow does not exist for this application."

## 9. Hard rules
  - base URL for v3 endpoints: verification.didit.me
  - auth header: x-api-key, one key per application
  - feature enum: OCR, LIVENESS, FACE_MATCH, IP_ANALYSIS, AML (uppercase)
  - result path: decision.id_verifications[] in the webhook body and
    id_verifications[] on the GET decision response
  - webhook: X-Signature-V2 plus X-Timestamp, canonical JSON, freshness from
    the signed body timestamp

## 10. Verify your integration
Sandbox (an application in sandbox mode: nothing is billed).
https://docs.didit.me/integration/sandbox-testing
  - create the workflow, create a session, and read its decision: expect 201,
    201 with url, and 200 with status "Not Started"
  - to get a finished session without a person, call
    POST https://verification.didit.me/v3/session/{session_id}/simulate/ with
    your x-api-key and { "new_status": "Approved" }. It sets the status and
    sends the webhook; the feature arrays stay null.
  - share that session. With no second application yet, send a random UUID
    as for_application_id and expect the 400 "Target application does not
    exist.": that proves the call is wired. A full share and import needs
    the second application's id and API key; do not fake that step.
  - assert the webhook accepts a correctly signed payload and rejects a wrong
    X-Signature-V2, a changed body, and a payload whose signed timestamp is
    older than 300 seconds, even when X-Timestamp is refreshed

Docs:
  - https://docs.didit.me/core-technology/reusable-kyc/overview
  - https://docs.didit.me/sessions-api/create-session
  - https://docs.didit.me/sessions-api/retrieve-session
  - https://docs.didit.me/integration/webhooks
¿Necesitas más contexto? Consulta la documentación completa del módulo.docs.didit.me →
Cumplimiento por diseño

Abre un nuevo país en un clic. Nosotros hacemos el trabajo duro.

Abrimos las filiales locales, aseguramos las licencias, realizamos las pruebas de penetración, obtenemos las certificaciones y nos alineamos con cada nueva regulación. Para lanzar verificaciones en un nuevo país, activa un interruptor. Más de 220 países en vivo, auditados y probados trimestralmente, el único proveedor de identidad que un gobierno de un estado miembro de la UE ha calificado formalmente como más seguro que la verificación presencial.
Lee el dossier de seguridad y cumplimiento
SOC 2 · Type II — AICPA · 2026
SOC 2 · Type I — AICPA · 2026
ISO/IEC 27001 — Seguridad de la información · 2026
Sandbox financiero de la UE — Tesoro · SEPBLAC · BdE
FIDO Alliance — Miembro asociado · 2026
iBeta Level 1 PAD — NIST / NIAP · 2026
GDPR — EU 2016/679
HIPAA — 45 CFR §160 · §164
DORA — EU 2022/2554
MiCA — EU 2023/1114
Onboarding remoto EBA — EBA/GL/2022/15
AMLD6 · eIDAS 2.0 — Alineado con la UE por diseño
Jugendschutz geprüft — FSM · JMStV §4(2) · 2026

Cifras que lo demuestran

Cifras que lo demuestran
  • $0.33
    Por la primera verificación, la única vez que un usuario paga por el paquete KYC de Didit.
  • Free
    En cada plataforma receptora. Cada reutilización, cada presentación, cada revelación selectiva.
  • 27
    Estados miembros de la UE. Cada uno debe ofrecer una cartera EUDI antes del 24 de diciembre de 2026, y la aceptación de la cartera EUDI en Didit llegará próximamente.
  • 5
    eIDs nacionales disponibles hoy: MitID, BankID Sweden, Finnish Trust Network, Smart-ID y Mobile-ID.
Tres niveles, una lista de precios

Empieza gratis. Paga por uso. Escala a Enterprise.

500 verificaciones gratis cada mes, para siempre. Después, paga solo cuando se ejecute un módulo. Contratos personalizados, residencia de datos y acuerdos de nivel de servicio (SLA) en Enterprise.

Gratis

$0/ mes · sin tarjeta

Para construir, probar y tus primeros usuarios.

Todo lo que necesitas para empezar:
  • 500 verificaciones KYC completas cada mes
  • ID, prueba de vida, coincidencia facial, dispositivo e IP
  • Más de 200 señales de fraude, lista de bloqueo, duplicados
  • KYC reutilizable en toda la red Didit
  • Constructor de flujos de trabajo, gestión de casos, SDKs
  • Soporte con IA Agente de IA en consola, documentación y comunidad.
El más popular

Paga por uso

$0.33por KYC completo

Más de 25 módulos con precios públicos. Descuentos automáticos por volumen.

Todo lo de Gratis, más:
  • Detección y monitoreo AML desde 0,07 $
  • Precios de registro de empresas por país y nivel de datos
  • Monitoreo de transacciones a $0.02 cada una
  • Detección de wallets a $0.15 por verificación
  • Flujo de marca blanca con tu propia marca
  • Soporte con IA Agente de IA en consola, documentación y comunidad.

Enterprise

Personalizadocontrato anual

Para grandes volúmenes y programas regulados.

Todo lo de Paga por uso, más:
  • Contratos anuales, precios por volumen comprometido
  • Términos legales personalizados y un SLA de tiempo de actividad del 99,99 %
  • Residencia de datos, retención, revisión de seguridad
  • Revisores manuales bajo demanda
  • Términos para revendedores y marca blanca
  • Soporte humano prioritario Canal de Slack compartido 24/7, gestor de éxito dedicado.

Los descuentos por volumen se aplican automáticamente a medida que aumenta el uso, sin negociaciones ni llamadas de ventas.

FAQ

Preguntas frecuentes

¿Qué es Didit?

Didit es la infraestructura para identidad y fraude, la plataforma que nos hubiera gustado tener cuando desarrollábamos nuestros propios productos: abierta, flexible y pensada para desarrolladores, para que se integre de verdad en tu stack en lugar de ser una caja negra que tienes que rodear.

Una única API cubre la verificación de personas (KYC, know your customer), la verificación de empresas (KYB, know your business), el análisis de carteras de criptomonedas (KYT, know your transaction) y la monitorización de transacciones en tiempo real, todo ello sobre una arquitectura diseñada para ser:

  • Rápida, p99 inferior a 2 segundos en cada sesión
  • Fiable, en producción con más de 3.000 empresas en más de 220 países
  • Segura, SOC 2 Tipo 1 y Tipo 2, ISO 27001, nativa de GDPR y formalmente certificada por el regulador financiero español como más segura que la verificación presencial

La base tecnológica: más de 14.000 tipos de documentos en más de 48 idiomas, más de 1.000 fuentes de datos y más de 200 señales de fraude en cada sesión. La infraestructura de Didit aprende dinámicamente de cada sesión y mejora cada día.

¿Qué es eIDAS 2.0, en español sencillo?

eIDAS 2.0, abreviatura de electronic IDentification, Authentication and trust Services, es la actualización de 2024 de la UE a su reglamento de identidad. El cambio principal es la Cartera Europea de Identidad Digital (a menudo abreviada como Cartera EUDI): una aplicación para smartphone a la que todo ciudadano y residente de la UE tendrá derecho a finales de 2026.

La cartera contiene credenciales verificables, un carné de conducir digital, una certificación de identidad verificada, un diploma académico, emitidas por partes de confianza y presentadas a las partes que confían con prueba criptográfica, opcionalmente con divulgación selectiva (demostrar que eres mayor de 18 años sin revelar tu fecha de nacimiento completa).

Para las empresas, eIDAS 2.0 trata tanto de aceptar las credenciales presentadas por la cartera como de emitir las credenciales que llevan tus usuarios.

¿Quién debe aceptar la cartera EUDI y cuándo?

Lo que establece el Reglamento (UE) 2024/1183 (eIDAS 2):

  • Los Estados miembros deben ofrecer al menos una Cartera Europea de Identidad Digital (EUDI Wallet) antes del 24 de diciembre de 2026.
  • Las partes usuarias privadas que estén legal o contractualmente obligadas a utilizar una autenticación de usuario fuerte para la identificación en línea deben aceptar la cartera EUDI a petición del usuario antes del 24 de diciembre de 2027 (Artículo 5f(2)). Las microempresas y las pequeñas empresas están exentas.
  • Las plataformas en línea de muy gran tamaño que requieran autenticación de usuario también deben aceptar la cartera EUDI a petición voluntaria del usuario (Artículo 5f(3)). El texto no establece una fecha separada para esta obligación.

Otras empresas pueden aceptar la cartera voluntariamente. La aceptación de la cartera EUDI por parte de Didit llegará pronto: lee lo que una empresa necesita para aceptar la cartera EUDI.

¿Qué tan rápida es la verificación para mi usuario final?

El flujo completo normalmente tarda menos de 30 segundos de principio a fin: coge el DNI, escanea el documento, hazte el selfie, listo. Es el más rápido del mercado. Los proveedores de KYC tradicionales suelen tardar más de 90 segundos para el mismo proceso.

En el back-end, Didit devuelve el resultado en menos de dos segundos en p99, medido desde que el usuario termina el selfie hasta que se activa tu webhook. La captura móvil está optimizada para teléfonos y redes lentas: compresión progresiva de imágenes, carga diferida del SDK y un traspaso con un solo toque de escritorio a teléfono mediante código QR si el usuario empieza en la web.

¿En qué se diferencia la identidad reutilizable del inicio de sesión federado (Iniciar sesión con Apple, Google)?

El inicio de sesión federado prueba que existe una cuenta con el proveedor de identidad; la empresa receptora obtiene una dirección de correo electrónico y, quizás, un nombre. Esto no es una identidad con grado regulatorio.

La identidad reutilizable incluye:

  • Una verificación con grado de documento gubernamental (pasaporte, documento nacional de identidad escaneado y con OCR)
  • Un vínculo biométrico con la persona que presenta la credencial (selfie comparada con la foto del documento)
  • Una comprobación de vida que detecta deepfakes, máscaras y ataques de repetición
  • Un estado AML filtrado contra listas de sanciones, PEP y medios adversos
  • Una certificación firmada de un proveedor regulado, con sello de tiempo y un rastro verificable

El verificador obtiene la misma tranquilidad regulatoria que obtendría al ejecutar su propio KYC, pero sin el coste, la fricción y la caída en la conversión.

¿Qué pasa si un usuario falla, abandona o caduca?

Cada sesión tiene uno de siete estados claros, para que tu código siempre sepa qué hacer:

  • Approved, todas las comprobaciones superadas. Haz que el usuario avance.
  • Declined, una o más comprobaciones fallaron. Puedes permitir que el usuario vuelva a enviar el paso específico que falló (por ejemplo, volver a hacerse la selfie) sin ejecutar de nuevo todo el flujo.
  • In Review, marcado para revisión de cumplimiento. Abre el caso en la consola, revisa todas las señales y decide si aprobar o rechazar.
  • In Progress, el usuario está a mitad del flujo.
  • Not Started, enlace enviado, el usuario aún no lo ha abierto. Envía un recordatorio si pasa demasiado tiempo.
  • Abandoned, el usuario abrió el enlace pero no terminó a tiempo. Vuelve a contactar o expira.
  • Expired, el enlace de la sesión caducó. Crea una nueva sesión.

Un webhook firmado se activa con cada cambio de estado, para que tu base de datos siempre esté sincronizada. Las sesiones abandonadas y rechazadas son gratuitas.

¿Dónde residen los datos de mis clientes y cómo se protegen?

Por defecto, los datos de producción se procesan y almacenan en la Unión Europea, en Amazon Web Services. Los contratos empresariales pueden solicitar regiones alternativas para aquellas jurisdicciones cuyos reguladores lo exijan.

Cifrado en todas partes. AES-256 en reposo en cada base de datos, almacén de objetos y copia de seguridad. Transport Layer Security 1.3 en tránsito en cada llamada a la API, webhook y sesión de la Business Console. Los datos biométricos se cifran con una Customer Master Key independiente.

Tú controlas la retención. La retención por defecto es indefinida (ilimitada), a menos que configures un periodo más corto, entre 30 días y 10 años por aplicación, y puedes eliminar cualquier sesión individual en cualquier momento desde el panel de control o la API.

Certificaciones: SOC 2 Tipo 1 y Tipo 2, ISO/IEC 27001:2022, iBeta Nivel 1 PAD, y una certificación pública del Tesoro / SEPBLAC / CNMV de España que acredita que la verificación de identidad remota de Didit es más segura que verificar a alguien en persona. Informe completo en /security-compliance.

¿Didit cumple con la normativa de mi sector?

Didit cumple por defecto con los reguladores importantes para la infraestructura de identidad:

  • GDPR + UK GDPR, separación entre responsable y encargado del tratamiento, Acuerdo de Tratamiento de Datos completo publicado, autoridad de control principal designada (la AEPD española).
  • AMLD6 + EU AML Single Rulebook, más de 1.300 listas de sanciones, de personas políticamente expuestas y de medios adversos cotejadas en tiempo real.
  • eIDAS 2.0, cinco eID nacionales activas hoy (MitID, BankID Suecia, Finnish Trust Network, Smart-ID, Mobile-ID); aceptación de la cartera EUDI próximamente.
  • MiCA (Markets in Crypto-Assets), listo para rampas de acceso a criptoactivos, exchanges y custodios.
  • DORA, Digital Operational Resilience Act, resiliencia operativa de los servicios financieros de la UE.
  • BIPA, CUBI, Washington HB 1493, CCPA / CPRA, privacidad biométrica de EE. UU. (Illinois, Texas, Washington) y privacidad del consumidor de California.
  • UK Online Safety Act, obligaciones de control de edad y seguridad infantil.
  • FATF Travel Rule, datos del ordenante y del beneficiario en transferencias de criptoactivos, interoperable con IVMS-101.

Informe detallado, cada certificado, cada carta del regulador: /security-compliance.

¿Qué tan rápido puedo integrar y empezar a verificar usuarios?
  • 60 segundos para una cuenta sandbox en business.didit.me, sin tarjeta de crédito.
  • 5 minutos para una verificación funcional a través de Claude Code, Cursor o cualquier agente de codificación mediante nuestro servidor Model Context Protocol (MCP).
  • Un fin de semana para una integración lista para producción con verificación de webhook firmado, reintentos y un flujo de remediación cuando se rechaza a un usuario.

Tres rutas de integración, elige la que mejor se adapte a tu stack:

  • Integra de forma nativa con nuestro SDK para Web, iOS, Android, React Native o Flutter.
  • Redirige al usuario a la página de verificación alojada, sin SDK.
  • Envía un enlace por correo electrónico, SMS, WhatsApp o cualquier canal, sin trabajo de front-end.

Mismo panel de control, misma facturación, mismo precio de pago por éxito para los tres. Guía paso a paso en docs.didit.me/integration/integration-prompt.

¿Cómo es la historia de la privacidad bajo GDPR?

La identidad reutilizable es una mejora de privacidad sobre el stack KYC tradicional:

  • La divulgación selectiva está integrada: el verificador solo ve los campos necesarios, no el documento subyacente.
  • No hay registro central: la credencial reside en la cartera del usuario, no en un registro de Didit sobre quién presentó qué a quién.
  • Consentimiento por presentación: el usuario aprueba cada divulgación explícitamente.
  • Almacenamiento en la UE: el paquete de pruebas del emisor permanece en centros de datos de la UE; la cartera en sí está en el dispositivo del usuario.
  • Derecho al olvido: cuando un usuario revoca una credencial, la plataforma receptora debe eliminarla de sus registros según el GDPR; la API de revocación por plataforma de Didit lo convierte en una sola llamada.

La base legal para el procesamiento en el lado receptor es el interés legítimo bajo el GDPR: el usuario ha presentado explícitamente una credencial para acceder al servicio. El Acuerdo de Procesamiento de Datos (DPA) estándar de Didit cubre la relación de controlador conjunto.

¿Qué pasa si el usuario cambia su documento de identidad o se muda de país?

Tres tipos de disparadores:

  • Renovación de documento (el pasaporte caduca, se emite un nuevo documento de identidad nacional) → el usuario vuelve a ejecutar una actualización ligera; la verificación se reemite con la nueva huella digital del documento
  • Cambio material de identidad (nuevo nombre legal, cambio de marcador de género, cambio de país de residencia) → reverificación completa por $0.33; la credencial antigua se revoca y se emite una nueva
  • Cambio de estado AML (un usuario previamente limpio se convierte en PEP o entra en una lista de sanciones) → el monitoreo continuo de Didit detecta el cambio automáticamente, el campo AML de la credencial se actualiza y cada plataforma receptora ve el estado actualizado en la siguiente presentación

La plataforma receptora nunca tiene que perseguir al usuario para obtener actualizaciones, la credencial lleva su propia señal de frescura y las credenciales obsoletas se rechazan en el momento de la presentación.

¿Qué pruebas ve un regulador para una verificación reutilizada?

El verificador (la plataforma receptora) obtiene el mismo paquete de pruebas por presentación que obtuvo el verificador original, además de la cadena de emisión:

  • La prueba KYC original, escaneo de documentos, similitud biométrica, coincidencias AML, señales de riesgo de dispositivo + IP, marcas de tiempo firmadas.
  • La cadena de emisión, qué plataforma impulsada por Didit emitió la credencial, cuándo, en qué flujo de trabajo.
  • El registro de presentación, cuándo este usuario se presentó a tu plataforma, qué campos divulgó, el veredicto de tu verificador.
  • El estado AML actual, actualizado diariamente por el monitoreo continuo de Didit.
  • La firma HMAC SHA-256 en cada campo, para que la cadena de custodia sea demostrable.

Didit es la única plataforma KYC con una certificación formal de un gobierno de un estado miembro de la UE, el Tesoro de España, el Banco de España y el SEPBLAC certificaron conjuntamente el servicio como más seguro que la verificación en persona. Esa certificación se extiende a cada presentación reutilizada.

Infraestructura para identidad y fraude.

Una API para KYC, KYB, Monitoreo de Transacciones y Detección de Fraude en Wallets. Intégrala en 5 minutos.

Pide a una IA que resuma esta página