Travel Rule API: VASP के लिए FATF अनुपालन

​

अवलोकन

• आप transaction_category: "travelRule" के साथ एक ट्रांसफ़र सबमिट करते हैं।
• Didit प्रतिपक्ष VASP तक पहुँचने के लिए प्राथमिकता क्रम में मार्गों को आज़माता है, पहले पहुँचने वाले मार्ग पर विनिमय चलाता है और, जहाँ दूसरी ओर से लाभार्थी का नाम लौटाया जाता है, उसे आपके भेजे गए नाम से मिलाता है।
• केवल जब विनिमय COMPLETED तक पहुँच जाए, तभी आपको ट्रांसफ़र को ऑन-चेन ब्रॉडकास्ट करना चाहिए।
• फिर आप ऑन-चेन लेन-देन का हैश Didit को वापस रिपोर्ट करते हैं, ताकि विनिमय FINISHED के रूप में बंद हो जाए।

​

जब आप ट्रांसफ़र सबमिट करते हैं तो क्या चलता है

1. मान्यकरण और subject बाइंडिंग। payload का मान्यकरण होता है। transaction_id जो आपके एप्लिकेशन में पहले से उपयोग हो चुका है, उसे 400 के साथ अस्वीकार किया जाता है। जब दो अनुरोध एक ही id के साथ टकराते हैं, तो उनमें से एक को 409 मिलता है। subject को vendor_data के ज़रिए आपके उपयोगकर्ता या व्यवसाय प्रोफ़ाइल से जोड़ा जाता है, ताकि ट्रांसफ़र मॉनिटरिंग के लिए उस प्रोफ़ाइल पर दिखे। ब्लॉकलिस्ट किए गए subject या प्रतिपक्ष vendor_data को 400 के साथ अस्वीकार किया जाता है, और कोई लेन-देन नहीं बनता। ब्लॉकलिस्ट किए गए वॉलेट, बैंक खाते, IP और डिवाइस चरण 6 में जाँचे जाते हैं। वहाँ रूटिंग चलने के बाद वे लेन-देन को अस्वीकार करते हैं।
2. डिवाइस और नेटवर्क एन्रिचमेंट। पक्षों के IP को भू-स्थानिक जानकारी से समृद्ध किया जाता है। कोई भी डिवाइस संदर्भ (SDK सबमिशन पर स्वचालित) डिवाइस ग्राफ़ में सामान्य किया जाता है। यह वही ग्राफ़ है जिसमें KYC सत्र डेटा डालते हैं, इसलिए “डिवाइस के आधार पर संबंधित” ऑनबोर्डिंग और लेन-देन दोनों में काम करता है।
3. क्रिप्टो स्क्रीनिंग। मॉनिटरिंग चालू होने पर क्रिप्टो ट्रांसफ़र के लिए संबंधित वॉलेट (या ऑन-चेन हैश) को किसी भी एक्सचेंज से पहले ब्लॉकचेन एनालिटिक्स के विरुद्ध स्क्रीन किया जाता है। इसमें प्रतिबंधों के संपर्क में आने का जोखिम, मिक्सर से निकटता और चोरी किए गए फ़ंड की जाँच की जाती है। देखें क्रिप्टो और वॉलेट स्क्रीनिंग।
4. Travel Rule ट्रांसफ़र। एक्सचेंज इंजन थ्रेशोल्ड की जाँच करता है और स्व-होस्टेड वॉलेट घोषणा का सम्मान करता है। फिर ट्रांसफ़र सहेजता है: आपके थ्रेशोल्ड से नीचे NOT_APPLICABLE, घोषित स्व-होस्टेड वॉलेट के लिए UNCONFIRMED_OWNERSHIP, जब दूसरा वॉलेट आपका अपना सत्यापित वॉलेट हो तो COMPLETED, और बाकी मामलों में AWAITING_COUNTERPARTY, जिसकी रेल अभी खाली होती है। हर स्थिति परिवर्तन एक travel_rule.status.updated इवेंट कतार में डालता है, और Didit इसे लेन-देन के transaction.created (चरण 7) के बाद भेजता है।
5. वॉलेट-स्वामित्व मिंटिंग। अगर ट्रांसफ़र के लिए अंतिम उपयोगकर्ता के नियंत्रण का प्रमाण चाहिए और auto_wallet_verification चालू है, तो वॉलेट-स्वामित्व विजेट सत्र बनाया जाता है और action_required में लौटाया जाता है।
6. नियमों का मूल्यांकन। हर सक्रिय नियम चलता है। EU TFR बंडल चरण 4 में सेट किए गए ट्रांसफ़र स्थिति पर प्रतिक्रिया देता है, आपके कस्टम नियम चरण 3 के स्क्रीनिंग आउटपुट को देखते हैं, और कोई नियम लेन-देन को रोक सकता है (IN_REVIEW), उसे अस्वीकार कर सकता है, या अतिरिक्त सत्यापन माँग सकता है (AWAITING_USER)।
7. बिलिंग और सूचना। आउटबाउंड लेन-देन एक ही लाइन पर बिल होता है: जब उसने एक्सचेंज शुरू किया हो तो Travel Rule लाइन, और बाकी मामलों में Transaction Screening। इनबाउंड ट्रांसफ़र पर कोई शुल्क नहीं लगता, और सैंडबॉक्स एप्लिकेशन से कभी शुल्क नहीं लिया जाता। रिस्पॉन्स लौटता है, transaction.created आपके webhook गंतव्यों पर फ़ायर होता है, और उसके बाद चरण 4 के travel_rule.status.updated इवेंट आते हैं।
8. रूटिंग, रिस्पॉन्स के बाद। Didit सात रेल को प्राथमिकता क्रम में देखता है। अगर कोई भी समाधान नहीं होता, तो ब्लॉकचेन एनालिटिक्स एट्रिब्यूशन प्रतिपक्ष की पहचान करता है और रेलें एक बार फिर चलती हैं। पहली पहुँच योग्य रेल एक्सचेंज ले जाती है। प्रतिपक्ष के जवाब देने तक ट्रांसफ़र उस रेल पर AWAITING_COUNTERPARTY रहता है। जब कोई INTERNAL प्रतिपक्ष मेल खाता है, तो ट्रांसफ़र तुरंत निपट जाता है (COMPLETED या COUNTERPARTY_MISMATCHED_DATA)। जब कोई रेल प्रतिपक्ष तक नहीं पहुँचती, तो स्थिति COUNTERPARTY_VASP_NOT_FOUND हो जाती है। हर परिवर्तन travel_rule.status.updated फ़ायर करता है, और जब भी स्थिति या रेल बदलती है, आपके नियम फिर चलते हैं। जो ट्रांसफ़र रूटिंग के बाद COUNTERPARTY_VASP_NOT_FOUND में रहता है, उसे उसी समय उसका वॉलेट-स्वामित्व विजेट सत्र मिलता है (जब auto_wallet_verification चालू हो)। इसे लेन-देन के action_required से Get transaction के साथ पढ़ें।

​

हर चरण आपकी ज़िम्मेदारी कैसे पूरी करता है

​

जीवनचक्र

​

डिलीवरी और पुनः प्रयास

​

पुरानी स्थिति मान

​

सेटअप

curl -X GET https://verification.didit.me/v3/travel-rule/settings/ \
  -H "x-api-key: YOUR_API_KEY"

{
  "is_enabled": false,
  "jurisdiction": "EU",
  "name_matching_strictness": "DEFAULT",
  "confirmation_timeout_hours": 48,
  "timeout_outcome": "HOLD",
  "threshold_amount": "0.00",
  "inbound_auto_accept": true,
  "allow_self_declaration": true,
  "allow_screenshot_proof": true,
  "auto_wallet_verification": true,
  "vasp_attribution_enabled": true,
  "counterparty_screening_enabled": false,
  "sunrise_policy": "",
  "sunrise_jurisdictions": ["CO", "KH", "VN"],
  "non_responsive_policy": "",
  "legal_name": "",
  "lei": "",
  "compliance_email": "",
  "is_discoverable": true,
  "travel_address": "",
  "disabled_networks": [],
  "networks": {
    "gtr": { "rail": "GTR", "mode": "unavailable", "platform_available": false, "connected": false },
    "trust": { "rail": "TRUST", "mode": "unavailable", "platform_available": false, "connected": false },
    "verifyvasp": { "rail": "VERIFYVASP", "mode": "unavailable", "platform_available": false, "connected": false },
    "sygna": { "rail": "SYGNA", "mode": "unavailable", "platform_available": false, "connected": false }
  }
}

curl -X PUT https://verification.didit.me/v3/travel-rule/settings/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "is_enabled": true,
    "legal_name": "Origin CASP SL",
    "jurisdiction": "EU",
    "name_matching_strictness": "DEFAULT",
    "confirmation_timeout_hours": 48,
    "timeout_outcome": "HOLD",
    "is_discoverable": true
  }'

​

नाम मिलान की सख्ती

​

स्वामित्व सत्यापन मोड

​

डेटा साझाकरण

{
  "data_sharing_fields": {
    "individual": ["name", "wallet_address", "address", "date_of_birth"],
    "company": ["name", "wallet_address", "address"]
  }
}

• व्यक्ति name, wallet_address, address, national_id, customer_identification, date_of_birth और place_of_birth साझा कर सकते हैं। कंपनियाँ पहले पाँच साझा करती हैं।
• name और wallet_address हमेशा भेजे जाते हैं।
• जिस इकाई प्रकार को आपने कभी चुना नहीं, वह हर फ़ील्ड साझा करता है। खाली सूची भी एक चुनाव है: वह केवल नाम और वॉलेट साझा करती है।
• PUT इकाई प्रकार के अनुसार मर्ज करता है, इसलिए individual भेजने से संग्रहीत company चुनाव अप्रभावित रहता है।
• ऐसा चुनाव जो आपके क्षेत्राधिकार (jurisdiction) की व्यवस्था (EU TFR या FATF सिफ़ारिश 16) की प्रेषक दायित्वों को पूरा नहीं कर सकता, खाली सूची सहित, 400 के साथ अस्वीकार होता है। त्रुटियाँ data_sharing_fields के अंतर्गत इकाई प्रकार के अनुसार दिखती हैं।

​

फ़ील्ड-वार मिलान

{
  "matching_rules": {
    "individual": { "name": "DEFAULT", "date_of_birth": "STRICT", "address": "NONE", "account": "STRICT" },
    "company": { "name": "FUZZY", "address": "NONE", "account": "STRICT" }
  }
}

​

क्षेत्राधिकार के अनुसार थ्रेशोल्ड

​

IVMS 101 डेटा मॉडल

