Didit intercanvia dades de Travel Rule i criba la cartera de la contrapart en la mateixa trucada de transacció /v3/. Càrregues útils IVMS-101, 0,17 $ per transferència gestionada, 500 verificacions gratuïtes cada mes.
Robinhood Ventures
Confiat per més de 2.000 organitzacions a tot el món.
El que la Travel Rule exigeix
Cada VASP regulat ha de complir amb ambdues parts en cada transferència: el paquet IVMS-101 per al VASP contrapart, i el cribratge de risc en cadena per a si mateix. Didit els envia com una sola trucada a l'API de Transaccions: 0,17 $ gestionada, 0,04 $ amb Bring Your Own Key al proveïdor de cartera. 500 verificacions gratuïtes cada mes.
Tria les comprovacions que vulguis: identificació, prova de vida, coincidència facial, sancions, adreça, edat, telèfon, correu electrònic, preguntes personalitzades. Arrossega-les a un flux al panell de control, o publica el mateix flux a la nostra API. Crea ramificacions segons condicions, executa proves A/B, sense necessitat de codi.
Integra't de forma nativa amb el nostre SDK per a Web, iOS, Android, React Native o Flutter. Redirigeix a una pàgina allotjada. O simplement envia un enllaç al teu usuari, per correu electrònic, SMS, WhatsApp, on vulguis. Tria el que s'adapti al teu stack.
Didit allotja la càmera, les indicacions d'il·luminació, el traspàs mòbil i l'accessibilitat. Mentre l'usuari està en el flux, puntuam més de 200 senyals de frau en temps real i verifiquem cada camp amb fonts de dades autoritzades. Resultat en menys de dos segons.
Els webhooks signats en temps real mantenen la teva base de dades sincronitzada en el moment en què un usuari és aprovat, rebutjat o enviat a revisió. Consulta l'API sota demanda. O obre la consola per inspeccionar cada sessió, cada senyal i gestionar els casos a la teva manera.
Didit · IVMS-101
Originador
Beneficiari
Didit · Regles per regió
Didit · Interoperabilitat TR
Didit · Cartera no allotjada
Didit · API de transaccions
Didit · Paquet d'evidències
$ 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"
}'{ estat Aprovat · En revisió · Rebutjat }$ curl -X POST https://verification.didit.me/v3/transactions/ \
-H "x-api-key: $DIDIT_API_KEY" \
-d '{
"transaction_id": "tx-9001",
"transaction_details": { "direction": "OUTBOUND", "currency_kind": "crypto" },
"subject": { "full_name": "J. Pérez" },
"counterparty": { "full_name": "R. Beneficiary", "payment_method": { "account_id": "bc1qa3…hk22" }}
}'{ estat APROVAT · EN_REVISIÓ · REBUTJAT · ESPERANT_USUARI }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 es requereix targeta de crèdit.
Paga només pel que utilitzes. Més de 25 mòduls. Preus públics per mòdul, sense quota mínima mensual.
MSA i SLA personalitzats. Per a grans volums i programes regulats.
Comença gratis → paga només quan s'executa una comprovació → desbloqueja Enterprise per a un contracte personalitzat, SLA o residència de dades.
Didit és la infraestructura per a la identitat i el frau, la plataforma que ens hauria agradat tenir quan construíem els nostres propis productes: oberta, flexible i pensada per a desenvolupadors, perquè s'integri de veritat al teu stack en lloc de ser una caixa negra que has d'adaptar.
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 un stack dissenyat per ser:
La base: 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 en cada sessió. La infraestructura de Didit aprèn dinàmicament de cada sessió i millora cada dia.
La Travel Rule estableix que quan el valor es mou entre dos proveïdors regulats, certes dades del client,nom, número de compte, adreça, han de viatjar juntament amb el valor.
Va començar en les finances tradicionals (la US Bank Secrecy Act de 1970), va ser estesa globalment pel Grup d'Acció Financera (FATF) el 2019, i ara s'aplica a les criptomonedes a tot arreu. El format de càrrega estàndard és InterVASP Messaging Standard 101 (IVMS-101), un esquema JSON que tots els protocols principals de la Travel Rule utilitzen.
L'objectiu del regulador és simple: evitar que els actors maliciosos blanquegin guanys de forma anònima a través de cadenes de proveïdors, assegurant que les dades d'identitat segueixin el valor a cada pas.
Tot proveïdor de serveis d'actius virtuals (VASP) o proveïdor de serveis de criptoactius (CASP) regulat, exchanges, passarel·les d'entrada/sortida, carteres de custòdia, brokers, taules OTC, institucions de pagament que toquen la liquidació de criptomonedes.
Jurisdiccions actives:
FATF realitza avaluacions mútues de la implementació de cada país. Les jurisdiccions que no compleixen corren el risc de ser designades a la llista grisa.
El flux complet normalment triga menys de 30 segons de principi a fi, agafar l'ID, fer la foto del document, fer la selfie, fet. Això és el més ràpid del mercat. Els proveïdors de KYC tradicionals solen trigar més de 90 segons per al mateix flux.
Al backend, Didit retorna el resultat en menys de dos segons al p99, mesurat des del moment en què l'usuari acaba la selfie fins al moment en què s'activa el teu webhook. La captura mòbil està optimitzada 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.
El conjunt de dades mínim del FATF és:
Les dades es mouen a través d'un protocol de Travel Rule entre els dos proveïdors, no a la cadena, no a la nota de la transacció. El mercat actual està fragmentat: els proveïdors trien un o més de TRP, Sumsub Travel Rule, Notabene, Veriscope, OpenVASP i Shyft. El llenguatge compartit és IVMS-101, que tots els protocols llegeixen i escriuen.
El receptor de la transferència verifica les dades abans d'acreditar el compte del beneficiari.
Cada sessió acaba en 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 la selfie) sense tornar a executar 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.
Les dades de producció es processen i emmagatzemen a la Unió Europea per defecte, a Amazon Web Services. Els contractes empresarials poden sol·licitar regions alternatives per a jurisdiccions els reguladors de les quals ho requereixin.
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 d'API, webhook i sessió de la Business Console. Les dades biomètriques es xifren sota una Customer Master Key separada.
La retenció és teva per controlar. La retenció per defecte és indefinida (il·limitada) tret que configuris una durada 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 (auditoria Type 2 en curs), ISO/IEC 27001:2022, iBeta Level 1 PAD, i una certificació pública del Tesoro / SEPBLAC / CNMV d'Espanya que la verificació d'identitat remota de Didit és més segura que verificar algú en persona. Informe complet a /security-compliance.
Didit compleix per defecte amb els reguladors importants per a la infraestructura d'identitat:
Memo detallat, cada certificat, cada carta del regulador: /security-compliance.
Tres rutes d'integració, tria la que millor s'adapti al teu stack:
Mateix tauler de control, mateixa facturació, mateix preu de pagament per èxit per als tres. Guia pas a pas a docs.didit.me/integration/integration-prompt.
La vida real rarament produeix paquets de Travel Rule nets: les contraparts envien dades parcials, els camps no coincideixen amb el nom del KYC, els formats d'adreça difereixen. Dues vies:
DECLINED i es demana a l'usuari que torni a enviar-laIN_REVIEW i s'obre un cas a la Business Console amb la diferència destacadaAWAITING_USER i Didit crea una sessió de remei automàticament, retornant una URL de verificació a la respostaEl teu equip de compliment tria el cas, sol·licita més dades si cal, i aprova o rebutja des de la Consola. Les notes del revisor, la decisió i les marques de temps es registren per al paquet d'auditoria.
Les dades de la Travel Rule es recullen per transferència, no per relació, no hi ha una "actualització" d'un paquet de Travel Rule. Però els usuaris darrere de les transferències han de ser monitoritzats contínuament sota el paquet AML de la UE i règims equivalents.
Didit executa:
Els tres alimenten la mateixa superfície de gestió de casos, de manera que un sol revisor veu la imatge completa per usuari.
La majoria de reguladors exigeixen almenys 5 anys de registres de cada transferència de Travel Rule i de la identitat de l'usuari subjacent, de vegades més si el teu supervisor ho sol·licita.
Model de retenció de Didit:
Didit és l'única plataforma KYC amb una certificació formal d'un estat membre de la UE, el Tresor, el Banc d'Espanya i el SEPBLAC van certificar conjuntament el servei com a més segur que la verificació presencial. L'informe s'arxiva directament al teu paquet d'autorització CASP.
Una API per a KYC, KYB, monitorització de transaccions i anàlisi de carteres. Integra-la en 5 minuts.