Didit échange les données de la Travel Rule et screene le portefeuille du contrepartie sur le même appel de transaction /v3/. Payloads IVMS-101, 0,17 $ par transfert géré, 500 vérifications gratuites chaque mois.
Robinhood Ventures
Approuvé par plus de 2 000 organisations dans le monde entier.
Ce que la Travel Rule exige
Chaque VASP réglementé doit fournir les deux moitiés à chaque transfert, le paquet IVMS-101 pour le VASP contrepartie, le screening de risque on-chain pour lui-même. Didit les livre en un seul appel d'API Transactions : 0,17 $ géré, 0,04 $ avec Bring Your Own Key sur le fournisseur de portefeuille. 500 vérifications gratuites chaque mois.
Choisis les vérifications que tu souhaites, ID, liveness, correspondance faciale, sanctions, adresse, âge, téléphone, e-mail, questions personnalisées. Glisse-les dans un flux sur le tableau de bord, ou publie le même flux sur notre API. Branche sur des conditions, exécute des tests A/B, aucun code requis.
Intègre nativement avec nos SDK Web, iOS, Android, React Native ou Flutter. Redirige vers une page hébergée. Ou envoie simplement un lien à ton utilisateur, par e-mail, SMS, WhatsApp, n'importe où. Choisis ce qui convient à ta stack.
Didit gère la caméra, les repères lumineux, le transfert mobile et l'accessibilité. Pendant que l'utilisateur est dans le flux, nous évaluons plus de 200 signaux de fraude en temps réel et vérifions chaque champ par rapport à des sources de données fiables. Résultat en moins de deux secondes.
Les webhooks signés en temps réel maintiennent ta base de données synchronisée dès qu'un utilisateur est approuvé, refusé ou envoyé en révision. Interroge l'API à la demande. Ou ouvre la console pour inspecter chaque session, chaque signal, et gérer les cas à ta manière.
Didit · IVMS-101
Initiateur
Bénéficiaire
Didit · Règles par région
Didit · Interopérabilité TR
Didit · Portefeuille non hébergé
Didit · API Transactions
Didit · Dossier de preuves
$ 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"
}'{ statut Approuvé · En révision · Refusé }$ curl -X POST https://verification.didit.me/v3/transactions/ \
-H "x-api-key: $DIDIT_API_KEY" \
-d '{
"transaction_id": "tx-9001",
"transaction_details": { "direction": "SORTANT", "type_devise": "crypto" },
"sujet": { "nom_complet": "J. Pérez" },
"contrepartie": { "nom_complet": "R. Bénéficiaire", "méthode_paiement": { "id_compte": "bc1qa3…hk22" }}
}'{ statut APPROUVÉ · EN_REVUE · REFUSÉ · EN_ATTENTE_UTILISATEUR }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 $ / mois. Aucune carte de crédit requise.
Payez uniquement ce que vous utilisez. Plus de 25 modules. Tarification publique par module, sans minimum mensuel.
MSA et SLA personnalisés. Pour les gros volumes et les programmes réglementés.
Commence gratuitement → ne paie que lorsqu'une vérification est effectuée → débloque l'Enterprise pour un contrat personnalisé, un SLA ou la résidence des données.
Didit est une infrastructure d'identité et de lutte contre la fraude, la plateforme que nous aurions aimé avoir lorsque nous développions nos propres produits : ouverte, flexible et pensée pour les développeurs, afin qu'elle s'intègre parfaitement à ta stack, plutôt que d'être une boîte noire autour de laquelle tu dois t'adapter.
Une seule API couvre la vérification des personnes (KYC, Know Your Customer), la vérification des entreprises (KYB, Know Your Business), le contrôle des portefeuilles crypto (KYT, Know Your Transaction), et la surveillance des transactions en temps réel, le tout sur une stack conçue pour être :
Notre empreinte technologique : plus de 14 000 types de documents dans plus de 48 langues, plus de 1 000 sources de données, et plus de 200 signaux de fraude sur chaque session. L'infrastructure Didit apprend dynamiquement de chaque session et s'améliore chaque jour.
La Travel Rule stipule que lorsqu'une valeur transite entre deux prestataires réglementés, certaines informations client, nom, numéro de compte, adresse, doivent accompagner cette valeur.
Elle est née dans la finance traditionnelle (le Bank Secrecy Act américain de 1970), a été étendue mondialement par le Groupe d'action financière (FATF) en 2019, et s'applique désormais aux cryptos partout. Le format de données standard est l'InterVASP Messaging Standard 101 (IVMS-101), un schéma JSON que tous les principaux protocoles Travel Rule utilisent.
L'objectif du régulateur est simple : empêcher les acteurs malveillants de blanchir des fonds anonymement via des chaînes de prestataires en s'assurant que les données d'identité suivent la valeur à chaque étape.
Chaque Virtual Asset Service Provider (VASP) ou Crypto-Asset Service Provider (CASP) réglementé, exchanges, rampes d'accès/sortie, portefeuilles de garde, courtiers, desks OTC, institutions de paiement qui touchent au règlement crypto.
Juridictions actives :
Le FATF réalise des évaluations mutuelles de la mise en œuvre de chaque pays. Les juridictions non conformes risquent d'être désignées sur liste grise.
Le processus complet prend normalement moins de 30 secondes de bout en bout, prendre la pièce d'identité, la scanner, prendre le selfie, c'est fait. C'est le plus rapide du marché. Les fournisseurs KYC traditionnels prennent généralement plus de 90 secondes pour le même processus.
Côté back-end, Didit renvoie le résultat en moins de deux secondes au p99, mesuré à partir du moment où l'utilisateur termine le selfie jusqu'au déclenchement de votre webhook. La capture mobile est optimisée pour les téléphones et les réseaux lents : compression d'image progressive, chargement paresseux du SDK, et un transfert en un clic du bureau au téléphone via QR code si l'utilisateur commence sur le web.
Le jeu de données minimal du FATF est :
Les données transitent via un protocole Travel Rule entre les deux prestataires, pas on-chain, pas dans le mémo de transaction. Le marché actuel est fragmenté : les prestataires choisissent un ou plusieurs parmi TRP, Sumsub Travel Rule, Notabene, Veriscope, OpenVASP et Shyft. Le langage commun est IVMS-101, que chaque protocole lit et écrit.
Le destinataire du transfert vérifie les données avant de créditer le compte du bénéficiaire.
Chaque session aboutit à l'un des sept statuts clairs, afin que votre code sache toujours quoi faire :
Approved, toutes les vérifications sont passées. L'utilisateur peut continuer.Declined, une ou plusieurs vérifications ont échoué. Vous pouvez permettre à l'utilisateur de soumettre à nouveau l'étape spécifique qui a échoué (par exemple, reprendre le selfie) sans relancer tout le processus.In Review, signalé pour examen de conformité. Ouvrez le cas dans la console, consultez tous les signaux, décidez d'approuver ou de refuser.In Progress, l'utilisateur est en cours de processus.Not Started, lien envoyé, l'utilisateur ne l'a pas encore ouvert. Envoyez un rappel s'il reste trop longtemps inactif.Abandoned, l'utilisateur a ouvert le lien mais n'a pas terminé à temps. Relancez ou expirez.Expired, le lien de session a expiré. Créez une nouvelle session.Un webhook signé se déclenche à chaque changement de statut, afin que votre base de données reste toujours synchronisée. Les sessions abandonnées et refusées sont gratuites.
Les données de production sont traitées et stockées par défaut dans l'Union Européenne, sur Amazon Web Services. Les contrats d'entreprise peuvent demander des régions alternatives pour les juridictions dont les régulateurs l'exigent.
Chiffrement partout. AES-256 au repos sur chaque base de données, stockage d'objets et sauvegarde. Transport Layer Security 1.3 en transit sur chaque appel API, webhook et session de la Business Console. Les données biométriques sont chiffrées sous une Customer Master Key distincte.
La rétention est sous votre contrôle. La rétention par défaut est indéfinie (illimitée), sauf si vous configurez une durée plus courte, entre 30 jours et 10 ans par application, et vous pouvez supprimer n'importe quelle session individuelle à tout moment depuis le tableau de bord ou l'API.
Certifications : SOC 2 Type 1 (audit Type 2 en cours), ISO/IEC 27001:2022, iBeta Level 1 PAD, et une attestation publique du Tesoro / SEPBLAC / CNMV espagnol que la vérification d'identité à distance de Didit est plus sûre que la vérification en personne. Rapport complet sur /security-compliance.
Didit est conforme par défaut pour les régulateurs importants en matière d'infrastructure d'identité :
Mémo détaillé, chaque certificat, chaque lettre de régulateur : /security-compliance.
Trois chemins d'intégration, choisissez celui qui correspond à votre stack :
Même tableau de bord, même facturation, même prix par succès pour les trois. Guide étape par étape sur docs.didit.me/integration/integration-prompt.
La réalité produit rarement des paquets Travel Rule impeccables, les contreparties envoient des données partielles, les champs ne correspondent pas au nom KYC, les formats d'adresse diffèrent. Deux chemins :
DECLINED et l'utilisateur est invité à soumettre à nouveauIN_REVIEW et un cas s'ouvre dans la Business Console avec la différence mise en évidenceAWAITING_USER et Didit crée automatiquement une session de remédiation, renvoyant une URL de vérification dans la réponseVotre équipe de conformité examine le cas, demande plus de données si nécessaire, et approuve ou rejette depuis la Console. Les notes du réviseur, la décision et les horodatages sont enregistrés pour le dossier d'audit.
Les données de la Travel Rule sont collectées par transfert, et non par relation, il n'y a pas de « rafraîchissement » d'un paquet Travel Rule. Mais les utilisateurs derrière les transferts doivent être surveillés en permanence en vertu du paquet AML de l'UE et des régimes équivalents.
Didit exécute :
Les trois alimentent la même interface de gestion des cas, de sorte qu'un seul examinateur a une vue d'ensemble complète par utilisateur.
La plupart des régulateurs exigent au moins 5 ans de conservation des enregistrements pour chaque transfert Travel Rule et l'identité de l'utilisateur sous-jacent, parfois plus si votre superviseur le demande.
Le modèle de rétention de Didit :
Didit est la seule plateforme KYC avec une attestation officielle d'un État membre de l'UE, le Trésor espagnol, la Banque d'Espagne et le SEPBLAC ont conjointement attesté que le service est plus sûr que la vérification en personne. Le rapport est directement intégré à votre dossier d'autorisation CASP.
Une seule API pour le KYC, le KYB, la surveillance des transactions et le screening de portefeuilles. Intégration en 5 minutes.