Ves al contingut principal
Didit recapta 7,5M $ per construir la infraestructura per a identitat i frau
Didit
KYC reutilitzable · eIDAS 2 de la UE

Verifica una vegada. Reutilitza a tot arreu.

Fes un únic KYC de $0.33. L'usuari verificat comparteix aquesta verificació de Didit amb qualsevol altra app que utilitzi Didit, amb divulgació selectiva i gratis a cada reutilització. Cinc eID nacionals ja són actives i l'acceptació de la cartera EUDI arribarà properament.

Amb el suport de
Y CombinatorRobinhood Ventures
Firecrawl
Slash
Crnogorski Telekom
UCSF Neuroscape
Bit2Me

Confiat per més de 3.000 organitzacions a tot el món.

Què desbloqueja la identitat reutilitzable

Identitat a la butxaca de l'usuari. Gratuït per a tothom que l'accepti.

Qualsevol KYC de Didit es pot compartir com una verificació KYC reutilitzable signada amb altres aplicacions que utilitzen Didit. Qualsevol plataforma receptora la llegeix de franc. Una verificació, per a qualsevol negoci que accepti Didit. Comença gratis.

Com funciona

Des del registre fins a l'usuari verificat en quatre passos.

Pas 01 / 04

Crea el flux de treball

Tria les comprovacions que vulguis, DNI, prova de vida, coincidència facial, sancions, adreça, edat, telèfon, correu electrònic, preguntes personalitzades. Arrossega-les a un flux al tauler de control, o publica el mateix flux a la nostra API. Crea ramificacions segons condicions, executa proves A/B, sense necessitat de codi.

Dissenyat per a la identitat reutilitzable · Preu d'infraestructura

Un KYC. Cada plataforma després, gratuït.

La identitat reutilitzable real no és una característica, és un sistema. Emissió, retenció, presentació, divulgació selectiva, actualització, revocació. Tot sota una sessió /v3/.
01 · Verifica una vegada

Un KYC. Una credencial emesa.

La primera vegada, l'usuari completa el paquet estàndard de $0.33: document d'identitat, liveness passiu, face match i anàlisi de dispositiu i IP. En acabar, Didit signa la verificació perquè l'usuari la pugui compartir amb altres apps que utilitzen Didit.
Mòdul de verificació d'usuari
02 · Divulgació selectiva

Revela només el que el verificador necessita.

Demostra que ets major de 18 anys sense revelar la data de naixement. Demostra el país sense revelar l'adreça. L'aplicació receptora només llegeix els camps que sol·licita, signats per Didit.
Mòdul KYC reutilitzable
03 · eID nacionals

Cinc eID nacionals, actives avui.

MitID, BankID Suècia, Finnish Trust Network, Smart-ID i Mobile-ID ja funcionen en el mateix flux. Qui no té eID segueix la ruta del document amb lectura del xip NFC, prova de vida i comparació facial. L'acceptació de la cartera EUDI arribarà properament.
Verificació eID
04 · Emissor · Titular · Verificador

Tres rols. Una credencial.

L'emissor signa la credencial després del KYC. L'usuari la guarda a la seva cartera. El verificador valida la signatura de l'emissor només en els camps divulgats. El triangle de confiança estàndard de les credencials verificables.
Seguretat i compliment
05 · Vigència de la credencial

Vigència de la credencial, automàtica.

L'AML continu re-examina l'usuari diàriament. Caducitat de documents, canvi de nom, sancions, tot apareix automàticament a la credencial. Les credencials caducades es rebutgen en el moment de la presentació.
Mòdul de cribratge AML
06 · Gratuït per rebre

Gratuït per a cada plataforma receptora.

L'emissió està inclosa amb cada KYC. L'emmagatzematge a la cartera és al dispositiu de l'usuari. La presentació, la divulgació selectiva i la validació de la signatura són gratuïtes, per sempre. Actualització contínua d'AML a $0.07 per usuari a l'any en comptes de gran volum.
Mòdul KYC reutilitzable
Integra

Dues crides. Una verificació, compartida.

Comparteix una sessió finalitzada des d'una aplicació de Didit i importa-la en una altra. La part receptora llegeix la decisió completa sense demanar a la persona que es torni a verificar.
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 amb una sessió finalitzada. Només l'aplicació que indiquis pot bescanviar 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"
  }'