• लैटिन लिपि। IVMS 101 के लिए लैटिन-लिपि के मान आवश्यक हैं, इसलिए जो नाम किसी दूसरी लिपि में लिखे हैं उन्हें लैटिन में ट्रांसलिटरेट करें। Didit का नाम मिलान सामान्यीकृत token सेट की तुलना करता है, इसलिए क्रम और अक्षर-रूप के अंतर से आदान-प्रदान विफल नहीं होता। लेकिन दोनों ओर अलग-अलग लिपियाँ होने पर वह विफल होगा।
• वह डेटा भेजें जिसे आपने सत्यापित किया है। जब vendor_data से जुड़ा विषय ऐसा उपयोगकर्ता हो जिसकी Didit KYC सत्यापन स्वीकृत है, तो Didit आपके टाइप किए मानों के बजाय सत्यापित पहचान भेजता है। देखें सत्यापित डेटा और स्रोत। किसी अन्य विषय के लिए Didit वही originator_data भेजता है जो आप भेजते हैं। इसलिए उसे ऑनबोर्डिंग के समय सत्यापित पहचान से बनाएँ, किसी असत्यापित फ़ॉर्म फ़ील्ड से नहीं। FATF की “required and accurate originator information” शर्त यही माँगती है। INTERNAL चैनल पर, लाभार्थी का एप्लिकेशन अपने आने वाले लेन-देन के प्रतिपक्ष के रूप में वह subject भी प्राप्त करता है जो आपने भेजा था (नाम, vendor_data, जन्म तिथि, देश और पता)।

​

सत्यापित डेटा और स्रोत

• POST /v3/transactions/ से आपके बनाए outbound transfer का originator;
• POST /v3/transactions/ से आपके रिपोर्ट किए inbound transfer का beneficiary, या POST /v3/travel-rule/inbound/ से, जब मिलान किए गए wallet का holder_vendor_data उस उपयोगकर्ता का नाम बताता हो।

{
  "metadata": {
    "originator_provenance": { "name": "verified", "date_of_birth": "verified", "customer_identification": "caller" },
    "originator_verified_differences": {
      "name": { "caller": "Jane Doe", "verified": "Jane Elizabeth Doe" }
    }
  }
}

​

IVMS 101 सीधे भेजना

• एक originator और एक beneficiary block, जिसमें originatorPersons या beneficiaryPersons के भीतर naturalPerson या legalPerson हो, साथ में accountNumber;
• वही blocks एक ivms101 (या IVMS101) object के भीतर;
• एक IVMS 101 person, या पूरा block, originator_data या beneficiary_data के रूप में।

{
  "travel_rule_details": {
    "status": "AWAITING_COUNTERPARTY",
    "beneficiary": {
      "beneficiaryPersons": [
        {
          "naturalPerson": {
            "name": { "nameIdentifier": [{ "primaryIdentifier": "Ruiz", "secondaryIdentifier": "Carlos", "nameIdentifierType": "LEGL" }] }
          }
        }
      ],
      "accountNumber": ["0xBeneficiaryWallet01"]
    }
  }
}

​

नियामकीय व्यवस्था के अनुसार आवश्यक डेटा

​

Travel Address

ta2ih1MicegQ3JqiKz9xT89KsSuwaDJYw8DgzmeSEp1h9tduJcNDZ5SgKLEHeyGMcS1s2HgbM6undFrMQknhM5aTXw3G9KBzi16hx

​

नेटवर्क क्रेडेंशियल के बिना परीक्षण

• सैंडबॉक्स आउटबाउंड: सैंडबॉक्स एप्लिकेशन से travelRule ट्रांज़ैक्शन सबमिट करें। थ्रेशोल्ड और स्व-होस्टेड वॉलेट की जाँच के बाद, Didit Test VASP उसका उत्तर Didit के भीतर ही देता है, उस परिदृश्य के साथ जो आप लाभार्थी वॉलेट या नाम से चुनते हैं: स्वीकृति, अस्वीकृति, नाम का मेल न खाना, पहुँच से बाहर होना, टाइमआउट या स्व-होस्टेड। कोई नेटवर्क, ईमेल, या कोई अन्य Didit ग्राहक कुछ भी प्राप्त नहीं करता।
• सैंडबॉक्स इनबाउंड: Test VASP से Trigger Test VASP Inbound Transfer के ज़रिए आपको ट्रांसफ़र भेजवाएँ, या Register Inbound Travel Rule Transfer से स्वयं एक पंजीकृत करें। अज्ञात वॉलेट, असत्यापित वॉलेट, लाभार्थी के नाम का मेल न खाना, और सत्यापित मेल खाने वाला वॉलेट परखें। ये किसी नेटवर्क से संपर्क किए बिना वास्तविक इनबाउंड निर्णयों का परीक्षण होता है।
• दो नियंत्रित लाइव एप्लिकेशन: अपने दो लाइव एप्लिकेशन के बीच INTERNAL रेल का उपयोग करें (प्राप्त करने वाला एप्लिकेशन खोजा जा सकता है और हस्ताक्षरित संदेश या टेस्ट डिपॉज़िट से गंतव्य वॉलेट पर अपना नियंत्रण सिद्ध करता है), या कोई नियंत्रित TRP प्रतिपक्ष, ताकि वाणिज्यिक नेटवर्क क्रेडेंशियल के बिना दो-पक्षीय आदान-प्रदान का परीक्षण हो सके। लाइव एप्लिकेशन पर सामान्य शुल्क और सूचनाएँ लग सकती हैं; केवल ऐसी टेस्ट पहचान और प्रतिपक्ष उपयोग करें जो आपके नियंत्रण में हों।

​

ट्रांसफ़र भेजना

1. यदि राशि आपकी कॉन्फ़िगर की गई threshold_amount से कम है, तो ट्रांसफ़र तुरंत NOT_APPLICABLE पर हल हो जाता है और कोई बातचीत नहीं होती।
2. यदि काउंटरपार्टी की भुगतान विधि गंतव्य को स्व-होस्टेड वॉलेट घोषित करती है (payment_method.method_type: "unhosted_wallet"), तो कोई मार्ग आज़माया नहीं जाता। ट्रांसफ़र सीधे UNCONFIRMED_OWNERSHIP पर जाता है और वॉलेट-स्वामित्व विजेट अपने आप बन जाता है (देखें घोषित स्व-होस्टेड वॉलेट)।
3. अन्यथा मार्ग प्राथमिकता क्रम में चलते हैं, और पहला मार्ग जो काउंटरपार्टी तक पहुँच सकता है, वही एक्सचेंज संचालित करता है:
   • INTERNAL - ठीक एक अन्य Didit ग्राहक के पास beneficiary_data.wallet_address के लिए साइन किए गए संदेश या टेस्ट डिपॉज़िट का प्रमाण होता है, जो वॉलेट के आख़िरी बार स्वामी बदलने के बाद बनाया गया हो। आपका अपना एप्लिकेशन कभी नहीं गिना जाता, और जब आपका अंतिम उपयोगकर्ता वॉलेट-स्वामित्व विजेट में Didit नेटवर्क के किसी सदस्य को चुनता है, तो केवल उस सदस्य का प्रमाण गिना जाता है। उस ग्राहक का एप्लिकेशन लाइव (सैंडबॉक्स नहीं) है, उसके पास Travel Rule चालू है और is_discoverable सेट है, और वही VASP है जिसका नाम आप counterparty_vasp_lei या counterparty_vasp_name भेजते समय देते हैं। जो वॉलेट केवल स्व-घोषित है, स्क्रीनशॉट से सिद्ध है, असत्यापित है या केवल एड्रेस बुक में सूचीबद्ध है, उसे INTERNAL के ज़रिए कभी कुछ नहीं मिलता।
   • TRP - ट्रांसफ़र के एसेट की नेटवर्क के लिए Digital Token Identifier मैपिंग है (देखें TRP एसेट पहचानकर्ता), और payload में beneficiary_data.travel_address है, या गंतव्य की अपनी एड्रेस-बुक प्रविष्टि एक Travel Address संग्रहीत करती है, या काउंटरपार्टी डायरेक्टरी में (counterparty_vasp_lei या counterparty_vasp_name द्वारा) TRP एंडपॉइंट के साथ हल होती है।
   • GTR, TRUST, VERIFYVASP, SYGNA - आपने Marketplace में उस नेटवर्क के लिए अपनी स्वयं की सदस्यता जोड़ी है, और काउंटरपार्टी एक नेटवर्क आईडी तक हल होती है (स्पष्ट फ़ील्ड या डायरेक्टरी प्रविष्टि, देखें काउंटरपार्टी रिज़ॉल्यूशन फ़ील्ड)। Didit के पास अभी इन नेटवर्कों पर कोई प्लेटफ़ॉर्म सदस्यता नहीं है (यह प्रदाता के रूप में ऑनबोर्ड हो रहा है), इसलिए disabled_networks आज इस चरण को नहीं बदलता।
   • EMAIL - beneficiary_data.counterparty_vasp_email दिया गया था, या counterparty_vasp_name एक डायरेक्टरी प्रविष्टि तक हल होता है जिसमें अनुपालन ईमेल है।
4. यदि कोई मार्ग काउंटरपार्टी को हल नहीं कर सकता, तो Didit काउंटरपार्टी खोज श्रृंखला चलाता है। vasp_attribution_enabled चालू होने पर, इसमें ब्लॉकचेन एनालिटिक्स एट्रिब्यूशन भी शामिल है: गंतव्य वॉलेट को उसके स्वामी VASP से जोड़ा जाता है, एट्रिब्यूट किया गया नाम beneficiary_data.counterparty_vasp_name में लिखा जाता है (यदि वह खाली हो) और डायरेक्टरी में भी, और मार्ग एक बार फिर चलाए जाते हैं। इसलिए जिस वॉलेट का एट्रिब्यूशन ऐसे VASP से है जिसकी डायरेक्टरी प्रविष्टि में TRP एंडपॉइंट, नेटवर्क आईडी या अनुपालन ईमेल है, वह इस दूसरे पास में रूट होता है।
5. यदि काउंटरपार्टी अब भी अनसुलझा है, तो ट्रांसफ़र COUNTERPARTY_VASP_NOT_FOUND पर चला जाता है। आउटबाउंड ट्रांसफ़र पर Didit वॉलेट-स्वामित्व विजेट अपने आप बनाता है (जब auto_wallet_verification चालू हो), ताकि ट्रांसफ़र स्व-होस्टेड-वॉलेट ट्रांसफ़र के रूप में अब भी पूरा हो सके। बेहतर काउंटरपार्टी डेटा मिलने के बाद आप action: "resend" के साथ रूटिंग दोबारा चला सकते हैं।

​

TRP एसेट पहचानकर्ता

​

काउंटरपार्टी खोज

​

प्रतिपक्ष समाधान फ़ील्ड

​

चेन की संरचनाएँ

​

UTXO लेन-देन

