Travel Rule इंटरऑपरेबिलिटी - Didit VASP से जुड़ें

यह पेज दूसरे पक्ष के लिए है, यानी प्रतिपक्ष VASP (या उसकी इंजीनियरिंग टीम), जिसे Didit Travel Rule एक्सचेंज के तहत Didit पर चलने वाले VASP को Travel Rule डेटा भेजना होता है या उससे प्राप्त करना होता है। यहाँ दस्तावेज़ की गई हर चीज़ Didit द्वारा संचालित सार्वजनिक इन्फ़्रास्ट्रक्चर है। इंटरऑपरेट करने के लिए आपको Didit खाता, API कुंजी या Didit के साथ किसी भी व्यावसायिक संबंध की ज़रूरत नहीं है। सबसे गहरे इंटीग्रेशन के लिए भी केवल HTTPS और JSON चाहिए।

Didit एक्सचेंज को कैसे रूट करता है

जब कोई Didit ग्राहक ट्रांसफ़र भेजता है, तो Didit इन रेल्स को सख़्त प्राथमिकता क्रम में आज़माता है और जो पहली रेल आप तक पहुँच सकती है, उसका उपयोग करता है:

प्राथमिकता	रेल	इसका आपके लिए क्या अर्थ है
1	`INTERNAL`	दोनों VASP Didit पर चलते हैं - एक्सचेंज प्लेटफ़ॉर्म के भीतर ही सेटल होता है और कोई बाहरी कॉल नहीं की जाती।
2	`TRP`	आप एक Travel Rule Protocol (TRP) endpoint उपलब्ध कराते हैं, या Didit ग्राहक आपका Travel Address जानता है। Didit `BTC`, `ETH` और `USDC` ट्रांसफ़र के लिए आपके TRP पूछताछ endpoint को मशीन-से-मशीन कॉल करता है (`USDC` तब जब ट्रांसफ़र उस नेटवर्क का नाम दे जिस पर वह चलता है)।
3	`GTR`	प्रेषक के लिए Global Travel Rule (GTR) सदस्यता सक्रिय है और आप GTR VASP कोड से पहचाने जा सकते हैं। Didit आपका उत्तर GTR की प्रतिक्रिया से पढ़ता है, या अनुरोध की स्थिति की पोलिंग करके।
4	`TRUST`	प्रेषक के लिए TRUST सदस्यता सक्रिय है और आप TRUST सदस्यता आईडी से पहचाने जा सकते हैं। केवल भेजने के लिए: नीचे दी गई चेतावनी देखें।
5	`VERIFYVASP`	प्रेषक के लिए VerifyVASP सदस्यता सक्रिय है और आप VerifyVASP आईडी से पहचाने जा सकते हैं। Didit सत्यापन की स्थिति की पोलिंग करके आपका उत्तर पढ़ता है।
6	`SYGNA`	प्रेषक के लिए Sygna Bridge सदस्यता सक्रिय है और आप Sygna VASP कोड से पहचाने जा सकते हैं। Didit Sygna प्रोटोकॉल में मूल रूप से संवाद करता है (ECIES-एन्क्रिप्टेड IVMS101, हस्ताक्षरित अनुमति अनुरोध), और ट्रांसफ़र की स्थिति की पोलिंग करके आपका अनुमति उत्तर पढ़ता है: उसका Sygna callback अभी लाइव नहीं है।
7	`EMAIL`	कोई प्रोटोकॉल चैनल उपलब्ध नहीं है - इसके बजाय आपके अनुपालन संपर्क को एक बार-उपयोग वाला ईमेल पिकअप लिंक मिलता है।

Didit TRUST का उत्तर प्राप्त नहीं कर सकता, और नेटवर्क के ज़रिए उसे भेजे गए ट्रांसफ़र अभी स्वीकार नहीं करता। TRUST पर, Didit ग्राहक का ट्रांसफ़र आप तक पहुँचता है, लेकिन आपका उत्तर वापस नहीं आ सकता, और ट्रांसफ़र भेजने वाले की पुष्टि की समय-सीमा पर समाप्त हो जाता है, पूरा होने के बजाय। GTR, VERIFYVASP और SYGNA पर, Didit आपका उत्तर नेटवर्क से ही पढ़ता है, उसकी प्रतिक्रिया से या ट्रांसफ़र की स्थिति की पोलिंग करके।