201Creat{ "shared_from_session": "…" }
Retorna la decisió completa amb un nou id de sessió. Posa trust_review a false per enviar-la a In Review.docs →
Integració preparada per a agents

Implementa un flux d'identitat reutilitzable amb una sola indicació.

Enganxa-ho a Claude Code, Cursor, Codex, Devin, Aider o Replit Agent. Omple el teu stack. L'agent crea el flux de treball, la sessió, les crides per compartir i importar i el webhook signat.
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
Necessites més context? Consulta la documentació completa del mòdul.docs.didit.me →
Compliment per disseny

Obre un nou país amb un clic. Nosaltres fem la feina difícil.

Obrim les filials locals, assegurem les llicències, realitzem les proves de penetració, obtenim les certificacions i ens alineem amb cada nova regulació. Per desplegar verificacions en un nou país, només has d'activar un interruptor. Més de 220 països en funcionament, auditats i provats trimestralment, l'únic proveïdor d'identitat que un govern d'un estat membre de la UE ha qualificat formalment com més segur que la verificació presencial.
Llegeix el dossier de seguretat i compliment
SOC 2 · Type II — AICPA · 2026
SOC 2 · Type I — AICPA · 2026
ISO/IEC 27001 — Seguretat de la informació · 2026
Sandbox financer de la UE — Tesoro · SEPBLAC · BdE
FIDO Alliance — Membre associat · 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 remot EBA — EBA/GL/2022/15
AMLD6 · eIDAS 2.0 — Alineat amb la UE per disseny
Jugendschutz geprüft — FSM · JMStV §4(2) · 2026

Xifres de prova

Xifres de prova
  • $0.33
    Per cada primera verificació, l'única vegada que un usuari paga pel paquet KYC de Didit.
  • Free
    A cada plataforma receptora. Cada reutilització, cada presentació, cada revelació selectiva.
  • 27
    Estats membres de la UE. Cadascun ha d'oferir una cartera EUDI abans del 24 de desembre de 2026, i l'acceptació de la cartera EUDI a Didit arribarà properament.
  • 5
    eIDs nacionals disponibles avui: MitID, BankID Sweden, Finnish Trust Network, Smart-ID i Mobile-ID.
Tres nivells, una llista de preus

Comença gratis. Paga per ús. Escala a Enterprise.

500 verificacions gratuïtes cada mes, per sempre. Després, paga només quan s'executa un mòdul. Contractes personalitzats, residència de dades i acords de nivell de servei (SLA) a Enterprise.

Gratuït

$0/ mes · sense targeta

Per construir, provar i per als teus primers usuaris.

Tot el que necessites per començar:
  • 500 verificacions KYC completes cada mes
  • Identificació, prova de vida, coincidència facial, dispositiu i IP
  • Més de 200 senyals de frau, llista de bloqueig, duplicats
  • KYC reutilitzable a tota la xarxa Didit
  • Constructor de fluxos de treball, gestió de casos, SDKs
  • Suport amb IA Agent d'IA a la consola, documentació i comunitat.
Més popular

Paga per ús

$0.33per KYC complet

Més de 25 mòduls amb preus públics. Descomptes automàtics per volum.

Tot el que inclou Gratuït, i a més:
  • Detecció i seguiment AML des de 0,07 $
  • Preus del registre d'empreses per país i nivell de dades
  • Monitorització de transaccions a $0.02 cadascuna
  • Detecció de carteres a $0.15 per comprovació
  • Flux de marca blanca amb la teva pròpia marca
  • Suport amb IA Agent d'IA a la consola, documentació i comunitat.

Enterprise

Personalitzatcontracte anual

Per a grans volums i programes regulats.

Tot el que inclou Paga per ús, i a més:
  • Contractes anuals, preus per volum compromès
  • Condicions legals personalitzades i un SLA del 99,99% de temps d'activitat
  • Residència de dades, retenció, revisió de seguretat
  • Revisors manuals sota demanda
  • Condicions de revenda i marca blanca
  • Suport humà prioritari Canal de Slack compartit 24/7, gestor d'èxit assignat.

Els descomptes per volum s'apliquen automàticament a mesura que augmenta l'ús — sense negociacions ni trucades de vendes.

FAQ

Preguntes freqüents