• प्रेषक: originator_data.wallet_address जब आप इसे भेजते हैं, अन्यथा वह इनपुट पता जिसने सबसे अधिक योगदान दिया (source: largest_input)।
• लाभार्थी: घोषित वॉलेट, अन्यथा वह एकमात्र आउटपुट जो किसी इनपुट पते को चेंज के रूप में वापस भुगतान नहीं करता (only_non_change_output), अन्यथा वह एक आउटपुट जो लेन-देन की राशि चुकाता है (amount_match)।

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "btc-withdrawal-0042",
    "transaction_category": "travelRule",
    "transaction_details": {
      "direction": "outbound",
      "amount": "0.25",
      "currency": "BTC",
      "currency_kind": "crypto"
    },
    "subject": { "vendor_data": "user-042", "full_name": "Ana Diaz" },
    "counterparty": { "full_name": "Luis Perez" },
    "travel_rule_details": {
      "status": "AWAITING_COUNTERPARTY",
      "beneficiary_data": { "name": "Luis Perez", "counterparty_vasp_name": "Destination Exchange" },
      "utxo": {
        "inputs": [
          { "address": "bc1qsenderhotwallet01", "amount": "0.30" },
          { "address": "bc1qsendercoldwallet02", "amount": "0.05" }
        ],
        "outputs": [
          { "address": "bc1qbeneficiarydeposit01", "amount": "0.25" },
          { "address": "bc1qsenderhotwallet01", "amount": "0.0999" }
        ]
      }
    }
  }'

{
  "chain_details": {
    "chain": "BTC",
    "shape": "utxo",
    "originator": { "address": "bc1qsenderhotwallet01", "memo": "", "source": "largest_input" },
    "beneficiary": { "address": "bc1qbeneficiarydeposit01", "memo": "", "source": "only_non_change_output" },
    "utxo": {
      "inputs": [
        { "address": "bc1qsenderhotwallet01", "amount": "0.300000000000000000" },
        { "address": "bc1qsendercoldwallet02", "amount": "0.050000000000000000" }
      ],
      "outputs": [
        { "address": "bc1qbeneficiarydeposit01", "amount": "0.250000000000000000" },
        { "address": "bc1qsenderhotwallet01", "amount": "0.099900000000000000" }
      ],
      "change_output_indexes": [1],
      "beneficiary_output_index": 0
    }
  }
}

​

Memo और tag नेटवर्क

• memo वाली एड्रेस-बुक प्रविष्टि केवल उन्हीं ट्रांसफ़र से मेल खाती है जिनमें वही memo लिखा हो। जिस प्रविष्टि में memo नहीं है, वह पूरे पते से मेल खाती है। जो ट्रांसफ़र कोई memo नहीं बताता, वह कभी ऐसी प्रविष्टि तक नहीं पहुँचता जिसमें memo हो: साझा पते पर, टैग के बिना आया डिपॉज़िट किसी का नहीं है।
• XRP X-address में उसका टैग शामिल होता है: Didit उसे क्लासिक पते और टैग में अलग करता है (source: x_address), इसलिए किसी भी रूप में पंजीकृत वॉलेट दूसरे रूप वाले ट्रांसफ़र से मेल खाता है।
• साझा पते पर हर memo लेन-देन पर अपनी अलग भुगतान विधि होती है।
• हर नेटवर्क क्या स्वीकार करता है: XRP destination tag 0 से 4294967295 तक की पूर्ण संख्या है (JSON number स्वीकार्य है); Stellar memo अधिकतम 28 बाइट का टेक्स्ट है, 64-bit id, या hex में 32-बाइट का hash; EOS 256 बाइट तक, Cosmos 256 अक्षर तक, Hedera 100 बाइट तक लेता है। जिस चेन पर memo होता ही नहीं (Bitcoin, EVM chains, Solana, Tron, Litecoin, Bitcoin Cash, Dogecoin, Lightning) वहाँ memo 400 है।

​

Lightning

​

प्रेषक वॉलेट अपडेट करना

curl -X PATCH "https://verification.didit.me/v3/transactions/$TRANSACTION_ID/travel-rule/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "action": "update_originator_wallet", "wallet_address": "bc1qsendercoldwallet02" }'

• केवल outbound ट्रांसफ़र के लिए, और कभी भी CANCELLED या EXPIRED ट्रांसफ़र के लिए नहीं (409)।
• जब ट्रांसफ़र के UTXO इनपुट ज्ञात हों, तो वॉलेट उनमें से एक होना चाहिए (अन्यथा 400)। memo नेटवर्क पर memo भी भेजें।
• यह केवल रिकॉर्ड बदलता है: प्रतिपक्ष को कुछ दोबारा नहीं भेजा जाता और स्थिति वही रहती है। chain_details.originator नया वॉलेट बन जाता है, source: updated के साथ; timeline पिछला और नया वॉलेट दर्ज करती है; और ट्रांसफ़र का INTERNAL समकक्ष उसी तरह अपडेट होता है।

​

ब्लॉकचेन एनालिटिक्स एट्रिब्यूशन

1. ट्रांसफ़र पर एट्रिब्यूशन दर्ज करता है: beneficiary_data.counterparty_vasp_name भर दिया जाता है (जब आपने कोई नाम न दिया हो), और ट्रांसफ़र के metadata में एक vasp_attribution ब्लॉक होता है, जिसमें इकाई का नाम, इकाई का प्रकार, देश और source: "blockchain_analytics" होता है।
2. इकाई को VASP डायरेक्टरी में जोड़ता है (या मौजूदा प्रविष्टि से मिलाता है), ताकि एट्रिब्यूशन सभी ट्रांसफ़र पर स्थिर रहे।
3. जुड़े हुए नाम के साथ रेलों को एक बार फिर चलाता है: जिस directory प्रविष्टि में पहले से TRP endpoint हो, वह ट्रांसफ़र सीधे रूट हो जाता है और COUNTERPARTY_VASP_NOT_FOUND में नहीं जाता।

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "trv-2026-07-05-001",
    "transaction_category": "travelRule",
    "transaction_details": {
      "direction": "outbound",
      "action_type": "transfer",
      "amount": "0.25",
      "currency": "ETH",
      "currency_kind": "crypto"
    },
    "subject": {
      "entity_type": "individual",
      "vendor_data": "user-042",
      "full_name": "Jane Doe"
    },
    "travel_rule_details": {
      "status": "AWAITING_COUNTERPARTY",
      "originator_data": {
        "first_name": "Jane",
        "last_name": "Doe",
        "date_of_birth": "1990-04-12",
        "residence_country": "ES",
        "customer_identification": "user-042",
        "wallet_address": "0x135908330861442a814796ae99feac507925782a"
      },
      "beneficiary_data": {
        "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
        "name": "Ana Diaz",
        "counterparty_vasp_email": "compliance@bene-casp.example"
      }
    }
  }'

{
  "uuid": "22222222-3333-4444-5555-666666666666",
  "txn_id": "trv-2026-07-05-001",
  "transaction_type": "travelRule",
  "direction": "OUTBOUND",
  "status": "APPROVED",
  "amount": "0.25",
  "currency": "ETH",
  "currency_type": "crypto",
  "travel_rule": {
    "uuid": "33333333-4444-5555-6666-777777777777",
    "status": "AWAITING_COUNTERPARTY",
    "protocol": null,
    "required": true,
    "obligations_count": 0,
    "originator_data": {
      "first_name": "Jane",
      "last_name": "Doe",
      "date_of_birth": "1990-04-12",
      "residence_country": "ES",
      "customer_identification": "user-042",
      "wallet_address": "0x135908330861442a814796ae99feac507925782a"
    },
    "beneficiary_data": {
      "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
      "name": "Ana Diaz",
      "counterparty_vasp_email": "compliance@bene-casp.example",
      "chain": "ETH"
    },
    "metadata": {
      "compliance_email_source": "caller_supplied"
    }
  },
  "action_required": null
}

• originator_data वही है जो आपने भेजा, क्योंकि उदाहरण में दिए गए उपयोगकर्ता का कोई स्वीकृत KYC सत्यापन नहीं है; सत्यापित उपयोगकर्ता के लिए Didit इसे सत्यापित डेटा से बनाता है (देखें सत्यापित डेटा और उद्गम)। EMAIL rail प्राप्तकर्ता को केवल वही प्रेषक फ़ील्ड दिखाती है जो आप data_sharing_fields में साझा करते हैं।
• beneficiary_data.chain का मान ETH है, क्योंकि अनुरोध में कोई चेन नहीं दी गई थी, इसलिए Didit ने इसे मुद्रा से लिया।
• status का मान APPROVED है, क्योंकि किसी नियम ने लेन-देन पर कार्रवाई नहीं की; आपके अपने नियम कोई दूसरी स्थिति सेट कर सकते हैं।
• अनुपालन संपर्क को पिकअप लिंक मिलता है, और जब वे जवाब देते हैं तो ट्रांसफ़र पूरा होता है, नाम मिलान में विफल होता है, या अस्वीकार हो जाता है; अगर वे जवाब नहीं देते तो वह समाप्त हो जाता है (देखें ईमेल पिकअप)।

curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"payment_txn_id": "0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060"}'

curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"action": "resend"}'

​

ट्रांसफ़र क्यों अटका है

• reason स्थानांतरण का मशीन-पठनीय कारण है, और किसी अन्य स्थिति के लिए यह "" होता है।
• next_actions उन कार्रवाइयों की सूची है जो स्थानांतरण को आगे बढ़ाती हैं, और किसी अन्य स्थिति के लिए यह [] होता है।
• delivery वह सबसे नया संदेश है जो स्थानांतरण को दूसरी ओर भेजना बाकी है: kind, status (QUEUED, SENDING, RETRYING, DELIVERED, या FAILED), rail, attempts, last_error, next_attempt_at, और delivered_at। जब कोई संदेश भेजना बाकी न हो, तो यह null होता है।
• discovery वह जगह है जहाँ Didit ने प्रतिपक्ष को खोजा, और इसमें हर चलाए गए चरण के लिए एक प्रविष्टि होती है: step, outcome (match, miss, या skipped), reason, vasp, rail, और at।

{
  "uuid": "33333333-4444-5555-6666-777777777777",
  "status": "COUNTERPARTY_VASP_NOT_REACHABLE",
  "protocol": "EMAIL",
  "direction": "OUTBOUND",
  "rail": "EMAIL",
  "counterparty_vasp": null,
  "delivery": {
    "kind": "SEND",
    "status": "FAILED",
    "rail": "EMAIL",
    "attempts": 1,
    "last_error": "email undeliverable",
    "next_attempt_at": null,
    "delivered_at": null
  },
  "reason": "email_undeliverable",
  "next_actions": [
    { "action": "update_compliance_email" },
    { "action": "resend" }
  ]
}

curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"action": "update_compliance_email", "compliance_email": "desk@bene-casp.example"}'

curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"action": "resend"}'

​