ऊपर की तालिका उन ट्रांसफ़र पर लागू होती है जो Didit ग्राहक भेजता है। जब आप किसी Didit ग्राहक को ट्रांसफ़र भेजते हैं, तो Didit उसे केवल एक TRP ट्रांसफ़र पूछताछ के रूप में ले सकता है, जब Didit का सार्वजनिक TRP होस्ट लाइव हो (अभी उत्तर नहीं देता, देखें TRP endpoints), या, सेटलमेंट के बाद, sunrise पंजीकरण के रूप में: आज कोई नेटवर्क रेल और कोई ईमेल चैनल किसी Didit ग्राहक तक आने वाला ट्रांसफ़र नहीं पहुँचाता। नेटवर्क रेल्स (GTR, TRUST, VERIFYVASP, SYGNA) प्रेषक की ओर की सदस्यता के माध्यम से चलती हैं। आज इसके लिए Didit ग्राहक की अपनी जुड़ी हुई सदस्यता होनी चाहिए: Didit के पास इनमें से किसी भी नेटवर्क पर अभी प्लेटफ़ॉर्म सदस्यता नहीं है और वह एक प्रदाता के रूप में ऑनबोर्ड हो रहा है। GTR डिफ़ॉल्ट रूप से शामिल नहीं है, और यही सदस्यता आवश्यकता चारों नेटवर्कों पर लागू होती है। प्रेषक को Get Travel Rule Settings में networks ऑब्जेक्ट की जाँच करनी चाहिए: didit का अर्थ है कि Didit की सदस्यता उस एप्लिकेशन के लिए नेटवर्क पर स्वयं प्रतिभागी होती है, own का अर्थ है जुड़ी हुई ग्राहक सदस्यता, off का अर्थ है कि प्लेटफ़ॉर्म रूटिंग अक्षम है, और unavailable का अर्थ है कि उस एप्लिकेशन के लिए उस नेटवर्क पर अभी कोई भी नहीं भेज सकता। जब तक Didit के पास प्लेटफ़ॉर्म सदस्यता नहीं होती, कोई भी नेटवर्क didit नहीं दिखाता। Travel Rule सक्षम करने से नेटवर्क सदस्यता सक्रिय नहीं होती। हर नेटवर्क आज कहाँ तक पहुँचता है, इसके लिए Travel Rule networks देखें। यदि आप इनमें से किसी नेटवर्क पर हैं और Didit ग्राहक की वहाँ अपनी सदस्यता है, तो उसके साथ अपनी नेटवर्क पहचान साझा करें, और ट्रांसफ़र उस नेटवर्क के ज़रिए आप तक पहुँचेगा जिसका आप पहले से संचालन करते हैं। SYGNA पर, आपका अनुमति उत्तर ट्रांसफ़र को पूरा या अस्वीकार करता है: Didit हर 5 मिनट में ट्रांसफ़र की स्थिति पोल करता है, और हर अनुमति अनुरोध के callback के रूप में https://trp.didit.me/sygna/callbacks/permission/{token}/ भी पंजीकृत करता है, जिसका token उस ट्रांसफ़र के लिए बनाया जाता है। यह callback Didit के सार्वजनिक TRP होस्ट पर है, जो अभी अनुरोधों का उत्तर नहीं देता। ACCEPTED का permission_status भेजने वाले के ट्रांसफ़र को COMPLETED पर ले जाता है, और REJECTED उसे COUNTERPARTY_VASP_GENERAL_DECLINE पर ले जाता है, या जब reject_code BVRC007 हो (लाभार्थी का नाम मेल नहीं खाता) तो COUNTERPARTY_MISMATCHED_DATA पर। Callback को आपके हस्ताक्षर की आवश्यकता है: वैध हस्ताक्षर के बिना यह 401 के साथ {"status": "INVALID_SIGNATURE"} लौटाता है, अज्ञात token के लिए 404, और ऐसे निर्णय के लिए फिर 200 लौटाता है जिसे वह पहले ही लागू कर चुका है। बिना किसी साझा सदस्यता के, TRP वह रास्ता है जिसकी योजना बनानी चाहिए: Didit ग्राहक के साथ अपना Travel Address साझा करें, और उनके ट्रांसफ़र आपके TRP endpoint तक पहुँचेंगे। आप अपनी पूछताछ के उत्तर में जो उत्तर देते हैं, वह ट्रांसफ़र को तुरंत पूरा या अस्वीकार करता है; बाद में Didit के callback पर आप जो उत्तर भेजते हैं, उसके लिए Didit के सार्वजनिक TRP होस्ट की ज़रूरत होती है, जो अभी लाइव नहीं है। जब कोई भी रेल आपकी पहचान नहीं कर पाती, तो Didit एक और समाधान चरण चलाता है: ब्लॉकचेन विश्लेषण के आधार पर पहचान। गंतव्य वॉलेट की पहचान ब्लॉकचेन विश्लेषण डेटा के आधार पर की जाती है, और जब उसे आपके एक्सचेंज या कस्टडी सेवा से जोड़ा जाता है, तो Didit आपका नाम अपनी VASP डायरेक्टरी में दर्ज करता है और उसके साथ रेल्स को फिर से आज़माता है। इसका अर्थ है कि यदि प्रेषक ने केवल वॉलेट पता दिया हो, तब भी आपकी पहचान हो सकती है। ब्लॉकचेन विश्लेषण के आधार पर जोड़े गए ट्रांसफ़र आप तक स्वचालित रूप से तभी रूट होते हैं जब आपकी डायरेक्टरी प्रविष्टि में कोई रूट हो: सत्यापित TRP endpoint, नेटवर्क सूची, या अनुपालन संपर्क (देखें Didit VASP डायरेक्टरी में प्रवेश)। इसलिए पूरी समाधान श्रृंखला यह है: वह Didit ग्राहक जिसने वॉलेट पर नियंत्रण सिद्ध किया है (INTERNAL) और वह Travel Address जो प्रेषक ने उसके लिए संग्रहीत किया, फिर प्रोटोकॉल और नेटवर्क रेल्स, और अंत में ब्लॉकचेन विश्लेषण।

