Didit ट्रैवल रूल डेटा का आदान-प्रदान करता है और उसी /v3/ ट्रांजैक्शन कॉल पर काउंटरपार्टी वॉलेट को स्क्रीन करता है। IVMS-101 पेलोड, प्रति प्रबंधित ट्रांसफर $0.17, हर महीने 500 वेरिफिकेशन मुफ्त।
Robinhood Ventures
दुनिया भर में 2,000+ संगठनों द्वारा विश्वसनीय।
ट्रैवल रूल क्या देता है
हर विनियमित VASP हर ट्रांसफर पर दोनों हिस्सों का भुगतान करता है, काउंटरपार्टी VASP के लिए IVMS-101 पैकेट, और अपने लिए ऑन-चेन जोखिम स्क्रीन। Didit उन्हें एक ही ट्रांजैक्शन API कॉल के रूप में भेजता है: $0.17 प्रबंधित, वॉलेट प्रोवाइडर पर Bring Your Own Key के साथ $0.04। हर महीने 500 वेरिफिकेशन मुफ्त।
आप जो चेक चाहते हैं उन्हें चुनें, ID, लाइवनेस, फेस मैच, प्रतिबंध, पता, आयु, फोन, ईमेल, कस्टम प्रश्न। उन्हें डैशबोर्ड में एक फ्लो में ड्रैग करें, या उसी फ्लो को हमारे API पर पोस्ट करें। शर्तों पर ब्रांच करें, A/B टेस्ट चलाएं, किसी कोड की आवश्यकता नहीं है।
हमारे वेब, iOS, Android, React Native, या Flutter SDK के साथ मूल रूप से एम्बेड करें। एक होस्टेड पेज पर रीडायरेक्ट करें। या बस अपने उपयोगकर्ता को एक लिंक भेजें, ईमेल, SMS, WhatsApp, कहीं भी। चुनें कि आपके स्टैक के लिए क्या उपयुक्त है।
Didit कैमरा, लाइटिंग क्यू, मोबाइल हैंड-ऑफ और एक्सेसिबिलिटी को होस्ट करता है। जब उपयोगकर्ता फ्लो में होता है, तो हम वास्तविक समय में 200+ धोखाधड़ी संकेतों को स्कोर करते हैं और आधिकारिक डेटा स्रोतों के खिलाफ हर फ़ील्ड को सत्यापित करते हैं। दो सेकंड से भी कम समय में परिणाम।
रियल-टाइम हस्ताक्षरित वेबहुक आपके डेटाबेस को सिंक में रखते हैं जैसे ही कोई उपयोगकर्ता स्वीकृत, अस्वीकृत होता है, या समीक्षा के लिए भेजा जाता है। मांग पर API को पोल करें। या हर सेशन, हर सिग्नल का निरीक्षण करने और अपने तरीके से मामलों को प्रबंधित करने के लिए कंसोल खोलें।
Didit · IVMS-101
ओरिजिनेटर
बेनिफिशियरी
Didit · क्षेत्र-वार नियम
Didit · TR इंटरऑपरेबिलिटी
Didit · अनहोस्टेड वॉलेट
Didit · ट्रांज़ैक्शन API
Didit · एविडेंस पैक
$ 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"
}'{ स्टेटस अप्रूव्ड · इन रिव्यू · डिक्लाइंड }$ curl -X POST https://verification.didit.me/v3/transactions/ \
-H "x-api-key: $DIDIT_API_KEY" \
-d '{
"transaction_id": "tx-9001",
"transaction_details": { "direction": "आउटबाउंड", "currency_kind": "क्रिप्टो" },
"subject": { "full_name": "जे. पेरेज़" },
"counterparty": { "full_name": "आर. बेनिफिशियरी", "payment_method": { "account_id": "bc1qa3…hk22" }}
}'{ स्टेटस अप्रूव्ड · इन_रिव्यू · डिक्लाइंड · अवेटिंग_यूज़र }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 / महीना। क्रेडिट कार्ड की ज़रूरत नहीं।
आप जितना उपयोग करते हैं, केवल उसी का भुगतान करें। 25+ मॉड्यूल। प्रति-मॉड्यूल सार्वजनिक मूल्य निर्धारण, कोई मासिक न्यूनतम शुल्क नहीं।
कस्टम MSA और SLA। बड़ी मात्रा और विनियमित कार्यक्रमों के लिए।
मुफ़्त में शुरू करें → केवल चेक चलने पर भुगतान करें → कस्टम कॉन्ट्रैक्ट, SLA, या डेटा रेज़िडेंसी के लिए एंटरप्राइज़ अनलॉक करें।
Didit पहचान और धोखाधड़ी के लिए इंफ्रास्ट्रक्चर है, एक ऐसा प्लेटफॉर्म जिसकी हमें खुद प्रोडक्ट बनाते समय ज़रूरत महसूस हुई थी: ओपन, फ्लेक्सिबल और डेवलपर-फ्रेंडली, ताकि यह आपके स्टैक का एक वास्तविक हिस्सा बन सके, न कि एक ब्लैक बॉक्स जिसे आपको इंटीग्रेट करना पड़े।
एक API लोगों को वेरिफाई करने (KYC, अपने ग्राहक को जानें), व्यवसायों को वेरिफाई करने (KYB, अपने व्यवसाय को जानें), क्रिप्टो वॉलेट्स की स्क्रीनिंग करने (KYT, अपने ट्रांजेक्शन को जानें), और रियल टाइम में ट्रांजेक्शन की निगरानी करने का काम करता है, एक ऐसे स्टैक पर जो इस तरह से बनाया गया है:
इसके पीछे का फुटप्रिंट: 48+ भाषाओं में 14,000+ डॉक्यूमेंट प्रकार, 1,000+ डेटा स्रोत, और हर सेशन पर 200+ धोखाधड़ी सिग्नल। Didit इंफ्रास्ट्रक्चर हर सेशन से गतिशील रूप से सीखता है और हर दिन बेहतर होता जाता है।
जब दो रेगुलेटेड प्रोवाइडर्स के बीच वैल्यू का आदान-प्रदान होता है, तो ट्रैवल रूल के अनुसार ग्राहक की कुछ जानकारी, नाम, अकाउंट नंबर, पता, वैल्यू के साथ ही जानी चाहिए।
यह पारंपरिक फाइनेंस (1970 का अमेरिकी बैंक सीक्रेसी एक्ट) में शुरू हुआ था, जिसे 2019 में फाइनेंशियल एक्शन टास्क फोर्स (FATF) द्वारा विश्व स्तर पर बढ़ाया गया था, और अब यह हर जगह क्रिप्टो पर लागू होता है। स्टैंडर्ड पेलोड फॉर्मेट InterVASP Messaging Standard 101 (IVMS-101) है, एक JSON स्कीमा जिसे हर प्रमुख ट्रैवल रूल प्रोटोकॉल समझता है।
रेगुलेटर का लक्ष्य सीधा है: यह सुनिश्चित करके कि हर कदम पर पहचान डेटा वैल्यू के साथ चलता है, बुरे एक्टर्स को प्रोवाइडर्स की चेन के माध्यम से गुमनाम रूप से पैसे की हेराफेरी करने से रोकना।
हर रेगुलेटेड वर्चुअल एसेट सर्विस प्रोवाइडर (VASP) या क्रिप्टो-एसेट सर्विस प्रोवाइडर (CASP), एक्सचेंज, ऑन/ऑफ-रैंप, कस्टोडियल वॉलेट, ब्रोकर्स, OTC डेस्क, पेमेंट इंस्टीट्यूशंस जो क्रिप्टो सेटलमेंट से जुड़े हैं।
लाइव ज्यूरिसडिक्शन:
FATF प्रत्येक देश के कार्यान्वयन का आपसी मूल्यांकन करता है। गैर-अनुपालन वाले ज्यूरिसडिक्शन को ग्रे-लिस्ट पदनाम का जोखिम होता है।
पूरा फ्लो आमतौर पर एंड-टू-एंड 30 सेकंड से कम समय लेता है, आईडी उठाएं, डॉक्यूमेंट स्नैप करें, सेल्फी स्नैप करें, हो गया। यह मार्केट में सबसे तेज़ है। लेगेसी KYC प्रोवाइडर्स आमतौर पर इसी फ्लो के लिए 90 सेकंड से अधिक लेते हैं।
बैक एंड पर, Didit p99 पर दो सेकंड से कम में परिणाम देता है, यह उस क्षण से मापा जाता है जब यूजर सेल्फी पूरी करता है और उस क्षण तक जब आपका वेबहुक फायर होता है। मोबाइल कैप्चर धीमे फोन और धीमे नेटवर्क के लिए ट्यून किया गया है: प्रोग्रेसिव इमेज कंप्रेशन, लेज़ी सॉफ्टवेयर डेवलपमेंट किट लोड, और अगर यूजर वेब पर शुरू करता है तो QR कोड के माध्यम से डेस्कटॉप से फोन पर एक-टैप हैंड-ऑफ।
न्यूनतम FATF डेटासेट है:
डेटा दो प्रोवाइडर्स के बीच एक ट्रैवल रूल प्रोटोकॉल के माध्यम से चलता है, ऑन-चेन नहीं, ट्रांजेक्शन मेमो में नहीं। आज का मार्केट खंडित है: प्रोवाइडर्स TRP, Sumsub Travel Rule, Notabene, Veriscope, OpenVASP, और Shyft में से एक या अधिक चुनते हैं। साझा भाषा IVMS-101 है, जिसे हर प्रोटोकॉल पढ़ता और लिखता है।
ट्रांसफर का रिसीवर लाभार्थी के अकाउंट में क्रेडिट करने से पहले डेटा को वेरिफाई करता है।
हर सेशन सात स्पष्ट स्टेटस में से एक पर समाप्त होता है, इसलिए आपका कोड हमेशा जानता है कि क्या करना है:
Approved, सभी चेक पास हो गए। यूजर को आगे बढ़ाएं।Declined, एक या अधिक चेक फेल हो गए। आप यूजर को विशिष्ट फेल हुए स्टेप को फिर से सबमिट करने की अनुमति दे सकते हैं (उदाहरण के लिए, सेल्फी फिर से लें) पूरे फ्लो को फिर से चलाए बिना।In Review, कंप्लायंस रिव्यू के लिए फ्लैग किया गया। कंसोल में केस खोलें, हर सिग्नल देखें, अप्रूव या डिक्लाइन का फैसला करें।In Progress, यूजर फ्लो के बीच में है।Not Started, लिंक भेजा गया, यूजर ने अभी तक इसे नहीं खोला है। अगर यह बहुत देर तक रहता है तो रिमाइंडर भेजें।Abandoned, यूजर ने लिंक खोला लेकिन समय पर पूरा नहीं किया। फिर से संलग्न करें या एक्सपायर करें।Expired, सेशन लिंक पुराना हो गया। एक नया सेशन बनाएं।हर स्टेटस चेंज पर एक साइंड वेबहुक फायर होता है, इसलिए आपका डेटाबेस हमेशा सिंक में रहता है। अबैंडंड और डिक्लाइन किए गए सेशन मुफ्त हैं।
प्रोडक्शन डेटा डिफ़ॉल्ट रूप से यूरोपीय संघ में प्रोसेस और स्टोर किया जाता है, Amazon Web Services पर। एंटरप्राइज कॉन्ट्रैक्ट्स उन ज्यूरिसडिक्शन के लिए वैकल्पिक क्षेत्रों का अनुरोध कर सकते हैं जिनके रेगुलेटर को इसकी आवश्यकता होती है।
हर जगह एन्क्रिप्शन। हर डेटाबेस, ऑब्जेक्ट स्टोर और बैकअप में AES-256 रेस्ट पर। हर API कॉल, वेबहुक और बिजनेस कंसोल सेशन पर ट्रांजिट में ट्रांसपोर्ट लेयर सिक्योरिटी 1.3। बायोमेट्रिक डेटा एक अलग कस्टमर मास्टर की के तहत एन्क्रिप्ट किया गया है।
रिटेंशन आपके नियंत्रण में है। डिफ़ॉल्ट रिटेंशन अनिश्चित (असीमित) है जब तक आप कम कॉन्फ़िगर नहीं करते, प्रति एप्लिकेशन 30 दिन से 10 साल के बीच, और आप डैशबोर्ड या API से किसी भी समय किसी भी व्यक्तिगत सेशन को हटा सकते हैं।
प्रमाणन: SOC 2 Type 1 (Type 2 ऑडिट प्रगति पर), ISO/IEC 27001:2022, iBeta Level 1 PAD, और स्पेन के टेसोरो / SEPBLAC / CNMV से एक सार्वजनिक सत्यापन कि Didit का रिमोट आइडेंटिटी वेरिफिकेशन व्यक्तिगत रूप से किसी को वेरिफाई करने से अधिक सुरक्षित है। पूरी रिपोर्ट /security-compliance पर।
Didit डिफ़ॉल्ट रूप से उन रेगुलेटरों के लिए कंप्लायंट है जो आइडेंटिटी इंफ्रास्ट्रक्चर के लिए महत्वपूर्ण हैं:
विस्तृत मेमो, हर सर्टिफिकेट, हर रेगुलेटर लेटर: /security-compliance।
तीन इंटीग्रेशन पाथ, जो भी आपके स्टैक के अनुकूल हो उसे चुनें:
तीनों के लिए एक ही डैशबोर्ड, एक ही बिलिंग, एक ही पे-पर-सक्सेस कीमत। docs.didit.me/integration/integration-prompt पर स्टेप-बाय-स्टेप गाइड।
वास्तविक जीवन में शायद ही कभी साफ ट्रैवल रूल पैकेट बनते हैं, काउंटरपार्टी आंशिक डेटा भेजते हैं, फ़ील्ड KYC नाम से मेल नहीं खाते, पते के फॉर्मेट अलग होते हैं। दो रास्ते:
DECLINED रिटर्न करता है और यूजर को फिर से सबमिट करने के लिए कहा जाता हैIN_REVIEW रिटर्न करता है और बिजनेस कंसोल में एक केस खुलता है जिसमें अंतर हाइलाइट किया जाता हैAWAITING_USER रिटर्न करता है और Didit स्वचालित रूप से एक रेमेडिएशन सेशन बनाता है, प्रतिक्रिया पर एक वेरिफिकेशन URL लौटाता हैआपकी कंप्लायंस टीम केस को ट्राइएज करती है, यदि आवश्यक हो तो अधिक डेटा का अनुरोध करती है, और कंसोल के भीतर से अप्रूव या रिजेक्ट करती है। समीक्षक के नोट्स, निर्णय और टाइमस्टैम्प ऑडिट पैक के लिए रिकॉर्ड किए जाते हैं।
ट्रैवल रूल डेटा प्रति ट्रांसफर एकत्र किया जाता है, न कि प्रति संबंध, ट्रैवल रूल पैकेट का कोई "रिफ्रेश" नहीं होता है। लेकिन ट्रांसफर के पीछे के यूजर्स को EU AML पैकेज और समकक्ष व्यवस्थाओं के तहत लगातार मॉनिटर किया जाना चाहिए।
Didit चलाता है:
तीनों एक ही केस मैनेजमेंट सतह को फीड करते हैं, ताकि एक ही समीक्षक प्रति यूजर पूरी तस्वीर देख सके।
अधिकांश रेगुलेटर हर ट्रैवल रूल ट्रांसफर और अंतर्निहित यूजर आइडेंटिटी पर कम से कम 5 साल के रिकॉर्ड की आवश्यकता होती है, कभी-कभी अधिक यदि आपका पर्यवेक्षक इसका अनुरोध करता है।
Didit का रिटेंशन मॉडल:
Didit एकमात्र KYC प्लेटफॉर्म है जिसके पास एक औपचारिक EU सदस्य-राज्य सरकार का सत्यापन है, स्पेन के ट्रेजरी, बैंको डी एस्पाना, और SEPBLAC ने संयुक्त रूप से सेवा को व्यक्तिगत रूप से वेरिफिकेशन से अधिक सुरक्षित के रूप में सत्यापित किया। रिपोर्ट सीधे आपके CASP प्राधिकरण पैक में फाइल होती है।
KYC, KYB, ट्रांज़ैक्शन मॉनिटरिंग और वॉलेट स्क्रीनिंग के लिए एक API। 5 मिनट में इंटीग्रेट करें।