घोषित स्व-होस्टेड वॉलेट

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "trv-2026-07-07-002",
    "transaction_category": "travelRule",
    "transaction_details": {
      "direction": "outbound",
      "action_type": "transfer",
      "amount": "0.25",
      "currency": "ETH",
      "currency_kind": "crypto"
    },
    "subject": {
      "entity_type": "individual",
      "vendor_data": "user-042",
      "full_name": "Jane Doe"
    },
    "counterparty": {
      "entity_type": "external",
      "full_name": "Jane Doe",
      "payment_method": {
        "method_type": "unhosted_wallet",
        "account_id": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9"
      }
    },
    "travel_rule_details": {
      "status": "AWAITING_COUNTERPARTY",
      "beneficiary_data": {
        "wallet_address": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9",
        "name": "Jane Doe"
      }
    }
  }'

• कोई रेल आज़माई नहीं जाती - आदान-प्रदान के लिए कोई प्रतिपक्ष VASP नहीं है - और स्थानांतरण सीधे UNCONFIRMED_OWNERSHIP में बनाया जाता है।
• जब auto_wallet_verification चालू हो (डिफ़ॉल्ट), तो Didit लेन-देन से जुड़ा एक वॉलेट-स्वामित्व विजेट सत्र अपने आप बनाता है और उसे लेन-देन के action_required ब्लॉक में लौटाता है। SDK क्लाइंट-साइड सबमिशन पर उसे अपने आप लॉन्च करते हैं।
• जब ग्राहक वॉलेट पर नियंत्रण साबित कर देता है, तो स्थानांतरण लाभार्थी के नाम का मिलान करता है और COMPLETED पर पहुँचता है (या विफल मिलान पर COUNTERPARTY_MISMATCHED_DATA पर)।

​

प्राप्त करना

​

स्वामित्व की पुष्टि करना

• कोई इनबाउंड ट्रांसफ़र एड्रेस बुक की ऐसी प्रविष्टि से मेल खाता है जिसका स्वामित्व अभी सत्यापित नहीं हुआ है।
• प्रतिपक्ष का वॉलेट स्व-होस्टेड घोषित किया गया था (counterparty.payment_method.method_type: "unhosted_wallet"), आउटबाउंड निकासी या इनबाउंड जमा पर। देखें घोषित स्व-होस्टेड वॉलेट।

curl -X POST https://verification.didit.me/v3/transactions/{transaction_uuid}/travel-rule/ownership/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"confirmed": true}'

• UNCONFIRMED_OWNERSHIP, किसी भी दिशा में।
• इनबाउंड ट्रांसफ़र पर ON_HOLD।
• इनबाउंड TRP ट्रांसफ़र पर UNCONFIRMED_OWNERSHIP, ON_HOLD या COUNTERPARTY_MISMATCHED_DATA, ताकि अनुपालन अधिकारी प्रतिपक्ष की इंक्वायरी को हाथ से हल कर सके।

• confirmed: true मिलान वाले वॉलेट पते की एड्रेस बुक प्रविष्टि को स्वामित्व सत्यापित के रूप में चिह्नित करता है, फिर उस प्रविष्टि के holder_name के विरुद्ध नाम मिलान चलाता है: पास होने पर COMPLETED, न होने पर COUNTERPARTY_MISMATCHED_DATA। INTERNAL रेल का समकक्ष, यदि हो, वही परिणाम पाता है। घोषित स्व-होस्टेड वॉलेट के लिए confirmed: true दर्ज करता है कि आपके ग्राहक ने प्रतिपक्ष के वॉलेट के नियंत्रक की पुष्टि की है, और ट्रांसफ़र पूरा होता है (COMPLETED), आउटबाउंड हो या इनबाउंड। जिस इनबाउंड ट्रांसफ़र की जमा राशि पहले ही निपट चुकी है, वह सीधे FINISHED पर चला जाता है।
• confirmed: false ट्रांसफ़र के दोनों पक्षों को COUNTERPARTY_VASP_GENERAL_DECLINE पर ले जाता है।
• मिलान वाली प्रविष्टि आपकी अपनी एड्रेस बुक में केवल वॉलेट पते से खोजी जाती है, चेन की जाँच के बिना। इनबाउंड ON_HOLD को बिना मिलान वाली प्रविष्टि के हल करने पर ट्रांसफ़र के beneficiary_data.wallet_address से प्रविष्टि बनती है और उसे सत्यापित चिह्नित किया जाता है। घोषित स्व-होस्टेड वॉलेट इसका अपवाद है: वह वॉलेट आपकी एड्रेस बुक में स्वामित्व-सत्यापित के रूप में दर्ज होता है, जैसा नीचे बताया गया है। अन्य हर स्थिति में प्रविष्टि न मिलने पर 409 लौटता है, जिसमें {"detail": "wallet address entry no longer available"} होता है। हटाई गई प्रविष्टि पर भी यही लौटता है।

• confirmed: true के लिए लौटाने हेतु एक भुगतान पता चाहिए, जो अनुरोध के wallet_address से, फिर मिलान वाली प्रविष्टि से, और फिर beneficiary_data.wallet_address से लिया जाता है। इन तीनों में से कुछ भी न होने पर अनुरोध 400 लौटाता है, जिसमें {"wallet_address": ["wallet_address is required to approve."]} होता है। Didit प्रविष्टि बनाता या सत्यापित करता है, प्रतिपक्ष को इंक्वायरी-समाधान कॉलबैक भेजता है, ownership_confirmed सेट करता है, और ट्रांसफ़र को COMPLETED पर ले जाता है।
• confirmed: false एक अस्वीकृत समाधान भेजता है और ट्रांसफ़र को COUNTERPARTY_VASP_GENERAL_DECLINE पर ले जाता है।
• यदि प्रतिपक्ष का कॉलबैक endpoint पहुँच में नहीं है, तो अनुरोध 502 लौटाता है और ट्रांसफ़र अपनी वर्तमान स्थिति पर रहता है। स्वीकृति की स्थिति में भी वॉलेट पते की एड्रेस बुक प्रविष्टि बनाई जाती है या उसे सत्यापित के रूप में चिह्नित किया जाता है।

{"confirmed": true, "wallet_address": "0xCounterpartyWallet01"}

• नेटवर्क ट्रांसफ़र, जिसका उत्तर उसके नेटवर्क पर पहले ही दिया जा चुका है (VerifyVASP ट्रांसफ़र, या पहले से तय GTR या Sygna Bridge ट्रांसफ़र), 409 लौटाता है (देखें नेटवर्क से ट्रांसफ़र)।

​

नेटवर्क से ट्रांसफ़र

• रूटिंग। संदेश आपके एप्लिकेशन तक तब पहुँचता है जब वह उस नेटवर्क पर आपकी अपनी जुड़ी सदस्यता का प्रतिभागी कोड बताता है। Didit की अपनी सदस्यता को संबोधित संदेश केवल तभी आप तक पहुँचता है जब आप ही एकमात्र लाइव Didit ग्राहक हों जिसने लाभार्थी वॉलेट पर नियंत्रण सिद्ध किया है। बाकी सब कुछ अस्वीकार होता है, ताकि कोई ग्राहक किसी दूसरे ग्राहक का ट्रांसफ़र कभी न पाए।
• निर्णय। Didit आपके एप्लिकेशन पर इनबाउंड ट्रांसफ़र बनाता है और उसे TRP इंक्वायरी की तरह तय करता है: वॉलेट मिलान, स्वामित्व, नाम मिलान और inbound_auto_accept।
• एक बार। नेटवर्क तब तक संदेश दोबारा भेजते हैं जब तक उसका उत्तर न मिले। दोहराया गया संदेश वही उत्तर पाता है जो पहली प्रति को मिला था, और कुछ भी दोबारा न बनाया जाता है और न तय किया जाता है।
• आपकी समीक्षा, GTR और SYGNA पर। जो ट्रांसफ़र आपका इंतज़ार करता है (UNCONFIRMED_OWNERSHIP, ON_HOLD या COUNTERPARTY_MISMATCHED_DATA), उसे POST .../travel-rule/ownership/ से तय किया जाता है: confirmed: true उसे स्वीकृत करता है (जब ट्रांसफ़र कोई वॉलेट न बताए तो wallet_address भेजें) और confirmed: false उसे अस्वीकार करता है। Didit प्रतिक्रिया के बाद नेटवर्क को उत्तर देता है, उन्हीं पुनः प्रयासों के साथ। जो ट्रांसफ़र पहले ही उत्तर पा चुका है, उस पर 409 लौटता है।
• VERIFYVASP पर बाद में कोई उत्तर नहीं। VerifyVASP अपना उत्तर तब लेता है जब वह पूछता है, इसलिए जो ट्रांसफ़र आपकी समीक्षा माँगता, उसे तुरंत अस्वीकार कर दिया जाता है और बाद में तय नहीं किया जा सकता (409)।

​

मास्क किया गया प्रतिपक्ष डेटा

{
  "data_masked": false,
  "data_unmasked": { "at": "2026-10-17T10:00:00Z", "reason": "wallet_proof", "actor": "" }
}

​

मिलान न होने पर प्रतिक्रिया

{
  "status": "COUNTERPARTY_MISMATCHED_DATA",
  "mismatched_fields": ["date_of_birth"],
  "data_match": {
    "matched": false,
    "mismatched_fields": ["date_of_birth"],
    "fields": {
      "name": { "result": "matched", "strictness": "DEFAULT" },
      "date_of_birth": { "result": "mismatched", "strictness": "STRICT" },
      "address": { "result": "not_compared", "strictness": "NONE" },
      "account": { "result": "matched", "strictness": "STRICT" }
    }
  }
}

​

नाम मिलान स्कोर

{
  "name_match": {
    "score": 90,
    "matched": false,
    "method": "sequence_ratio",
    "strictness": "FUZZY",
    "compared_with": "wallet_holder",
    "transfer_name": "Ana Diaz",
    "compared_name": "Ana Diaz Garcia",
    "matched_names": ["Ana", "Diaz"],
    "mismatched_names": ["Garcia"]
  }
}

• score दोनों पूरे नामों की समानता है, 0 से 100 तक, और कोई एक नाम खाली हो तो 0। matched परिणाम strictness पर आधारित है, इसलिए दोनों अलग हो सकते हैं: FUZZY अपने समानता अनुपात 0.85 पर स्वयं निर्णय लेता है।
• matched_names ट्रांसफ़र के नाम के वे शब्द हैं जो दूसरे नाम में मिलते हैं; mismatched_names वे शब्द हैं जो किसी एक पक्ष के पास हैं पर दूसरे के पास नहीं।
• method के मान हैं none, exact_token, token_subset, token_containment या sequence_ratio, जो क्रमशः NONE, STRICT, DEFAULT, CONTAINS और FUZZY से मेल खाते हैं।
• compared_with का मान wallet_holder (वॉलेट के लिए दर्ज धारक) या counterparty_vasp (ईमेल प्रतिक्रिया पेज पर प्रतिपक्ष ने जो नाम दिया, या Didit Test VASP का उत्तर) होता है।
• ट्रांसफ़र का परिणाम data_match के अनुसार तय होता है, जो हर फ़ील्ड की तुलना करता है, इसलिए कोई ट्रांसफ़र COUNTERPARTY_MISMATCHED_DATA हो सकता है जबकि name_match.matched true हो।
• name_match उस ट्रांसफ़र ऑब्जेक्ट पर होता है जिसे Travel Rule endpoints लौटाते हैं, और ट्रांज़ैक्शन के एम्बेडेड travel_rule पर भी होता है। जब तक कोई नाम तुलना में न आया हो, यह null रहता है। ट्रांसफ़र सूची और webhooks इसे नहीं रखते।
• जब तक पक्ष मास्क किए गए हों तो, और INTERNAL विनिमय के दूसरे ग्राहक की प्रति में, नाम छिपे रहते हैं।