Travel Address

हर ऐसा Didit VASP जिसमें Travel Rule सक्षम है, उसका एक Travel Address होता है। यह ta से शुरू होने वाली एक संक्षिप्त स्ट्रिंग है, जो उसके व्यक्तिगत TRP ट्रांसफ़र-पूछताछ endpoint का URL एन्कोड करती है। Didit ग्राहक अपना Travel Address अपनी Travel Rule सेटिंग्स से पढ़ते हैं और उसे प्रतिपक्षों के साथ साझा करते हैं। जब कोई Didit ग्राहक आपको अपना Travel Address देता है, तो TRP के ज़रिए उस तक पहुँचने के लिए आपके पास ज़रूरी सब कुछ होता है। एन्कोडिंग TRP Travel Address परिपाटी का पालन करती है:

ta उपसर्ग हटाएँ।
बाकी हिस्से को Base58Check डिकोड करें (Bitcoin वर्णमाला, डबल-SHA256 चेकसम)।
डिकोड किए गए बाइट्स स्कीम के बिना पूछताछ URL हैं; उसके आगे https:// जोड़ें।
URL में हमेशा क्वेरी जोड़ी t=i (प्रकार: पूछताछ) होती है।

एक डिकोड किया गया Didit Travel Address इन दो रूपों में से एक का होता है:

https://trp.didit.me/trp/inquiries/{profile_uuid}/?t=i
https://trp.didit.me/trp/inquiries/{profile_uuid}/wallets/{entry_uuid}/?t=i

पहला रूप होस्टेड VASP प्रोफ़ाइल की पहचान करता है। {profile_uuid} उसी प्रोफ़ाइल का UUID है। अपने ट्रांसफ़र की पूछताछ इसी URL पर POST करें, और सबसे पहले यह सत्यापित करने के लिए कि आप किससे बात कर रहे हैं, मिलते-जुलते पहचान endpoint को क्वेरी करें। दूसरा रूप प्रति-वॉलेट Travel Address है। यह Didit ग्राहक के एक वॉलेट का नाम बताता है (उसकी पता पुस्तिका में receiving_travel_address), इसलिए आपकी पूछताछ ग्राहक के खाता संख्या या धारक के नाम से मिलान किए बिना उस वॉलेट तक पहुँचती है। वॉलेट हटा दिए जाने के बाद, या उसके किसी अन्य VASP के नाम दर्ज होने पर, यह 404 लौटाता है।

TRP endpoints

Didit, TRP API संस्करण 3.2.1 का उपयोग करता है, और इसका बेस URL https://trp.didit.me है। सभी endpoint HTTPS पर JSON का आदान-प्रदान करते हैं।

Didit का सार्वजनिक TRP होस्ट अभी ये endpoint नहीं देता। जब तक यह ऐसा नहीं करता, Didit के किसी ग्राहक को भेजी गई TRP पूछताछ या पहचान अनुरोध डिलीवर नहीं किया जा सकता; यह सेक्शन वह अनुबंध है जिसका उत्तर होस्ट लाइव होने के बाद देगा।

विधि	पाथ	उद्देश्य
`GET`	`/identity`	प्लेटफ़ॉर्म ऑपरेटर की पहचान (`/trp/identity` पर भी उपलब्ध)।
`GET`	`/trp/identity/{profile_uuid}/`	एक होस्टेड VASP प्रोफ़ाइल की पहचान।
`POST`	`/trp/inquiries/{profile_uuid}/`	एक होस्टेड VASP को ट्रांसफ़र पूछताछ सबमिट करें।
`POST`	`/trp/inquiries/{profile_uuid}/wallets/{entry_uuid}/`	होस्टेड VASP के एक वॉलेट के लिए ट्रांसफ़र पूछताछ सबमिट करें (प्रति-वॉलेट Travel Address)।
`POST`	`/trp/callbacks/resolution/{token}/`	वह पूछताछ हल करें जो Didit ने आपको भेजी (स्वीकृत या अस्वीकृत)।
`POST`	`/trp/callbacks/confirmation/{token}/`	Didit द्वारा आपके लिए स्वीकृत ट्रांसफ़र की पुष्टि करें या उसे रद्द करें।

दो TRP हेडर महत्वपूर्ण हैं:

api-version - आप जिस TRP प्रोटोकॉल संस्करण का उपयोग करते हैं, उदाहरण के लिए 3.2.1। पूछताछ और दोनों callback पर आवश्यक।
request-identifier - अनुरोध के लिए आपका अद्वितीय ID, जो रिस्पॉन्स हेडर में वापस भेजा जाता है। पूछताछ और दोनों callback पर आवश्यक।