Què és Didit?

Didit és la infraestructura per a la identitat i el frau, la plataforma que ens hauria agradat tenir quan creàvem els nostres propis productes: oberta, flexible i pensada per a desenvolupadors, perquè s'integri perfectament al teu "stack" en lloc de ser una caixa negra.

Una sola API cobreix la verificació de persones (KYC, know your customer), la verificació d'empreses (KYB, know your business), el cribratge de carteres de criptomonedes (KYT, know your transaction) i el monitoratge de transaccions en temps real, tot sobre una arquitectura dissenyada per ser:

  • Ràpida, amb un p99 de menys de 2 segons per sessió
  • Fiable, en producció amb més de 3.000 empreses en més de 220 països
  • Segura, SOC 2 Type 1 & Type 2, ISO 27001, nativa de GDPR i formalment certificada pel regulador financer espanyol com a més segura que la verificació presencial

La base tecnològica inclou: més de 14.000 tipus de documents en més de 48 idiomes, més de 1.000 fonts de dades i més de 200 senyals de frau per sessió. La infraestructura de Didit aprèn dinàmicament de cada sessió i millora cada dia.

Què és eIDAS 2.0, en paraules senzilles?

eIDAS 2.0, abreviatura d'electronic IDentification, Authentication and trust Services, és l'actualització de la UE de 2024 al seu reglament d'identitat. El canvi principal és la Cartera d'Identitat Digital Europea (sovint abreujada com a EUDI Wallet): una aplicació per a telèfons intel·ligents a la qual tindrà dret cada ciutadà i resident de la UE a finals de 2026.

La cartera conté credencials verificables, un carnet de conduir digital, una certificació d'identitat verificada, un diploma acadèmic, emeses per parts de confiança i presentades a parts dependents amb prova criptogràfica, opcionalment amb divulgació selectiva (demostrar que tens més de 18 anys sense revelar la teva data de naixement completa).

Per a les empreses, eIDAS 2.0 tracta tant d'acceptar les credencials presentades per la cartera com d'emetre les credencials que els teus usuaris porten.

Qui ha d'acceptar la Cartera EUDI, i quan?

El que estableix el Reglament (UE) 2024/1183 (eIDAS 2):

  • Els Estats membres han d'oferir almenys una Cartera Europea d'Identitat Digital (cartera EUDI) abans del 24 de desembre de 2026.
  • Les parts privades receptores legalment o contractualment obligades a utilitzar una autenticació d'usuari forta per a la identificació en línia han d'acceptar la cartera EUDI a petició de l'usuari abans del 24 de desembre de 2027 (article 5f, apartat 2). Les micro i petites empreses estan exemptes.
  • Les plataformes en línia molt grans que requereixen autenticació d'usuari també han d'acceptar la cartera EUDI a petició voluntària de l'usuari (article 5f, apartat 3). El text no estableix cap data separada per a aquesta obligació.

Altres empreses poden acceptar la cartera voluntàriament. L'acceptació de la cartera EUDI de Didit arribarà aviat: llegeix què necessita una empresa per acceptar la cartera EUDI.

Quina rapidesa té la verificació per al meu usuari final?

El flux complet normalment triga menys de 30 segons de principi a fi, agafar l'identificador, fer una foto del document, fer-se un selfie, fet. Això és el més ràpid del mercat. Els proveïdors de KYC antics solen trigar més de 90 segons per al mateix flux.

Al backend, Didit retorna el resultat en menys de dos segons a p99, mesurat des del moment en què l'usuari acaba el selfie fins al moment en què s'activa el vostre webhook. La captura mòbil està ajustada per a telèfons lents i xarxes lentes: compressió progressiva d'imatges, càrrega lenta del kit de desenvolupament de programari i un traspàs amb un sol toc de l'escriptori al telèfon mitjançant codi QR si l'usuari comença al web.

Com es diferencia la identitat reutilitzable de l'inici de sessió federat (Iniciar sessió amb Apple, Google)?

L'inici de sessió federat demostra que un compte existeix amb el proveïdor d'identitat; el negoci receptor obté una adreça de correu electrònic i potser un nom. Això no és una identitat amb grau regulador.