​

संदेश और दस्तावेज़ अनुरोध

curl -X POST https://verification.didit.me/v3/transactions/{transaction_uuid}/travel-rule/messages/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"kind": "DOCUMENT_REQUEST", "body": "Please confirm the beneficiary date of birth.", "requested_documents": ["Proof of address"]}'

• kind का मान MESSAGE (डिफ़ॉल्ट) या DOCUMENT_REQUEST होता है। दस्तावेज़ अनुरोध के लिए requested_documents में कम से कम एक प्रविष्टि चाहिए (अधिकतम 10); संदेश के लिए body (5000 अक्षर तक) या कोई फ़ाइल चाहिए।
• reply_to उसी ट्रांसफ़र के किसी पिछले संदेश का नाम है। दूसरी ओर से आया ऐसा उत्तर जिसमें दस्तावेज़ हो, उस दस्तावेज़ अनुरोध को पूरा करता है जिसका वह उत्तर है, और उस पर fulfilled_at सेट हो जाता है। आपका अपना उत्तर आपके अपने अनुरोध को कभी पूरा नहीं करता।
• files के साथ multipart भेजें, ताकि प्रति फ़ाइल 10 MB तक की 5 फ़ाइलें जुड़ सकें, PDF, PNG, JPEG या WebP में। Didit हर फ़ाइल की सामग्री जाँचता है, केवल घोषित प्रकार नहीं, और किसी अन्य फ़ाइल के लिए files पर 400 उत्तर मिलता है (“Attach PDF, PNG, JPEG or WebP files only.”)।
• एक ट्रांसफ़र में अधिकतम 100 संदेश हो सकते हैं, जिनमें से अधिकतम 20 में अटैचमेंट हो सकते हैं (हर एक में अधिकतम 5 फ़ाइलें), दोनों पक्षों को मिलाकर गिनती होती है। इनमें से किसी भी सीमा से आगे अनुरोध 400 लौटाता है। संदेश के अटैचमेंट लेन-देन के अपने दस्तावेज़ों में नहीं गिने जाते।
• संदेश INTERNAL और EMAIL चैनल पर काम करते हैं। INTERNAL पर, दूसरा Didit ग्राहक संदेश अपनी ओर के युग्म में देखता है। EMAIL पर, प्रतिपक्ष को ईमेल जाता है और वह पिकअप पोर्टल पर उत्तर देता है। अगर वह सूचना ईमेल नहीं भेजा जा सका, तब भी संदेश सहेज लिया जाता है और अनुरोध 201 लौटाता है।
• अनुरोध 409 लौटाता है, जिसमें detail में कारण होता है, इन स्थितियों में: TRP, GTR, TRUST, VerifyVASP या Sygna पर ट्रांसफ़र (ये प्रोटोकॉल संदेश नहीं रखते); ऐसा ट्रांसफ़र जिसका अभी तक कोई प्रतिपक्ष नहीं है; INTERNAL ट्रांसफ़र जिसका डेटा वॉलेट धारक से मेल नहीं खाया (प्राप्तकर्ता तक कुछ नहीं पहुँचा); INTERNAL ट्रांसफ़र जिसके प्राप्तकर्ता ने अभी तक वॉलेट पर नियंत्रण सिद्ध नहीं किया है (दोनों ओर से, जब तक वह न करे); EMAIL ट्रांसफ़र जिसके प्रतिपक्ष के पास अब अनुपालन ईमेल पता नहीं है; और EMAIL ट्रांसफ़र जिसका पिकअप लिंक समाप्त हो गया है या जिसका ट्रांसफ़र बंद है।
• प्रतिपक्ष के जवाब देने पर कोई webhook ट्रिगर नहीं होता। संदेश endpoint पढ़ें।
• प्रतिपक्ष को नए संदेश की सूचना देने वाला ईमेल अंग्रेज़ी में भेजा जाता है।

​

वॉलेट पता पुस्तिका

curl -X POST https://verification.didit.me/v3/travel-rule/wallet-addresses/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
    "chain": "ETH",
    "holder_name": "Ana Diaz",
    "holder_vendor_data": "user-042",
    "self_declared": true
  }'

​

बड़ी संख्या में वॉलेट इंपोर्ट करना

curl -X POST https://verification.didit.me/v3/travel-rule/wallet-addresses/import/ \
  -H "x-api-key: YOUR_API_KEY" \
  -F "file=@wallets.csv;type=text/csv"

address,address_hash,chain,memo,holder_name,holder_vendor_data
0xBeneficiaryWallet01,,ethereum,,Ana Diaz,user-042
,4f7d2e1c9b8a7f6e5d4c3b2a1f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e,bitcoin,,,user-043
rExchangeSharedAddress01,,XRP,104729,Ana Diaz,user-042

​

पहुँच से बाहर प्रतिपक्षों के लिए ईमेल पिकअप

• सही पतों पर। आपके द्वारा पास किया गया counterparty_vasp_email ही एकमात्र प्राप्तकर्ता है। अन्यथा Didit अधिकतम तीन पतों पर लिखता है: प्रतिपक्ष के संपर्क जो बाउंस नहीं हुए (पहले आपके अपने, फिर प्लेटफ़ॉर्म के संपर्क, और जो पहले जवाब दे चुके थे वे पहले), फिर डायरेक्टरी एंट्री का अनुपालन ईमेल, यदि कोई स्लॉट खाली बचा हो। हर पते को उसका अलग ईमेल मिलता है।
• आपके नाम से। ईमेल Didit के पते से “आपका कानूनी नाम via Didit” के रूप में आता है, प्रतिपक्ष के अधिकार क्षेत्र की भाषा में (कोई भी भाषा ज्ञात न होने पर अंग्रेज़ी में), और लिंक उसी भाषा में जवाब पेज खोलता है। आपको उसकी कोई प्रति नहीं मिलती: ट्रांसफ़र की टाइमलाइन देखें।
• रिमाइंडर के साथ। जब तक प्रतिपक्ष जवाब नहीं देता, Didit समय-सीमा से 72, 24 और 6 घंटे पहले रिमाइंडर भेजता है, अनुरोध या पिछले रिमाइंडर के कम से कम 12 घंटे बाद, और समय-सीमा के बाद कभी नहीं।
• बाउंस संभालने के साथ। बाउंस या स्पैम शिकायत उस संपर्क को, जिस तक वह पहुँची, कारण सहित अमान्य चिह्नित करती है, और ट्रांसफ़र की टाइमलाइन इसे दर्ज करती है। प्लेटफ़ॉर्म संपर्क तब हर Didit ग्राहक के लिए अमान्य होता है; आपके एप्लिकेशन का अपना संपर्क केवल आपके एप्लिकेशन के लिए। जब Didit की ईमेल डिलीवरी किसी पते पर बिल्कुल भेजना बंद कर देती है (स्थायी बाउंस, स्पैम शिकायत या सदस्यता रद्द करने के बाद), तो उस पते के हर संपर्क को अमान्य (suppressed) चिह्नित किया जाता है, और जैसे ही उस पते पर भेजना फिर शुरू होता है, वे संपर्क फिर मान्य हो जाते हैं। जब लिखने के लिए कोई पता न बचे, तो ट्रांसफ़र COUNTERPARTY_VASP_NOT_REACHABLE हो जाता है और उसकी टाइमलाइन में प्राप्त करने वाले मेल सर्वर का कारण दर्ज होता है। आपके पास दिए गए counterparty_vasp_email पर स्थायी बाउंस या स्पैम शिकायत यही परिणाम तुरंत देती है, क्योंकि वही एकमात्र प्राप्तकर्ता है; उस पर अस्थायी बाउंस (soft_bounce), या डायरेक्टरी एंट्री के अपने अनुपालन ईमेल पर, अनुरोध को रिमाइंडर के लिए खुला रखता है।

curl https://verification.didit.me/v3/travel-rule/pickup/{token}/

{
  "reference": "33333333-4444-5555-6666-777777777777",
  "requested_at": "2026-07-05T10:00:00Z",
  "originator_vasp_name": "Origin CASP SL",
  "originator_vasp_lei": "529900EXAMPLEORIG001",
  "recipient_vasp_name": "Example Counterparty VASP",
  "language": "es",
  "amount": "0.250000000000000000",
  "currency": "ETH",
  "fiat_amount": "",
  "fiat_currency": "",
  "chain": "ETH",
  "beneficiary_wallet": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
  "status": "AWAITING_COUNTERPARTY",
  "ivms_version": "ivms101.2023",
  "deadline_at": "2026-07-07T10:00:00Z",
  "reminders_sent": 0,
  "contact": "",
  "decline_reasons": ["data_mismatch", "not_our_customer", "wallet_not_hosted", "sanctions", "risk_appetite", "jurisdiction", "insufficient_data", "other"],
  "join_invitation": { "eligible": false, "url": "" },
  "originator_data": { "name": "Jane Doe", "wallet_address": "0x77ccff0cc624a53cd8b8d8703ced826710211ec7" },
  "beneficiary_data": { "name": "Ana Diaz", "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb" },
  "ivms_request": {
    "originator": {
      "originatorPersons": [{ "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Doe", "secondaryIdentifier": "Jane", "nameIdentifierType": "LEGL" }] } } }],
      "accountNumber": ["0x77ccff0cc624a53cd8b8d8703ced826710211ec7"]
    },
    "beneficiary": {
      "beneficiaryPersons": [{ "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Diaz", "secondaryIdentifier": "Ana", "nameIdentifierType": "LEGL" }] } } }],
      "accountNumber": ["0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb"]
    }
  },
  "data_masked": false
}

curl -X POST https://verification.didit.me/v3/travel-rule/pickup/{token}/respond/ \
  -H "Content-Type: application/json" \
  -d '{"decision": "accept", "beneficiary_name": "Ana Diaz"}'

​

बिना मिलान वाले डिपॉज़िट

curl "https://verification.didit.me/v3/travel-rule/unmatched/" \
  -H "x-api-key: YOUR_API_KEY"