पूछताछ या callback endpoint पर बिना दोनों हेडर के किया गया अनुरोध 400 लौटाता है। Didit का हर रिस्पॉन्स api-version: 3.2.1 के साथ आता है और आपका request-identifier वापस भेजता है।

GET /identity

प्लेटफ़ॉर्म ऑपरेटर की पहचान लौटाता है। इसके लिए कोई हेडर आवश्यक नहीं है।

curl https://trp.didit.me/identity

{
  "name": "Didit",
  "lei": "",
  "x509": ""
}

GET /trp/identity//

उस विशिष्ट VASP की पहचान लौटाता है जिसके साथ आप आदान-प्रदान करने वाले हैं। PII भेजने से पहले नाम और LEI सत्यापित करने के लिए इसका उपयोग करें। जब Didit शुरुआत करता है, तो वह उलटी दिशा में भी यही जाँच करता है: यदि आपके endpoint द्वारा रिपोर्ट की गई पहचान अपेक्षित LEI या नाम से मेल नहीं खाती, तो एक्सचेंज निरस्त कर दिया जाता है।

curl https://trp.didit.me/trp/identity/11111111-2222-3333-4444-555555555555/

{
  "name": "Bene CASP GmbH",
  "lei": "5493001KJTIIGC8Y1R12",
  "x509": ""
}

प्रोफ़ाइल मौजूद न होने या उसका Travel Rule सेटअप अक्षम होने पर 404 लौटाता है।

POST /trp/inquiries//

ट्रांसफ़र पूछताछ सबमिट करें। आप प्रेषक VASP हैं, और Didit का ग्राहक लाभार्थी VASP है।

curl -X POST https://trp.didit.me/trp/inquiries/11111111-2222-3333-4444-555555555555/ \
  -H "Content-Type: application/json" \
  -H "api-version: 3.2.1" \
  -H "request-identifier: 7f6a1c1e-0a63-4b1f-9f6e-7dcd7c3f1a01" \
  -d '{
    "asset": { "dti": "X9J9K872S" },
    "amount": 250000000000000000,
    "callback": "https://trp.yourvasp.example/callbacks/inquiry/abc123",
    "IVMS101": {
      "originator": {
        "originatorPersons": [
          { "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Ruiz", "secondaryIdentifier": "Carlos", "nameIdentifierType": "LEGL" }] } } }
        ],
        "accountNumber": ["0x77ccff0cc624a53cd8b8d8703ced826710211ec7"]
      },
      "beneficiary": {
        "beneficiaryPersons": [
          { "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Diaz", "secondaryIdentifier": "Ana", "nameIdentifierType": "LEGL" }] } } }
        ],
        "accountNumber": ["0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb"]
      }
    }
  }'

फ़ील्ड	प्रकार	विवरण
`asset.dti`	string	आवश्यक। ट्रांसफ़र की जा रही संपत्ति का Digital Token Identifier (ISO 24165)। इसके बिना पूछताछ `400` देती है; pre-3.2.0 `asset.slip0044` नहीं पढ़ा जाता।
`amount`	number	आवश्यक। संपत्ति की सबसे छोटी इकाई में पूरी राशि (DTI के दशमलव के अनुसार base units)। पूर्ण संख्या का कोई भी JSON संकेतन स्वीकार होता है, घातांक रूप भी, और अंकों की स्ट्रिंग भी। भिन्न, या दर्ज न हो सकने वाली बहुत बड़ी राशि `400` देती है।
`callback`	string	आवश्यक। आपकी ओर का पूर्ण सार्वजनिक `http(s)` URL, जहाँ Didit पूछताछ का निपटारा पोस्ट करता है (`https` अनुशंसित)। वही `callback` दोहराने वाला पुनः प्रयास उसी पूछताछ से मिलाया जाता है जिसे वह दोहराता है।
`IVMS101`	object	आवश्यक। IVMS 101 पेलोड: `originator.originatorPersons` और `beneficiary.beneficiaryPersons` (Didit हर एक का पहला `naturalPerson` पढ़ता है; कानूनी-व्यक्ति डेटा नहीं पढ़ा जाता), साथ में `accountNumber` वॉलेट सरणियाँ।

