Didit intercambia datos de Travel Rule y analiza la cartera de la contraparte en la misma llamada a la transacción /v3/. Cargas útiles IVMS-101, $0.17 por transferencia gestionada, 500 verificaciones gratis cada mes.
Robinhood Ventures
Con la confianza de más de 2.000 organizaciones en todo el mundo.
Lo que la Travel Rule debe
Cada VASP regulado debe ambas partes en cada transferencia: el paquete IVMS-101 para el VASP contraparte y el análisis de riesgo en cadena para sí mismo. Didit los envía como una sola llamada a la API de Transacciones: $0.17 gestionada, $0.04 con Bring Your Own Key en el proveedor de cartera. 500 verificaciones gratis cada mes.
Elige las comprobaciones que quieras: identificación, 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.
Intégralo de forma nativa con nuestro SDK para Web, iOS, Android, React Native o Flutter. Redirige a una página alojada. O simplemente envía a tu usuario un enlace, por correo electrónico, SMS, WhatsApp, donde quieras. Elige lo que mejor se adapte a tu stack.
Didit aloja la cámara, las indicaciones de iluminación, la transferencia móvil y la accesibilidad. Mientras el usuario está en el flujo, puntuamos más de 200 señales de fraude en tiempo real y verificamos cada campo con fuentes de datos autorizadas. El resultado en menos de dos segundos.
Los webhooks firmados en tiempo real mantienen tu base de datos sincronizada en el momento en que un usuario es aprobado, rechazado o enviado a revisión. Consulta la API bajo demanda. O abre la consola para inspeccionar cada sesión, cada señal y gestionar los casos a tu manera.
Didit · IVMS-101
Originador
Beneficiario
Didit · Reglas por región
Didit · Interoperabilidad TR
Didit · Monedero no alojado
Didit · API de transacciones
Didit · Paquete de pruebas
$ curl -X POST https://verification.didit.me/v3/session/ \
-H "x-api-key: $DIDIT_API_KEY" \
-d '{
"workflow_id": "wf_casp_onboard",
"vendor_data": "user-42"
}'{ estado Aprobado · En revisión · Rechazado }$ curl -X POST https://verification.didit.me/v3/transactions/ \
-H "x-api-key: $DIDIT_API_KEY" \
-d '{
"transaction_id": "tx-9001",
"transaction_details": { "dirección": "SALIDA", "tipo_moneda": "cripto" },
"asunto": { "nombre_completo": "J. Pérez" },
"contraparte": { "nombre_completo": "R. Beneficiario", "método_pago": { "id_cuenta": "bc1qa3…hk22" }}
}'{ estado APROBADO · EN_REVISIÓN · RECHAZADO · ESPERANDO_USUARIO }You are integrating Didit into a Virtual Asset Service Provider (VASP) / Crypto-Asset Service Provider (CASP) to satisfy the Travel Rule on every crypto transfer. Two obligations:
1. Verify the user (KYC) — identity, liveness, face match, device + IP, AML. The originator data on every outbound transfer comes from this verified profile.
2. Submit each transfer with originator + beneficiary fields (IVMS-101) AND screen the counterparty wallet — one /v3/transactions/ call.
Bundle pricing (verified live 2026-05-16):
- User Verification (KYC) bundle: $0.33 per user (Sessions API)
- Transactions API call: $0.02 base + $0.15 managed wallet screen = $0.17 per managed transfer
- With Bring Your Own Key (BYOK) on the wallet provider: $0.04 per transfer ($0.02 + $0.02)
- First 500 verifications free every month, forever
PRE-REQUISITES
- Production API key from https://business.didit.me (sandbox key in 60 seconds, no credit card).
- Webhook endpoint with HMAC SHA-256 verification of the X-Signature-V2 header.
HMAC-SHA256 verification MUST run against the raw body bytes (the raw payload as Didit sent it) BEFORE any JSON parsing — re-serialising the parsed body changes whitespace and key order, which invalidates the signature. - A workflow_id from the no-code Workflow Builder with ID Verification + Passive Liveness + Face Match 1:1 + Device & IP Analysis + AML Screening.
- Transaction Monitoring + Wallet Screening enabled in the Business Console (Transactions > Settings).
STEP 1 — Verify the user with the Sessions API (one-time onboarding)
POST https://verification.didit.me/v3/session/
Headers:
x-api-key: <your api key>
Content-Type: application/json
Body:
{
"workflow_id": "<wf id with KYC + AML modules>",
"vendor_data": "<your user id>",
"callback": "https://<your-app>/casp/onboard/callback",
"metadata": {
"purpose": "casp_onboarding"
}
}
Response: 201 Created with the hosted session URL. Sub-2-second median verdict on completion.
STEP 2 — Read the signed webhook on KYC completion
Status enum (exact case): Approved | Declined | In Review | Resubmitted | Expired | Not Finished | Kyc Expired | Abandoned.
Verify the X-Signature-V2 header BEFORE reading the body.
Capture the user's full name, date of birth, address, and any registered identity-document number from the decision payload. These fields populate the IVMS-101 originator block on every subsequent transfer.
STEP 3 — Submit every transfer with IVMS-101 + wallet screen in one call
POST https://verification.didit.me/v3/transactions/
Headers:
x-api-key: <your api key>
Content-Type: application/json
Body (required fields verified live 2026-05-16):
{
"transaction_id": "<your internal transfer reference>",
"transaction_category": "finance",
"include_crypto_screening": true,
"transaction_details": {
"direction": "OUTBOUND",
"amount": "0.45",
"currency": "ETH",
"currency_kind": "crypto",
"action_type": "transfer"
},
"subject": {
"entity_type": "individual",
"vendor_data": "<your user id>",
"full_name": "<originator name from KYC>",
"address": "<originator address from KYC>",
"dob": "<originator dob from KYC, YYYY-MM-DD>"
},
"counterparty": {
"entity_type": "individual",
"full_name": "<beneficiary name>",
"address": "<beneficiary address if known>",
"payment_method": {
"method_type": "crypto_wallet",
"account_id": "<counterparty wallet address>"
}
}
}
REQUIRED fields the API rejects if missing:
- subject.vendor_data + subject.full_name
- counterparty.full_name
- transaction_details.direction + currency + currency_kind + amount
- counterparty.payment_method.account_id (the wallet address)
Didit packages the subject + counterparty fields into an IVMS-101 payload, hands them off to the connected Travel Rule protocol (TRP / Sumsub TR / Notabene / Veriscope), runs Wallet Screening on the counterparty address server-side, and returns one verdict.
Response shape (excerpted from a real successful 201):
{
"uuid": "<server transaction uuid>",
"txn_id": "<your transaction_id echoed back>",
"status": "APPROVED",
"score": 0,
"severity": null,
"travel_rule": { "status": "EXCHANGED", "protocol": "<network>", "ivms_packet_id": "<id>" },
"props": {
"wallet_risk_score": 0,
"sanctions_hit": false,
"aml_provider": "<provider slug>",
"aml_screening_type": "WALLET_SCREENING",
"aml_screening_status": "COMPLETED"
},
"cost_breakdown": {
"total_price": 0.17,
"items": [
{ "usage_type": "transaction_aml_monitoring", "price": 0.15 },
{ "usage_type": "transaction_monitoring", "price": 0.02 }
]
}
}
Transaction status enum (exact case, UPPER_SNAKE_CASE): APPROVED | IN_REVIEW | DECLINED | AWAITING_USER.
Wallet-screen severity (UPPER): LOW | MEDIUM | HIGH | CRITICAL | UNKNOWN.
Branch logic:
APPROVED → release the crypto.
IN_REVIEW → hold the transfer, route to analyst queue.
DECLINED → refuse the transfer, log the IVMS attempt for the audit.
AWAITING_USER → redirect the user to the remediation URL on the response.
STEP 4 — Inbound transfers: ingest the counterparty's IVMS packet
When you RECEIVE a transfer from another VASP:
- The connected Travel Rule protocol delivers the originator IVMS data to you BEFORE the on-chain transfer settles.
- Submit it via the same POST /v3/transactions/ with direction: "INBOUND" and the originator fields on subject and your own beneficiary on counterparty.
- Wallet Screening runs on the originator wallet (subject.payment_method.account_id).
- Verdict drives whether to credit the user.
STEP 5 — Self-hosted (unhosted) wallet transfers
For transfers TO a self-hosted wallet (no counterparty VASP to exchange with):
- Collect the beneficiary identity from the user via a custom questionnaire ($0.10).
- Above local enhanced-due-diligence thresholds, prompt the user to sign a short message with the beneficiary wallet's private key as proof of control.
- Submit the transaction with the captured beneficiary fields + wallet address.
- Didit still runs Wallet Screening on the destination and stores the IVMS-format record for the audit.
STEP 6 — Continuous AML on the user is automatic
Every approved user is re-screened daily against 1,300+ sanctions, PEP, and adverse-media lists. There is NO separate endpoint to call. When a previously-clean user crosses an AML threshold, the session status updates and a signed webhook fires.
WEBHOOK EVENT NAMES
- Sessions: status changes flow through the standard session webhook.
- Transactions: transaction.created · transaction.updated · transaction.status.changed · transaction.alert.generated.
Verify X-Signature-V2 on every payload.
CONSTRAINTS
- Session statuses Title Case With Spaces; transaction statuses UPPER_SNAKE_CASE. Don't mix.
- EU Transfer of Funds Regulation has NO de minimis threshold for crypto — every transfer carries originator + beneficiary data.
- US Travel Rule kicks in at $3,000; UK at £1,000; Singapore at SGD 1,500; Switzerland at CHF 1,000. Apply per-workflow.
- Default record retention is 5 years post-transfer per most AML regimes; extensible per supervisor guidance.
- Wallet Screening MUST run BEFORE the crypto leaves — a post-transfer screen is useful for audit but useless for blocking.
Read the docs:
- https://docs.didit.me/transaction-monitoring/overview
- https://docs.didit.me/transaction-monitoring/transactions
- https://docs.didit.me/transaction-monitoring/aml-screening
- https://docs.didit.me/sessions-api/create-session
- https://docs.didit.me/integration/webhooks
Start free at https://business.didit.me — sandbox key in 60 seconds, 500 verifications free every month, no credit card.$0 / mes. No se requiere tarjeta de crédito.
Paga solo por lo que usas. Más de 25 módulos. Precios públicos por módulo, sin cuota mínima mensual.
MSA y SLA personalizados. Para grandes volúmenes y programas regulados.
Empieza gratis → paga solo cuando se ejecuta una verificación → desbloquea Enterprise para un contrato personalizado, SLA o residencia de datos.
Didit es la infraestructura para la identidad y el fraude que nos hubiera gustado tener cuando creá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 con la que tienes que lidiar.
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 monederos de criptomonedas (KYT, Know Your Transaction) y la monitorización de transacciones en tiempo real, todo ello sobre una infraestructura diseñada para ser:
Nuestra huella: 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.
La Travel Rule establece que cuando el valor se mueve entre dos proveedores regulados, cierta información del cliente,nombre, número de cuenta, dirección, debe viajar junto con el valor.
Comenzó en las finanzas tradicionales (la Ley de Secreto Bancario de EE. UU. de 1970), fue extendida globalmente por el Grupo de Acción Financiera Internacional (FATF) en 2019, y ahora se aplica a las criptomonedas en todas partes. El formato de carga estándar es InterVASP Messaging Standard 101 (IVMS-101), un esquema JSON que todos los principales protocolos de Travel Rule entienden.
El objetivo del regulador es simple: evitar que los malos actores laven ganancias de forma anónima a través de cadenas de proveedores, asegurando que los datos de identidad sigan el valor en cada salto.
Todo Proveedor de Servicios de Activos Virtuales (VASP) o Proveedor de Servicios de Criptoactivos (CASP) regulado: exchanges, pasarelas on/off-ramp, monederos de custodia, brókeres, mesas OTC, instituciones de pago que manejan liquidaciones de criptomonedas.
Jurisdicciones activas:
FATF realiza evaluaciones mutuas de la implementación de cada país. Las jurisdicciones que no cumplen corren el riesgo de ser designadas en la lista gris.
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.
El conjunto de datos mínimo de FATF es:
Los datos se mueven a través de un protocolo Travel Rule entre los dos proveedores, no en la cadena de bloques ni en el memo de la transacción. El mercado actual está fragmentado: los proveedores eligen uno o más de TRP, Sumsub Travel Rule, Notabene, Veriscope, OpenVASP y Shyft. El lenguaje compartido es IVMS-101, que todos los protocolos leen y escriben.
El receptor de la transferencia verifica los datos antes de abonar la cuenta del beneficiario.
Cada sesión termina en 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 hacer el selfie) sin ejecutar todo el flujo de nuevo.In Review, marcado para revisión de cumplimiento. Abre el caso en la consola, consulta todas las señales, decide 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.
Los datos de producción se procesan y almacenan en la Unión Europea por defecto, en Amazon Web Services. Los contratos empresariales pueden solicitar regiones alternativas para jurisdicciones cuyos reguladores lo requieran.
Cifrado en todas partes. AES-256 en reposo en cada base de datos, almacenamiento de objetos y copia de seguridad. Transport Layer Security 1.3 en tránsito en cada llamada API, webhook y sesión de la Business Console. Los datos biométricos se cifran bajo una Customer Master Key separada.
Tú controlas la retención. La retención predeterminada es indefinida (ilimitada) a menos que configures un período 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 (auditoría Tipo 2 en curso), ISO/IEC 27001:2022, iBeta Nivel 1 PAD, y una certificación pública del Tesoro / SEPBLAC / CNMV de España de 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 por defecto con los reguladores clave para la infraestructura de identidad:
Memorándum detallado, cada certificado, cada carta del regulador: /security-compliance.
Tres rutas de integración, elige la que mejor se adapte a tu stack:
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.
La vida real rara vez produce paquetes de Travel Rule impecables: las contrapartes envían datos parciales, los campos no coinciden con el nombre del KYC, los formatos de dirección difieren. Dos caminos:
DECLINED y se le pide al usuario que vuelva a enviar los datos.IN_REVIEW y se abre un caso en la Business Console con la diferencia resaltada.AWAITING_USER y Didit crea automáticamente una sesión de remediación, devolviendo una URL de verificación en la respuesta.Tu equipo de cumplimiento clasifica el caso, solicita más datos si es necesario y aprueba o rechaza desde la Consola. Las notas del revisor, la decisión y las marcas de tiempo se registran para el paquete de auditoría.
Los datos de la Travel Rule se recopilan por transferencia, no por relación; no hay una "actualización" de un paquete de Travel Rule. Pero los usuarios detrás de las transferencias deben ser monitoreados continuamente bajo el paquete AML de la UE y regímenes equivalentes.
Didit ejecuta:
Los tres alimentan la misma interfaz de gestión de casos, para que un único revisor vea la imagen completa por usuario.
La mayoría de los reguladores exigen al menos 5 años de registros de cada transferencia de Travel Rule y de la identidad del usuario subyacente, a veces más si tu supervisor lo solicita.
El modelo de retención de Didit:
Didit es la única plataforma KYC con una certificación formal de un estado miembro de la UE, el Tesoro, el Banco de España y el SEPBLAC de España certificaron conjuntamente el servicio como más seguro que la verificación en persona. El informe se incluye directamente en tu paquete de autorización CASP.
Una API para KYC, KYB, Monitoreo de Transacciones y Detección de Fraude en Wallets. Intégrala en 5 minutos.