La identitat reutilitzable inclou:

  • Una verificació de grau de document governamental (passaport, document nacional d'identitat escanejat i amb OCR)
  • Un enllaç biomètric amb la persona que presenta la credencial (selfie comparada amb el retrat del document)
  • Una comprovació de vivacitat que detecta deepfakes, màscares i atacs de reproducció
  • Un estat AML cribrat contra sancions, PEP i llistes de mitjans adversos
  • Una certificació signada d'un proveïdor regulat, amb segell de temps i un rastre verificable

El verificador obté la mateixa seguretat reguladora que obtindria en realitzar el seu propi KYC, sense el cost, la fricció i la caiguda de conversió.

Què passa si un usuari falla, abandona o caduca?

Cada sessió té un dels set estats clars, així el teu codi sempre sap què fer:

  • Approved, totes les comprovacions superades. Fes avançar l'usuari.
  • Declined, una o més comprovacions han fallat. Pots permetre a l'usuari tornar a enviar el pas fallit específic (per exemple, tornar a fer-se la selfie) sense haver de repetir tot el flux.
  • In Review, marcat per a revisió de compliment. Obre el cas a la consola, consulta tots els senyals, decideix aprovar o rebutjar.
  • In Progress, l'usuari està a mig flux.
  • Not Started, enllaç enviat, l'usuari encara no l'ha obert. Envia un recordatori si passa massa temps.
  • Abandoned, l'usuari va obrir l'enllaç però no va acabar a temps. Torna a contactar o fes que caduqui.
  • Expired, l'enllaç de la sessió ha caducat. Crea una nova sessió.

Un webhook signat s'activa amb cada canvi d'estat, així la teva base de dades sempre està sincronitzada. Les sessions abandonades i rebutjades són gratuïtes.

On resideixen les dades dels meus clients i com es protegeixen?

Les dades de producció es processen i s'emmagatzemen a la Unió Europea per defecte, a Amazon Web Services. Els contractes empresarials poden sol·licitar regions alternatives per a jurisdiccions que ho requereixin els seus reguladors.

Xifratge a tot arreu. AES-256 en repòs a totes les bases de dades, emmagatzematge d'objectes i còpies de seguretat. Transport Layer Security 1.3 en trànsit a cada trucada API, webhook i sessió de la Business Console. Les dades biomètriques es xifren amb una Customer Master Key separada.

La retenció la controles tu. La retenció per defecte és indefinida (il·limitada), tret que la configuris més curta, entre 30 dies i 10 anys per aplicació, i pots eliminar qualsevol sessió individual en qualsevol moment des del tauler de control o l'API.

Certificacions: SOC 2 Type 1 & Type 2, ISO/IEC 27001:2022, iBeta Level 1 PAD, i una certificació pública del Tesoro / SEPBLAC / CNMV d'Espanya que la verificació remota d'identitat de Didit és més segura que la verificació presencial. Informe complet a /security-compliance.

Didit compleix amb la normativa del meu sector?

Didit compleix per defecte amb els reguladors importants per a la infraestructura d'identitat:

  • GDPR + UK GDPR, separació entre responsable i encarregat del tractament, Acord de Tractament de Dades complet publicat, autoritat de control principal designada (l'AEPD espanyola).
  • AMLD6 + EU AML Single Rulebook, més de 1.300 llistes de sancions, de persones políticament exposades i de mitjans adversos verificades en temps real.
  • eIDAS 2.0, cinc eID nacionals actives avui (MitID, BankID Suècia, Finnish Trust Network, Smart-ID, Mobile-ID); acceptació de la cartera EUDI properament.
  • MiCA (Markets in Crypto-Assets), preparat per a rampes d'accés a criptoactius, exchanges i custodis.
  • DORA, Digital Operational Resilience Act, resiliència operativa dels serveis financers de la UE.
  • BIPA, CUBI, Washington HB 1493, CCPA / CPRA, privacitat biomètrica dels EUA (Illinois, Texas, Washington) i privacitat del consumidor de Califòrnia.
  • UK Online Safety Act, obligacions de control d'edat i seguretat infantil.
  • FATF Travel Rule, dades de l'ordenant i del beneficiari en transferències de criptoactius, interoperable amb IVMS-101.

Informe detallat, cada certificat, cada carta del regulador: /security-compliance.

Quant de temps triga a integrar-se i començar a verificar usuaris?
  • 60 segons per a un compte sandbox a business.didit.me, sense targeta de crèdit.
  • 5 minuts per a una verificació funcional mitjançant Claude Code, Cursor o qualsevol agent de codificació a través del nostre servidor Model Context Protocol (MCP).
  • Un cap de setmana per a una integració llesta per a producció amb verificació de webhook signat, reintents i un flux de remei quan un usuari és rebutjat.

Tres rutes d'integració: tria la que millor s'adapti al teu stack:

  • Integra de forma nativa amb el nostre SDK per a Web, iOS, Android, React Native o Flutter.
  • Redirigeix l'usuari a la pàgina de verificació allotjada, sense SDK.
  • Envia un enllaç per correu electrònic, SMS, WhatsApp o qualsevol canal, sense feina de front-end.

Mateix tauler de control, mateixa facturació, mateix preu per èxit per als tres. Guia pas a pas a docs.didit.me/integration/integration-prompt.

Com és la història de la privacitat sota el GDPR?

La identitat reutilitzable és una millora de la privacitat respecte a l'antic stack KYC:

  • La divulgació selectiva està integrada: el verificador només veu els camps necessaris, no el document subjacent
  • Sense registre central: la credencial resideix a la cartera de l'usuari, no en un registre de Didit de qui va presentar què a qui
  • Consentiment per presentació: l'usuari aprova cada divulgació explícitament
  • Emmagatzematge resident a la UE: el paquet de proves del costat de l'emissor es manté en centres de dades de la UE; la cartera mateixa es troba al dispositiu de l'usuari
  • Dret a l'oblit: quan un usuari revoca una credencial, la plataforma receptora ha d'eliminar-la dels seus registres segons el GDPR; l'API de revocació per plataforma de Didit fa que això sigui una sola trucada

La base legal per al processament al costat receptor és l'interès legítim segons el GDPR: l'usuari ha presentat explícitament una credencial per accedir al servei. L'Acord de Processament de Dades (DPA) estàndard de Didit cobreix la relació de controlador conjunt.

Què passa si l'usuari canvia el seu document d'identitat o es muda de país?

Tres tipus de desencadenants:

  • Renovació de documents (el passaport caduca, s'emet un nou document d'identitat nacional) → l'usuari fa una actualització lleugera; la verificació es torna a emetre amb la nova empremta del document
  • Canvi material d'identitat (nou nom legal, canvi de marcador de gènere, canvi de país de residència) → reverificació completa per 0,33 $; la credencial antiga es revoca i se n'emet una de nova
  • Canvi d'estat AML (un usuari prèviament net es converteix en PEP o entra en una llista de sancions) → el monitoratge continu de Didit detecta el canvi automàticament, el camp AML de la credencial s'actualitza i cada plataforma receptora veu l'estat actualitzat en la següent presentació

La plataforma receptora no ha de perseguir mai l'usuari per a actualitzacions, la credencial porta el seu propi indicador de vigència i les credencials obsoletes es rebutgen en el moment de la presentació.

Quines proves veu un regulador per a una verificació reutilitzada?

El verificador (la plataforma receptora) obté el mateix paquet de proves per presentació que va obtenir el verificador original, a més de la cadena d'emissió:

  • Les proves KYC originals, escaneig de documents, similitud biomètrica, coincidències AML, senyals de risc de dispositiu + IP, segells de temps signats
  • La cadena d'emissió, quina plataforma impulsada per Didit va emetre la credencial, quan, en quin flux de treball
  • El registre de presentació, quan aquest usuari es va presentar a la teva plataforma, quins camps va revelar, el veredicte del teu verificador
  • L'estat AML actual, actualitzat diàriament pel monitoratge continu de Didit
  • La signatura HMAC SHA-256 en cada camp, de manera que la cadena de custòdia és demostrable

Didit és l'única plataforma KYC amb una certificació formal del govern d'un estat membre de la UE, el Tresor, el Banc d'Espanya i el SEPBLAC d'Espanya van certificar conjuntament el servei com a més segur que la verificació en persona. Aquesta certificació s'estén a cada presentació reutilitzada.

Infraestructura per a identitat i frau.

Una API per a KYC, KYB, monitorització de transaccions i anàlisi de carteres. Integra-la en 5 minuts.

Demana a una IA que resumeixi aquesta pàgina