curl -X POST "https://verification.didit.me/v3/travel-rule/unmatched/{transaction_uuid}/match/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"transaction_id": "<uuid of the received message transaction>"}'

​

डिपॉज़िट के बाद सनराइज़ पंजीकरण

curl -X POST https://verification.didit.me/v3/travel-rule/inbound/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "chain": "eth",
    "txid": "0xf103cfc37f6d390b61827987b9dc631b5e1d2bfeb008a780c1e38047ae5d557b",
    "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
    "amount": "500.00",
    "currency": "USDC",
    "originator_data": { "name": "Carlos Ruiz", "wallet_address": "0x77ccff0cc624a53cd8b8d8703ced826710211ec7" },
    "beneficiary_data": { "name": "Ana Diaz" },
    "originating_vasp": {
      "name": "Northwind Digital Assets Ltd",
      "lei": "5493001KJTIIGC8Y1R12",
      "travel_address": "tareGfwAzkySLkFzcqr7AKno3K4VsT3jayMwPvj3ovbFZHzpayHLmgCrAMoLqjfCYRPpvLqr9dSr2VVTFAncwChcMjL4AheNuHCJM8NRcUg"
    }
  }'

• कोई मेल खाती प्रविष्टि नहीं -> ON_HOLD। इसे POST .../travel-rule/ownership/ से हल करें: confirmed: true वॉलेट को सत्यापित के रूप में आपकी पता बुक में जोड़ता है और नाम मिलान चलाता है; मिलान होने पर ट्रांसफ़र COMPLETED में जाता है, फिर FINISHED में।
• प्रविष्टि मौजूद है, लेकिन स्वामित्व सिद्ध नहीं है -> UNCONFIRMED_OWNERSHIP।
• लाभार्थी का नाम प्रविष्टि के holder_name से मेल नहीं खाता -> COUNTERPARTY_MISMATCHED_DATA।
• सत्यापित प्रविष्टि है और नाम मेल खाता है -> COMPLETED, फिर तुरंत FINISHED (जमा पहले ही सेटल हो चुका है)।

{
  "transaction_id": "44444444-5555-6666-7777-888888888888",
  "txn_id": "tr-in-0xf103cfc37f6d390b61827987b9dc631b5e1d2bfeb008a780c1e38047ae5d557b-6151d81b366e",
  "created": true,
  "travel_rule": {
    "uuid": "55555555-6666-7777-8888-999999999999",
    "status": "FINISHED",
    "direction": "INBOUND",
    "rail": null,
    "protocol": null,
    "ivms_version": "ivms101.2023",
    "required": true,
    "ownership_confirmed": true,
    "deadline_at": null,
    "timeline": [
      { "status": "COMPLETED", "at": "2026-07-06T10:15:02.114208+00:00", "detail": "matched verified wallet address book entry" },
      { "status": "FINISHED", "at": "2026-07-06T10:15:02.131544+00:00", "detail": "on-chain deposit already settled" }
    ],
    "counterparty_vasp": null,
    "originator_data": { "name": "Carlos Ruiz", "wallet_address": "0x77ccff0cc624a53cd8b8d8703ced826710211ec7" },
    "beneficiary_data": { "name": "Ana Diaz", "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb", "chain": "eth" },
    "created_at": "2026-07-06T10:15:02.087412Z"
  }
}

​

वॉलेट स्वामित्व विजेट

​

डायरेक्टरी

curl "https://verification.didit.me/v3/travel-rule/vasps/?search=counterparty" \
  -H "x-api-key: YOUR_API_KEY"

{
  "count": 1,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": "0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91",
      "kind": "directory",
      "name": "Example Counterparty VASP",
      "lei": "529900EXAMPLECPTY001",
      "jurisdiction": "DE",
      "domains": ["counterparty.example"],
      "reachable": true,
      "aliases": [{ "name": "Example Counterparty", "kind": "trading_name" }],
      "networks": [
        {
          "network": "GTR",
          "code": "EXAMPLE01",
          "listed_name": "Example Counterparty VASP",
          "country": "DE",
          "verified_at": "2026-10-12T09:30:00Z",
          "last_seen_at": "2026-10-12T09:30:00Z",
          "source": "staff"
        }
      ],
      "routes": [
        { "rail": "GTR", "status": "unavailable", "reason": "no_membership", "via": "" },
        { "rail": "EMAIL", "status": "available", "reason": "", "via": "contact" }
      ],
      "umbrella": null,
      "entities": [],
      "contacts": [
        {
          "id": "6c1f9b8e-2d4a-4f7e-8b3c-5a9d0e1f2a3b",
          "email": "travelrule@counterparty.example",
          "name": "Travel Rule desk",
          "source": "staff",
          "scope": "platform",
          "verified_at": null
        }
      ],
      "dd_status": "NOT_STARTED",
      "dd_score": 62,
      "dd_score_breakdown": {
        "jurisdiction": { "points": 25.0, "max": 25, "reason": "jurisdiction_not_high_risk", "detail": "DEU is not on the high-risk jurisdiction list" },
        "verification": { "points": 3.8, "max": 15, "reason": "dd_status_not_started", "detail": "due diligence status NOT_STARTED" },
        "protocol": { "points": 6.0, "max": 15, "reason": "email_only", "detail": "reachable over the email fallback only" },
        "lei": { "points": 10.0, "max": 10, "reason": "lei_valid", "detail": "valid LEI on record" },
        "history": { "points": 5.0, "max": 10, "reason": "no_history", "detail": "no exchange history" },
        "essentials": { "points": 7.5, "max": 15, "reason": "no_essential_checks", "detail": "no decided essential check yet" },
        "responsiveness": { "points": 5.0, "max": 10, "reason": "responsiveness_unknown", "detail": "0 decided recent requests, too few to judge" }
      },
      "dd_assessed_at": "2026-10-12T09:30:00Z",
      "dd_score_semantic": "higher_is_safer",
      "risk_level": "MEDIUM",
      "responsiveness": { "status": "UNKNOWN", "answered": 0, "total": 0, "computed_at": "2026-10-12T09:30:00Z" },
      "essential_checks": {},
      "reachable_rails": ["GTR", "EMAIL"],
      "is_didit_customer": false,
      "decision": {
        "decision": "APPROVED",
        "reason": "Licensed in DE",
        "decided_by": "",
        "updated_at": "2026-10-14T10:05:00Z",
        "inherited_from": null
      },
      "entity_screening": {
        "id": "7a1d2c3b-4e5f-4a6b-8c7d-9e0f1a2b3c4d",
        "status": "Approved",
        "total_hits": 0,
        "score": null,
        "screened_at": "2026-10-14T09:58:00Z",
        "fresh": true,
        "flagged": false
      },
      "questionnaires": []
    }
  ]
}

​

रूट

• TRP जब प्रविष्टि में एक TRP endpoint हो जिसे डायरेक्टरी ने सत्यापित किया हो।
• GTR, TRUST, VERIFYVASP, SYGNA जब कोई नेटवर्क VASP को किसी कोड के तहत सूचीबद्ध करे। रूट केवल तब available है जब आपका एप्लिकेशन आज उस नेटवर्क पर भेज सकता हो (via: own_membership आपकी अपनी जुड़ी हुई सदस्यता के लिए, via: didit_membership Didit की सदस्यता के लिए)। अन्यथा वह reason: no_membership या reason: network_switched_off के साथ unavailable होता है, और उसे VASP तक पहुँचने के तरीके के रूप में कभी नहीं दिखाया जाता। Didit की अपनी नेटवर्क सदस्यताएँ अभी लाइव नहीं हैं, इसलिए आज नेटवर्क रूट केवल उस सदस्यता के ज़रिए उपलब्ध है जिसे आपने Marketplace में जोड़ा है।
• EMAIL जब प्रविष्टि के लिए कोई अनुपालन संपर्क हो।
• INTERNAL किसी Didit नेटवर्क सदस्य के लिए।

​

ब्रांड और उनकी इकाइयाँ

​

संपर्क

curl -X POST https://verification.didit.me/v3/travel-rule/counterparty-contacts/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"counterparty": "0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91", "email": "compliance@counterparty.example", "name": "Compliance desk"}'

• GET /v3/travel-rule/counterparty-contacts/ वे सभी संपर्क सूचीबद्ध करता है जिन पर आपका एप्लिकेशन भेज सकता है, जिनमें प्लेटफ़ॉर्म संपर्क और बाउंस हो चुके संपर्क भी शामिल हैं। परिणाम सबसे नए पहले आते हैं और limit और offset से पेजिनेट होते हैं। ?counterparty= और एक डायरेक्टरी प्रविष्टि के id से फ़िल्टर करें। जो मान UUID नहीं है, उस पर 400 आता है।
• POST एक निजी संपर्क जोड़ता है (counterparty, email, वैकल्पिक name) और 201 लौटाता है। ऐसा पता जोड़ना जो उस प्रविष्टि के लिए आपके अपने संपर्कों में पहले से है, वही संपर्क लौटाता है। अज्ञात प्रविष्टि पर 400 आता है ("No directory entry with this id.")।
• DELETE /v3/travel-rule/counterparty-contacts/{contact_uuid}/ आपका अपना एक संपर्क हटाता है (204)। प्लेटफ़ॉर्म संपर्क हटाए नहीं जा सकते, और उन पर 404 आता है।

​

डायरेक्टरी में प्रविष्टियाँ कैसे आती हैं

• ESMA का अंतरिम MiCA रजिस्टर, क्रिप्टो-एसेट सेवा प्रदाताओं का, जिसे हर सप्ताह पढ़ा जाता है: हर प्रदाता का नाम, LEI और गृह सदस्य राज्य।
• सार्वजनिक TRISA डायरेक्टरी, जिसे हर सप्ताह पढ़ा जाता है: हर सदस्य कौन है, उसका देश और उसकी TRISA लिस्टिंग। जो लिस्टिंग तीन सप्ताह तक डायरेक्टरी में नहीं दिखती, उसे हटा दिया जाता है।
• वैश्विक LEI रजिस्टर किसी प्रविष्टि का LEI, अन्य कानूनी नाम और देश भरता है, और अपने देश में सटीक कानूनी नाम से किसी प्रविष्टि का LEI खोजता है।
• ब्लॉकचेन एनालिटिक्स एट्रिब्यूशन किसी गंतव्य वॉलेट के मालिक VASP को जोड़ता है या उससे मिलाता है, और एट्रिब्यूट किया गया नाम उपनाम के रूप में रखता है।
• Didit स्टाफ़ प्रविष्टियों को क्यूरेट करता है: सत्यापित रूटिंग पहचानकर्ता और नेटवर्क लिस्टिंग, अनुपालन संपर्क, उपनाम, ब्रांड और उनकी इकाइयाँ, मर्ज की गई डुप्लीकेट प्रविष्टियाँ और छिपी हुई प्रविष्टियाँ।

​

Didit नेटवर्क