इस चैनल पर संपत्तियाँ DTI से पहचानी जाती हैं, और एक DTI एक ही ब्लॉकचेन पर एक token की पहचान करता है। Didit आज नौ नेटवर्क पर BTC (4H95J0R2X), ETH (X9J9K872S) और USDC को मैप करता है, और समय के साथ और संपत्तियाँ जोड़ी जाएँगी। पूरी सूची के लिए TRP परिसंपत्ति पहचानकर्ता देखें। जिस पूछताछ का DTI Didit नहीं पहचानता, उसे फिर भी स्वीकार किया जाता है, और DTI को asset code के रूप में लाभार्थी VASP तक पहुँचाया जाता है। 200 रिस्पॉन्स का अर्थ है कि पूछताछ प्रोसेसिंग के लिए स्वीकार हो गई। 400 का अर्थ है TRP हेडर गायब हैं या body अमान्य है। 404 का अर्थ है कि प्रोफ़ाइल (या प्रति-वॉलेट पते का वॉलेट) अज्ञात या अक्षम है। 422 का अर्थ है कि अनुरोध किसी TRP एक्सटेंशन का उपयोग करता है: Didit कोई एक्सटेंशन समर्थित नहीं करता, इसलिए api-extensions हेडर या body में extensions कुंजी अस्वीकार की जाती है। उसी request-identifier को दोबारा भेजना आइडेम्पोटेंट है: मूल पूछताछ दोहराई नहीं जाती, बल्कि फिर से उपयोग की जाती है। इसके बाद Didit ग्राहक के एप्लिकेशन में इनबाउंड ट्रांसफ़र बनाता है और उसे ग्राहक की वॉलेट पता पुस्तिका और नीति के विरुद्ध हल करता है। वह लाभार्थी का मिलान इस क्रम में करता है: पहले, प्रति-वॉलेट Travel Address द्वारा नामित वॉलेट से; अन्यथा IVMS101.beneficiary.accountNumber के पहले वॉलेट पते से; या, इनमें से कुछ न होने पर, ग्राहक की सत्यापित वॉलेट प्रविष्टियों के विरुद्ध beneficiaryPersons[0].naturalPerson नाम से। जब Didit तुरंत उत्तर दे सकता है, तो 200 रिस्पॉन्स में उत्तर होता है:

{"approved": {"address": "...", "callback": "..."}} जब पूछताछ अपने आप स्वीकृत हो गई हो। Didit यह स्वीकृति आपके callback पर अलग से पोस्ट नहीं करता।
{"rejected": "NOT_ENOUGH_COUNTERPARTY_DATA: inquiry carries no beneficiary identification"} जब पूछताछ में न तो लाभार्थी की पहचान होती है और न ही वॉलेट पता, इसलिए हमेशा दोनों शामिल करें।
{"version": "3.2.1"} जब निर्णय Didit ग्राहक की प्रतीक्षा करता है। निपटारा बाद में आपके callback URL पर POST के रूप में आता है, नीचे दिए दो body में से एक के साथ।

{
  "approved": {
    "address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
    "callback": "https://trp.didit.me/trp/callbacks/confirmation/{token}/"
  }
}

{
  "rejected": "Wallet ownership denied by beneficiary VASP"
}

स्वीकृति स्वचालित हो सकती है, जब लाभार्थी VASP auto-accept सक्षम करता है और लाभार्थी संपत्ति की ब्लॉकचेन पर किसी सत्यापित वॉलेट प्रविष्टि से मेल खाता है। या लाभार्थी पक्ष पर मैन्युअल समीक्षा या वॉलेट-स्वामित्व प्रमाण के बाद आ सकती है। इसलिए पूछताछ और निपटारे के बीच देरी के लिए तैयार रहें। पूछताछ कभी ऐसे वॉलेट से मेल नहीं खाती जिसे Didit ग्राहक ने किसी दूसरे VASP का दर्ज किया हो, और originatingVASP में दिया गया आपका VASP नाम ही Didit ग्राहक को ट्रांसफ़र के प्रेषक VASP के रूप में दिखाई देता है। आपकी भेजी गई पूछताछ पर Didit कोई समय-सीमा नहीं लगाता, और यदि Didit ग्राहक उसे रद्द करता है, तो वह आपको कोई अस्वीकृति नहीं भेजता। इसलिए अपना खुद का टाइमआउट लागू करें। स्वीकृति प्राप्त करने और ट्रांसफ़र को ऑन-चेन प्रसारित करने के बाद, वह approved.callback URL, जो आपको दिया गया था, उस पर POST करके एक्सचेंज बंद करें:

curl -X POST "https://trp.didit.me/trp/callbacks/confirmation/{token}/" \
  -H "Content-Type: application/json" \
  -H "api-version: 3.2.1" \
  -H "request-identifier: 0b8e2f4a-6c1d-4e9a-8f3b-2d7c5a1e9f60" \
  -d '{ "txid": "0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060" }'

यदि आप ट्रांसफ़र निरस्त करते हैं, तो इसके बजाय उसी URL पर { "canceled": "reason" } भेजें। txid लाभार्थी-पक्ष के ट्रांसफ़र को FINISHED पर ले जाता है; canceled उसे CANCELLED पर ले जाता है। दोनों callback संभाले जाने पर 204 लौटाते हैं। अज्ञात token या ऐसे ट्रांसफ़र के लिए, जो अब उस callback की प्रतीक्षा नहीं कर रहा, 404 लौटता है। ऐसी body के लिए, जिसमें callback के दोनों फ़ील्ड में से कोई भी न हो, 400 लौटता है।

Didit द्वारा आपको भेजी गई इंक्वायरी का समाधान

जब कोई Didit ग्राहक TRP के ज़रिए आपको ट्रांसफ़र भेजता है, तो Didit:

आपके इंक्वायरी URL के होस्ट की रूट पर मौजूद /identity लाता है (https://{your-host}/identity) और उसमें बताए गए नाम और LEI को ग्राहक की अपेक्षित जानकारी से मिलाता है। जब रूट Didit की डायरेक्टरी से आया हो, तो आपके /identity को उस डायरेक्टरी एंट्री का LEI बताना होगा।
आपके इंक्वायरी URL पर एक ट्रांसफ़र इंक्वायरी POST करता है, जिसकी बॉडी की संरचना ऊपर जैसी ही होती है: asset.dti, बेस-यूनिट में amount JSON नंबर के रूप में, एक callback, और IVMS101 payload।

केवल 2xx उत्तर को डिलीवर हुआ माना जाता है। 3xx को अस्वीकार किया जाता है, क्योंकि रीडायरेक्ट फ़ॉलो नहीं किए जाते। किसी भी अन्य उत्तर को ग्राहक की ट्रांसफ़र टाइमलाइन पर आपके स्टेटस कोड के साथ दर्ज किया जाता है, जैसे refused by counterparty (HTTP 403): ...। दोनों कॉल में दोनों TRP हेडर होते हैं, और Didit इन पर HTTP रीडायरेक्ट फ़ॉलो नहीं करता, इसलिए /identity और इंक्वायरी URL को सीधे सर्व करें। अगर /identity पहुँच में नहीं है, कोई LEI नहीं बताता, या ग्राहक द्वारा दिए गए LEI से अलग LEI बताता है, या ऐसा नाम बताता है जो मेल नहीं खाता, तो Didit इंक्वायरी भेजने से पहले रुक जाता है और ग्राहक का ट्रांसफ़र COUNTERPARTY_VASP_NOT_REACHABLE पर चला जाता है। अगर इसके बाद इंक्वायरी POST विफल होता है, या आपका endpoint उसका 4xx या 5xx स्टेटस देता है, तो भी ट्रांसफ़र COUNTERPARTY_VASP_NOT_REACHABLE पर चला जाता है। उस इंक्वायरी में दिया गया callback Didit के रिज़ॉल्यूशन endpoint की ओर इशारा करता है (/trp/callbacks/resolution/{token}/)। जवाब देने के लिए वही रिज़ॉल्यूशन बॉडी POST करें जिन्हें Didit खुद इस्तेमाल करता है: मंज़ूरी के लिए { "approved": { "address": "...", "callback": "..." } } (आपका callback वह जगह है जहाँ Didit ऑन-चेन पुष्टि POST करेगा), या अस्वीकार के लिए { "rejected": "reason" }। इसके साथ दोनों TRP हेडर भेजें। हैंडल होने के बाद Didit 204 देता है, 404 तब देता है जब ट्रांसफ़र अब रिज़ॉल्यूशन का इंतज़ार नहीं कर रहा, और 400 तब देता है जब मंज़ूरी में address न हो या callback एक सार्वजनिक http(s) URL न हो जिसे Didit कॉल कर सके। मंज़ूरी के बाद Didit की ओर से ट्रांसफ़र COMPLETED पर चला जाता है। जब ग्राहक ऑन-चेन हैश बताता है, तो Didit पुष्टि के लिए आपके दिए गए callback पर { "txid": "..." } POST करता है (या अगर ट्रांसफ़र पहले रद्द हो जाए, तो { "canceled": "reason" })।

कॉलबैक टोकन एक ही उद्देश्य के लिए होते हैं, उनका अनुमान नहीं लगाया जा सकता, और हर ट्रांसफ़र के लिए अलग से बनाए जाते हैं। पूरे कॉलबैक URL को गोपनीय मानें, और ध्यान रखें कि रिज़ॉल्यूशन केवल तब स्वीकार होता है जब ट्रांसफ़र अब भी उसका इंतज़ार कर रहा हो।

ईमेल से पिकअप

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

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

{
  "originator_vasp_name": "Origin CASP SL",
  "amount": "0.250000000000000000",
  "currency": "ETH",
  "beneficiary_wallet": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
  "status": "AWAITING_COUNTERPARTY"
}

amount वही संग्रहित दशमलव मान है, जिसमें पूरे 18 दशमलव स्थान शामिल हैं।

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" }'

decision या तो accept होता है या decline। accept के मामले में, लाभार्थी का नाम वैसा ही दें जैसा आपके रिकॉर्ड में है, ताकि प्रेषक पक्ष नाम मिलान चला सके। या फिर अपना पूरा IVMS 101 रिस्पॉन्स ivms_response के रूप में भेजें, और उसमें दिया गया लाभार्थी नाम प्राथमिकता पाएगा। decline के मामले में आप decline_reason दे सकते हैं (data_mismatch, not_our_customer, wallet_not_hosted, sanctions, risk_appetite, jurisdiction, insufficient_data या other) और decline_detail में 512 अक्षरों तक का विवरण दे सकते हैं, जो other के लिए अनिवार्य है। अगर accept के साथ beneficiary_name नहीं है, तो उसे मिलान में गड़बड़ी माना जाता है, जब प्रेषक ने लाभार्थी का नाम दिया हो, जब तक प्रेषक ने नाम मिलान बंद न किया हो। उत्तर के रूप में परिणामी {"status": "..."} मिलता है: नाम मेल खाने पर COMPLETED, मेल न खाने पर COUNTERPARTY_MISMATCHED_DATA, या decline के बाद COUNTERPARTY_VASP_GENERAL_DECLINE। आप एक ही बार जवाब दे सकते हैं, जब तक ट्रांसफ़र आपके जवाब का इंतज़ार कर रहा हो। जवाब देने के बाद, ट्रांसफ़र रद्द होने के बाद, या उसकी पुष्टि की समय-सीमा निकल जाने के बाद, दोनों endpoint 410 लौटाते हैं, और अज्ञात टोकन पर 404 लौटता है। इस अनुरोध में प्रेषक द्वारा साझा किए गए प्रेषक फ़ील्ड और IVMS 101 ivms_request दिखते हैं, जो आपके क्षेत्राधिकार की भाषा में होता है। जब तक आप जवाब नहीं देते, समय-सीमा से 72, 24 और 6 घंटे पहले आपको याद दिलाया जाता है।

सनराइज़: ऐसे ट्रांसफ़र जो विनिमय से पहले सेटल हो गए

जब कोई ट्रांसफ़र Travel Rule विनिमय होने से पहले Didit ग्राहक के वॉलेट तक पहुँच जाता है (क्योंकि उस समय कोई साझा रेल मौजूद नहीं था), तब भी सेटलमेंट के बाद डेटा डिलीवर किया जा सकता है। Didit ग्राहक को (जो आपका लाभार्थी प्रतिपक्ष है) अपने सामान्य चैनल से Travel Rule payload भेजें और उन्हें उसे रजिस्टर करने को कहें। वे POST /v3/travel-rule/inbound/ को डिपॉज़िट की चेन, txid, वॉलेट पता, राशि, मुद्रा और आपका प्रेषक डेटा के साथ कॉल करेंगे। अपनी VASP पहचान (नाम, LEI और Travel Address) उस payload में originating_vasp के रूप में शामिल करें, ताकि Didit ग्राहक के ट्रांसफ़र रिकॉर्ड में दर्ज हो कि डिपॉज़िट किसने भेजा। यह जानकारी केवल उसी ट्रांसफ़र पर रहती है और आपकी डायरेक्टरी एंट्री को कभी न बनाती है और न बदलती है। LEI 20 अक्षरों का वैध LEI होना चाहिए और Travel Address भी वैध होना चाहिए, नहीं तो रजिस्ट्रेशन अस्वीकार हो जाएगा।

Didit VASP डायरेक्टरी में शामिल होना

Didit एक VASP डायरेक्टरी रखता है, जिसे उसके ग्राहकों की आउटबाउंड रूटिंग संदर्भित करती है। प्रविष्टियाँ इन स्रोतों से आती हैं:

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

Didit के किसी ग्राहक द्वारा आपके बारे में दी गई जानकारी, जैसे सनराइज़ पंजीकरण पर originating_vasp या किसी ट्रांसफ़र पर Travel Address, केवल उस ग्राहक के ट्रांसफ़र पर रहती है और आपकी प्रविष्टि को कभी नहीं बदलती। आप जो ट्रांसफ़र पूछताछ किसी Didit ग्राहक को भेजते हैं, वह भी आपकी प्रविष्टि नहीं बनाती और न ही उसे अपडेट करती है। आपकी प्रविष्टि आपको ट्रांसफ़र तब भेजती है जब उसमें सत्यापित TRP endpoint, भेजने वाले के लिए उपलब्ध कोई नेटवर्क सूची, या ईमेल फ़ॉलबैक के लिए कोई अनुपालन संपर्क हो। आपके अपने किसी डोमेन का अनुपालन पता, जो अपने प्रतिक्रिया लिंक के माध्यम से अनुरोध का उत्तर देता है, एक ऐसा संपर्क बन जाता है जिसका हर Didit ग्राहक उपयोग कर सकता है। जब तक आपकी प्रविष्टि में कोई रूट नहीं है, कोई Didit ग्राहक आप तक केवल उन फ़ील्ड्स के माध्यम से पहुँचता है जो वह हर ट्रांसफ़र के साथ भेजता है: आपका Travel Address, आपका नेटवर्क पहचानकर्ता (counterparty_gtr_vasp_code, counterparty_trust_membership_id, counterparty_verifyvasp_id, या counterparty_sygna_vasp_code), या आपका अनुपालन ईमेल (counterparty_vasp_email)। आज पहुँच योग्य होने के लिए, अपना Travel Address, नेटवर्क पहचानकर्ता, या अनुपालन ईमेल उन Didit ग्राहकों के साथ साझा करें जिनके साथ आप काम करते हैं।

प्रतिपक्ष VASP के लिए चेकलिस्ट

आप पहले से TRP चलाते हैं: Didit ग्राहक के साथ अपना Travel Address और LEI साझा करें - उसके BTC, ETH और USDC ट्रांसफ़र आपके endpoint पर मानक TRP पूछताछ के रूप में पहुँचेंगे। अपनी पूछताछ प्रतिक्रिया में उत्तर दें: बाद का उत्तर Didit के सार्वजनिक TRP होस्ट की माँग करता है, जो अभी लाइव नहीं है।
आप GTR, TRUST, या VerifyVASP पर हैं: अपना नेटवर्क पहचानकर्ता साझा करें; जब Didit ग्राहक वहाँ अपनी स्वयं की सदस्यता रखता है, तब ट्रांसफ़र उस नेटवर्क के माध्यम से पहुँचते हैं। Didit आपका GTR या VerifyVASP उत्तर नेटवर्क से पढ़ता है, लेकिन TRUST उत्तर नहीं पढ़ता, इसलिए जब TRUST पर कोई एक्सचेंज पूरा करना हो तो एक TRP endpoint भी प्रकाशित करें। Travel Rule नेटवर्क बताता है कि यह कब बदलता है।
आप Sygna Bridge पर हैं: अपना Sygna VASP कोड साझा करें; जब Didit ग्राहक की अपनी Sygna सदस्यता हो, तब आपका अनुमति-संबंधी उत्तर ट्रांसफ़र को पूरा करता है या अस्वीकार करता है, जब Didit उसे पोलिंग से पढ़ लेता है।
आपके पास अभी कोई प्रोटोकॉल चैनल नहीं है: Didit ग्राहक को निगरानी में रखा गया अनुपालन ईमेल पता दें - आपको पिकअप लिंक मिलेंगे और आप बिना किसी इंटीग्रेशन के होस्टेड पेज से उत्तर दे सकेंगे।
कोई ट्रांसफ़र पहले ही सेटल हो चुका है: Didit ग्राहक के माध्यम से डेटा सनराइज़ पंजीकरण से भेजें।
आप Didit VASPs को आउटबाउंड ट्रांसफ़र भी करना चाहते हैं: अपने प्रतिपक्ष से उनकी Didit Travel Rule सेटिंग्स से उनका Travel Address माँगें, और Didit का सार्वजनिक TRP होस्ट लाइव होने के बाद POST /trp/inquiries को कॉल करें।

अगले चरण

Travel Rule

ग्राहक-उन्मुख उत्पाद: लाइफ़साइकल, सेटिंग्स, रेल्स, और /v3/ API।

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

जब कोई वॉलेट स्व-होस्टेड होता है, तब लाभार्थी-पक्ष के स्वामित्व प्रमाण कैसे एकत्र किए जाते हैं।

सनराइज़ पंजीकरण

उन डिपॉज़िट के लिए Travel Rule डेटा पंजीकृत करना जो ऑन-चेन पहले ही सेटल हो चुके हैं।

webhook

Didit ग्राहक अपनी ओर से हर एक्सचेंज स्थिति परिवर्तन कैसे देखते हैं।

शुरुआत करें

सुविधाएँ

संदर्भ

कंसोल

Travel Rule इंटरऑपरेबिलिटी - Didit VASP से जुड़ें

Didit एक्सचेंज को कैसे रूट करता है

Travel Address

TRP endpoints

GET /identity

GET /trp/identity//

POST /trp/inquiries//

Didit द्वारा आपको भेजी गई इंक्वायरी का समाधान

ईमेल से पिकअप

सनराइज़: ऐसे ट्रांसफ़र जो विनिमय से पहले सेटल हो गए

Didit VASP डायरेक्टरी में शामिल होना

प्रतिपक्ष VASP के लिए चेकलिस्ट

अगले चरण

Travel Rule

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

सनराइज़ पंजीकरण

webhook

​Didit एक्सचेंज को कैसे रूट करता है

​Travel Address

​TRP endpoints

​GET /identity

​GET /trp/identity//

​POST /trp/inquiries//

​Didit द्वारा आपको भेजी गई इंक्वायरी का समाधान

​ईमेल से पिकअप

​सनराइज़: ऐसे ट्रांसफ़र जो विनिमय से पहले सेटल हो गए

​Didit VASP डायरेक्टरी में शामिल होना

​प्रतिपक्ष VASP के लिए चेकलिस्ट

​अगले चरण

Travel Rule

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

सनराइज़ पंजीकरण

webhook

Didit एक्सचेंज को कैसे रूट करता है

Travel Address

TRP endpoints

GET /identity

GET /trp/identity//

POST /trp/inquiries//

Didit द्वारा आपको भेजी गई इंक्वायरी का समाधान

ईमेल से पिकअप

सनराइज़: ऐसे ट्रांसफ़र जो विनिमय से पहले सेटल हो गए

Didit VASP डायरेक्टरी में शामिल होना

प्रतिपक्ष VASP के लिए चेकलिस्ट

अगले चरण