• आपका एप्लिकेशन लाइव है (सैंडबॉक्स नहीं) और Travel Rule चालू है;
• is_discoverable true है और legal_name सेट है;
• compliance_email सेट है और उसकी पुष्टि हो चुकी है: पुष्टि POST /v3/travel-rule/settings/compliance-email/confirmation/ से भेजें और ईमेल में आया लिंक खोलें। पता बदलने पर नई पुष्टि करनी होगी;
• Didit ने एप्लिकेशन को टेस्ट, डेमो या आंतरिक के रूप में चिह्नित नहीं किया है।

​

रूटिंग पहचानकर्ता

​

प्रतिपक्ष ड्यू डिलिजेंस

• साझा मूल्यांकन। हर डायरेक्टरी प्रविष्टि के साथ एक ड्यू-डिलिजेंस स्कोर, उसका जोखिम स्तर, प्रतिक्रियाशीलता की स्थिति और एक आवश्यक जाँच रिपोर्ट आती है। Didit इन्हें प्लेटफ़ॉर्म के अपने डेटा से गणना करता है, इसलिए हर ग्राहक को एक ही मान दिखते हैं।
• आपके अपने रिकॉर्ड। उस VASP पर आपका निर्णय, उसकी प्रतिबंध स्क्रीनिंग और प्रतिकूल मीडिया स्क्रीनिंग, और उसके साथ आदान-प्रदान की गई ड्यू-डिलिजेंस प्रश्नावलियाँ केवल आपके एप्लिकेशन से संबंधित हैं। कोई दूसरा ग्राहक इन्हें नहीं देखता, और ये साझा प्रविष्टि को कभी नहीं बदलते।

​

स्कोर और जोखिम स्तर

​

आवश्यक जाँचें

​

प्रतिक्रियाशीलता

{ "status": "UNRESPONSIVE", "answered": 0, "total": 6, "computed_at": "2026-10-12T09:30:00Z" }

• गिने जाते हैं: नेटवर्क या प्रोटोकॉल रेल से भेजे गए अनुरोध, और साझा पते पर ईमेल किए गए अनुरोध, जो प्रविष्टि का अनुपालन पता या कोई प्लेटफ़ॉर्म संपर्क होता है।
• कभी नहीं गिने जाते: वह अनुरोध जो किसी एक ग्राहक द्वारा टाइप किए गए पते पर, या किसी ग्राहक के निजी संपर्क पर ईमेल किया गया हो। वह आदान-प्रदान ग्राहक के अपने ट्रांसफ़र इतिहास में रहता है और दूसरे सभी के लिए VASP पर कोई लेबल नहीं लगाता।
• जवाब दिया गया: COMPLETED, FINISHED, COUNTERPARTY_VASP_GENERAL_DECLINE या COUNTERPARTY_MISMATCHED_DATA। अस्वीकृति या असंगति भी एक जवाब है: VASP ने भाग लिया।
• जवाब नहीं दिया गया: EXPIRED।
• इनमें से कुछ नहीं: बाकी हर स्थिति। CANCELLED अनुरोध प्रेषक का अपना कार्य है, COUNTERPARTY_VASP_NOT_REACHABLE प्रेषक की ओर की विफलता हो सकती है, और जो अनुरोध अभी प्रगति में है, उस पर अभी निर्णय नहीं हुआ है।

​

प्रतिपक्ष पर आपका निर्णय

curl -X PUT https://verification.didit.me/v3/travel-rule/vasps/0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91/decision/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"decision": "BLOCKED", "reason": "Unlicensed in its home jurisdiction"}'

{
  "decision": {
    "decision": "BLOCKED",
    "reason": "Unlicensed in its home jurisdiction",
    "decided_by": "",
    "updated_at": "2026-10-14T10:05:00Z",
    "inherited_from": null
  }
}

• यह निर्णय केवल आपके एप्लिकेशन के लिए निजी है: कोई दूसरा ग्राहक इसे नहीं देखता, और यह साझा प्रविष्टि को कभी नहीं बदलता।
• निर्णय अपने आप कुछ नहीं बदलता और कभी भी ट्रांसफ़र के रूटिंग के तरीके को नहीं बदलता। यह counterparty_dd_status नियम फ़ील्ड के ज़रिए आपके लेन-देन तक पहुँचता है: प्रीसेट इंस्टॉल करें, या इस पर अपना नियम लिखें।
• किसी ब्रांड पर लिया गया निर्णय उसकी हर इकाई पर लागू होता है जिसका अपना कोई निर्णय नहीं है, और इकाई inherited_from में ब्रांड दिखाती है। इकाई पर लिया गया निर्णय उस इकाई के लिए ब्रांड के निर्णय को ओवरराइड करता है।
• GET वह निर्णय लौटाता है जो लागू होता है, या {"decision": null}। DELETE आपका अपना निर्णय हटा देता है और बाद में जो लागू होता है वह लौटाता है: किसी इकाई के लिए ब्रांड का निर्णय, अन्यथा null। यदि आपके एप्लिकेशन का प्रतिपक्ष पर अपना कोई निर्णय नहीं है, तो यह 404 देता है।
• reason वैकल्पिक है, 255 अक्षरों तक, और हर PUT इसे बदल देता है। decided_by वह कंसोल उपयोगकर्ता है जिसने निर्णय लिया या अंतिम बार बदला, और किसी API कुंजी द्वारा किए जाने पर यह खाली रहता है।

​

प्रतिपक्ष स्क्रीनिंग

curl -X POST https://verification.didit.me/v3/travel-rule/vasps/0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91/screening/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"refresh": false}'

{
  "outcome": "screened",
  "screening": {
    "id": "7a1d2c3b-4e5f-4a6b-8c7d-9e0f1a2b3c4d",
    "status": "In Review",
    "total_hits": 2,
    "score": 85.0,
    "screened_at": "2026-10-14T09:58:00Z",
    "fresh": true,
    "flagged": true
  }
}

• बिलिंग। हर नई स्क्रीनिंग पर आपके संगठन की कंपनी AML स्क्रीनिंग की कीमत लगती है। GET /v3/travel-rule/vasps/{vasp_id}/screening/ बिना किसी शुल्क के वह price, fresh_days और यह कि स्क्रीनिंग enabled है या नहीं, लौटाता है। 30 दिन से कम पुरानी स्क्रीनिंग ताज़ा है: POST उसे 200 और outcome: reused के साथ फिर से लौटाता है और कोई बिलिंग नहीं करता, जब तक आप refresh: true न भेजें। नई स्क्रीनिंग 201 और outcome: screened के साथ उत्तर देती है। सैंडबॉक्स एप्लिकेशन की कभी स्क्रीनिंग या बिलिंग नहीं होती।
• स्वचालित स्क्रीनिंग। स्क्रीनिंग चालू होने पर, Didit आउटबाउंड एक्सचेंज शुरू होने पर उस प्रतिपक्ष को भी स्क्रीन करता है जिस तक एक्सचेंज पहुँचता है, आपके नियमों द्वारा लेन-देन का मूल्यांकन करने से पहले, उसी पुनः उपयोग और बिलिंग के नियम के साथ। वहाँ कोई इनकार या विफलता कभी ट्रांसफ़र को विफल नहीं करती।
• परिणाम। status Approved होता है जब कोई संभावित मिलान ध्यान देने योग्य न हो, और संभावित प्रतिबंध या प्रतिकूल-मीडिया मिलान के लिए In Review या Declined। flagged true रहता है जब ताज़ा स्क्रीनिंग In Review या Declined हो।
• प्रभाव। जब तक आपकी प्रतिपक्ष की नवीनतम स्क्रीनिंग फ़्लैग्ड है और स्क्रीनिंग चालू है, आपके नियमों में counterparty_risk_level HIGH होता है, इसलिए travel-rule-counterparty-high-risk प्रीसेट, एक बार इंस्टॉल होने पर, उसके ट्रांसफ़र रोक देता है। डायरेक्टरी में साझा risk_level नहीं बदलता।
• गोपनीयता। स्क्रीनिंग केवल आपके एप्लिकेशन के लिए निजी है: कोई दूसरा ग्राहक इसे नहीं देखता, और यह साझा प्रविष्टि को कभी नहीं बदलती। डायरेक्टरी आपकी नवीनतम स्क्रीनिंग को entity_screening के रूप में दिखाती है।
• अस्वीकृतियाँ। स्क्रीनिंग बंद होने पर, सैंडबॉक्स एप्लिकेशन के लिए, या जब उसी प्रतिपक्ष की कोई स्क्रीनिंग पहले से चल रही हो, तो 409। जब आपका बैलेंस कीमत को कवर नहीं कर सकता, तो code: insufficient_credits के साथ 403। जब स्क्रीनिंग पूरी न हो सके तो 502। इनमें से कोई भी बिलिंग नहीं करता।

​

ड्यू-डिलिजेंस प्रश्नावली

curl -X POST https://verification.didit.me/v3/travel-rule/vasps/0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91/questionnaires/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"sent_to": "travelrule@counterparty.example"}'

{
  "id": "3f9e8d7c-6b5a-4c3d-9e2f-1a0b9c8d7e6f",
  "status": "SENT",
  "form_version": "1",
  "sent_to": "travelrule@counterparty.example",
  "sent_at": "2026-10-14T10:00:00Z",
  "expires_at": "2026-11-13T10:00:00Z",
  "answered_at": null,
  "valid_until": null,
  "current": false,
  "answers": {}
}

• कहाँ जाती है। sent_to रिकॉर्ड पर दर्ज एक अनुपालन पता होना चाहिए: डायरेक्टरी प्रविष्टि के लिए, उसका अनुपालन पता या contacts में आपके एप्लिकेशन को दिखने वाला कोई संपर्क; Didit नेटवर्क सदस्य के लिए, उसका पुष्ट अनुपालन ईमेल। इसे छोड़ देने पर वही पता उपयोग होता है जहाँ प्रतिपक्ष को जाने वाला Travel Rule ईमेल जाता है: पहले आपका अपना संपर्क, फिर एक प्लेटफ़ॉर्म संपर्क, फिर प्रविष्टि का अनुपालन पता। Didit प्रश्नावली कहीं और नहीं भेजता, और जब प्रतिपक्ष का रिकॉर्ड पर कोई अनुपालन पता न हो, तो 400 देता है।
• उत्तर देना। लिंक /v3/travel-rule/questionnaires/{token}/ खोलता है, जो प्रतिपक्ष के किसी व्यक्ति के लिए एक पेज है और जिसे किसी खाते या API कुंजी की ज़रूरत नहीं। वे हर प्रश्न का उत्तर देते हैं, प्रत्येक 2,000 अक्षरों तक (जहाँ लागू न हो वहाँ N/A), और एक बार सबमिट करते हैं। प्रतिपक्ष उसी लिंक पर {"answers": {"<question id>": "<answer>"}} भी पोस्ट कर सकता है। जो लिंक उपयोग हो चुका है, बदला जा चुका है, या अपनी समय-सीमा पार कर चुका है, वह इसके बजाय एक समाप्ति पेज दिखाता है। ईमेल और पेज अनुवादित होते हैं; प्रश्न हमेशा अंग्रेज़ी में रहते हैं, ताकि उनका अर्थ भाषाओं के बीच कभी न बदले।
• समय-सीमाएँ। प्रतिपक्ष के पास उत्तर देने के लिए 30 दिन हैं (expires_at)। उत्तर 365 दिनों तक ताज़ा रहते हैं (valid_until), और तब तक current true रहता है। समय-सीमा पार कर चुकी बिना उत्तर वाली प्रश्नावली, और वैधता पार कर चुके उत्तर, EXPIRED हो जाते हैं।
• प्रति प्रतिपक्ष एक खुली प्रश्नावली। नई भेजे जाने पर वह उसी प्रतिपक्ष को भेजी गई आपकी पिछली बिना उत्तर वाली प्रश्नावली को बदल देती है: वह EXPIRED हो जाती है और उसका लिंक काम करना बंद कर देता है। किसी पते पर प्रति मिनट एक ईमेल जा सकता है; इससे तेज़ भेजने पर 429 मिलता है।
• उत्तर पढ़ना। GET /v3/travel-rule/vasps/{vasp_id}/questionnaires/ प्रतिपक्ष से जुड़ी आपकी प्रश्नावलियाँ सबसे नई पहले सूचीबद्ध करता है, और उत्तर दिए जाने के बाद answers प्रश्न id द्वारा कुंजीबद्ध होते हैं। डायरेक्टरी इन्हें questionnaires के रूप में दिखाती है। ये केवल आपके एप्लिकेशन के लिए निजी हैं।

​

एक प्रतिपक्ष वाले स्थानांतरण

​

सनराइज़ और गैर-प्रतिक्रियाशील नीतियाँ

curl -X PUT https://verification.didit.me/v3/travel-rule/settings/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"sunrise_policy": "PROCEED", "non_responsive_policy": "HOLD"}'

1. sunrise_policy, जब वह सेट हो और प्रतिपक्ष का अधिकार-क्षेत्र sunrise_jurisdictions में हो।
2. non_responsive_policy, जब वह सेट हो और प्रतिपक्ष UNRESPONSIVE हो।
3. बाकी सभी स्थितियों में timeout_outcome, जिनमें Didit नेटवर्क सदस्य के साथ का स्थानांतरण या ऐसे प्रतिपक्ष का स्थानांतरण शामिल है जिसकी कोई डायरेक्टरी प्रविष्टि नहीं है।

​

नियम फ़ील्ड और प्रीसेट

​

वेबहुक

{
  "event_id": "9c0c8b8a-1111-4222-9333-666666666666",
  "webhook_type": "travel_rule.status.updated",
  "timestamp": 1774970000,
  "created_at": 1774970000,
  "application_id": "11111111-2222-3333-4444-555555555555",
  "environment": "live",
  "transaction_id": "22222222-3333-4444-5555-666666666666",
  "txn_id": "trv-2026-07-05-001",
  "travel_rule_status": "COMPLETED",
  "rail": "INTERNAL",
  "direction": "OUTBOUND"
}

​

मूल्य निर्धारण

• यह बहिर्गामी travelRule लेन-देन पर लागू होता है, ऐसे एप्लिकेशन पर जिसमें Travel Rule चालू है, और जिसकी राशि आपके threshold_amount के बराबर या उससे अधिक है, इसलिए Didit उसके लिए प्रबंधित एक्सचेंज शुरू करता है। स्व-होस्टेड वॉलेट या आपके उपयोगकर्ता के अपने सत्यापित वॉलेट पर भेजा गया ट्रांसफ़र भी इसमें गिना जाता है: स्वामित्व प्रमाण ही उसका एक्सचेंज है।
• बाकी हर बहिर्गामी लेन-देन जिसमें Travel Rule डेटा हो, वह मानक Transaction Screening के रूप में बिल होता है। यह आपके प्लान में उसकी मासिक लेन-देन सीमा तक शामिल है, और इसके बाद प्रत्येक लेन-देन के लिए $0.001 की कीमत लगती है: आपकी थ्रेशोल्ड से कम का ट्रांसफ़र, Lightning भुगतान जिस पर Travel Rule लागू नहीं होता, और वह ट्रांसफ़र जो Travel Rule बंद होने पर निष्क्रिय रूप से दर्ज हुआ। एक लेन-देन का बिल दो में से एक ही लाइन पर बनता है, दोनों पर कभी नहीं।
• आवक travelRule लेन-देन पर कोई Travel Rule या मॉनिटरिंग शुल्क नहीं लगता: यानी INTERNAL रेल के ज़रिए लाभार्थी के एप्लिकेशन पर Didit द्वारा बनाया गया आवक लेग, आवक TRP पूछताछ, और जमा करने के बाद के पंजीकरण।
• जो एप्लिकेशन मुफ़्त Travel Rule में शामिल हुआ, वह बहिर्गामी travelRule लेन-देन पर दोनों शुल्क तब तक नहीं देता जब तक वह POST /v3/travel-rule/workspace/billing/ से बहिर्गामी बिलिंग चालू नहीं करता; प्राप्त करना मुफ़्त ही रहता है।
• सैंडबॉक्स एप्लिकेशन से कभी शुल्क नहीं लिया जाता।
• Travel Rule शुल्क की सूचीबद्ध कीमत $0.02 है, और आपकी सीमा से अधिक होने पर Transaction Screening $0.001 है। हर लेन-देन पर उसी लाइन की कीमत लगती है जिस पर वह बिल होता है।
• यदि उसी लेन-देन पर क्रिप्टो AML/वॉलेट स्क्रीनिंग भी चलती है (उदाहरण के लिए currency_kind: "crypto" वाला आवक डिपॉज़िट, और मॉनिटरिंग चालू), तो वह मानक Wallet Verification & Screening दर पर अलग से बिल होती है। वह Travel Rule शुल्क में शामिल नहीं होती।
• प्रतिपक्ष स्क्रीनिंग वैकल्पिक है और अलग से बिल होती है, प्रति स्क्रीनिंग Company AML Screening मूल्य पर; 30 दिन से कम पुरानी स्क्रीनिंग बिना शुल्क दोबारा उपयोग होती है। निर्णय, प्रश्नावलियाँ और डायरेक्टरी का ड्यू डिलिजेंस आकलन कोई शुल्क नहीं लेते।

​

एट्रिब्यूशन मूल्य निर्धारण

• क्रिप्टो मॉनिटरिंग ने इस लेन-देन पर वॉलेट पहले ही स्क्रीन कर लिया है - संग्रहीत परिणाम फिर से उपयोग होता है। एक एनालिटिक्स कॉल, एक Wallet Verification & Screening शुल्क (वही जो क्रिप्टो मॉनिटरिंग पहले ले चुकी है)। एट्रिब्यूशन कुछ नहीं जोड़ता।
• क्रिप्टो मॉनिटरिंग नहीं चली - Didit आवश्यक एनालिटिक्स कॉल एक बार करता है और उसका पूरा मूल्य आगे देता है: लेन-देन पर मानक Wallet Verification & Screening दर लगती है ($0.15, Didit द्वारा प्रबंधित एनालिटिक्स के साथ), और बदले में पूरा क्रिप्टो स्क्रीनिंग आउटपुट मिलता है - जोखिम स्कोर, वॉलेट जोखिम श्रेणी, नेटवर्क स्नैपशॉट - न कि केवल VASP का नाम। उपयोग की लाइन आइटम पर travel_rule_attribution ट्रिगर चिह्नित होता है, ताकि शुल्क समझाया जा सके।
• अपनी एनालिटिक्स कुंजी लाएँ - वही प्लेटफ़ॉर्म शुल्क लागू होता है जो अपनी कुंजी वाली क्रिप्टो मॉनिटरिंग पर लागू होता है ($0.02 प्रति कॉल)। आपका प्रदाता अंतर्निहित लुकअप का बिल सीधे आपको भेजता है।
• विफल लुकअप का कभी शुल्क नहीं लिया जाता, दोबारा भेजने पर बिना नए कॉल या शुल्क के, दर्ज एट्रिब्यूशन फिर से उपयोग होता है, और सैंडबॉक्स एप्लिकेशन से कभी शुल्क नहीं लिया जाता।

​

EU TFR नियम बंडल

​

एक ही प्लेटफ़ॉर्म पर यह बेहतर क्यों काम करता है

• हाथ में सत्यापित डेटा। हर ट्रांसफ़र से संबंधित पक्ष vendor_data द्वारा उस KYC प्रोफ़ाइल से जुड़ा होता है जिसे Didit ने ऑनबोर्डिंग के समय सत्यापित किया था (दस्तावेज़ OCR, लाइवनेस, चेहरा मिलान), ताकि आप उसी प्लेटफ़ॉर्म पर सत्यापित फ़ील्ड से originator_data बना सकें। जिस उपयोगकर्ता के पास स्वीकृत KYC सत्यापन है, Didit आपके द्वारा टाइप किए गए मान के बजाय सत्यापित पहचान भेजता है (देखें सत्यापित डेटा और प्रोवेनेंस)।
• जोखिम भरे ट्रांसफ़र के लिए अतिरिक्त बायोमेट्रिक जाँच। एक नियम किसी भी उच्च-मूल्य ट्रांसफ़र को तब तक रोक सकता है जब तक उपयोगकर्ता ऑनबोर्डिंग के समय लिए गए चेहरे के विरुद्ध बायोमेट्रिक पुनः जाँच पास न कर ले। निकासी के क्षण में खाता अधिग्रहण का यह सबसे मज़बूत संभव जवाब है। व्यावहारिक उदाहरण देखें।
• एक डिवाइस ग्राफ़। SDK से सबमिट किए गए ट्रांसफ़र में KYC सत्रों के समान डिवाइस इंटेलिजेंस होती है, इसलिए “नया डिवाइस + उच्च राशि + पहली बार का लाभार्थी” एक ही नियम है, डेटा-वेयरहाउस जॉइन नहीं।
• एक ही जगह पर स्क्रीनिंग, नियम, केस और एक्सचेंज। वॉलेट स्क्रीनिंग, जो counterparty VASP की पहचान करती है, वही स्क्रीनिंग है जिसे आपके नियम और विश्लेषक देखते हैं: एक शुल्क, एक कंसोल, एक ऑडिट ट्रेल।
• प्रकाशित मूल्य निर्धारण। प्रति आउटबाउंड एक्सचेंज $0.02, कोई वॉल्यूम स्तर नहीं, कोई सेल्स कॉल नहीं।

​

FAQ

​

आदान-प्रदान कैसे काम करता है

​

मूल्य निर्धारण और लाइसेंसिंग

​

संचालन और डेटा

​

अगले चरण