> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

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

> Didit का Travel Rule API: crypto VASP और PSP के लिए प्रेषक-लाभार्थी डेटा एक्सचेंज, प्रोटोकॉल ट्रैकिंग और ऑटो-रिमेडिएशन। प्रति एक्सचेंज $0.02।

Didit, FATF/EU Transfer of Funds Regulation (TFR) के तहत वर्चुअल एसेट ट्रांसफ़र के लिए प्रेषक-लाभार्थी आदान-प्रदान चलाता है। यह ऐसा चैनल खोजता है जो प्रतिपक्ष VASP तक पहुँचता हो, उसी चैनल पर आवश्यक डेटा को लेकर बातचीत करता है, 13 स्थितियों वाले जीवनचक्र के ज़रिए आदान-प्रदान पर नज़र रखता है, और जब आदान-प्रदान पूरा हो जाता है तो आपको बताता है, ताकि आप ऑन-चेन धनराशि जारी कर सकें।

## अवलोकन

FATF Travel Rule (Recommendation 16), जिसे EU में Transfer of Funds Regulation के रूप में लागू किया गया है, यह अनिवार्य करता है कि भेजने वाला Virtual Asset Service Provider (**प्रेषक VASP**) वर्चुअल एसेट ट्रांसफ़र के निपटान से पहले प्रेषक और लाभार्थी की जानकारी एकत्र करे और उसे प्राप्त करने वाले VASP (**लाभार्थी VASP**) को भेजे।

अधिकांश अधिकार-क्षेत्रों के विपरीत, EU TFR **किसी न्यूनतम राशि के बिना** लागू होता है। हर क्रिप्टो ट्रांसफ़र दायरे में है, केवल रिपोर्टिंग सीमा से ऊपर वाले ट्रांसफ़र ही नहीं।

Didit का Travel Rule उत्पाद केवल एक डेटा फ़ील्ड नहीं, बल्कि एक प्रबंधित विनिमय है:

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

इस रिलीज़ में सात मार्ग शामिल हैं, जो सख्त प्राथमिकता क्रम में आज़माए जाते हैं। जो मार्ग पहले प्रतिपक्ष तक पहुँच सके, वही चुना जाता है।

| प्राथमिकता | मार्ग | यह कैसे काम करता है |
| - | - | - |
| 1 | `INTERNAL` | तब उपयोग होता है जब किसी दूसरे Didit ग्राहक ने हस्ताक्षरित संदेश या टेस्ट डिपॉज़िट के माध्यम से लाभार्थी वॉलेट पर नियंत्रण साबित किया हो। Didit उस ग्राहक के एप्लिकेशन पर एक मेल खाता इनबाउंड ट्रांसफ़र बनाता है और विनिमय को पूरी तरह प्लेटफ़ॉर्म के भीतर तय करता है, बिना किसी आउटबाउंड नेटवर्क कॉल के। तुरंत। |
| 2 | `TRP` | खुले Travel Rule Protocol (TRP / OpenVASP) का नेटिव इंटीग्रेशन। तब उपयोग होता है जब ट्रांसफ़र में [Travel Address](#travel-address) हो, गंतव्य वॉलेट की एड्रेस-बुक प्रविष्टि में Travel Address संग्रहीत हो, या प्रतिपक्ष VASP [डायरेक्टरी](#डायरेक्टरी) में TRP एंडपॉइंट के साथ हल होता हो। यह [TRP एसेट पहचानकर्ता](#trp-एसेट-पहचानकर्ता) के अंतर्गत सूचीबद्ध एसेट ले जाता है। Didit प्रेषक और लाभार्थी का डेटा मशीन-से-मशीन आदान-प्रदान करता है, बिना ईमेल के चक्कर के। |
| 3 | `GTR` | Global Travel Rule (GTR) नेटवर्क। प्रतिपक्ष को स्पष्ट `counterparty_gtr_vasp_code` से या उस डायरेक्टरी प्रविष्टि से हल किया जाता है जिसमें वह कोड हो। Didit प्रतिपक्ष का उत्तर GTR के रिस्पॉन्स से पढ़ता है, या जब तक ट्रांसफ़र प्रतीक्षा में है, हर 5 मिनट पर अनुरोध की स्थिति की पोलिंग करके। |
| 4 | `TRUST` | TRUST नेटवर्क। प्रतिपक्ष को `counterparty_trust_membership_id` से या उस डायरेक्टरी प्रविष्टि से हल किया जाता है जिसमें वह हो। केवल-भेजने वाला मार्ग: TRUST कोई ऐसा उत्तर वापस नहीं भेजता जिसे Didit पढ़ सके, इसलिए ट्रांसफ़र की समय-सीमा समाप्त होने तक `AWAITING_COUNTERPARTY` में प्रतीक्षा करता है। |
| 5 | `VERIFYVASP` | VerifyVASP नेटवर्क। प्रतिपक्ष को `counterparty_verifyvasp_id` से या उस डायरेक्टरी प्रविष्टि से हल किया जाता है जिसमें वह हो। Didit सत्यापन की स्थिति हर 5 मिनट पर पोल करके प्रतिपक्ष का उत्तर पढ़ता है। |
| 6 | `SYGNA` | Sygna Bridge नेटवर्क (2026 में VerifyVASP ने इसे अधिग्रहित किया, और मौजूदा सदस्यों के लिए यह अब भी चालू है)। Sygna प्रोटोकॉल का नेटिव कार्यान्वयन: हस्ताक्षरित अनुमति अनुरोधों के साथ ECIES-एन्क्रिप्टेड IVMS101। प्रतिपक्ष को `counterparty_sygna_vasp_code` से या उस डायरेक्टरी प्रविष्टि से हल किया जाता है जिसमें वह हो। प्रतिपक्ष की स्वीकृति या अस्वीकृति का उत्तर ट्रांसफ़र को पूरा करता है या अस्वीकार करता है: Didit हर 5 मिनट पर ट्रांसफ़र की स्थिति पोल करता है, और Didit का सार्वजनिक TRP होस्ट चालू होने के बाद उसके Sygna कॉलबैक पर भी उत्तर लेता है। |
| 7 | `EMAIL` | वह फ़ॉलबैक जो तब उपयोग होता है जब कोई प्रोटोकॉल या नेटवर्क मार्ग प्रतिपक्ष तक नहीं पहुँचता और आप `counterparty_vasp_email` में उसका अनुपालन संपर्क बताते हैं, या प्रतिपक्ष की डायरेक्टरी प्रविष्टि में [अनुपालन संपर्क](#संपर्क) हो। Didit उस संपर्क को एक वन-टाइम पिकअप लिंक ईमेल करता है, ताकि वे Didit खाते के बिना विनिमय की पुष्टि या अस्वीकार कर सकें। यही सनराइज़ समस्या का मुख्य समाधान है, यानी ऐसे प्रतिपक्ष जो अभी किसी भी नेटवर्क पर पहुँच योग्य नहीं हैं। |

नेटवर्क मार्गों (`GTR`, `TRUST`, `VERIFYVASP`, `SYGNA`) के लिए भेजने वाली ओर नेटवर्क सदस्यता चाहिए, और आज यह सदस्यता **आपकी अपनी** होनी चाहिए।
कंसोल में **Marketplace** (Travel Rule networks श्रेणी) में अपने सदस्यता क्रेडेंशियल कनेक्ट करें, और आपके ट्रांसफ़र आपकी अपनी नेटवर्क पहचान के तहत जाएँगे।

**Didit के पास आज इन चारों में से किसी भी नेटवर्क की प्लेटफ़ॉर्म सदस्यता नहीं है, और वह इन सभी पर एक प्रदाता के रूप में ऑनबोर्ड हो रहा है।**
जब तक यह ऑनबोर्डिंग पूरी नहीं होती, चारों के लिए `platform_available` `false` है, सेटिंग्स का `didit` मोड (Didit की प्लेटफ़ॉर्म सदस्यता के माध्यम से रूटिंग) किसी भी नेटवर्क के लिए उपलब्ध नहीं है, और `disabled_networks` में बंद करने के लिए कुछ नहीं है।
आपकी अपनी जोड़ी गई सदस्यता हमेशा प्लेटफ़ॉर्म सदस्यता से पहले लागू होती है।
डिफ़ॉल्ट रूप से कोई भी नेटवर्क सदस्यता शामिल नहीं होती, GTR भी नहीं।
Travel Rule चालू करने से GTR, TRUST, VerifyVASP या Sygna सक्रिय नहीं होते।
अपने एप्लिकेशन के प्रभावी `networks` मोड देखने के लिए [Travel Rule सेटिंग्स प्राप्त करें](https://docs.didit.me/hi/management-api/travel-rule/get-settings.md) जाँचें, और आज हर नेटवर्क किन तक पहुँचता है, यह जानने के लिए [Travel Rule नेटवर्क](https://docs.didit.me/hi/transaction-monitoring/travel-rule-networks.md) जाँचें।
यदि चारों `unavailable` दिखाते हैं, तो कोई भी विनिमय रूट नहीं कर सकता: **Marketplace** में अपनी सदस्यता जोड़ें, या किसी पहुँच योग्य `INTERNAL`, `TRP` या `EMAIL` प्रतिपक्ष का उपयोग करें।

जब आप सदस्यता सहेजते हैं, तो उसका प्रतिभागी कोड आपका अपना होना चाहिए: यदि कोड उस नेटवर्क पर Didit का अपना कोड है, या किसी दूसरे एप्लिकेशन की सदस्यता में वह कोड पहले से मौजूद है, तो सहेजने पर `400` लौटता है।
GTR सदस्यता को अपनी ed25519 निजी कुंजी (base64) चाहिए, वह कुंजी जिसकी सार्वजनिक कुंजी GTR के पोर्टल में पंजीकृत है। यह आपके भेजे गए व्यक्तिगत डेटा को एन्क्रिप्ट करती है और आपको मिले डेटा को डिक्रिप्ट करती है।
VerifyVASP सदस्यता आपके अपने VerifyVASP Enclave की ओर इंगित करती है: उसका URL आपके Enclave का है, और उसका token वह है जो आपका Enclave Didit को प्रस्तुत करता है।

आपकी अपनी सदस्यता होने पर भी, कोई नेटवर्क मार्ग ट्रांसफ़र को तभी रूट करता है जब उसके `beneficiary_data` में उस नेटवर्क पर प्रतिपक्ष का id हो (`counterparty_gtr_vasp_code`, `counterparty_trust_membership_id`, `counterparty_verifyvasp_id`, या `counterparty_sygna_vasp_code`), या प्रतिपक्ष की डायरेक्टरी प्रविष्टि में वह उस नेटवर्क पर सूचीबद्ध हो (देखें [रूट](#रूट))।

`platform_available` यह बताता है कि प्लेटफ़ॉर्म सदस्यता कॉन्फ़िगर है या नहीं, यह लाइव नेटवर्क हेल्थ चेक नहीं है। इसी तरह, `connected` का अर्थ है कि आपके सदस्यता क्रेडेंशियल सहेजे गए हैं और स्थानीय सत्यापन पास कर चुके हैं। पहला लाइव विनिमय उन्हें नेटवर्क के विरुद्ध सत्यापित करता है। `didit` या `own` मोड प्रतिपक्ष की पहुँच या सफल डिलीवरी की गारंटी नहीं देता।

जब आपकी अपनी मेंबरशिप होती है, तब Didit `GTR`, `VERIFYVASP` और `SYGNA` पर प्रतिपक्ष का जवाब नेटवर्क के रिस्पॉन्स से पढ़ता है, या हर 5 मिनट में नेटवर्क से पूछताछ (polling) करके यह देखता है। इसी से स्थानांतरण पूरा होता है या अस्वीकृत हो जाता है।
`TRUST` केवल भेजने के लिए है। इसके ज़रिए भेजा गया स्थानांतरण `confirmation_timeout_hours` बीतने तक `AWAITING_COUNTERPARTY` में रहता है, फिर `EXPIRED` में चला जाता है और आपका `timeout_outcome` लागू होता है।
किसी अन्य VASP द्वारा नेटवर्क के ज़रिए आपको भेजे गए स्थानांतरण को प्राप्त करना अभी चालू नहीं है, और किसी भी लाइव नेटवर्क पर अभी तक किसी नेटवर्क एक्सचेंज को पूरा नहीं किया गया है। देखें [Travel Rule नेटवर्क](https://docs.didit.me/hi/transaction-monitoring/travel-rule-networks.md)।

CODE (कोरियाई गठबंधन), TRISA, Notabene और Veriscope जैसे अन्य नेटवर्क कंसोल के **Marketplace** में एक्सेस-अनुरोध टाइल्स के रूप में सूचीबद्ध हैं।
Didit का इन नेटवर्कों के साथ अभी तक कोई इंटीग्रेशन नहीं है, इसलिए आज कोई भी स्थानांतरण इनके ज़रिए रूट नहीं हो सकता।

जब सातों रास्तों में से कोई भी प्रतिपक्ष का समाधान नहीं कर पाता, तब Didit हार मानने से पहले एक और चरण चलाता है: ब्लॉकचेन एनालिटिक्स एट्रिब्यूशन।
गंतव्य वॉलेट को ब्लॉकचेन एनालिटिक्स डेटा के साथ मिलाकर देखा जाता है। जब वॉलेट किसी ज्ञात एक्सचेंज या कस्टोडियन का निकलता है, तब Didit स्थानांतरण पर पहचाने गए VASP को दर्ज करता है, उसे [डायरेक्टरी](#डायरेक्टरी) में जोड़ता है, और नए नाम के साथ रास्तों को एक बार फिर चलाता है।
पूरे व्यवहार और मूल्य निर्धारण के लिए देखें [ब्लॉकचेन एनालिटिक्स एट्रिब्यूशन](#ब्लॉकचेन-एनालिटिक्स-एट्रिब्यूशन)।

जिस स्थानांतरण का गंतव्य [स्व-होस्टेड वॉलेट](#घोषित-स्व-होस्टेड-वॉलेट) के रूप में घोषित है, वह सातों रास्तों को छोड़ देता है, क्योंकि वहाँ आदान-प्रदान के लिए कोई प्रतिपक्ष VASP नहीं होता। ऐसा स्थानांतरण सीधे अंतिम उपयोगकर्ता के वॉलेट के स्वामित्व के प्रमाण पर जाता है।

> [!NOTE]
>
> Didit प्रतिपक्ष की ओर वाले आदान-प्रदान का हिस्सा भी संचालित करता है: सार्वजनिक TRP पहचान और पूछताछ endpoint, जिन पर अन्य VASP आपसे संपर्क करने के लिए कॉल करते हैं, कॉलबैक endpoint, और ईमेल पिकअप फ़्लो। इन्हें आप स्वयं कभी कॉल नहीं करते, क्योंकि ये प्रबंधित इंफ़्रास्ट्रक्चर हैं। फिर भी [Travel Rule इंटरऑपरेबिलिटी](https://docs.didit.me/hi/transaction-monitoring/travel-rule-interoperability.md) पेज इनमें से हर एक का दस्तावेज़ीकरण करता है, ताकि प्रतिपक्ष VASP आपसे जुड़ सकें।
> आप Travel Rule के साथ केवल इस पेज पर वर्णित `/v3/` endpoints के ज़रिए इंटरैक्ट करते हैं।

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

जाँचें एक ही `POST /v3/transactions/` कॉल के भीतर चलती हैं। जब तक आपको रिस्पॉन्स मिलता है, तब तक स्क्रीनिंग चल चुकी होती है, ट्रांसफ़र सहेजा जा चुका होता है, और नियमों का मूल्यांकन हो चुका होता है।
एक्सचेंज स्वयं रिस्पॉन्स के बाद शुरू होता है। Didit रेल चुनता है और आपके अनुरोध के बाहर प्रतिपक्ष से संपर्क करता है, इसलिए कोई नेटवर्क या प्रतिपक्ष इसे बनाने के अनुरोध को धीमा या विफल नहीं कर सकता।
इसके बाद हर स्थिति परिवर्तन एक [`travel_rule.status.updated`](#वेबहुक) webhook के रूप में आता है, जिसमें रेल का नाम होता है। Travel Rule ट्रांसफ़र endpoints द्वारा लौटाए गए ट्रांसफ़र ऑब्जेक्ट में एक [`delivery`](#डिलीवरी-और-पुनः-प्रयास) फ़ील्ड होता है, जो दिखाता है कि संदेश पहुँचा या नहीं।
पोल करने के लिए कोई पाइपलाइन नहीं है। असिंक्रोनस हिस्से एक्सचेंज, प्रतिपक्ष का जवाब और किसी भी अंतिम उपयोगकर्ता की कार्रवाई तक सीमित हैं।

```mermaid theme={null}
sequenceDiagram
    autonumber
    participant You as Your platform
    participant Didit as Didit API
    participant CP as Counterparty VASP
    participant User as Your customer

    You->>Didit: POST /v3/transactions/ (travelRule)
    Note over Didit: Validate + bind subject + blocklist check
    Note over Didit: Device & IP enrichment
    Note over Didit: Crypto screening (when crypto + monitoring on)
    Note over Didit: Threshold check -> transfer stored (AWAITING_COUNTERPARTY)
    Note over Didit: Rules engine (EU TFR bundle + your rules)
    Didit--)You: transaction.created webhook
    Didit-->>You: Transaction + travel_rule.status + action_required
    Note over Didit: After the response: rails in priority order -> analytics attribution
    Didit->>CP: Exchange over the first reachable rail
    Didit--)You: travel_rule.status.updated (each status change)
    User->>Didit: Proves wallet control (when action_required)
    CP-->>Didit: Confirms beneficiary data
    Didit--)You: travel_rule.status.updated (COMPLETED)
    You->>You: Broadcast on-chain
    You->>Didit: PATCH .../travel-rule/ { payment_txn_id }
    Didit--)You: travel_rule.status.updated (FINISHED)
```

चरण-दर-चरण:

1. **मान्यकरण और subject बाइंडिंग।** payload का मान्यकरण होता है।
   `transaction_id` जो आपके एप्लिकेशन में पहले से उपयोग हो चुका है, उसे `400` के साथ अस्वीकार किया जाता है। जब दो अनुरोध एक ही id के साथ टकराते हैं, तो उनमें से एक को `409` मिलता है।
   `subject` को `vendor_data` के ज़रिए आपके उपयोगकर्ता या व्यवसाय प्रोफ़ाइल से जोड़ा जाता है, ताकि ट्रांसफ़र मॉनिटरिंग के लिए उस प्रोफ़ाइल पर दिखे।
   ब्लॉकलिस्ट किए गए subject या प्रतिपक्ष `vendor_data` को `400` के साथ अस्वीकार किया जाता है, और कोई लेन-देन नहीं बनता।
   ब्लॉकलिस्ट किए गए वॉलेट, बैंक खाते, IP और डिवाइस चरण 6 में जाँचे जाते हैं। वहाँ रूटिंग चलने के बाद वे लेन-देन को अस्वीकार करते हैं।
2. **डिवाइस और नेटवर्क एन्रिचमेंट।** पक्षों के IP को भू-स्थानिक जानकारी से समृद्ध किया जाता है। कोई भी डिवाइस संदर्भ ([SDK सबमिशन](https://docs.didit.me/hi/transaction-monitoring/sdk-transaction-submission.md) पर स्वचालित) डिवाइस ग्राफ़ में सामान्य किया जाता है। यह वही ग्राफ़ है जिसमें KYC सत्र डेटा डालते हैं, इसलिए "डिवाइस के आधार पर संबंधित" ऑनबोर्डिंग और लेन-देन दोनों में काम करता है।
3. **क्रिप्टो स्क्रीनिंग।** मॉनिटरिंग चालू होने पर क्रिप्टो ट्रांसफ़र के लिए संबंधित वॉलेट (या ऑन-चेन हैश) को किसी भी एक्सचेंज से पहले ब्लॉकचेन एनालिटिक्स के विरुद्ध स्क्रीन किया जाता है। इसमें प्रतिबंधों के संपर्क में आने का जोखिम, मिक्सर से निकटता और चोरी किए गए फ़ंड की जाँच की जाती है। देखें [क्रिप्टो और वॉलेट स्क्रीनिंग](https://docs.didit.me/hi/transaction-monitoring/aml-screening.md)।
4. **Travel Rule ट्रांसफ़र।** एक्सचेंज इंजन थ्रेशोल्ड की जाँच करता है और [स्व-होस्टेड वॉलेट घोषणा](#घोषित-स्व-होस्टेड-वॉलेट) का सम्मान करता है। फिर ट्रांसफ़र सहेजता है: आपके थ्रेशोल्ड से नीचे `NOT_APPLICABLE`, घोषित स्व-होस्टेड वॉलेट के लिए `UNCONFIRMED_OWNERSHIP`, जब दूसरा वॉलेट आपका अपना सत्यापित वॉलेट हो तो `COMPLETED`, और बाकी मामलों में `AWAITING_COUNTERPARTY`, जिसकी रेल अभी खाली होती है।
   हर स्थिति परिवर्तन एक `travel_rule.status.updated` इवेंट कतार में डालता है, और Didit इसे लेन-देन के `transaction.created` (चरण 7) के बाद भेजता है।
5. **वॉलेट-स्वामित्व मिंटिंग।** अगर ट्रांसफ़र के लिए अंतिम उपयोगकर्ता के नियंत्रण का प्रमाण चाहिए और `auto_wallet_verification` चालू है, तो [वॉलेट-स्वामित्व विजेट](https://docs.didit.me/hi/transaction-monitoring/wallet-ownership-widget.md) सत्र बनाया जाता है और `action_required` में लौटाया जाता है।
6. **नियमों का मूल्यांकन।** हर सक्रिय नियम चलता है। [EU TFR बंडल](#eu-tfr-नियम-बंडल) चरण 4 में सेट किए गए ट्रांसफ़र स्थिति पर प्रतिक्रिया देता है, आपके कस्टम नियम चरण 3 के स्क्रीनिंग आउटपुट को देखते हैं, और कोई नियम लेन-देन को रोक सकता है (`IN_REVIEW`), उसे अस्वीकार कर सकता है, या [अतिरिक्त सत्यापन](https://docs.didit.me/hi/transaction-monitoring/sdk-transaction-submission.md#आवश्यक-उपयोगकर्ता-क्रियाएँ) माँग सकता है (`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](https://docs.didit.me/hi/management-api/transactions/get.md) के साथ पढ़ें।

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

| पाइपलाइन चरण | यह जिस ज़िम्मेदारी को पूरा करता है |
| - | - |
| आप `originator_data` में जो प्रेषक डेटा देते हैं | सटीक प्रेषक जानकारी (FATF R.16; EU TFR Art. 14)। जिन रेलों पर व्यक्ति का डेटा जाता है (`INTERNAL`, `TRP` और नेटवर्क रेलें), वहाँ जब subject एक ऐसा उपयोगकर्ता हो जिसके पास स्वीकृत Didit KYC सत्यापन है, तो Didit सत्यापित पहचान भेजता है (देखें [सत्यापित डेटा और उत्पत्ति](#सत्यापित-डेटा-और-स्रोत))। बाकी मामलों में ठीक वही `originator_data` भेजा जाता है जो आप भेजते हैं। |
| निपटान से पहले रेलों का एक्सचेंज | प्रेषक और लाभार्थी की जानकारी ट्रांसफ़र निपटने **से पहले** प्रतिपक्ष VASP को भेजी जाती है (FATF R.16; EU TFR Art. 14-16) |
| लाभार्थी नाम मिलान | इस बात का सत्यापन कि लाभार्थी डेटा गंतव्य से मेल खाता है (लाभार्थी CASP की EU TFR Art. 16 ज़िम्मेदारियाँ) |
| स्व-होस्टेड वॉलेट स्वामित्व प्रमाण | EU TFR की स्व-होस्टेड वॉलेट ज़िम्मेदारी: VASP के साथ एक्सचेंज करने के बजाय किसी अनहोस्टेड पते के स्वामित्व की पुष्टि करना |
| क्रिप्टो स्क्रीनिंग + EU TFR नियम बंडल | अधूरी या गायब जानकारी वाले ट्रांसफ़र के लिए जोखिम-आधारित प्रक्रियाएँ, और प्रतिबंधों के संपर्क में आने के जोखिम पर नियंत्रण |
| ब्रॉडकास्ट से पहले `COMPLETED` गेट | एक्सचेंज पूरा होने तक फ़ंड जारी नहीं होते। यही नियम का मूल है |
| ऑन-चेन हैश और टाइमलाइन के साथ `FINISHED` समापन | रिकॉर्डकीपिंग: हर ट्रांसफ़र अपनी पूरी बातचीत की टाइमलाइन ऑडिट के लिए रखता है |

> [!NOTE]
>
> **परीक्षण नोट।** सैंडबॉक्स एप्लिकेशन नियमों का मूल्यांकन और बिलिंग नहीं करते, और `transaction.created` या `transaction.status.updated` webhooks नहीं भेजते। सैंडबॉक्स लेन-देन `APPROVED` रहते हैं, जब तक कोई समाप्त होने वाला Travel Rule ट्रांसफ़र आपका `timeout_outcome` लागू न करे, और कुछ भी शुल्क नहीं लिया जाता।
> जब Travel Rule चालू हो, तो Travel Rule एक्सचेंज इंजन सैंडबॉक्स एप्लिकेशन पर भी चलता है, लेकिन केवल एक प्रतिपक्ष के साथ। हर **आउटबाउंड** एक्सचेंज `TEST_VASP` रेल पर [Didit Test VASP](https://docs.didit.me/hi/transaction-monitoring/travel-rule-sandbox.md) के पास जाता है, जो Didit के भीतर आपके चुने हुए परिदृश्य के साथ जवाब देता है। इसलिए ट्रांसफ़र पूरा हो सकता है, अस्वीकार हो सकता है, मेल न खा सकता है, पहुँच से बाहर हो सकता है, समाप्त हो सकता है, या वॉलेट स्वामित्व की प्रतीक्षा कर सकता है।
> कोई भी अनुपालन संदेश कभी किसी वास्तविक प्रतिपक्ष VASP तक नहीं पहुँचता, और `travel_rule.status.updated` webhooks `environment: sandbox` के साथ भेजे जाते हैं।
> **इनबाउंड** में, टेस्ट VASP आपको ट्रांसफ़र भेज सकता है ([Trigger Test VASP Inbound Transfer](https://docs.didit.me/hi/management-api/travel-rule/trigger-test-vasp-inbound.md)), और रजिस्ट्रेशन (`POST /v3/travel-rule/inbound/`) आपकी वॉलेट एड्रेस बुक के विरुद्ध वैसे ही निपटता है जैसे लाइव एप्लिकेशन पर। परिणाम हो सकते हैं `ON_HOLD`, `UNCONFIRMED_OWNERSHIP`, `COUNTERPARTY_MISMATCHED_DATA`, या `COMPLETED` और फिर `FINISHED`।
> देखें [सैंडबॉक्स में Travel Rule का परीक्षण](https://docs.didit.me/hi/transaction-monitoring/travel-rule-sandbox.md)।

## जीवनचक्र

हर ट्रांसफ़र की एक `status` होती है, जो 13 मानों में से कोई एक हो सकती है।
एक्सचेंज सामान्य स्थिति में `AWAITING_COUNTERPARTY` से शुरू होता है। यदि राशि आपकी `threshold_amount` से कम हो, या कोई Lightning पेमेंट अनुरोध किसी भुगतान-प्राप्तकर्ता का नाम न बताए (देखें [Lightning](#lightning)), तो यह `NOT_APPLICABLE` से शुरू होता है। यदि गंतव्य वॉलेट को [स्व-होस्टेड वॉलेट घोषित किया गया](#घोषित-स्व-होस्टेड-वॉलेट) है, तो यह `UNCONFIRMED_OWNERSHIP` से शुरू होता है। यह इन अंतिम स्थितियों में से किसी एक पर समाप्त होता है: `FINISHED`, `CANCELLED`, या `EXPIRED`।

ट्रांसफ़र की अपनी स्टेट मशीन चलती है, जो अंतर्निहित लेन-देन की समीक्षा स्थिति से **अलग** है।
एक्सचेंज की स्थिति अपने आप लेन-देन की स्थिति कभी नहीं बदलती, केवल एक अपवाद के साथ: समय-सीमा समाप्त होने पर आपका कॉन्फ़िगर किया गया `timeout_outcome` लागू होता है (या जब लागू हो, तो [सनराइज़ या गैर-प्रतिक्रियाशील नीति](#सनराइज़-और-गैर-प्रतिक्रियाशील-नीतियाँ))।
इसके बजाय आपके नियम हर ट्रांज़िशन पर फिर से चलते हैं, इसलिए [EU TFR नियम](#eu-tfr-नियम-बंडल) या `travel_rule_status` पर आधारित कोई भी नियम लेन-देन को आगे बढ़ा सकता है, जैसे उसे `IN_REVIEW` में ले जाना।
जिस ट्रांसफ़र को अंतिम उपयोगकर्ता के वॉलेट-नियंत्रण के प्रमाण की ज़रूरत हो, वह लेन-देन में `action_required` ब्लॉक जोड़ता है, लेकिन उसकी `status` वही रहती है जैसी आपके नियमों ने छोड़ी थी।
एक्सचेंज की स्थिति `travel_rule.status` से पढ़ें, और अनुमति / रोक / अस्वीकृति का निर्णय लेन-देन की अपनी `status` से पढ़ें।

हर ट्रांज़िशन (और हर निष्क्रिय रूप से रिपोर्ट की गई स्थिति) लेन-देन के कस्टम वैल्यू पर भी दर्ज होती है, ताकि [नियम](https://docs.didit.me/hi/transaction-monitoring/rules.md) उस पर आधारित हो सकें: `custom_values.travel_rule_status` (मानक स्थिति), `custom_values.travel_rule_rail` (वह रेल जिसने एक्सचेंज चलाया; कोई रेल चुने जाने तक खाली), और `custom_values.travel_rule_regime` (आपकी [सेटिंग्स](#सेटअप) के `jurisdiction` से निकला: `SG` → `singapore`, `GB` → `uk`, और कोई भी EU या EEA सदस्य कोड, जैसे `DE` या `FR` → `eu`; जो कोड मैप नहीं है, वह छोटे अक्षरों में सेट होता है, जैसे `US` → `us`। आप स्वयं जो `props.travel_rule_regime` सबमिट करते हैं, वह हमेशा निकाले गए मान पर भारी पड़ता है)।

| स्थिति | अर्थ |
| - | - |
| `AWAITING_COUNTERPARTY` | ट्रांसफ़र काउंटरपार्टी का इंतज़ार करता है: पहले तब तक, जब Didit रेल चुनकर एक्सचेंज भेजता है, जो बनाए जाने के ठीक बाद होता है, और फिर तब तक, जब काउंटरपार्टी जवाब देती है। ट्रांसफ़र की [`delivery`](#डिलीवरी-और-पुनः-प्रयास) बताती है कि संदेश पहुँचा या नहीं। `TRUST` केवल भेजता है, इसलिए उसके ज़रिए जाने वाला ट्रांसफ़र समय-सीमा समाप्त होने तक इसी स्थिति में रहता है। |
| `UNCONFIRMED_OWNERSHIP` | ट्रांसफ़र वॉलेट-नियंत्रण के प्रमाण का इंतज़ार कर रहा है। यह तब होता है जब सबमिशन के समय काउंटरपार्टी वॉलेट को [स्व-होस्टेड घोषित](#घोषित-स्व-होस्टेड-वॉलेट) किया गया हो (आउटबाउंड या इनबाउंड), या जब कोई इनबाउंड ट्रांसफ़र ऐसी [एड्रेस बुक एंट्री](#वॉलेट-पता-पुस्तिका) से मेल खाए जिसका स्वामित्व अभी सत्यापित नहीं है। यह [वॉलेट-स्वामित्व विजेट](https://docs.didit.me/hi/transaction-monitoring/wallet-ownership-widget.md) या [`POST .../travel-rule/ownership/`](#स्वामित्व-की-पुष्टि-करना) से आगे बढ़ता है। |
| `ON_HOLD` | Didit इसे केवल इनबाउंड ट्रांसफ़र पर सेट करता है: [जमा-पश्चात पंजीकरण](#डिपॉज़िट-के-बाद-सनराइज़-पंजीकरण) का गंतव्य वॉलेट, या इनबाउंड `TRP` पूछताछ का वॉलेट, आपकी [एड्रेस बुक](#वॉलेट-पता-पुस्तिका) में नहीं है; या इनबाउंड `TRP` पूछताछ आपके निर्णय का इंतज़ार कर रही है (ऑटो-स्वीकृति बंद है, या स्वचालित उत्तर भेजा नहीं जा सका)। इसे [`POST .../travel-rule/ownership/`](#स्वामित्व-की-पुष्टि-करना) से हल करें। यह अपने आप लेन-देन की स्थिति नहीं बदलता; वैकल्पिक `travel-rule-pending-action` [लाइब्रेरी नियम](https://docs.didit.me/hi/transaction-monitoring/rules-library.md), जिसे आप चालू कर सकते हैं, ऐसे लेन-देनों को `AWAITING_USER` में ले जाता है। |
| `COMPLETED` | एक्सचेंज सफलतापूर्वक पूरा हुआ: काउंटरपार्टी ने (या इनबाउंड ट्रांसफ़र पर आपने) इसे स्वीकृत किया, या उस पथ पर Didit द्वारा चलाई गई जाँचें पास हुईं (लाभार्थी नाम मिलान, वॉलेट स्वामित्व प्रमाण)। अब ट्रांसफ़र को ऑन-चेन प्रसारित करना सुरक्षित है। |
| `FINISHED` | एक्सचेंज अपने ऑन-चेन लेन-देन हैश के साथ बंद हो जाता है। आउटबाउंड ट्रांसफ़र पर, आप हैश [`PATCH .../travel-rule/`](#ट्रांसफ़र-भेजना) से रिपोर्ट करते हैं। इनबाउंड ट्रांसफ़र पर, Didit इसे तब सेट करता है जब जमा पहले ही सेटल हो चुका हो ([जमा-पश्चात पंजीकरण](#डिपॉज़िट-के-बाद-सनराइज़-पंजीकरण)), जब प्रेषक `TRP` ट्रांसफ़र की पुष्टि करे, या जब `INTERNAL` आउटबाउंड पक्ष पूरा हो जाए। |
| `CANCELLED` | किसी भी गैर-अंतिम स्थिति से `action: "cancel"` के साथ मैन्युअली रद्द किया गया, या इनबाउंड `TRP` ट्रांसफ़र के प्रेषक द्वारा रद्द किया गया। |
| `EXPIRED` | `confirmation_timeout_hours` बीत गए, जबकि ट्रांसफ़र `AWAITING_COUNTERPARTY` में था। एक स्वीपर (हर 15 मिनट पर) ट्रांसफ़र को समाप्त करता है और लेन-देन पर आपका कॉन्फ़िगर किया गया `timeout_outcome` लागू करता है: `REJECT` उसे अस्वीकार करता है, `HOLD` उसे समीक्षा में ले जाता है, `PROCEED` उसे अछूता छोड़ता है। जब लागू हो, तो आपकी [सनराइज़ या गैर-प्रतिक्रियाशील नीति](#सनराइज़-और-गैर-प्रतिक्रियाशील-नीतियाँ) `timeout_outcome` की जगह ले लेती है। |
| `COUNTERPARTY_MISMATCHED_DATA` | लाभार्थी का नाम दूसरे पक्ष के मुकाबले कॉन्फ़िगर किए गए `name_matching_strictness` को पूरा नहीं करता: वह नाम जो काउंटरपार्टी ने लौटाया, या मिलान करने वाली एड्रेस बुक एंट्री का `holder_name`। |
| `COUNTERPARTY_VASP_NOT_FOUND` | सातों रेलों में से कोई भी इस ट्रांसफ़र के लिए पहुँच योग्य काउंटरपार्टी VASP नहीं ढूँढ सकी, और [ब्लॉकचेन एनालिटिक्स एट्रिब्यूशन](#ब्लॉकचेन-एनालिटिक्स-एट्रिब्यूशन) फ़ॉलबैक भी ऐसा नहीं कर सका। कोई भी एट्रिब्यूट की गई इकाई फिर भी ट्रांसफ़र और डायरेक्टरी में दर्ज होती है। आउटबाउंड ट्रांसफ़र पर, Didit (जब `auto_wallet_verification` चालू हो) स्वतः एक [वॉलेट-स्वामित्व विजेट](https://docs.didit.me/hi/transaction-monitoring/wallet-ownership-widget.md) सत्र बनाता है, ताकि ट्रांसफ़र स्व-होस्टेड-वॉलेट ट्रांसफ़र के रूप में फिर भी पूरा हो सके। `reason` और `next_actions` बताते हैं कि ऐसा क्यों हुआ और इसे आगे बढ़ाने के लिए क्या करना है: देखें [ट्रांसफ़र क्यों अटका है](#ट्रांसफ़र-क्यों-अटका-है)। |
| `COUNTERPARTY_VASP_NOT_REACHABLE` | काउंटरपार्टी VASP की पहचान हुई, पर चुनी गई रेल उसे पहुँचा नहीं सकी: उसकी `TRP` पहचान या पूछताछ endpoint से संपर्क नहीं हो सका, उसने जो पहचान बताई वह `counterparty_vasp_lei` या `counterparty_vasp_name` से मेल नहीं खाई, नेटवर्क ने संदेश ठुकराया या छह प्रयासों के बाद भी स्वीकार नहीं किया (देखें [डिलीवरी और पुनः प्रयास](#डिलीवरी-और-पुनः-प्रयास)), या मेल प्रदाता ने अनुपालन ईमेल ठुकरा दिया। `reason` इन्हें अलग-अलग बताता है और `next_actions` बताता है कि ट्रांसफ़र को कैसे आगे बढ़ाया जाए: देखें [ट्रांसफ़र क्यों अटका है](#ट्रांसफ़र-क्यों-अटका-है)। पुनः पहुँच योग्य होने पर `action: "resend"` के साथ पुनः प्रयास करें। |
| `COUNTERPARTY_VASP_GENERAL_DECLINE` | काउंटरपार्टी ने एक्सचेंज अस्वीकार किया: स्वामित्व से इनकार, ईमेल ग्रहण से इनकार, या `TRP` या Sygna अस्वीकृति। |
| `NOT_ENOUGH_COUNTERPARTY_DATA` | इनबाउंड `TRP` पूछताछ ने लाभार्थी की पहचान न नाम से की, न वॉलेट पते से, इसलिए Didit उसे आपकी एड्रेस बुक से मिला नहीं सका। न स्वामित्व endpoint और न `resend` ऐसे इनबाउंड ट्रांसफ़र को स्वीकार करते हैं: आप केवल उसे रद्द कर सकते हैं, और रद्द करने से काउंटरपार्टी की पूछताछ का उत्तर नहीं मिलता। Didit आउटबाउंड ट्रांसफ़र पर इसे कभी सेट नहीं करता; यदि आप किसी आउटबाउंड ट्रांसफ़र पर इसे स्वयं दर्ज करते हैं, तो `action: "resend"` रूटिंग फिर से चलाता है। |
| `NOT_APPLICABLE` | ट्रांसफ़र की राशि कॉन्फ़िगर की गई `threshold_amount` से कम थी, कोई आउटबाउंड [Lightning](#lightning) भुगतान अनुरोध किसी प्राप्तकर्ता का नाम नहीं देता (`chain_details.not_applicable_reason` कारण बताता है), या आपने Travel Rule बंद होने पर यह स्थिति स्वयं दर्ज की (पुराने `UNKNOWN` और `EXEMPT` मानों सहित, नीचे देखें)। |

> [!WARNING]
>
> **`COMPLETED` से पहले कभी ब्रॉडकास्ट न करें।**
> जब कोई ट्रांसफ़र `AWAITING_COUNTERPARTY`, `UNCONFIRMED_OWNERSHIP` में हो, या किसी मिलान न होने या अस्वीकृति की स्थिति में हो, तब ऑन-चेन फ़ंड जारी करना इस आदान-प्रदान के उद्देश्य को विफल कर देता है।
> ब्रॉडकास्ट चरण को `status == "COMPLETED"` पर सीमित करें, फिर परिणामी `payment_txn_id` के साथ `PATCH .../travel-rule/` कॉल करें ताकि स्थिति `FINISHED` पर जाए।

स्थिति-परिवर्तन एक नज़र में (`CANCELLED` हर गैर-अंतिम स्थिति से `action: "cancel"` के साथ अतिरिक्त रूप से पहुँचा जा सकता है):

```mermaid theme={null}
stateDiagram-v2
    [*] --> NOT_APPLICABLE: below threshold
    [*] --> UNCONFIRMED_OWNERSHIP: self-hosted wallet declared
    [*] --> AWAITING_COUNTERPARTY: transfer stored, routing queued
    [*] --> COMPLETED: your own verified wallet
    [*] --> ON_HOLD: inbound with no matching wallet entry
    [*] --> NOT_ENOUGH_COUNTERPARTY_DATA: inbound TRP inquiry names no beneficiary
    AWAITING_COUNTERPARTY --> COUNTERPARTY_MISMATCHED_DATA: INTERNAL rail, verified entry, name mismatch
    AWAITING_COUNTERPARTY --> COUNTERPARTY_VASP_NOT_FOUND: no rail resolved
    AWAITING_COUNTERPARTY --> COUNTERPARTY_VASP_NOT_REACHABLE: delivery failed
    AWAITING_COUNTERPARTY --> COMPLETED: counterparty confirmed, names match where checked
    AWAITING_COUNTERPARTY --> COUNTERPARTY_MISMATCHED_DATA: name match failed
    AWAITING_COUNTERPARTY --> COUNTERPARTY_VASP_GENERAL_DECLINE: counterparty declined
    AWAITING_COUNTERPARTY --> EXPIRED: confirmation timeout
    AWAITING_COUNTERPARTY --> COUNTERPARTY_VASP_NOT_REACHABLE: TRP inquiry not delivered
    UNCONFIRMED_OWNERSHIP --> COMPLETED: ownership proven, names match
    UNCONFIRMED_OWNERSHIP --> COUNTERPARTY_MISMATCHED_DATA: name match failed
    UNCONFIRMED_OWNERSHIP --> COUNTERPARTY_VASP_GENERAL_DECLINE: ownership denied
    ON_HOLD --> COMPLETED: you confirm the wallet, names match
    ON_HOLD --> COUNTERPARTY_MISMATCHED_DATA: you confirm the wallet, name mismatch
    ON_HOLD --> COUNTERPARTY_VASP_GENERAL_DECLINE: you deny the wallet
    COUNTERPARTY_MISMATCHED_DATA --> COMPLETED: you approve an inbound TRP inquiry
    COUNTERPARTY_MISMATCHED_DATA --> COUNTERPARTY_VASP_GENERAL_DECLINE: you decline an inbound TRP inquiry
    COUNTERPARTY_VASP_NOT_FOUND --> COMPLETED: wallet ownership proven in the widget
    COUNTERPARTY_VASP_NOT_FOUND --> AWAITING_COUNTERPARTY: action resend
    COUNTERPARTY_VASP_NOT_REACHABLE --> AWAITING_COUNTERPARTY: action resend
    COMPLETED --> FINISHED: payment_txn_id reported or deposit already settled
    FINISHED --> [*]
    EXPIRED --> [*]
```

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

Didit, ट्रांसफ़र के लिए देय हर संदेश को उस अनुरोध से बाहर भेजता है जिसने उसे उत्पन्न किया, और जब तक दूसरा पक्ष उसे प्राप्त न कर ले, तब तक उसका पुनः प्रयास करता है।
[समाप्त करें, रद्द करें या पुनः भेजें](https://docs.didit.me/hi/management-api/travel-rule/update-transfer.md), [स्वामित्व की पुष्टि करें](https://docs.didit.me/hi/management-api/travel-rule/confirm-ownership.md) और [sunrise पंजीकरण](#डिपॉज़िट-के-बाद-सनराइज़-पंजीकरण) से लौटाए गए ट्रांसफ़र ऑब्जेक्ट में नवीनतम संदेश `delivery` में होता है, और लेन-देन के अंतर्निहित `travel_rule` ऑब्जेक्ट में भी यही होता है; जब ट्रांसफ़र के लिए कोई संदेश कभी देय नहीं था, तब यह `null` होता है।

| फ़ील्ड | अर्थ |
| - | - |
| `kind` | `SEND` (प्रतिपक्ष को पहला संदेश), `ANSWER` (आपकी स्वीकृति या अस्वीकृति, उस नेटवर्क को देय जिसने पूछा था), `TXID` (ऑन-चेन हैश, ट्रांसफ़र पूरा करने के बाद), `CANCEL` (आपके इसे रद्द करने के बाद), या `POLL` (ऐसे नेटवर्क को स्थिति क्वेरी जो यह सुविधा देता है, हर 5 मिनट पर, जब तक ट्रांसफ़र प्रतिपक्ष की प्रतीक्षा में है)। |
| `status` | `QUEUED`, `SENDING`, `RETRYING`, `DELIVERED`, या `FAILED`। |
| `rail` | वह चैनल जो संदेश ले जाता है; पहले संदेश के लिए, जब तक Didit कोई चैनल न चुन ले, तब तक खाली रहता है। |
| `attempts` | अब तक किए गए प्रयास। |
| `last_error` | आखिरी प्रयास क्यों विफल हुआ, कोई भी प्रयास विफल न हुआ हो तो खाली। एक संक्षिप्त कारण जिसमें चरण और विफलता का प्रकार बताया जाता है, उदाहरण के लिए `sygna permission request failed: HTTP 503` या `sygna status query failed: no answer in time`; जब GTR त्रुटि के साथ उत्तर देता है, तो उसका अपना स्टेटस कोड और संदेश शामिल किया जाता है। रिस्पॉन्स बॉडी कभी शामिल नहीं की जाती। |
| `next_attempt_at` | अगला प्रयास कब किया जाएगा, जब संदेश `QUEUED` या `RETRYING` हो। |
| `delivered_at` | कब दूसरे पक्ष ने संदेश प्राप्त किया। |

वह विफलता जिससे नेटवर्क अभी भी उबर सकता है (समय पर उत्तर नहीं, कनेक्शन विफल, HTTP `408`, `429` या `5xx`), उसका पुनः प्रयास 30 सेकंड, 2 मिनट, 10 मिनट, 30 मिनट और 1 घंटे बाद किया जाता है।
जब पहला संदेश स्थायी रूप से विफल हो जाता है - नेटवर्क ने उसे अस्वीकार किया, या छठा प्रयास भी विफल रहा - तो ट्रांसफ़र `COUNTERPARTY_VASP_NOT_REACHABLE` पर चला जाता है, और उसकी `timeline` में `last_error` दर्ज होता है; आप `action: "resend"` के साथ उसका पुनः प्रयास कर सकते हैं।
कोई अन्य संदेश जो स्थायी रूप से विफल होता है, उसे `timeline` में दर्ज किया जाता है।
`delivery` कभी ट्रांसफ़र की `status` की जगह नहीं लेता: आदान-प्रदान की स्थिति `status` से पढ़ें, और `delivery` से देखें कि ट्रांसफ़र अभी प्रतीक्षा में क्यों है।

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

यदि आप इस रिलीज़ से पहले ही `travel_rule_details.status` भेज रहे थे, तो वे मान अब भी काम करते हैं और अपने-आप मैप हो जाते हैं।
किसी भी स्थिति के camelCase रूप (उदाहरण के लिए `counterpartyVaspNotFound`) भी स्वीकार किए जाते हैं, सबमिशन पर और [नियम](https://docs.didit.me/hi/transaction-monitoring/rules.md) की शर्त वाले मानों में, और मानक रूप में सामान्यीकृत हो जाते हैं:

| पुराना मान | मैप किया गया मान |
| - | - |
| `UNKNOWN` | `NOT_APPLICABLE` |
| `COMPLIANT` | `COMPLETED` |
| `PENDING_ACTION` | `ON_HOLD` |
| `PENDING_COUNTERPARTY` | `AWAITING_COUNTERPARTY` |
| `FAILED` | `CANCELLED` |
| `EXEMPT` | `NOT_APPLICABLE` |

## सेटअप

प्रति एप्लिकेशन एक बार `GET`/`PUT /v3/travel-rule/settings/` के साथ अपनी VASP प्रोफ़ाइल और बातचीत नीति कॉन्फ़िगर करें।

```bash theme={null}
curl -X GET https://verification.didit.me/v3/travel-rule/settings/ \
  -H "x-api-key: YOUR_API_KEY"
```

```json theme={null}
{
  "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 }
  }
}
```

```bash theme={null}
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
  }'
```

`PUT` एक आंशिक अपडेट है - केवल वे फ़ील्ड भेजें जिन्हें आप बदलना चाहते हैं।

| फ़ील्ड | प्रकार | विवरण |
| - | - | - |
| `is_enabled` | बूलियन | इस एप्लिकेशन से बाहर जाने वाले `travelRule` लेन-देन के लिए प्रबंधित बातचीत प्रवाह चालू करता है। इसके लिए एक खाली न होने वाला `legal_name` चाहिए (पहले से सहेजा गया हो, या उसी अनुरोध में शामिल हो) - अन्यथा अनुरोध `400` लौटाता है। |
| `legal_name` | स्ट्रिंग | आपके VASP का कानूनी नाम। ईमेल पिकअप पेज पर प्रतिपक्ष को दिखाया जाता है और [VASP डायरेक्टरी](#डायरेक्टरी) में लौटाया जाता है। |
| `lei` | स्ट्रिंग | आपका लीगल एंटिटी आइडेंटिफ़ायर, जो VASP डायरेक्टरी में लौटाया जाता है। |
| `jurisdiction` | स्ट्रिंग | आपके VASP के संचालन क्षेत्राधिकार का कोड, अधिकतम 8 अक्षर (डिफ़ॉल्ट `"EU"`)। |
| `name_matching_strictness` | स्ट्रिंग | `NONE`, `STRICT`, `CONTAINS`, `DEFAULT`, या `FUZZY` - नीचे देखें। |
| `confirmation_timeout_hours` | पूर्णांक | घंटों की वह अवधि जिसके लिए `AWAITING_COUNTERPARTY` ट्रांसफ़र रुका रह सकता है, उसके बाद वह स्वतः समाप्त हो जाता है। न्यूनतम `1`, डिफ़ॉल्ट `48`। |
| `timeout_outcome` | स्ट्रिंग | ट्रांसफ़र समाप्त होने पर अंतर्निहित लेन-देन के साथ क्या होता है: `HOLD` उसे समीक्षा में भेजता है, `REJECT` उसे अस्वीकार करता है, `PROCEED` उसकी स्थिति अछूती छोड़ता है। डिफ़ॉल्ट `HOLD`। जब `sunrise_policy` या `non_responsive_policy` लागू होती हैं, तो वे प्राथमिकता लेती हैं। |
| `sunrise_policy` | स्ट्रिंग | `HOLD`, `REJECT`, `PROCEED`, या `""` (डिफ़ॉल्ट) ताकि `timeout_outcome` का पालन हो: जब प्रतिपक्ष `sunrise_jurisdictions` में सूचीबद्ध क्षेत्राधिकार की डायरेक्टरी प्रविष्टि हो, तो समाप्त ट्रांसफ़र क्या करता है। देखें [Sunrise और गैर-प्रतिक्रियाशील नीतियाँ](#सनराइज़-और-गैर-प्रतिक्रियाशील-नीतियाँ)। |
| `non_responsive_policy` | स्ट्रिंग | `HOLD`, `REJECT`, `PROCEED`, या `""` (डिफ़ॉल्ट) ताकि `timeout_outcome` का पालन हो: जब प्रतिपक्ष ऐसी डायरेक्टरी प्रविष्टि हो जिसकी [प्रतिक्रियाशीलता](#प्रतिक्रियाशीलता) `UNRESPONSIVE` है, तो समाप्त ट्रांसफ़र क्या करता है। दोनों लागू होने पर `sunrise_policy` पहले लागू होती है। |
| `sunrise_jurisdictions` | स्ट्रिंग\[] | केवल पढ़ने के लिए। वे देश जिन्हें Didit Travel Rule सनराइज़ अवधि में मानता है, अभी `["CO", "KH", "VN"]`। कोई अन्य क्षेत्राधिकार `timeout_outcome` का पालन करता है। |
| `compliance_email` | स्ट्रिंग | आपकी VASP प्रोफ़ाइल के लिए अनुपालन संपर्क ईमेल। [Didit नेटवर्क](#didit-नेटवर्क) आपकी प्रोफ़ाइल तभी सूचीबद्ध करता है जब यह पता ईमेल में भेजे गए लिंक के माध्यम से पुष्ट हो जाए; इसे बदलने पर नई पुष्टि चाहिए। |
| `is_discoverable` | बूलियन | क्या आपकी VASP प्रोफ़ाइल [Didit नेटवर्क](#didit-नेटवर्क) में सूचीबद्ध हो सकती है: अन्य Didit ग्राहक इसे `GET /v3/travel-rule/vasps/` में खोज सकते हैं और INTERNAL रेल पर इससे संपर्क किया जा सकता है। सूचीबद्धता की कुछ और शर्तें भी हैं; सेटिंग्स में `didit_network` बताता है कि कौन सी शर्तें छूटी हैं। डिफ़ॉल्ट `true`। |
| `inbound_auto_accept` | बूलियन | `true` होने पर, अंदर आने वाली `TRP` पूछताछ जिसका लाभार्थी वॉलेट आपकी पता पुस्तिका में सत्यापित प्रविष्टि है और जिसका नाम मेल खाता है, अपने आप स्वीकृत हो जाती है। `false` होने पर, वह आपके निर्णय के लिए `ON_HOLD` में रहती है। अन्य अंदर आने वाले पथ यह सेटिंग नहीं पढ़ते। डिफ़ॉल्ट `true`। |
| `allow_self_declaration` | बूलियन | `true` होने पर, [वॉलेट-स्वामित्व विजेट](https://docs.didit.me/hi/transaction-monitoring/wallet-ownership-widget.md) स्व-घोषणा को प्रमाण विधि के रूप में प्रस्तुत करता है, और आप `self_declared: true` के साथ [वॉलेट पता पुस्तिका](#वॉलेट-पता-पुस्तिका) प्रविष्टियाँ बना सकते हैं। डिफ़ॉल्ट `true`। |
| `allow_screenshot_proof` | बूलियन | `true` होने पर, [वॉलेट-स्वामित्व विजेट](https://docs.didit.me/hi/transaction-monitoring/wallet-ownership-widget.md) स्क्रीनशॉट अपलोड को स्वामित्व प्रमाण की विधि के रूप में प्रस्तुत करता है। स्क्रीनशॉट अकेले वॉलेट को कभी सत्यापित नहीं करता: आपकी अनुपालन टीम उसकी समीक्षा करती है और ट्रांसफ़र की पुष्टि करती है। यह क्रिप्टोग्राफ़िक साइनिंग से कमज़ोर है - जहाँ आपकी नीति के लिए हस्ताक्षर-स्तर का प्रमाण चाहिए, वहाँ इसे बंद करें। डिफ़ॉल्ट `true`। |
| `auto_wallet_verification` | बूलियन | `true` होने पर, बाहर जाने वाला ऐसा ट्रांसफ़र जिसे अंतिम उपयोगकर्ता से वॉलेट नियंत्रण का प्रमाण चाहिए, लेन-देन से जुड़ा [वॉलेट-स्वामित्व विजेट](https://docs.didit.me/hi/transaction-monitoring/wallet-ownership-widget.md) सत्र अपने आप बनाता है और उसे लेन-देन के `action_required` ब्लॉक में दिखाता है - Didit SDK [क्लाइंट-साइड सबमिशन](https://docs.didit.me/hi/transaction-monitoring/sdk-transaction-submission.md) पर इसे स्वतः लॉन्च करते हैं। डिफ़ॉल्ट `true`। |
| `counterparty_screening_enabled` | बूलियन | [प्रतिपक्ष VASPs](#प्रतिपक्ष-स्क्रीनिंग) की ऑप्ट-इन प्रतिबंध और प्रतिकूल मीडिया स्क्रीनिंग, जो हर स्क्रीनिंग के लिए कंपनी AML स्क्रीनिंग की कीमत पर बिल होती है। `true` होने पर, जब बाहर जाने वाला एक्सचेंज शुरू होता है, Didit उस प्रतिपक्ष की स्क्रीनिंग करता है जिस तक वह पहुँचता है, और 30 दिन से कम पुरानी स्क्रीनिंग का पुन: उपयोग करता है। डिफ़ॉल्ट `false`: कुछ भी स्क्रीन या बिल नहीं होता। |
| `vasp_attribution_enabled` | बूलियन | `true` होने पर, बाहर जाने वाला ऐसा ट्रांसफ़र जिसे कोई रेल रूट नहीं कर सकती, [ब्लॉकचेन एनालिटिक्स](#ब्लॉकचेन-एनालिटिक्स-एट्रिब्यूशन) के माध्यम से एट्रिब्यूट किया जाता है - गंतव्य वॉलेट को उसकी स्वामी VASP से जोड़ा जाता है, इकाई डायरेक्टरी में जोड़ी जाती है, और एट्रिब्यूट किए गए नाम के साथ रेलें एक बार फिर चलाई जाती हैं। डिफ़ॉल्ट `true`। |
| `threshold_amount` | स्ट्रिंग (दशमलव) | न्यूनतम ट्रांसफ़र राशि जो प्रबंधित एक्सचेंज शुरू करती है, आपके एप्लिकेशन की डिफ़ॉल्ट मुद्रा में: Didit इसकी तुलना ट्रांसफ़र राशि से करता है जिसे उस मुद्रा में बदली गई हो (या उस `amount_in_default_currency` से जो आप भेजते हैं), ट्रांसफ़र की अपनी मुद्रा की राशि से नहीं। इससे कम के ट्रांसफ़र सीधे `NOT_APPLICABLE` में जाते हैं और उनकी बातचीत कभी नहीं होती। यदि Didit राशि नहीं बदल सकता, तो थ्रेशोल्ड लागू नहीं होता और ट्रांसफ़र का एक्सचेंज होता है। सैंडबॉक्स एप्लिकेशन राशि नहीं बदलते, इसलिए वहाँ थ्रेशोल्ड केवल तभी लागू होता है जब आप `amount_in_default_currency` भेजें। डिफ़ॉल्ट `0.00` है - जो EU TFR की न्यूनतम राशि न होने वाली रूपरेखा से मेल खाता है, ताकि हर ट्रांसफ़र उसके आकार की परवाह किए बिना जाँचा जाए। |
| `ownership_validation_mode` | स्ट्रिंग | `FULL`, `SIMPLIFIED`, या `AUTOMATED` - वॉलेट स्वामित्व के लिए कितना प्रमाण चाहिए। देखें [स्वामित्व सत्यापन मोड](#स्वामित्व-सत्यापन-मोड)। डिफ़ॉल्ट `AUTOMATED`। |
| `simplified_validation_threshold` | स्ट्रिंग (दशमलव) | `SIMPLIFIED` मोड में, इस राशि से कम का ट्रांसफ़र स्व-घोषणा स्वीकार करता है। डिफ़ॉल्ट `0.00`। |
| `data_sharing_fields` | ऑब्जेक्ट | वे फ़ील्ड जो आप अपने उपयोगकर्ताओं के बारे में भेजते हैं, इकाई प्रकार के अनुसार। देखें [डेटा साझाकरण](#डेटा-साझाकरण)। |
| `matching_rules` | ऑब्जेक्ट | प्रतिपक्ष के डेटा के हर फ़ील्ड की तुलना कितनी सख़्ती से होती है, इकाई प्रकार के अनुसार। देखें [प्रति-फ़ील्ड मिलान](#फ़ील्ड-वार-मिलान)। |
| `disabled_networks` | string\[] | नेटवर्क रेल (`GTR`, `TRUST`, `VERIFYVASP`, `SYGNA`) जिनके ऊपर से आपके ट्रांसफ़र Didit की प्लेटफ़ॉर्म सदस्यता के माध्यम से बिल्कुल नहीं होने चाहिए। जिस नेटवर्क के लिए आपने अपनी सदस्यता कनेक्ट की है (कंसोल Marketplace), वह इस सूची से कभी प्रभावित नहीं होता। Didit के पास अभी कोई प्लेटफ़ॉर्म सदस्यता नहीं है, इसलिए यह सूची आज कोई रूटिंग प्रभाव नहीं डालती (सूचीबद्ध रेल `mode: off` रिपोर्ट करती है)। डिफ़ॉल्ट `[]`। |
| `networks` | object | केवल-पढ़ने योग्य। `gtr` / `trust` / `verifyvasp` / `sygna` द्वारा कुंजीबद्ध प्रति-नेटवर्क स्थिति: `{rail, mode, platform_available, connected}`, जहाँ `mode` है `own` (आपकी कनेक्ट की गई सदस्यता), `didit` (Didit की प्लेटफ़ॉर्म सदस्यता, जो अभी किसी भी नेटवर्क पर उपलब्ध नहीं है), `off` (आपके द्वारा अक्षम), या `unavailable`। |
| `travel_address` | string | केवल-पढ़ने योग्य। आपके VASP का अपना Travel Address, यानी एन्कोडेड इनबाउंड `TRP` पूछताछ endpoint जिसके ज़रिए अन्य VASP आपसे संपर्क करते हैं। Travel Rule सक्षम होने के बाद भरा जाता है, उदाहरण के लिए `ta2ih1MicegQ3JqiKz9xT89KsSuwaDJYw8DgzmeS5uNDp3dGW3bweBWLKws442chRsyNxmmJnyWc7frxjjSeABVsYR11UuBePkw6E`। |

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

| मान | व्यवहार |
| - | - |
| `NONE` | कोई भी लाभार्थी नाम स्वीकार होता है, कोई तुलना नहीं की जाती। |
| `STRICT` | दोनों नामों के सामान्यीकृत टोकन सेट बिल्कुल बराबर होने चाहिए। |
| `CONTAINS` | एक नाम के सभी शब्द दूसरे नाम में मौजूद होने चाहिए, चाहे वे कितने भी कम हों। |
| `DEFAULT` | छोटे नाम का हर टोकन लंबे नाम में मौजूद होना चाहिए (सबसेट मिलान), और जब तक दोनों नाम एक जैसे न हों, छोटे नाम में कम से कम दो टोकन होने चाहिए। |
| `FUZZY` | पूरी सामान्यीकृत स्ट्रिंग का समानता अनुपात कम से कम `0.85` होना चाहिए। |

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

`ownership_validation_mode` तय करता है कि कोई ट्रांसफ़र किसी वॉलेट पर निर्भर करने से पहले उसके स्वामित्व का कितना प्रमाण आवश्यक है।

| मोड | व्यवहार |
| - | - |
| `FULL` | हमेशा प्रमाण आवश्यक है: एक हस्ताक्षरित संदेश, एक टेस्ट जमा, या समीक्षा किया गया स्क्रीनशॉट। अंतिम उपयोगकर्ता की बात कभी नहीं गिनी जाती। विजेट `SELF_DECLARATION` की पेशकश नहीं करता, इसे शुरू करने पर `403` लौटता है, और `self_declared: true` के साथ बनी एड्रेस बुक एंट्री `400` लौटाती है। |
| `SIMPLIFIED` | जब तक लेन-देन `simplified_validation_threshold` से कम है, स्व-घोषणा स्वीकार की जाती है; उससे ऊपर प्रमाण आवश्यक है। इनबाउंड लेन-देन (TRP पूछताछ, नेटवर्क संदेश या आपके द्वारा रिपोर्ट की गई जमा) की जाँच उसकी राशि को वर्तमान दर पर आपके एप्लिकेशन की डिफ़ॉल्ट मुद्रा में बदलकर की जाती है। बिना दर वाली एसेट, और सैंडबॉक्स एप्लिकेशन का हर लेन-देन, थ्रेशोल्ड से ऊपर माना जाता है। |
| `AUTOMATED` | एड्रेस बुक और अंतिम उपयोगकर्ता के पिछले प्रमाण अपने आप पर्याप्त होते हैं, जिसमें स्व-घोषणाएँ भी शामिल हैं, जब तक `allow_self_declaration` `true` है। यह डिफ़ॉल्ट है और वही व्यवहार है जो मोड बनने से पहले हर एप्लिकेशन करता था। |

एक वॉलेट सत्यापित होने के बाद अंतिम उपयोगकर्ता के लिए याद रखा जाता है।
`FULL` और `SIMPLIFIED` में, बाद का लेन-देन उसी वॉलेट का उपयोग तभी करता है जब उस लेन-देन के लिए मोड द्वारा स्वीकार्य प्रमाण उसके साथ हो।
जब `inbound_auto_accept` को एड्रेस बुक में मिलान के लिए कोई वॉलेट नहीं मिलता, तो वह क्रिप्टो वॉलेट जो आपने ठीक एक अंतिम उपयोगकर्ता के लेन-देन पर दर्ज किया है, धारक की पहचान करता है।
Didit उस वॉलेट को अंतिम उपयोगकर्ता की एड्रेस बुक में आपकी स्व-घोषणा के रूप में जोड़ता है, जो सत्यापित होता है जब तक मोड `FULL` न हो। यह ऐसा वॉलेट कभी नहीं जोड़ता जो एड्रेस बुक में उसी चेन के किसी दूसरे नाम (`eth` और `ethereum`) के तहत पहले से सूचीबद्ध है, जिसमें दूसरे VASP के रूप में दर्ज वॉलेट भी शामिल है।
अन्य VASP भेजने से पहले (`GTR`, `Sygna` और `VerifyVASP` के ज़रिए) जो पते की जाँच करते हैं, वह भी मोड का पालन करती है: `FULL` के अंतर्गत, वह वॉलेट जिसे अंतिम उपयोगकर्ता ने केवल घोषित किया है, आपका नहीं बताया जाता।

### डेटा साझाकरण

`data_sharing_fields` तय करता है कि Didit आपके अपने उपयोगकर्ताओं के बारे में कौन से फ़ील्ड प्रतिपक्ष को भेजता है, व्यक्तियों और कंपनियों के लिए अलग-अलग:

```json theme={null}
{
  "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` तय करता है कि प्रतिपक्ष के डेटा के हर फ़ील्ड की तुलना आपके पास मौजूद डेटा से कितनी सख्ती से हो:

```json theme={null}
{
  "matching_rules": {
    "individual": { "name": "DEFAULT", "date_of_birth": "STRICT", "address": "NONE", "account": "STRICT" },
    "company": { "name": "FUZZY", "address": "NONE", "account": "STRICT" }
  }
}
```

हर मान `NONE`, `STRICT`, `CONTAINS`, `DEFAULT` या `FUZZY` है।
डिफ़ॉल्ट: `name` `name_matching_strictness` का अनुसरण करता है, `date_of_birth` और `address` `NONE` हैं, और `account` `STRICT` है।
जो फ़ील्ड छोड़ा गया है वह अपना डिफ़ॉल्ट रखता है, और जिस फ़ील्ड की तुलना उस इकाई प्रकार के लिए नहीं की जाती (कंपनी के पास `date_of_birth` नहीं होता) उसे `400` के साथ अस्वीकार किया जाता है।

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

`threshold_amount` इसलिए है क्योंकि Travel Rule का दायरा नियामक के अनुसार बदलता है।
Didit डिफ़ॉल्ट `0.00` रखता है, जो EU का रुख है, इसलिए आप जानबूझकर बढ़ाएँ नहीं तो हर ट्रांसफ़र के लिए जानकारी का आदान-प्रदान होता है:

| शासन | थ्रेशोल्ड | टिप्पणियाँ |
| - | - | - |
| **EU** - फ़ंड ट्रांसफ़र विनियमन (EU) 2023/1113 | **कोई न्यूनतम नहीं** | हर CASP-से-CASP क्रिप्टो लेन-देन दायरे में है। 1,000 EUR से ऊपर के लेन-देन के लिए स्व-होस्टेड वॉलेट का स्वामित्व सत्यापित होना चाहिए। |
| **FATF सिफ़ारिश 16** (वैश्विक आधार) | USD/EUR 1,000 | इससे नीचे FATF कम किया गया डेटा सेट अनुमति देता है (नाम और पते, बिना सत्यापन के)। |
| **संयुक्त राज्य अमेरिका** - BSA Travel Rule | USD 3,000 | FinCEN का लंबे समय से चला आ रहा फ़ंड-ट्रांसफ़र थ्रेशोल्ड, जो परिवर्तनीय वर्चुअल करेंसी पर लागू होता है। |
| **यूनाइटेड किंगडम** | EUR 1,000 के बराबर | इससे ऊपर पूरी जानकारी; इससे नीचे कम किया गया डेटा सेट (MLRs Part 7A)। |
| **सिंगापुर** - MAS PSN02 | SGD 1,500 | थ्रेशोल्ड से नीचे कम आवश्यकताएँ। |
| **स्विट्ज़रलैंड** - FINMA | कोई न्यूनतम नहीं | सभी लेन-देन के लिए जानकारी आवश्यक; स्व-होस्टेड वॉलेट के लिए स्वामित्व का प्रमाण अपेक्षित। |

`threshold_amount` को अपने नियामक के आंकड़े पर सेट करें; इससे कम के लेन-देन बिना किसी पहचान डेटा के आदान-प्रदान के `NOT_APPLICABLE` पर हल होते हैं।
थ्रेशोल्ड बदलते रहते हैं, इसलिए वर्तमान आंकड़े की पुष्टि अपने अनुपालन सलाहकार से करें, इस तालिका को कानूनी सलाह न मानें।

### IVMS 101 डेटा मॉडल

Travel Rule के तहत आदान-प्रदान होने वाले डेटा का उद्योग मानक **IVMS 101** (interVASP Messaging Standard) है।
`travel_rule_details.originator_data` और `travel_rule_details.beneficiary_data` IVMS 101-शैली के व्यक्ति payloads हैं। Didit इन्हें हर चैनल के अपने मूल envelope में लपेटता है: TRP चैनल `IVMS101` ब्लॉक का आदान-प्रदान करता है (`ivms101.2023`, जिसे transfer के `ivms_version` फ़ील्ड में दर्ज किया जाता है), Sygna चैनल अपना ECIES-एन्क्रिप्टेड IVMS रूप उपयोग करता है, और `GTR`, `TRUST` तथा `VERIFYVASP` चैनल अपने-अपने एन्क्रिप्टेड envelope उपयोग करते हैं। इसलिए एक ही payload का ढाँचा हर प्रतिपक्ष तक उसी प्रारूप में पहुँचता है जिसकी उसके प्रोटोकॉल को अपेक्षा होती है।

Didit IVMS 101 संदेश बनाते समय हर व्यक्ति payload से ये keys पढ़ता है: `first_name` और `last_name` (या एक ही `name` या `full_name`), `date_of_birth`, `place_of_birth`, `residence_country` (या `country`), `vendor_data` (या `customer_identification`), और `wallet_address`।

दो व्यावहारिक नियम:

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

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

जब किसी transfer का विषय आपका कोई उपयोगकर्ता हो, यानी ऐसा व्यक्ति जिसकी KYC सत्यापन स्वीकृत है, तो Didit उस पक्ष का आदान-प्रदान सत्यापित डेटा से बनाता है:

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

`POST /v3/transactions/` पर दोनों ही स्थितियाँ उस लेन-देन पर लागू होती हैं जिसका `transaction_category` `travel_rule` हो और Travel Rule चालू हो।

सत्यापित नाम, जन्म तिथि और जन्म स्थान, दस्तावेज़ की संख्या और प्रकार, पता, और उस पते से लिया गया निवास देश, आपके भेजे मानों पर प्राथमिकता पाते हैं। जो फ़ील्ड सत्यापन में नहीं है, वह आपका मान रखता है। इसी तरह आपका भेजा पूरा पता भी बना रहता है, यदि सत्यापित पता भेजने के लिए पर्याप्त पूरा नहीं है।

Transfer का `metadata`, जो लेन-देन के embedded `travel_rule` object पर होता है, दर्ज करता है कि हर फ़ील्ड कहाँ से आया और कहाँ आपके मान भिन्न थे:

```json theme={null}
{
  "metadata": {
    "originator_provenance": { "name": "verified", "date_of_birth": "verified", "customer_identification": "caller" },
    "originator_verified_differences": {
      "name": { "caller": "Jane Doe", "verified": "Jane Elizabeth Doe" }
    }
  }
}
```

`*_provenance` हर फ़ील्ड को `verified` या `caller` से मैप करता है। `*_verified_differences` हर उस फ़ील्ड की सूची देता है जहाँ आपने सत्यापित मान से भिन्न मान भेजा, और इसमें letter case, spacing तथा दो या तीन अक्षरों वाले देश कोड का अंतर नहीं गिना जाता। जब कोई inbound transfer का डेटा [मास्क किया गया](#मास्क-किया-गया-प्रतिपक्ष-डेटा) हो, तब ये भिन्नताएँ शामिल नहीं होतीं। दोनों की गणना Didit करता है, इसलिए `travel_rule_details.metadata` में आप इन keys की, या `name_match` की, जो भी प्रतियाँ भेजते हैं, वे हटा दी जाती हैं।

#### IVMS 101 सीधे भेजना

सपाट `originator_data` और `beneficiary_data` objects के अलावा, `travel_rule_details` (`POST /v3/transactions/` पर) और `POST /v3/travel-rule/inbound/` वास्तविक IVMS 101 भी स्वीकार करते हैं:

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

हर पक्ष में एक ही person लिया जाता है: `naturalPerson`, या `legalPerson`, जिससे पक्ष कंपनी बन जाता है। एक गैर-खाली flat `originator_data` या `beneficiary_data` उसी पक्ष के block पर प्राथमिकता पाता है।

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

गलत बने block पर `400` उत्तर आता है, जो उसके path से कुंजीबद्ध होता है, उदाहरण के लिए `{"travel_rule_details": {"originator.originatorPersons": ["must be a non-empty list of originator persons."]}}`। `POST /v3/travel-rule/inbound/` पर वही keys शीर्ष स्तर पर होती हैं, और wrapper उपयोग करने पर `ivms101.` के अंतर्गत आती हैं।

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

Travel Rule चालू होने पर, आपके थ्रेशोल्ड के बराबर या उससे अधिक outbound transfer में वह डेटा होना चाहिए जो उसका क्षेत्रीय नियम माँगता है, अन्यथा `400` उत्तर आता है। केवल वे पक्ष जाँचे जाते हैं जो आपने भेजे हैं, originator के लिए सत्यापित डेटा भी गिना जाता है, और त्रुटियाँ `travel_rule_details.originator_data` या `travel_rule_details.beneficiary_data` के अंतर्गत आती हैं, उदाहरण के लिए `"EU TFR requires the originator name."` या `"FATF Recommendation 16 requires the beneficiary wallet address."`:

| नियम | प्रेषक (Originator) | लाभार्थी (Beneficiary) |
| - | - | - |
| EU TFR (आपका `jurisdiction` कोई EU सदस्य राज्य, Iceland, Liechtenstein, Norway, `EU` या `EEA` है; डिफ़ॉल्ट `EU` है) | नाम, साथ में पता, आधिकारिक दस्तावेज़ संख्या और ग्राहक पहचान संख्या एक साथ, या जन्म तिथि और जन्म स्थान। कंपनी के लिए जन्म का कोई विकल्प नहीं है। | नाम और पता |
| FATF Recommendation 16 (हर अन्य अधिकार-क्षेत्र, जिसमें खाली अधिकार-क्षेत्र भी शामिल है) | नाम, साथ में पता, आधिकारिक दस्तावेज़ संख्या या ग्राहक पहचान संख्या में से कोई एक, या जन्म तिथि और जन्म स्थान एक साथ। कंपनी के लिए जन्म का कोई विकल्प नहीं है। | नाम और पता |

Originator की जाँच उन फ़ील्ड्स को पढ़ती है जिन्हें आपका एप्लिकेशन [`data_sharing_fields`](#डेटा-साझाकरण) में साझा करता है, क्योंकि ये वे सभी फ़ील्ड हैं जिन्हें कोई चैनल भेजता है। Beneficiary की जाँच वैसी ही होती है जैसा आपने भेजा। जब transfer नियम को केवल ऐसे फ़ील्ड से पूरा करता है जिसे आप साझा नहीं करते, तो `400` नियम की आवश्यकता बताता है और फिर वे फ़ील्ड बताता है जिन्हें आपकी सेटिंग्स साझा करती हैं।

आधिकारिक दस्तावेज़ संख्या `national_id` (या `document_number`) है, ग्राहक पहचान संख्या `customer_identification` (या `vendor_data`) है, और जन्म तिथि `date_of_birth` है। जाँच से पहले खाली `beneficiary_data.wallet_address` को `counterparty.payment_method.account_id` से भरा जाता है। UTXO withdrawal, जिसका beneficiary output Didit ने `travel_rule_details.utxo` से अनुमानित किया है, वह पता रखने वाला माना जाता है। जिस Lightning transfer पर Travel Rule लागू नहीं होता, उसकी जाँच नहीं होती।

### Travel Address

एक **Travel Address** एक संक्षिप्त, एन्कोडेड स्ट्रिंग है जो किसी VASP के इनबाउंड `TRP` पूछताछ endpoint की ओर इशारा करती है। यह कभी भी कच्चा URL या कोई पता उजागर नहीं करती।
Travel Rule सक्षम होने के बाद Didit आपका अपना `travel_address` बनाता है (जो सेटिंग्स में केवल-पढ़ने योग्य रूप में लौटाया जाता है), ताकि आप उसे उन अन्य VASPs के साथ साझा कर सकें जो `TRP` रेल पर आप तक पहुँचते हैं।
आपके एड्रेस बुक के हर वॉलेट को एक अलग `receiving_travel_address` भी मिलता है: उस पर भेजी गई पूछताछ उसी वॉलेट का नाम लेती है, इसलिए Didit को उसे खाता संख्या या धारक के नाम से खोजना नहीं पड़ता।
Didit का सार्वजनिक TRP होस्ट अभी अन्य VASPs को उत्तर नहीं देता, इसलिए `TRP` पर प्राप्ति तब तक उपलब्ध नहीं है जब तक ऐसा नहीं होता: देखें [Travel Rule नेटवर्क](https://docs.didit.me/hi/transaction-monitoring/travel-rule-networks.md)।
जब आपको किसी प्रतिपक्ष का Travel Address पता हो, तो उसे गंतव्य [वॉलेट एड्रेस बुक एंट्री](#वॉलेट-पता-पुस्तिका) पर सहेजें, ताकि Didit उस लाभार्थी के ट्रांसफ़र सीधे `TRP` पर भेजे, ईमेल पर वापस न जाए।
Didit उन Travel Addresses की पुष्टि करता है जो आप वॉलेट एड्रेस बुक एंट्री पर सहेजते हैं या `originating_vasp` में भेजते हैं: हर पता `ta` से शुरू होना चाहिए और एक इनक्वायरी URL में डिकोड होना चाहिए जिसमें `t=i` हो, इसलिए `ta...` जैसा प्लेसहोल्डर `400` लौटाता है।
ट्रांज़ैक्शन पर `beneficiary_data.travel_address` की पुष्टि नहीं होती: यदि वह डिकोड नहीं होता, तो `TRP` रेल छोड़ दी जाती है।

एन्कोडिंग Base58Check है जिसका प्रीफ़िक्स `ta` है: endpoint होस्ट और पाथ (जिसमें हमेशा क्वेरी जोड़ी `t=i` होती है) प्लस चार-बाइट का double-SHA-256 चेकसम, जिसे base58 में एन्कोड किया जाता है। एक असली पता कुछ इस तरह दिखता है और लगभग 100 अक्षरों तक जाता है:

```text theme={null}
ta2ih1MicegQ3JqiKz9xT89KsSuwaDJYw8DgzmeSEp1h9tduJcNDZ5SgKLEHeyGMcS1s2HgbM6undFrMQknhM5aTXw3G9KBzi16hx
```

जहाँ Didit Travel Address की पुष्टि करता है, वहाँ ऐसा मान जो सही रूप से बना हुआ और वैध चेकसम वाला पता नहीं है, वह `"Invalid travel address."` के साथ `400` लौटाता है।
अपनी सेटिंग्स के रिस्पॉन्स से असली पता लें, या प्रतिपक्ष से ही लें।

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

आपको उन सदस्यता-रहित पथों के परीक्षण के लिए GTR, TRUST, VerifyVASP या Sygna की सदस्यता की ज़रूरत नहीं है। फिर भी परीक्षण किए जा रहे एप्लिकेशन के लिए आपको Didit API कुंजी चाहिए।

* **सैंडबॉक्स आउटबाउंड:** सैंडबॉक्स एप्लिकेशन से `travelRule` ट्रांज़ैक्शन सबमिट करें। थ्रेशोल्ड और स्व-होस्टेड वॉलेट की जाँच के बाद, [Didit Test VASP](https://docs.didit.me/hi/transaction-monitoring/travel-rule-sandbox.md) उसका उत्तर Didit के भीतर ही देता है, उस परिदृश्य के साथ जो आप लाभार्थी वॉलेट या नाम से चुनते हैं: स्वीकृति, अस्वीकृति, नाम का मेल न खाना, पहुँच से बाहर होना, टाइमआउट या स्व-होस्टेड। कोई नेटवर्क, ईमेल, या कोई अन्य Didit ग्राहक कुछ भी प्राप्त नहीं करता।
* **सैंडबॉक्स इनबाउंड:** Test VASP से [Trigger Test VASP Inbound Transfer](https://docs.didit.me/hi/management-api/travel-rule/trigger-test-vasp-inbound.md) के ज़रिए आपको ट्रांसफ़र भेजवाएँ, या [Register Inbound Travel Rule Transfer](https://docs.didit.me/hi/management-api/travel-rule/register-inbound.md) से स्वयं एक पंजीकृत करें। अज्ञात वॉलेट, असत्यापित वॉलेट, लाभार्थी के नाम का मेल न खाना, और सत्यापित मेल खाने वाला वॉलेट परखें। ये किसी नेटवर्क से संपर्क किए बिना वास्तविक इनबाउंड निर्णयों का परीक्षण होता है।
* **दो नियंत्रित लाइव एप्लिकेशन:** अपने दो लाइव एप्लिकेशन के बीच `INTERNAL` रेल का उपयोग करें (प्राप्त करने वाला एप्लिकेशन खोजा जा सकता है और हस्ताक्षरित संदेश या टेस्ट डिपॉज़िट से गंतव्य वॉलेट पर अपना नियंत्रण सिद्ध करता है), या कोई नियंत्रित TRP प्रतिपक्ष, ताकि वाणिज्यिक नेटवर्क क्रेडेंशियल के बिना दो-पक्षीय आदान-प्रदान का परीक्षण हो सके। लाइव एप्लिकेशन पर सामान्य शुल्क और सूचनाएँ लग सकती हैं; केवल ऐसी टेस्ट पहचान और प्रतिपक्ष उपयोग करें जो आपके नियंत्रण में हों।

हर परिदृश्य और उसके सटीक परिणाम के लिए [Test Travel Rule in sandbox](https://docs.didit.me/hi/transaction-monitoring/travel-rule-sandbox.md) देखें। सफल सैंडबॉक्स या स्थानीय प्रोटोकॉल परीक्षण किसी वाणिज्यिक नेटवर्क के क्रेडेंशियल, सदस्यता, या प्रोडक्शन इंटरऑपरेबिलिटी की पुष्टि नहीं करते। उनके लिए अधिकृत नेटवर्क सैंडबॉक्स या मान्य सदस्यता क्रेडेंशियल वाला नियंत्रित लाइव आदान-प्रदान चाहिए।

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

[`POST /v3/transactions/`](https://docs.didit.me/hi/transaction-monitoring/transactions) पर ट्रांसफ़र शामिल करें। इसके लिए `transaction_category` को `travelRule` (या `travel_rule`) पर सेट करें और एक `travel_rule_details` ऑब्जेक्ट संलग्न करें (उपनाम: `travelRule`)।

`travel_rule_details` ब्लॉक स्वयं वैकल्पिक है, लेकिन एक बार आप इसे संलग्न करते हैं, तो `travel_rule_details.status` अनिवार्य है: इसके बिना ब्लॉक `400` लौटाता है।
जब आपके एप्लिकेशन के लिए Travel Rule **सक्षम** हो, तो Didit आपके भेजे गए `status` मान को अनदेखा कर देता है और एक्सचेंज स्वयं संचालित करता है:

1. यदि राशि आपकी कॉन्फ़िगर की गई `threshold_amount` से कम है, तो ट्रांसफ़र तुरंत `NOT_APPLICABLE` पर हल हो जाता है और कोई बातचीत नहीं होती।
2. यदि काउंटरपार्टी की भुगतान विधि गंतव्य को स्व-होस्टेड वॉलेट घोषित करती है (`payment_method.method_type: "unhosted_wallet"`), तो कोई मार्ग आज़माया नहीं जाता। ट्रांसफ़र सीधे `UNCONFIRMED_OWNERSHIP` पर जाता है और वॉलेट-स्वामित्व विजेट अपने आप बन जाता है (देखें [घोषित स्व-होस्टेड वॉलेट](#घोषित-स्व-होस्टेड-वॉलेट))।
3. अन्यथा मार्ग प्राथमिकता क्रम में चलते हैं, और पहला मार्ग जो काउंटरपार्टी तक पहुँच सकता है, वही एक्सचेंज संचालित करता है:
   * `INTERNAL` - ठीक एक अन्य Didit ग्राहक के पास `beneficiary_data.wallet_address` के लिए साइन किए गए संदेश या टेस्ट डिपॉज़िट का प्रमाण होता है, जो वॉलेट के आख़िरी बार स्वामी बदलने के बाद बनाया गया हो। आपका अपना एप्लिकेशन कभी नहीं गिना जाता, और जब आपका अंतिम उपयोगकर्ता [वॉलेट-स्वामित्व विजेट](https://docs.didit.me/hi/transaction-monitoring/wallet-ownership-widget.md) में Didit नेटवर्क के किसी सदस्य को चुनता है, तो केवल उस सदस्य का प्रमाण गिना जाता है। उस ग्राहक का एप्लिकेशन लाइव (सैंडबॉक्स नहीं) है, उसके पास Travel Rule चालू है और `is_discoverable` सेट है, और वही VASP है जिसका नाम आप `counterparty_vasp_lei` या `counterparty_vasp_name` भेजते समय देते हैं। जो वॉलेट केवल स्व-घोषित है, स्क्रीनशॉट से सिद्ध है, असत्यापित है या केवल एड्रेस बुक में सूचीबद्ध है, उसे `INTERNAL` के ज़रिए कभी कुछ नहीं मिलता।
   * `TRP` - ट्रांसफ़र के एसेट की नेटवर्क के लिए Digital Token Identifier मैपिंग है (देखें [TRP एसेट पहचानकर्ता](#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 [वॉलेट-स्वामित्व विजेट](https://docs.didit.me/hi/transaction-monitoring/wallet-ownership-widget.md) अपने आप बनाता है (जब `auto_wallet_verification` चालू हो), ताकि ट्रांसफ़र स्व-होस्टेड-वॉलेट ट्रांसफ़र के रूप में अब भी पूरा हो सके। बेहतर काउंटरपार्टी डेटा मिलने के बाद आप `action: "resend"` के साथ रूटिंग दोबारा चला सकते हैं।

चरण 1 और 2 अनुरोध के भीतर होते हैं। चरण 3 से 5 रिस्पॉन्स के ठीक बाद चलते हैं: ट्रांसफ़र `protocol: null` के साथ `AWAITING_COUNTERPARTY` लौटता है, और हर परिणाम एक [`travel_rule.status.updated`](#वेबहुक) webhook के रूप में पहुँचता है।

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

`TRP` ट्रांसफ़र किए गए एसेट का नाम ISO 24165 Digital Token Identifier (DTI) से देता है।
DTI किसी ब्लॉकचेन पर मौजूद टोकन की पहचान करता है, इसलिए मल्टी-चेन टोकन का हर नेटवर्क के लिए एक DTI होता है।

Didit इन एसेट्स के लिए `TRP` के ज़रिए ट्रांसफ़र भेजता है:

| एसेट | नेटवर्क | DTI |
| - | - | - |
| `BTC` | Bitcoin | `4H95J0R2X` |
| `ETH` | Ethereum | `X9J9K872S` |
| `USDC` | Ethereum | `CK9PW1MFH` |
| `USDC` | Celo | `2ZTG3NNVB` |
| `USDC` | Base | `CP6817N4B` |
| `USDC` | Optimism | `898NNTPZJ` |
| `USDC` | Arbitrum One | `4ZSZS1F4F` |
| `USDC` | Polygon PoS | `LS71LQK3L` |
| `USDC` | Avalanche C-Chain | `45J6XJX7H` |
| `USDC` | Solana | `5R3XFPZSM` |
| `USDC` | Plume | `N064ZKXDM` |

`USDC` के पहचानकर्ता वही हैं जिन्हें टोकन का जारीकर्ता अपने MiCA व्हाइट पेपर में प्रकाशित करता है।

मल्टी-चेन टोकन के लिए ट्रांसफ़र को अपना नेटवर्क `transaction_details.crypto_params.crypto_chain` में बताना होगा (उदाहरण के लिए `CELO`, `BASE`, `OP`, `ARB` या `POL`)।
नेटवर्क के बिना, या ऐसे नेटवर्क पर जिसकी कोई मैपिंग नहीं है, ट्रांसफ़र `TRP` के ज़रिए नहीं भेजा जाता और Didit शेष मार्ग आज़माता है: पहले इंटरऑपरेबिलिटी नेटवर्क, फिर ईमेल।

`USDT` की अभी मैपिंग नहीं है।
बिना DTI मैपिंग वाले टोकन, जैसे किसी कंपनी का अपना स्टेबलकॉइन, के लिए ज़रूरी है कि उसका जारीकर्ता ISO 24165 पंजीकरण प्राधिकरण के साथ DTI पंजीकृत कराए, हर ब्लॉकचेन पर हर टोकन के लिए एक।
एक बार DTI बन जाने पर, हर DTI, उसका ब्लॉकचेन और टोकन के दशमलव स्थान के साथ Didit सहायता से संपर्क करें, और Didit मैपिंग जोड़ देगा।

जो इनबाउंड `TRP` पूछताछ मैप की गई प्रति-चेन DTI लेकर आती है, वह टोकन की मुद्रा, टोकन के दशमलव में राशि और नेटवर्क के साथ दर्ज की जाती है।

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

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

| चरण | यह क्या करता है |
| - | - |
| `internal_address_book` | एक अन्य Didit ग्राहक ने वॉलेट पर नियंत्रण सिद्ध किया है (साइन किया गया संदेश या टेस्ट डिपॉज़िट), इसलिए `INTERNAL` मार्ग उन तक पहुँचाता है। जिस एड्रेस-बुक प्रविष्टि का प्रमाण न हो, उसे कभी नहीं गिना जाता। |
| `wallet_attribution` | वॉलेट का ब्लॉकचेन एनालिटिक्स एट्रिब्यूशन, जो ऐसे डायरेक्टरी VASP से मेल खाता है जिसके पास कोई मार्ग है। संग्रहीत परिणाम का दोबारा उपयोग किया जाता है और एक बार शुल्क लिया जाता है। इसके लिए `vasp_attribution_enabled` चालू होना ज़रूरी है। |
| `network_lookup` | Travel Rule नेटवर्क जो बताता है "इस पते का धारक कौन है", जब आपके एप्लिकेशन के पास उसकी पहुँच हो। आज केवल GTR यह सुविधा देता है, और यह तब चलता है जब GTR रेल भेजता है। अन्यथा यह चरण कारण सहित `skipped` के रूप में दर्ज होता है। |
| `customer_hint` | `beneficiary_data` में आपने जो VASP नाम, LEI या अधिकार क्षेत्र भेजा, वह उस डायरेक्टरी VASP से मेल खाता है जिसका रूट उपलब्ध है। `travel_address` या अनुपालन ईमेल अपनी अलग रेल से पहुँचे जाते हैं। |
| `end_user` | किसी ने प्रतिपक्ष का नाम नहीं दिया, इसलिए अंतिम उपयोगकर्ता से पूछा जाता है। नीचे देखें। |

लेन-देन का `discovery` फ़ील्ड हर उस चरण की सूची देता है जो चला, उसके `outcome` (`match`, `miss` या `skipped`) के साथ, एक मशीन-पठनीय `reason`, वह `vasp` और `rail` जो मिला, और एक टाइमस्टैम्प।
आपके या अंतिम उपयोगकर्ता द्वारा चुना गया VASP हर स्वचालित चरण से ऊपर रहता है: डिस्कवरी उसे अपने अनुमान से कभी नहीं बदलती।

जब किसी चरण में प्रतिपक्ष का नाम नहीं आता, तो लेन-देन `COUNTERPARTY_VASP_NOT_FOUND` पर चला जाता है, या `COUNTERPARTY_VASP_NOT_REACHABLE` पर, जब कोई VASP नामित हो लेकिन उसका कोई भी रूट आपके एप्लिकेशन के लिए उपलब्ध न हो।
फिर लेन-देन में एक `reason` होता है (`awaiting_end_user`, `no_directory_match`, `directory_match_no_route`, या `picked_member_without_proven_wallet`, जब अंतिम उपयोगकर्ता द्वारा चुने गए सदस्य ने वॉलेट का स्वामित्व सिद्ध नहीं किया हो) और `next_actions` की एक सूची:

| `action` | अर्थ |
| - | - |
| `select_counterparty_vasp` | अंतिम उपयोगकर्ता [वॉलेट विजेट](https://docs.didit.me/hi/transaction-monitoring/wallet-ownership-widget.md) में गंतव्य VASP चुनता है, या आप उसे स्वयं `{"action": "beneficiary_vasp", "beneficiary_vasp": "<directory VASP id>"}` के साथ [ट्रांसफ़र एंडपॉइंट](#ट्रांसफ़र-भेजना) पर नामित करते हैं। लेन-देन उस VASP की ओर रूट किया जाता है और फिर से भेजा जाता है। |
| `declare_self_hosted` | अंतिम उपयोगकर्ता उसी विजेट में वॉलेट को स्व-होस्टेड घोषित करता है। |
| `add_vasp_hint` | `beneficiary_data` में VASP का नाम, LEI या `travel_address` भेजें, फिर दोबारा भेजें। |
| `update_compliance_email` | जब पहला ईमेल अस्वीकार हुआ हो, तो प्रतिपक्ष का अनुपालन ईमेल फिर से दें; देखें [लेन-देन क्यों अटका है](#ट्रांसफ़र-क्यों-अटका-है)। |
| `resend` | जो बदला है उसके साथ डिस्कवरी फिर से चलाएँ। |

विजेट लिंक, अंतिम उपयोगकर्ता द्वारा की जाने वाली कार्रवाइयों में `url` के रूप में होता है।
जब वॉलेट स्वामित्व की कोई कार्रवाई लंबित हो, तो लेन-देन का `action_required` ब्लॉक (प्रकार `wallet_ownership`) वही `reason` और `next_actions` रखता है, ताकि जो क्लाइंट पहले से `action_required` को फ़ॉलो करता है, वह बिना अतिरिक्त काम के पिकर दिखा दे।

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

Didit प्रतिपक्ष के बारे में जो कुछ जानता है, वह `travel_rule_details.beneficiary_data` से आता है।
ये फ़ील्ड रेल समाधान को नियंत्रित करते हैं; ये सभी वैकल्पिक हैं:

| फ़ील्ड | नियंत्रित करता है |
| - | - |
| `wallet_address` | `INTERNAL` पता-बुक मिलान, `TRP` पता-बुक खोज, और वॉलेट-स्वामित्व प्रवाह। जब आप इसे छोड़ते हैं, तो Didit `counterparty.payment_method.account_id` का उपयोग करता है। |
| `chain` | दोनों पता-बुक खोजों का दायरा तय करता है: कोई प्रविष्टि तभी मेल खाती है जब उसकी `chain` इस मान के बराबर हो (केस-इनसेंसिटिव) या प्रविष्टि में `chain` न हो। जब आप इसे छोड़ते हैं, तो Didit इसे `transaction_details.crypto_params.crypto_chain`, `custom_properties.crypto_chain`, या लेन-देन की मुद्रा से भरता है, बड़े अक्षरों में, लेकिन केवल तब जब वह मान ऐसी चेन हो जिसे Didit पहचानता है (उदाहरण के लिए `ETH`, `BTC`, `SOL`, `TRX`); अन्यथा लेन-देन में कोई चेन नहीं होती और वह किसी भी चेन की प्रविष्टि से मेल खाता है। स्पष्ट चेन के बिना `USDT` या `USDC` लेन-देन के लिए, Didit `transaction_details.payment_reference_id` में लेन-देन हैश से इसका अनुमान लगाता है (`0x` हैश से `ETH` मिलता है)। |
| `memo` | `wallet_address` का गंतव्य टैग या मेमो, मेमो नेटवर्क पर। जहाँ भी `wallet_address` का मिलान होता है, वहाँ यह वॉलेट का हिस्सा होता है (देखें [मेमो और टैग नेटवर्क](#memo-और-tag-नेटवर्क))। उपनाम: `destinationTag`। |
| `travel_address` | `TRP` पर सीधे रूट करता है - आप जो सबसे मज़बूत संकेत दे सकते हैं। |
| `counterparty_vasp_lei` | `TRP`, `GTR`, `TRUST`, `VERIFYVASP` और `SYGNA` के लिए LEI द्वारा डायरेक्टरी खोज। TRP एंडपॉइंट द्वारा रिपोर्ट की गई पहचान से भी जाँचा जाता है - असंगति, या बिना LEI वाली पहचान, विनिमय को `COUNTERPARTY_VASP_NOT_REACHABLE` के रूप में रोक देती है। |
| `counterparty_vasp_name` | `TRP`, `GTR`, `TRUST`, `VERIFYVASP`, `SYGNA` और `EMAIL` के लिए डायरेक्टरी खोज: सटीक नाम, वही नाम किसी अन्य तरीके से लिखा हुआ (`BV` के लिए `B.V.`, कोई एक्सेंट), फिर किसी प्रविष्टि का उपनाम। जब दोनों मौजूद हों, तो TRP पहचान से फ़ज़ी जाँच होती है। |
| `counterparty_vasp_jurisdiction` | प्राप्त करने वाली इकाई का ISO 3166 देश कोड, जब नामित VASP ऐसा ब्रांड हो जिसकी कई विनियमित इकाइयाँ हों, या जब डायरेक्टरी में कई प्रविष्टियाँ एक ही नाम साझा करती हों - देखें [ब्रांड और उनकी इकाइयाँ](#ब्रांड-और-उनकी-इकाइयाँ)। |
| `counterparty_gtr_vasp_code` | स्पष्ट `GTR` नेटवर्क आईडी - डायरेक्टरी को छोड़ देता है। |
| `counterparty_trust_membership_id` | स्पष्ट `TRUST` नेटवर्क आईडी - डायरेक्टरी को छोड़ देता है। |
| `counterparty_verifyvasp_id` | स्पष्ट `VerifyVASP` नेटवर्क आईडी - डायरेक्टरी को छोड़ देता है। |
| `counterparty_sygna_vasp_code` | स्पष्ट `Sygna Bridge` VASP कोड - डायरेक्टरी को छोड़ देता है। |
| `counterparty_vasp_email` | `EMAIL` रेल के लिए स्पष्ट अनुपालन संपर्क - डायरेक्टरी को छोड़ देता है। |

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

अकाउंट चेन (EVM चेन, Solana, Tron) पर लेन-देन एक पते से दूसरे पते पर धन भेजता है, और Didit दोनों वॉलेट सीधे लेन-देन से पढ़ता है।
तीन अन्य संरचनाओं को अधिक जानकारी चाहिए, और Didit ने उनके लिए जो समाधान किया, वह लेन-देन पर `chain_details` के रूप में होता है (अकाउंट चेन पर खाली, `{}`)।
`chain_details.originator` और `chain_details.beneficiary` में से हर एक अपना `address`, उसका `memo`, और जिस `source` से वह आया, रखता है; मिलान और रूटिंग पहले वहीं से वॉलेट पढ़ते हैं।

#### UTXO लेन-देन

एक Bitcoin, Litecoin, Bitcoin Cash या Dogecoin लेन-देन किसी भी संख्या के पतों से इनपुट खर्च करता है और किसी भी संख्या के आउटपुट का भुगतान करता है, जिनमें से कुछ भेजने वाले को चेंज के रूप में वापस जाते हैं।
इनपुट और आउटपुट को `travel_rule_details.utxo` के रूप में भेजें (राशियाँ सिक्के की अपनी इकाई में, दशमलव स्ट्रिंग के रूप में), और Didit वह अनुमान लगाता है जो आप घोषित नहीं करते:

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

```bash theme={null}
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" }
        ]
      }
    }
  }'
```

इसके बाद ट्रांसफ़र में यह होता है:

```json theme={null}
{
  "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
    }
  }
}
```

`chain_details.warnings` उन बातों को चिह्नित करता है जो मेल नहीं खातीं: `declared_originator_not_an_input`, `declared_beneficiary_not_an_output`, `beneficiary_output_ambiguous` (कोई एक आउटपुट अलग नहीं पहचाना जा सका) और `beneficiary_output_amount_differs`।
किसी अन्य चेन पर `utxo` एक `400` है, और हर सूची में अधिकतम 1,000 प्रविष्टियाँ हो सकती हैं।
रिपोर्ट किए गए डिपॉज़िट में भी वही `utxo` ऑब्जेक्ट होता है (देखें [डिपॉज़िट के बाद सनराइज़ रजिस्ट्रेशन](#डिपॉज़िट-के-बाद-सनराइज़-पंजीकरण))।

#### Memo और tag नेटवर्क

XRP, Stellar (XLM), EOS, Cosmos (ATOM) और Hedera (HBAR) पर एक्सचेंज सभी ग्राहकों के लिए एक ही साझा पते पर भुगतान प्राप्त करता है और उन्हें destination tag या memo से अलग पहचानता है।
इसलिए memo वॉलेट का हिस्सा है: उसे प्रतिभागी पर `payment_method.memo` के रूप में भेजें, या `originator_data` / `beneficiary_data` में `memo` के रूप में (उपनाम `destinationTag`), और Didit पता और memo दोनों को एक साथ मिलाकर जाँचता है।

* 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

Lightning भुगतान में कोई on-chain लाभार्थी पता नहीं होता: भुगतानकर्ता के पास एक payment request होता है।
Bitcoin या Lightning crypto ट्रांसफ़र पर `payment_method.account_id` वही request हो सकता है, और Didit बिना किसी नेटवर्क से संपर्क किए उसी से लाभार्थी की पहचान करता है।

| आप जो भेजते हैं | लाभार्थी |
| - | - |
| BOLT11 इनवॉइस (`lnbc...`) | भुगतान प्राप्तकर्ता नोड, जो invoice में लिखा है या उसके हस्ताक्षर से निकाला गया है। |
| BOLT12 offer या invoice (`lno1...`, `lni1...`) | जारीकर्ता नोड, जब तक वह blinded paths के पीछे न छिपा हो। |
| Lightning Address (`name@domain`) | यही पता। |
| Node id | नोड स्वयं। |
| LNURL (`lnurl1...`, `lnurlp://`) | कोई नहीं: यह एक सेवा का नाम है, भुगतान प्राप्तकर्ता का नहीं। |

भुगतान प्राप्तकर्ता (payee) खाते के रूप में और `chain_details.beneficiary` में (`source: invoice_payee`) `LIGHTNING` चेन पर संग्रहीत होता है, और request में क्या लिखा है वह `chain_details.lightning` में होता है।
जब request में कोई payee नहीं होता, तो outbound ट्रांसफ़र `NOT_APPLICABLE` हो जाता है। कारण `chain_details.not_applicable_reason` में और उसकी `timeline` में दर्ज होता है: `LIGHTNING_NO_PAYEE_IDENTIFIER`, `LIGHTNING_BOLT12_BLINDED_PAYEE` या `LIGHTNING_LNURL_NAMES_NO_PAYEE`।
कोई मान तभी Lightning माना जाता है जब चेन bitcoin हो, `LIGHTNING` हो, या कोई चेन नामित न हो (Lightning Address केवल bitcoin या `LIGHTNING` पर); किसी और चेन पर वह उसी चेन का अपना पता है।

> [!NOTE]
>
> `INTERNAL` रेल केवल उस वॉलेट के ज़रिए दूसरे Didit ग्राहक तक पहुँचती है जिसे उस ग्राहक ने हस्ताक्षरित संदेश या test deposit से अपने नियंत्रण में होना साबित किया हो, और ऐसे प्रमाण आज Bitcoin, EVM chains, Solana और Tron के लिए मौजूद हैं।
> इसलिए memo नेटवर्क, Lightning, Litecoin, Bitcoin Cash और Dogecoin पर कोई ट्रांसफ़र `INTERNAL` के ज़रिए कभी दूसरे Didit ग्राहक तक नहीं पहुँचता।
> memo, tag और Lightning का मिलान फिर भी आपकी अपनी एड्रेस बुक पर लागू होता है: आपके वॉलेट की ओर आने वाले ट्रांसफ़र, रिपोर्ट किए गए डिपॉज़िट और `TRP` पूछताछ।

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

अक्सर निकासी ग्राहक के मुख्य वॉलेट से घोषित की जाती है, जबकि प्रसारण उन पतों से होता है जिनके पास सिक्के थे।
जिस वॉलेट से धनराशि वास्तव में निकली, उसे `PATCH /v3/transactions/{transaction_id}/travel-rule/` से दर्ज करें:

```bash theme={null}
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` समकक्ष उसी तरह अपडेट होता है।

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

जब आप केवल एक वॉलेट पता देते हैं, तब भी Didit यह पता लगा सकता है कि दूसरी तरफ़ कौन है।
अगर कोई रेल ट्रांसफ़र को रूट नहीं कर सकती, तो Didit गंतव्य वॉलेट को ब्लॉकचेन एनालिटिक्स एट्रिब्यूशन डेटा से मिलाता है: वही विश्लेषण जो [क्रिप्टो लेन-देन स्क्रीनिंग](https://docs.didit.me/hi/transaction-monitoring/aml-screening.md) को शक्ति देता है और जानता है कि कौन से वॉलेट किस एक्सचेंज और कस्टोडियन के हैं।
एट्रिब्यूशन केवल उन outbound ट्रांसफ़र पर चलता है जिनमें गंतव्य वॉलेट और `chain` दोनों हों (देखें [प्रतिपक्ष समाधान फ़ील्ड](#प्रतिपक्ष-समाधान-फ़ील्ड)); chain के बिना इसे छोड़ दिया जाता है।

जब वॉलेट किसी ज्ञात इकाई से जुड़ा हो, तो Didit:

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

एट्रिब्यूशन कॉल एक पूर्ण crypto screening का भी काम करती है: लेन-देन को पूरा screening आउटपुट मिलता है (जोखिम स्कोर, वॉलेट की जोखिम श्रेणी, नेटवर्क स्नैपशॉट), ठीक वैसे जैसे crypto monitoring चला हो। लेन-देन का `custom_values.aml_screening_trigger` `travel_rule_attribution` पर सेट होता है, ताकि आप देख सकें कि screening इसलिए चला क्योंकि Travel Rule routing को इसकी ज़रूरत पड़ी।
जब क्रिप्टो मॉनिटरिंग ने इसी लेन-देन पर उसी वॉलेट की पहले ही स्क्रीनिंग कर ली हो, तो सहेजा गया परिणाम दोबारा इस्तेमाल होता है: न दूसरी analytics कॉल, न दूसरा शुल्क।
एट्रिब्यूशन कभी लेन-देन बनाने को नहीं रोकता। अगर analytics lookup विफल हो जाए या आपका बैलेंस उसका खर्च न उठा सके, तो ट्रांसफ़र बस `COUNTERPARTY_VASP_NOT_FOUND` की ओर बढ़ता है, और इस प्रयास के लिए कुछ भी शुल्क नहीं लिया जाता।
`action: "resend"` पर, पहले दर्ज की गई एट्रिब्यूशन दोबारा क्वेरी करने की बजाय दोबारा इस्तेमाल की जाती है।

Disable the whole step with `vasp_attribution_enabled: false` in [सेटिंग्स](#सेटअप).
एट्रिब्यूशन कॉल का बिलिंग तरीका जानने के लिए [मूल्य निर्धारण](#मूल्य-निर्धारण) देखें।

जब Travel Rule **बंद** हो, तब `travel_rule_details` (कॉलर द्वारा दिया गया `status`, चाहे पुराना हो या वर्तमान) फिर भी लेन-देन पर दर्ज होता है, लेकिन निष्क्रिय रूप से - कोई rail भेजी नहीं जाती।
इसका उपयोग उस अनुपालन डेटा को भरने के लिए करें जिसे आप अपनी प्रक्रिया से पहले से ट्रैक कर चुके हैं।
निष्क्रिय आउटबाउंड ट्रांसफ़र कोई एक्सचेंज शुरू नहीं करता, इसलिए उसका बिल Transaction Screening के रूप में होता है, [Travel Rule लाइन](#मूल्य-निर्धारण) पर नहीं।

Travel Rule चालू होने पर यह अनुरोध `EMAIL` rail से रूट होता है, क्योंकि इसमें प्रतिपक्ष का अनुपालन ईमेल दिया गया है और कोई पहले की rail लाभार्थी तक नहीं पहुँच सकती:

```bash theme={null}
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"
      }
    }
  }'
```

रिस्पॉन्स, यहाँ प्रासंगिक फ़ील्ड तक संक्षिप्त रूप में:

```json theme={null}
{
  "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` है, क्योंकि किसी नियम ने लेन-देन पर कार्रवाई नहीं की; आपके अपने नियम कोई दूसरी स्थिति सेट कर सकते हैं।
* अनुपालन संपर्क को पिकअप लिंक मिलता है, और जब वे जवाब देते हैं तो ट्रांसफ़र पूरा होता है, नाम मिलान में विफल होता है, या अस्वीकार हो जाता है; अगर वे जवाब नहीं देते तो वह समाप्त हो जाता है (देखें [ईमेल पिकअप](#पहुँच-से-बाहर-प्रतिपक्षों-के-लिए-ईमेल-पिकअप))।

`protocol` अब भी `null` है, क्योंकि rail रिस्पॉन्स के बाद चुनी जाती है (उदाहरण के लिए `EMAIL`, जब आपने `counterparty_vasp_email` दिया हो): चुने जाने के बाद [लेन-देन प्राप्त करें](https://docs.didit.me/hi/management-api/transactions/get.md) इसे दिखाता है, और उसके बाद का हर `travel_rule.status.updated` webhook इसे `rail` में शामिल करता है।
अगर लाभार्थी वॉलेट किसी दूसरे Didit ग्राहक का है जिसने उस पर नियंत्रण सिद्ध किया है, तो `INTERNAL` rail रिस्पॉन्स के ठीक बाद पूरे एक्सचेंज का निपटान कर देती है, और वह webhook पहले ही `COMPLETED` (या `COUNTERPARTY_MISMATCHED_DATA`) बताता है। जब नाम मेल नहीं खाता, तब आपका ट्रांसफ़र `COUNTERPARTY_MISMATCHED_DATA` होता है और दूसरे ग्राहक को कुछ नहीं मिलता।
`counterparty_vasp_email` के बिना, और जब न rails और न [एट्रिब्यूशन](#ब्लॉकचेन-एनालिटिक्स-एट्रिब्यूशन) लाभार्थी तक पहुँच सकें, तब ट्रांसफ़र बाद में `COUNTERPARTY_VASP_NOT_FOUND` पर समाप्त होता है, और लेन-देन पर `wallet_ownership` कार्रवाई होती है।

> [!NOTE]
>
> लेन-देन की एम्बेडेड `travel_rule` ऑब्जेक्ट में ट्रांसफ़र के अपने फ़ील्ड (`uuid`, `status`, `protocol`, `required`, `obligations_count`, `originator_data`, `beneficiary_data`, `metadata`), जिन्हें Didit ने निर्धारित और मिलान किया है (`chain_details`, `name_match`, `data_match`, `mismatched_fields`, और [मास्किंग](#मास्क-किया-गया-प्रतिपक्ष-डेटा) फ़ील्ड `data_masked` और `data_unmasked`), और वे फ़ील्ड जो इसकी वर्तमान स्थिति बताते हैं: `direction`, `rail`, `counterparty_vasp`, `delivery`, `discovery`, `reason`, और `next_actions` (देखें [ट्रांसफ़र क्यों अटका है](#ट्रांसफ़र-क्यों-अटका-है)) शामिल होते हैं।
> [`GET /v3/transactions/`](https://docs.didit.me/hi/management-api/transactions/list) की हर पंक्ति में वही ब्लॉक होता है, या बिना ट्रांसफ़र वाले लेन-देन के लिए `null`।
> नीचे दिए गए समर्पित ट्रांसफ़र endpoint भी वे फ़ील्ड लौटाते हैं, साथ में `ivms_version`, `ownership_confirmed`, `deadline_at`, `timeline`, और `created_at`, लेकिन `obligations_count` या `metadata` नहीं।

जब आप कोई `COMPLETED` आउटबाउंड ट्रांसफ़र ऑन-चेन प्रसारित कर दें, तो उसे बंद करने के लिए:

```bash theme={null}
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"}'
```

इसके लिए ट्रांसफ़र का `COMPLETED` स्थिति वाला **आउटबाउंड** ट्रांसफ़र होना ज़रूरी है - अन्यथा API `409` लौटाता है।
सफल होने पर आउटबाउंड ट्रांसफ़र और उसका `INTERNAL` rail वाला समकक्ष दोनों `FINISHED` हो जाते हैं, और लेन-देन का `payment_txn_id` आपके दिए हैश पर सेट हो जाता है।
`TRP` rail पर Didit हैश को प्रतिपक्ष के पुष्टि कॉलबैक पर भी भेजता है।

जो ट्रांसफ़र अभी अंतिम स्थिति तक नहीं पहुँचा है उसे रद्द करने के लिए, उसी endpoint पर `{"action": "cancel"}` भेजें।
`INTERNAL` rail वाला समकक्ष भी रद्द हो जाता है, और `TRP` rail पर, जब प्रतिपक्ष पूछताछ स्वीकृत कर चुका हो, तब Didit रद्द करने की सूचना उसके पुष्टि कॉलबैक पर भेजता है।
जो ट्रांसफ़र पहले से `FINISHED`, `CANCELLED`, या `EXPIRED` में है, वह `409` लौटाता है।
जिस अनुरोध में न `payment_txn_id` है न कोई समर्थित `action`, वह `400` लौटाता है।

जो ट्रांसफ़र `GTR`, `VERIFYVASP` या `SYGNA` से गया, उसके लिए Didit रिस्पॉन्स के बाद ऑन-चेन हैश (या रद्द करने की सूचना) नेटवर्क को [उन्हीं पुनः प्रयासों](#डिलीवरी-और-पुनः-प्रयास) के साथ भेजता है; रिस्पॉन्स का `delivery` वह संदेश दिखाता है।

अगर आउटबाउंड ट्रांसफ़र अपने प्रतिपक्ष तक नहीं पहुँच सका - जो अभी `COUNTERPARTY_VASP_NOT_FOUND`, `COUNTERPARTY_VASP_NOT_REACHABLE`, या `NOT_ENOUGH_COUNTERPARTY_DATA` में है - तो पहले प्रतिपक्ष का डेटा बेहतर करें, उदाहरण के लिए गंतव्य वॉलेट प्रविष्टि में `travel_address` जोड़कर, प्रतिपक्ष की डायरेक्टरी प्रविष्टि के लिए एक [संपर्क](#संपर्क) जोड़कर, या [डायरेक्टरी](#डायरेक्टरी) में VASP को सूचीबद्ध करके।
फिर उसी endpoint पर `{"action": "resend"}` भेजें।
Didit पुष्टि की समय-सीमा फिर से शुरू करता है और ट्रांसफ़र पर संग्रहीत डेटा का उपयोग करके रूटिंग क्रम को फिर से शुरू से कतार में लगाता है: रिस्पॉन्स में ट्रांसफ़र `AWAITING_COUNTERPARTY` में वापस दिखता है (उसकी `timeline` में `resend queued` के साथ), और परिणाम `travel_rule.status.updated` webhook के रूप में आता है।
पहले प्रयास के अभी चल रहे होने के दौरान भेजा गया पुनः भेजने का अनुरोध उस प्रयास के निपटने के बाद भेजा जाता है।
कोई दूसरी स्थिति, या इनबाउंड ट्रांसफ़र, `409` लौटाता है।

```bash theme={null}
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"}'
```

जब [डिस्कवरी](#काउंटरपार्टी-खोज) प्रतिपक्ष को न खोज सके, तब आप खुद उसका नाम देने के लिए `{"action": "beneficiary_vasp", "beneficiary_vasp": "<directory VASP id>"}` भेजें (`GET /v3/travel-rule/vasps/` से `id`)।
ट्रांसफ़र उस VASP पर रूट होता है और फिर से भेजा जाता है।
केवल `COUNTERPARTY_VASP_NOT_FOUND`, `COUNTERPARTY_VASP_NOT_REACHABLE` या `NOT_ENOUGH_COUNTERPARTY_DATA` वाला आउटबाउंड ट्रांसफ़र इसे स्वीकार करता है; कोई दूसरी स्थिति `409` लौटाती है, और अज्ञात id `404` लौटाता है।

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

`COUNTERPARTY_VASP_NOT_FOUND` या `COUNTERPARTY_VASP_NOT_REACHABLE` वाला ट्रांसफ़र बताता है कि वह क्यों अटका है और उसे आगे क्या बढ़ाएगा, और हर बार लेन-देन पढ़ने पर यह बताता है।
[`GET /v3/transactions/{transaction_id}/`](https://docs.didit.me/hi/management-api/transactions/get) के `travel_rule` ब्लॉक में, [`POST /v3/transactions/`](https://docs.didit.me/hi/management-api/transactions/create) के `201` में, और [`GET /v3/transactions/`](https://docs.didit.me/hi/management-api/transactions/list) की हर पंक्ति में यह होता है, और [ट्रांसफ़र endpoint](https://docs.didit.me/hi/management-api/travel-rule/update-transfer.md) द्वारा लौटाए गए ट्रांसफ़र ऑब्जेक्ट में भी यह होता है:

* `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`।

`email_undeliverable` और `delivery_failed` एक विफल डिलीवरी से आते हैं और केवल `COUNTERPARTY_VASP_NOT_REACHABLE` पर दिखते हैं।
विफल डिलीवरी पहले `reason` तय करती है, इसलिए जिस प्रतिपक्ष को Didit ने ढूँढ लिया था, उसे कभी ऐसा नहीं बताया जाता कि वह नहीं मिला।
बाकी चार कारण खोज ट्रेस से आते हैं, और दोनों स्थितियों में लागू होते हैं।

| `reason` | क्या हुआ | `next_actions` |
| - | - | - |
| `email_undeliverable` | मेल प्रदाता ने अनुपालन ईमेल को अस्वीकार कर दिया और कोई पता आज़माने के लिए नहीं बचा: यह तब हुआ जब ईमेल भेजे जाने पर, रिमाइंडर भेजे जाने पर, या बाद में रिपोर्ट किए गए स्थायी बाउंस के रूप में। | `update_compliance_email`, फिर `resend` |
| `delivery_failed` | जिस रेल से डिलीवरी हो रही थी वह स्थायी रूप से विफल हो गई: कोई नेटवर्क रेल संदेश को अस्वीकार कर बैठी या पुनः प्रयास समाप्त हो गए, कोई `TRP` पहचान होस्ट जवाब नहीं दे पाया, या प्रतिपक्ष के `TRP` होस्ट ने पूछताछ स्वीकार नहीं की। | `resend` |
| `awaiting_end_user` | किसी भी खोज चरण ने ऐसा प्रतिपक्ष नहीं बताया जिस तक Didit पहुँच सके, इसलिए अंतिम उपयोगकर्ता से उसका नाम बताने को कहा जाता है। | `select_counterparty_vasp`, `declare_self_hosted`, `add_vasp_hint`, `resend` |
| `directory_match_no_route` | एक चरण ने [डायरेक्टरी](#डायरेक्टरी) प्रविष्टि का नाम लिया, लेकिन उस प्रविष्टि के पास आपके लिए Didit द्वारा उपयोग किया जा सकने वाला कोई रूट नहीं है। | `awaiting_end_user` के समान |
| `picked_member_without_proven_wallet` | अंतिम उपयोगकर्ता ने प्रतिपक्ष के रूप में Didit के किसी अन्य ग्राहक को चुना, लेकिन उस ग्राहक ने वॉलेट पर अपना नियंत्रण साबित नहीं किया है। | `awaiting_end_user` के समान |
| `no_directory_match` | खोज ट्रेस कोई अन्य कारण नहीं देता। | `awaiting_end_user` के समान |

| अगली कार्रवाई | क्या करें |
| - | - |
| `update_compliance_email` | ट्रांसफ़र endpoint पर `{"action": "update_compliance_email", "compliance_email": "..."}` के साथ प्रतिपक्ष का अनुपालन ईमेल फिर से दें। |
| `resend` | कुछ बदल जाने के बाद `{"action": "resend"}` के साथ रूटिंग फिर से चलाएँ। |
| `select_counterparty_vasp` | अंतिम उपयोगकर्ता [वॉलेट-स्वामित्व विजेट](https://docs.didit.me/hi/transaction-monitoring/wallet-ownership-widget.md) में गंतव्य VASP चुनता है। जब स्थानांतरण का विजेट सत्र खुला हो, तब `url` विजेट लिंक होता है। |
| `declare_self_hosted` | अंतिम उपयोगकर्ता उसी `url` पर विजेट में वॉलेट को स्व-होस्टेड घोषित करता है। |
| `add_vasp_hint` | Didit को बताएँ कि प्रतिपक्ष कौन है, VASP नाम, LEI, या Travel Address के साथ (उदाहरण के लिए गंतव्य वॉलेट की [एड्रेस-बुक प्रविष्टि](#वॉलेट-पता-पुस्तिका) पर `travel_address`), फिर पुनः भेजें। |

पुनः भेजने से स्थानांतरण आगे बढ़ता है, इसलिए उसका `reason` साफ़ हो जाता है।
जिस ट्रांज़िशन का कारण विफल डिलीवरी थी, उसकी टाइमलाइन प्रविष्टि `reason` के अंतर्गत वही मान रखती है।

यदि मेल प्रदाता [ऊपर दिए उदाहरण स्थानांतरण](#ट्रांसफ़र-भेजना) का अनुपालन ईमेल अस्वीकार कर दे, तो उसके लेन-देन का `travel_rule` ब्लॉक संक्षिप्त रूप में इस प्रकार पढ़ा जाता है:

```json theme={null}
{
  "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" }
  ]
}
```

यहाँ `delivery`, `reason` से मेल खाता है, क्योंकि भेजना स्वयं अस्वीकार हुआ था।
किसी रिमाइंडर पर अस्वीकृति, या बाद में रिपोर्ट हुआ बाउंस, `delivery.status` को `DELIVERED` पर ही रखता है: पहला ईमेल सचमुच चला गया था।
यह जानने के लिए कि स्थानांतरण क्यों अटका है, `reason` पढ़ें, `delivery` नहीं।

इसे ठीक करने के लिए प्रतिपक्ष का अनुपालन ईमेल फिर से दें, फिर पुनः भेजें:

```bash theme={null}
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"}'
```

`update_compliance_email` पता इस स्थानांतरण के `beneficiary_data.counterparty_vasp_email` के रूप में रखता है। यह केवल इसी स्थानांतरण का है और किसी डायरेक्टरी प्रविष्टि या संपर्क सूची में नहीं जुड़ता।
स्थिति नहीं बदलती, टाइमलाइन में `compliance email updated` जुड़ता है, और जब तक पुनः भेजने से अनुरोध नए पते पर नहीं जाता, स्थानांतरण `reason: email_undeliverable` बनाए रखता है।
इसे केवल वह बाहर जाने वाला स्थानांतरण स्वीकार करता है जो `COUNTERPARTY_VASP_NOT_FOUND`, `COUNTERPARTY_VASP_NOT_REACHABLE`, या `NOT_ENOUGH_COUNTERPARTY_DATA` स्थिति में हो। अन्य किसी भी स्थानांतरण पर उत्तर `409` होता है, और गायब या गलत बनावट वाला `compliance_email` `400` देता है।

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

जब आपका ग्राहक बताए कि गंतव्य उसका अपना स्व-होस्टेड (अनहोस्टेड) वॉलेट है, तो रूटिंग के खुद यह खोजने के बजाय कि उसके पीछे कोई VASP नहीं है, लेन-देन पर इसकी घोषणा करें: प्रतिपक्ष के भुगतान माध्यम का प्रकार `unhosted_wallet` सेट करें।

```bash theme={null}
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 लेन-देन से जुड़ा एक [वॉलेट-स्वामित्व विजेट](https://docs.didit.me/hi/transaction-monitoring/wallet-ownership-widget.md) सत्र अपने आप बनाता है और उसे लेन-देन के `action_required` ब्लॉक में लौटाता है। SDK [क्लाइंट-साइड सबमिशन](https://docs.didit.me/hi/transaction-monitoring/sdk-transaction-submission.md) पर उसे अपने आप लॉन्च करते हैं।
* जब ग्राहक वॉलेट पर नियंत्रण साबित कर देता है, तो स्थानांतरण लाभार्थी के नाम का मिलान करता है और `COMPLETED` पर पहुँचता है (या विफल मिलान पर `COUNTERPARTY_MISMATCHED_DATA` पर)।

यह EU TFR के स्व-होस्टेड वॉलेट दायित्व का API रूप है: प्रतिपक्ष VASP के साथ डेटा का आदान-प्रदान करने के बजाय अनहोस्टेड वॉलेट के स्वामित्व की पुष्टि करना।
यह घोषणा भुगतान माध्यम से पढ़ी जाती है, जो बाहर जाने वाले स्थानांतरण में **गंतव्य** पक्ष पर और आने वाले स्थानांतरण में **स्रोत** पक्ष पर होता है। दोनों स्थितियों में यह प्रतिपक्ष प्रतिभागी होता है।
घोषित-अनहोस्टेड स्थानांतरण पहले से अपने अंतिम, रेल-मुक्त पथ पर है, इसलिए `UNCONFIRMED_OWNERSHIP` ऐसी स्थिति नहीं है जिसे दोबारा भेजा जा सके। `action: "resend"` कॉल करने के बजाय स्वामित्व प्रमाण पूरा करें (या रद्द करें)।

## प्राप्त करना

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

ट्रांसफ़र दो मामलों में `UNCONFIRMED_OWNERSHIP` स्थिति में रहता है:

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

आपका एप्लिकेशन ट्रांसफ़र की पुष्टि या अस्वीकार करता है:

```bash theme={null}
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}'
```

बॉडी में `confirmed` (अनिवार्य, बूलियन) और वैकल्पिक `wallet_address` लिया जाता है।

यह endpoint इनमें से किसी भी स्थिति वाले ट्रांसफ़र को स्वीकार करता है, और किसी भी अन्य ट्रांसफ़र के लिए `409` लौटाता है, जिसमें `{"detail": "Transfer is not awaiting ownership confirmation."}` होता है:

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

ऐसे ट्रांसफ़र पर जिसे Didit ने स्वयं बनाया है (`INTERNAL` रेल, sunrise पंजीकरण, या घोषित स्व-होस्टेड वॉलेट):

* `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"}` होता है। हटाई गई प्रविष्टि पर भी यही लौटता है।

इनबाउंड `TRP` ट्रांसफ़र पर वही कॉल प्रतिपक्ष की इंक्वायरी का उत्तर देती है:

* `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` लौटाता है और ट्रांसफ़र अपनी वर्तमान स्थिति पर रहता है।
  स्वीकृति की स्थिति में भी वॉलेट पते की एड्रेस बुक प्रविष्टि बनाई जाती है या उसे सत्यापित के रूप में चिह्नित किया जाता है।

घोषित स्व-होस्टेड वॉलेट के लिए आप जो वॉलेट सत्यापित करते हैं, वह प्रतिपक्ष का होता है: आउटबाउंड निकासी का गंतव्य, या इनबाउंड जमा का स्रोत (प्रेषक का वॉलेट)।
Didit इसे प्रतिपक्ष के नाम से स्वामित्व-सत्यापित के रूप में एड्रेस बुक में जोड़ता है, इसलिए वॉलेट का मिलान प्रतिपक्ष के नाम से होता है (जमा के मामले में प्रेषक के नाम से)।
यदि एड्रेस बुक में वह वॉलेट पहले से किसी अलग धारक नाम के तहत है, तो ट्रांसफ़र इसके बजाय `COUNTERPARTY_MISMATCHED_DATA` पर चला जाता है।

यदि ट्रांसफ़र में कोई प्रतिपक्ष वॉलेट नहीं है, तो अनुरोध बॉडी में `wallet_address` भेजें।
जब न ट्रांसफ़र और न ही अनुरोध कोई वॉलेट पता देता है, तो अनुरोध `400` के साथ अस्वीकार हो जाता है।

```json theme={null}
{"confirmed": true, "wallet_address": "0xCounterpartyWallet01"}
```

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

उत्तर वही विस्तृत ट्रांसफ़र ऑब्जेक्ट है जो ऊपर बताया गया है।
नया `INTERNAL` ट्रांसफ़र यहाँ कभी इंतज़ार नहीं करता: वह केवल उस ग्राहक तक पहुँचता है जिसने पहले ही वॉलेट पर नियंत्रण सिद्ध किया है। वह पुराना `INTERNAL` ट्रांसफ़र, जो उस नियम से पहले का है और अब भी इंतज़ार में है, भेजने वाले का विवरण तब तक छिपाकर रखता है जब तक आप वॉलेट पर नियंत्रण सिद्ध नहीं करते (हस्ताक्षरित संदेश या परीक्षण जमा के रूप में), और तब तक उसकी पुष्टि करने पर `409` लौटता है। उसे अस्वीकार करना फिर भी काम करता है।
जब प्रतिपक्ष ने बताया कि वॉलेट स्व-होस्टेड है (आज [Didit Test VASP](https://docs.didit.me/hi/transaction-monitoring/travel-rule-sandbox.md) सैंडबॉक्स में यही उत्तर देता है), तो पुष्टि करने पर वॉलेट लाभार्थी के नाम से आपकी एड्रेस बुक में जुड़ता है और नाम मिलान चलता है: मिलान होने पर ट्रांसफ़र पूरा होता है और वॉलेट सत्यापित चिह्नित होता है।

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

Didit उन Travel Rule ट्रांसफ़र को भी प्राप्त कर सकता है जो कोई प्रतिपक्ष `GTR`, `VERIFYVASP` या `SYGNA` के ज़रिए भेजता है।
प्राप्ति हर नेटवर्क के लिए अलग से Didit द्वारा चालू की जाती है, और **आज कोई भी चालू नहीं है**: इसके लिए हर नेटवर्क पर Didit के endpoints का पंजीकरण भी चाहिए, और Didit के पास अभी इन नेटवर्कों की कोई सदस्यता नहीं है।
`TRUST` ट्रांसफ़र प्राप्त नहीं किए जा सकते।

एक बार नेटवर्क चालू होने पर, उससे आया संदेश इस तरह संभाला जाता है:

* **रूटिंग।** संदेश आपके एप्लिकेशन तक तब पहुँचता है जब वह उस नेटवर्क पर आपकी अपनी जुड़ी सदस्यता का प्रतिभागी कोड बताता है। Didit की अपनी सदस्यता को संबोधित संदेश केवल तभी आप तक पहुँचता है जब आप ही एकमात्र लाइव Didit ग्राहक हों जिसने लाभार्थी वॉलेट पर नियंत्रण सिद्ध किया है। बाकी सब कुछ अस्वीकार होता है, ताकि कोई ग्राहक किसी दूसरे ग्राहक का ट्रांसफ़र कभी न पाए।
* **निर्णय।** Didit आपके एप्लिकेशन पर इनबाउंड ट्रांसफ़र बनाता है और उसे [TRP इंक्वायरी](https://docs.didit.me/hi/transaction-monitoring/travel-rule-interoperability.md#trp-endpoints) की तरह तय करता है: वॉलेट मिलान, स्वामित्व, नाम मिलान और `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`)।

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

जब तक वॉलेट का स्वामित्व पुष्ट नहीं होता, इनबाउंड ट्रांसफ़र पर प्रतिपक्ष का व्यक्तिगत डेटा छोड़ा नहीं जाता, बल्कि मास्क करके लौटाया जाता है।
हर शब्द का पहला अक्षर रखा जाता है, जबकि वॉलेट, चेन और VASP रूटिंग पढ़ने योग्य रहते हैं।
`data_masked` का मान `true` होता है, और ट्रांज़ैक्शन विवरण, सूची और CSV एक्सपोर्ट में प्रतिपक्ष वाला पक्ष उसी तरह मास्क होता है।

स्वामित्व पुष्ट होने के बाद असली मान दिखते हैं, और `data_unmasked` एक ऑडिट एंट्री दर्ज करता है:

```json theme={null}
{
  "data_masked": false,
  "data_unmasked": { "at": "2026-10-17T10:00:00Z", "reason": "wallet_proof", "actor": "" }
}
```

`reason` के मान हैं: `ownership_confirmed`, `wallet_proof`, `address_book_match`, `own_verified_wallet`, `inquiry_approved` (आपने `TRP` पूछताछ या `GTR` या `Sygna` संदेश को स्वीकृत किया), `known_payment_method` (आपके अपने रिकॉर्ड में मौजूद अंतिम उपयोगकर्ता के वॉलेट ने उत्तर दिया) या `travel_address` (प्रति-वॉलेट Travel Address ने वॉलेट को नामित किया)।
`INTERNAL` इनबाउंड ट्रांसफ़र बनते ही `reason: wallet_proof` के साथ `data_unmasked` रखता है, क्योंकि केवल वही प्राप्तकर्ता इसे पाता है जिसने वॉलेट सिद्ध किया हो।
`actor` कंसोल उपयोगकर्ता का ईमेल या API कुंजी का लेबल होता है, और स्वचालित निर्णय के लिए खाली रहता है।
**Travel Rule transfers log** रिपोर्ट (CSV और PDF) स्वामित्व पुष्ट होने तक इनबाउंड ट्रांसफ़र के नाम उसी तरह मास्क करती है। नियामक को दाखिल की गई रिपोर्ट, जैसे goAML XML और रेगुलेटरी रिपोर्ट PDF, प्रतिपक्ष का असली डेटा रखती हैं।

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

`COUNTERPARTY_MISMATCHED_DATA` ट्रांसफ़र अब उन फ़ील्ड के नाम बताता है जो भिन्न हैं।
`data_match` में तुलना रहती है और `mismatched_fields` में फ़ील्ड की सूची।
दोनों में केवल फ़ील्ड के नाम और परिणाम होते हैं, मान कभी नहीं, इसलिए डेटा मास्क रहने पर भी ये पढ़ने योग्य रहते हैं:

```json theme={null}
{
  "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" }
    }
  }
}
```

टाइमलाइन एंट्री फ़ील्ड के नाम बताती है, उदाहरण के लिए "लाभार्थी की जन्म तिथि वॉलेट धारक से मेल नहीं खाती"।
`TRP` अस्वीकृति, मिसमैच के बाद, मूल VASP को बताती है कि कौन से फ़ील्ड भिन्न हैं, उदाहरण के लिए "लाभार्थी डेटा वॉलेट धारक से मेल नहीं खाता: नाम"।
दूसरे VASP को क्या पता चलता है, यह जानबूझकर सीमित है: जब तक नाम गलत है, केवल नाम बताया जाता है (`mismatched_fields: ["name"]`, और बाकी हर फ़ील्ड `not_compared`)। नाम मेल खाते ही हर भिन्न फ़ील्ड का नाम बताया जाता है। यह नियम `INTERNAL` विनिमय की भेजने वाली ओर और `TRP` अस्वीकृति, दोनों पर लागू होता है।
जो नाम दोनों ओर से गायब है, वह `not_compared` दिखता है और मिसमैच नहीं है। देश उसके नामित मान के आधार पर मेल खाता है, इसलिए `ES` और `ESP` मेल खाते हैं।

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

हर ऐसा ट्रांसफ़र जिसके नाम की तुलना हुई हो, `name_match` रखता है, और जिस टाइमलाइन एंट्री ने निर्णय लिया, वह उसी ऑब्जेक्ट को अपने `detail` के साथ रखती है:

```json theme={null}
{
  "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` विनिमय के दूसरे ग्राहक की प्रति में, नाम छिपे रहते हैं।

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

दो VASP किसी विवादित ट्रांसफ़र को ईमेल के बजाय Didit के भीतर सुलझा सकते हैं।
`GET` और `POST /v3/transactions/{transaction_id}/travel-rule/messages/` किसी ट्रांसफ़र के संदेशों की सूची दिखाते हैं और संदेश भेजते हैं:

```bash theme={null}
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 पढ़ें।
* प्रतिपक्ष को नए संदेश की सूचना देने वाला ईमेल अंग्रेज़ी में भेजा जाता है।

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

अपने नियंत्रण वाले वॉलेट पंजीकृत करें, ताकि इनबाउंड ट्रांसफ़र (`INTERNAL` चैनल, इनबाउंड `TRP` पूछताछ, और [जमा के बाद पंजीकरण](#डिपॉज़िट-के-बाद-सनराइज़-पंजीकरण)) उनसे मिलान कर सकें। इसके लिए `POST`/`GET /v3/travel-rule/wallet-addresses/` और `PATCH`/`DELETE /v3/travel-rule/wallet-addresses/{entry_uuid}/` का उपयोग करें।

```bash theme={null}
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
  }'
```

| फ़ील्ड | प्रकार | विवरण |
| - | - | - |
| `address` | string | वॉलेट पता। प्रत्येक एप्लिकेशन, `chain` और `memo` के लिए अद्वितीय (पते की तुलना केस-इनसेंसिटिव रूप से होती है) - डुप्लिकेट होने पर `400` लौटता है। XRP X-address को उसके क्लासिक पते और उसके टैग के रूप में सहेजा जाता है। [हैश द्वारा इंपोर्ट की गई](#बड़ी-संख्या-में-वॉलेट-इंपोर्ट-करना) एंट्री पर यह खाली रहता है। |
| `address_hash` | string | केवल-पठन। लोअरकेस किए गए पते का SHA-256, लोअरकेस हेक्स में। |
| `memo` | string | वैकल्पिक। गंतव्य टैग या memo जो [memo नेटवर्क](#memo-और-tag-नेटवर्क) पर वॉलेट का हिस्सा है; पूरे पते के लिए खाली। उपनाम: `destinationTag`। |
| `chain` | string | वैकल्पिक चेन पहचानकर्ता, अधिकतम 32 अक्षर। अपने ट्रांसफ़र में मौजूद वही token उपयोग करें (उदाहरण के लिए `ETH` या `BTC`), या किसी भी चेन पर ट्रांसफ़र से मेल खाने के लिए इसे खाली छोड़ें - नीचे दिया नोट देखें। Bitcoin पर पंजीकृत Lightning payee (node id या Lightning Address) को `LIGHTNING` पर लोअरकेस में सहेजा जाता है, जहाँ [Lightning](#lightning) ट्रांसफ़र मिलाए जाते हैं। |
| `holder_name` | string | वॉलेट धारक का नाम, लाभार्थी नाम मिलान के लिए उपयोग होता है। |
| `holder_vendor_data` | string | धारक के लिए आपका आंतरिक पहचानकर्ता। |
| `entity_type` | string | 16 अक्षरों तक का मुक्त पाठ, डिफ़ॉल्ट `"individual"`। |
| `travel_address` | string | वैकल्पिक। इस वॉलेट के लिए प्रतिपक्ष VASP का Travel Address, यदि आपको पता है। इससे Didit इस लाभार्थी के लिए ट्रांसफ़र ईमेल के बजाय `TRP` रेल के ज़रिए भेज सकता है। |
| `receiving_travel_address` | string | केवल-पठन। इस वॉलेट के लिए आपका अपना प्रति-वॉलेट Travel Address। इसे उस VASP को दें जो इस वॉलेट पर भेजता है: उसकी TRP पूछताछ फिर सीधे इसी वॉलेट का नाम लेती है। किसी ऐसे वॉलेट के लिए खाली जो किसी दूसरे VASP का दर्ज किया गया हो, जब Travel Rule बंद हो, और आपका VASP प्रोफ़ाइल सहेजे जाने से पहले। वॉलेट हटाए जाने के बाद यह जवाब देना बंद कर देता है। |
| `is_ownership_verified` | boolean | केवल-पठन। क्या इस पते का स्वामित्व सिद्ध हो चुका है ([wallet-ownership widget](https://docs.didit.me/hi/transaction-monitoring/wallet-ownership-widget.md) या स्व-घोषणा के ज़रिए)। |
| `self_declared` | boolean | केवल-लेखन, केवल `POST`। जब `true` हो, तो एंट्री `SELF_DECLARATION` प्रमाण के ज़रिए पहले से सत्यापित बनाई जाती है - इस पते पर आने वाले ट्रांसफ़र `UNCONFIRMED_OWNERSHIP` को पूरी तरह छोड़कर सीधे नाम मिलान पर जाते हैं। आपकी सेटिंग्स में `allow_self_declaration` बंद होने पर `400` लौटता है। |

`PATCH` केवल `holder_name`, `holder_vendor_data`, `entity_type` और `travel_address` स्वीकार करता है, और केवल ये चार फ़ील्ड लौटाता है।
`DELETE` एंट्री को हटा देता है (`204`) - उसका पता पुनः पंजीकरण के लिए मुक्त हो जाता है और वह तुरंत नए ट्रांसफ़र से मेल खाना बंद कर देती है।

> [!NOTE]
>
> पते का मिलान केस-इनसेंसिटिव तरीके से होता है, memo नेटवर्क पर उसका `memo` भी शामिल करता है, और `chain` द्वारा सीमित रहता है।
> जब किसी ट्रांसफ़र में chain हो, तो एंट्री तभी मेल खाती है जब उसका `chain` वही मान (केस-इनसेंसिटिव) हो या खाली हो।
> Chain नामों की तुलना टेक्स्ट के रूप में होती है, अनुवाद करके नहीं, इसलिए `ethereum` के रूप में सहेजी गई एंट्री उस ट्रांसफ़र से मेल नहीं खाती जिसकी chain `ETH` है।
> आउटबाउंड ट्रांसफ़र अपनी chain इस क्रम में लेते हैं: पहले `beneficiary_data.chain`, फिर `transaction_details.crypto_params.crypto_chain`, फिर `custom_properties.crypto_chain`, फिर करेंसी (उदाहरण के लिए `ETH`, या `USDT` और `USDC` के लिए `payment_reference_id` से अनुमानित chain)। यह केवल तब सेट होती है जब वह Didit द्वारा पहचानी जाने वाली chain हो, और after-deposit पंजीकरण अपने `chain` फ़ील्ड से लेते हैं, लोअरकेस में।
> इनबाउंड `TRP` पूछताछ chain को अनदेखा करती हैं: वे पते से मेल खाती हैं, या, जब पूछताछ कोई वॉलेट नहीं बताती, तो आपकी सत्यापित एंट्री के विरुद्ध लाभार्थी नाम से।
> [`POST .../travel-rule/ownership/`](#स्वामित्व-की-पुष्टि-करना) भी केवल पते से मेल खाता है।
> जब कई एंट्री मेल खाती हैं, तो `INTERNAL` रेल और after-deposit पंजीकरण पहले स्वामित्व-सत्यापित एंट्री को प्राथमिकता देते हैं, फिर सबसे पुरानी को, और आउटबाउंड `TRP` लुकअप वह सबसे पुरानी एंट्री लेता है जिसमें Travel Address सहेजा हो।
> इनबाउंड `TRP` पूछताछ और स्वामित्व endpoint मेल खाने वाली किसी भी एक एंट्री को लेते हैं, इसलिए जहाँ संभव हो, हर पते के लिए एक ही एंट्री रखें।
> `INTERNAL` रेल किसी भी एंट्री से मेल नहीं खाती, जब उस पते के लिए सत्यापित एंट्री एक से अधिक अन्य एप्लिकेशन में मौजूद हों।

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

एक कॉल में [`POST /v3/travel-rule/wallet-addresses/import/`](https://docs.didit.me/hi/management-api/travel-rule/import-wallet-addresses) के ज़रिए 10,000 तक वॉलेट इंपोर्ट करें, JSON के रूप में (`{"entries": [...]}` या सीधा array), या UTF-8 CSV फ़ाइल के रूप में, जिसका आकार अधिकतम 5 MB हो और जिसमें एक हेडर पंक्ति हो।
एक पंक्ति वॉलेट को उसके `address` से, `address_hash` से (लोअरकेस किए गए पते का SHA-256, 64 हेक्स या 44 base64 अक्षर), या दोनों से नामित करती है, साथ ही ऊपर दिए गए एंट्री फ़ील्ड में से कोई भी। केवल हैश भेजकर आप वॉलेट को उसका पता बताए बिना पंजीकृत कर सकते हैं: वह उस पते के ट्रांसफ़र से वैसे ही मेल खाता है जैसे कोई अन्य एंट्री, और उसका स्वामित्व [wallet-ownership widget](https://docs.didit.me/hi/transaction-monitoring/wallet-ownership-widget.md) से सिद्ध किया जा सकता है।

```bash theme={null}
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"
```

```text theme={null}
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
```

इंपोर्ट आइडेम्पोटेंट है और हर पंक्ति को भेजे गए क्रम में रिपोर्ट करता है: `created`, `existing` (वही वॉलेट, chain और memo पहले से बुक में है और उसे छुआ नहीं गया), `duplicate` (किसी पिछली पंक्ति को दोहराती है, जिसका नाम `duplicate_of_row` में आता है) या `failed` अपने `errors` के साथ। एक खराब पंक्ति बाकी को कभी विफल नहीं करती: जब कोई पंक्ति विफल न हो तो प्रतिक्रिया `200` होती है, और जब एक भी विफल हो तो `207`, गिनती `total`, `created`, `existing`, `duplicate` और `failed` में होती है। CSV का खाली सेल "नहीं भेजा गया" माना जाता है, और वे कॉलम जिन्हें इंपोर्ट नहीं पढ़ता अनदेखे रहते हैं, इसलिए किसी दूसरे टूल से एक्सपोर्ट किया गया डेटा जैसा है वैसा ही इंपोर्ट हो जाता है।

`GET /v3/travel-rule/transfers/` पर हर पंक्ति दो वॉलेट के साथ `originator_memo` और `beneficiary_memo` भी लौटाती है।

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

जब कोई भी प्रोटोकॉल रेल प्रतिपक्ष तक नहीं पहुँच सकती, तो Didit `EMAIL` पर लौट आता है: वह `beneficiary_data.counterparty_vasp_email` पर एक वन-टाइम पिकअप लिंक भेजता है (या `beneficiary_data.counterparty_vasp_name` से VASP डायरेक्टरी रजिस्ट्री में मिलान करके निकाला गया ईमेल)। प्राप्तकर्ता को Didit खाते या API कुंजी की ज़रूरत नहीं होती - लिंक का token ही प्रमाणीकरण है।
अनुरोध इस तरह भेजा जाता है:

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

यह लिंक एक होस्टेड पेज खोलता है जो लंबित एक्सचेंज दिखाता है और प्राप्तकर्ता के लिए इन दो सार्वजनिक endpoints को कॉल करता है।
[ऊपर दिए उदाहरण ट्रांसफ़र](#ट्रांसफ़र-भेजना) के लिए, पिकअप विवरण ये हैं:

```bash theme={null}
curl https://verification.didit.me/v3/travel-rule/pickup/{token}/
```

```json theme={null}
{
  "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
}
```

`reference` ट्रांसफ़र का `uuid` है। `originator_data` और उससे बना IVMS 101 `ivms_request` केवल वही प्रेषक फ़ील्ड रखते हैं जो आप [`data_sharing_fields`](#डेटा-साझाकरण) में साझा करते हैं; नाम और वॉलेट हमेशा शामिल होते हैं। जब आपने कोई परिवर्तित मूल्य नहीं भेजा हो, तब `fiat_amount` और `fiat_currency` खाली होते हैं, `contact` लिंक के `?contact=` मान को दोहराता है, और `decline_reasons` उन मानों की सूची देता है जिन्हें `decline_reason` स्वीकार करता है। `join_invitation.eligible` तब तक `true` रहता है जब तक प्रतिपक्ष के पास Didit से जुड़ने का सक्रिय निमंत्रण है; निमंत्रण का लिंक स्वयं केवल ईमेल में भेजा जाता है।

यह endpoint संग्रहीत राशि को हूबहू लौटाता है, इसलिए इसमें पूरे 18 दशमलव स्थान होते हैं, न कि उस छोटे रूप में जो लेन-देन विवरण ऑब्जेक्ट उपयोग करता है।

```bash theme={null}
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` होने पर, दिया गया `beneficiary_name` आपके नाम के नियम के अनुसार ट्रांसफ़र के `beneficiary_data.name` से मिलाया जाता है - मिलान होने पर `COMPLETED`, अन्यथा `COUNTERPARTY_MISMATCHED_DATA`। प्रतिपक्ष इसके बजाय `ivms_response` के रूप में पूरा IVMS 101 रिस्पॉन्स भेज सकता है; तब उसका लाभार्थी नाम `beneficiary_name` से ऊपर माना जाता है।
`decline` होने पर ट्रांसफ़र `COUNTERPARTY_VASP_GENERAL_DECLINE` पर चला जाता है। प्रतिपक्ष `decline_reasons` में से एक `decline_reason` दे सकता है, साथ में `decline_detail` (अधिकतम 512 अक्षर, `other` के लिए अनिवार्य), और आपके ट्रांसफ़र की टाइमलाइन इसे दर्ज करती है, जैसे `counterparty declined: The beneficiary is not our customer`।
रिस्पॉन्स परिणामी `{"status": "..."}` होता है, और अस्वीकृति के बाद `decline_reason` भी। प्रतिपक्ष के उत्तर देने के बाद दोनों endpoints `410` लौटाते हैं।
अज्ञात token के लिए दोनों endpoints `404` लौटाते हैं, और विंडो समाप्त होने के बाद `410` लौटाते हैं - या तो ट्रांसफ़र `AWAITING_COUNTERPARTY` से बाहर निकल चुका है, या उसकी पुष्टि की समय-सीमा (बनाए जाने या आखिरी बार फिर से भेजे जाने के बाद `confirmation_timeout_hours`) बीत चुकी है।

प्रतिपक्ष `GET` और `POST /v3/travel-rule/pickup/{token}/messages/` के साथ पिकअप लिंक के जरिए पढ़ता और उत्तर देता है।
इसके लिए API कुंजी की आवश्यकता नहीं है, यह केवल PDF, PNG, JPEG या WebP अटैचमेंट स्वीकार करता है, और लिंक की समय-सीमा खत्म होने या ट्रांसफ़र बंद होने पर `410` लौटाता है।
आपके भेजे गए संदेश में आपका VASP नाम `author` और अटैचमेंट के `uploaded_by` के रूप में दिखता है, कभी भी उसे भेजने वाले व्यक्ति या API कुंजी के नाम के रूप में नहीं।

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

कोई इनबाउंड डिपॉज़िट मूल VASP के Travel Rule डेटा से पहले पहुँच सकता है।
ऐसा डिपॉज़िट डेटा आने तक `AWAITING_COUNTERPARTY` या `NOT_ENOUGH_COUNTERPARTY_DATA` में रहता है।
जो डिपॉज़िट अभी भी प्रतीक्षा में हैं, उनकी सूची लेन-देन विशेषाधिकार वाली API कुंजी से लें:

```bash theme={null}
curl "https://verification.didit.me/v3/travel-rule/unmatched/" \
  -H "x-api-key: YOUR_API_KEY"
```

रिस्पॉन्स में वही पंक्तियाँ होती हैं जो `GET /v3/travel-rule/transfers/` में हैं, और केवल वे इनबाउंड डिपॉज़िट शामिल होते हैं जो मूल VASP के डेटा की प्रतीक्षा में हैं।

जब डेटा एक अलग प्राप्त संदेश के रूप में आ गया हो, तब दोनों को आप स्वयं जोड़ें:

```bash theme={null}
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>"}'
```

`{transaction_uuid}` डिपॉज़िट है।
`transaction_id` प्राप्त Travel Rule संदेश का लेन-देन है।
कॉल `{ "deposit": ..., "message": ... }` लौटाता है।
जब दोनों में से कोई भी लेन-देन मौजूद नहीं रहता, तब यह `404` लौटाता है, और जब दोनों में से कोई पक्ष पहले ही आगे बढ़ चुका हो, तब `travel_rule_match_conflict` ("This deposit can no longer be matched.") के साथ `409` लौटाता है।

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

जब कोई क्रिप्टो डिपॉज़िट किसी भी Travel Rule एक्सचेंज **से पहले** ऑन-चेन सेटल हो जाए - भेजने वाला VASP पहुँच से बाहर था, या आप पुराने डिपॉज़िट का बैकफ़िल कर रहे हैं - तो उसे `POST /v3/travel-rule/inbound/` के साथ बाद में पंजीकृत करें।

```bash theme={null}
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"
    }
  }'
```

`originating_vasp.travel_address` वास्तविक, चेकसम-वैध [Travel Address](#travel-address) होना चाहिए: प्लेसहोल्डर `"Invalid travel address."` के साथ `400` लौटाता है।
`originating_vasp.lei` खाली होना चाहिए या LEI प्रारूप में 20 अक्षर होने चाहिए (18 अक्षर या अंक, उसके बाद 2 अंक); इसके अलावा कुछ भी हो तो `"Invalid LEI: expected 20 alphanumeric characters (ISO 17442)."` के साथ `400` लौटता है।
Didit केवल यह प्रारूप जाँचता है, ISO 17442 के चेक अंक नहीं।

| फ़ील्ड | प्रकार | विवरण |
| - | - | - |
| `chain` | string | वह चेन जिस पर डिपॉज़िट सेटल हुआ, अधिकतम 32 अक्षर। Didit इसे छोटे अक्षरों में बदलता है और इसका उपयोग आपकी [एड्रेस बुक](#वॉलेट-पता-पुस्तिका) प्रविष्टियों से मिलान के लिए करता है, इसलिए वही token उपयोग करें जो आपकी प्रविष्टियों में है (`eth` उस प्रविष्टि से मेल खाता है जो `ETH` के रूप में संग्रहीत है)। यह भी तय करता है कि डिपॉज़िट को स्क्रीन किया जा सकता है या नहीं: `bitcoin`/`btc`, `ethereum`/`eth`, `solana`/`sol`, `tron`/`trx`, `polygon`/`matic`, `bsc`/`bnb`, `litecoin`/`ltc`, `ripple`/`xrp`, `bitcoin-cash`/`bch`, और `dogecoin`/`doge`। |
| `txid` | string | ऑन-चेन लेन-देन हैश। डुप्लिकेट पहचानने के लिए उपयोग होता है - वही `txid` + `wallet_address` नया डुप्लिकेट बनाने के बजाय मौजूदा ट्रांसफ़र लौटाता है। |
| `wallet_address` | string | वह गंतव्य वॉलेट जिस पर आपने डिपॉज़िट प्राप्त किया। XRP X-address को उसके क्लासिक पते और टैग में विभाजित किया जाता है। |
| `memo` | string | वैकल्पिक। [मेमो नेटवर्क](#memo-और-tag-नेटवर्क) पर डिपॉज़िट का डेस्टिनेशन टैग या मेमो: साझा डिपॉज़िट पते पर यह उस ग्राहक की पहचान बताता है जिससे डिपॉज़िट संबंधित है। |
| `amount` | string (decimal) | डिपॉज़िट राशि। |
| `currency` | string | डिपॉज़िट एसेट। |
| `originator_data` | object | भेजने वाले VASP से प्रेषक का विवरण, यदि ज्ञात हो, एक फ़्लैट ऑब्जेक्ट के रूप में: Didit `name` (या `full_name`), `first_name`, `last_name` और `vendor_data` पढ़ता है। |
| `beneficiary_data` | object | लाभार्थी का विवरण (आपका ग्राहक), एक फ़्लैट ऑब्जेक्ट के रूप में: Didit इसके `name` को मिलान की गई एड्रेस बुक प्रविष्टि के `holder_name` से मिलाता है, और इसमें `wallet_address` और `chain` जोड़ता है। |
| `utxo` | object | वैकल्पिक, केवल [UTXO चेन](#utxo-लेन-देन) के लिए। डिपॉज़िट लेन-देन के `inputs` और `outputs`: प्रेषक का वॉलेट `originator_data.wallet_address` होता है जब आप उसे घोषित करें, अन्यथा सबसे बड़ा इनपुट। |
| `originating_vasp` | object | वैकल्पिक `{ name, lei, travel_address }` जो भेजने वाले का वर्णन करता है। `lei` ऊपर दिए LEI प्रारूप से मेल खाना चाहिए और `travel_address` मान्य Travel Address होना चाहिए, नहीं तो अनुरोध `400` लौटाता है। इसे इस ट्रांसफ़र पर `metadata.originating_vasp` के रूप में रखा जाता है; यह कभी भी साझा [डायरेक्टरी](#डायरेक्टरी-में-प्रविष्टियाँ-कैसे-आती-हैं) प्रविष्टि नहीं बनाता या बदलता। |

Didit एक इनबाउंड `travelRule` लेन-देन बनाता है (या, यदि किसी इनबाउंड जमा में अभी तक Travel Rule ट्रांसफ़र नहीं है, तो उसी hash और वॉलेट वाला वह जमा दोबारा उपयोग करता है जिसे आपने पहले सबमिट किया था) और ट्रांसफ़र को पते और उसके memo के आधार पर आपकी [वॉलेट की पता पुस्तिका](#वॉलेट-पता-पुस्तिका) से मिलाता है:

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

[ऊपर दिए उदाहरण](#वॉलेट-पता-पुस्तिका) में पंजीकृत सत्यापित पता-बुक प्रविष्टि के साथ, रिस्पॉन्स यह है:

```json theme={null}
{
  "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"
  }
}
```

नए लेन-देन का `txn_id` `tr-in-` से शुरू होता है, इसके बाद `txid` के पहले 80 अक्षर और `txid` तथा वॉलेट से बने 12-अक्षरी hash आता है।
`created` `true` (HTTP `201`) होता है जब इस कॉल ने जमा पंजीकृत किया, और `false` (HTTP `200`) होता है जब वही `txid` और `wallet_address` पहले से पंजीकृत थे; उस स्थिति में मौजूदा ट्रांसफ़र बिना बदलाव के लौटाया जाता है।
सत्यापित-प्रविष्टि वाले पथ पर दोनों संक्रमण एंडपॉइंट के रिस्पॉन्स देने से पहले हो जाते हैं, इसलिए सिंक्रोनस रिस्पॉन्स में पहले से अंतिम `FINISHED` स्थिति दिखती है - बीच का `COMPLETED` चरण फिर भी ट्रांसफ़र की `timeline` में दर्ज होता है।
हर संक्रमण पर एक `travel_rule.status.updated` webhook फ़ायर होता है (`COMPLETED` और `FINISHED` में से हर एक एक-एक फ़ायर करता है)।
जब Didit ने नया लेन-देन बनाया, तो वह पहले [`transaction.created`](https://docs.didit.me/hi/integration/webhooks#इवेंट-प्रकार) भेजता है और उसके बाद ये इवेंट।
पंजीकरण पर कोई Travel Rule या निगरानी शुल्क नहीं लगता।
जब क्रिप्टो निगरानी सक्षम हो और `chain` ऐसी हो जिसे Didit स्क्रीन कर सकता है, तो नए बने जमा की भी स्क्रीनिंग होती है और वह एक बार वॉलेट सत्यापन और स्क्रीनिंग दर पर बिल किया जाता है।

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

`UNCONFIRMED_OWNERSHIP` से ट्रांसफ़र को बाहर निकालने के लिए - या किसी भी ट्रांसफ़र के आने से पहले वॉलेट को पहले से सत्यापित करने के लिए - `POST /v3/travel-rule/widget-session/` से एक होस्टेड वॉलेट-स्वामित्व विजेट बनाएँ और अपने ग्राहक को लौटाए गए `url` पर भेजें।
विजेट संदेश पर हस्ताक्षर (ERC-1271 और ERC-6492 के माध्यम से EVM स्मार्ट-कॉन्ट्रैक्ट खातों सहित), एक Satoshi test, एक स्क्रीनशॉट, या स्व-घोषणा के ज़रिए वॉलेट पर नियंत्रण सिद्ध करता है, और फिर मेल खाती पता-बुक प्रविष्टि को सत्यापित चिह्नित करता है ताकि एक्सचेंज आगे बढ़ सके।
स्क्रीनशॉट अपवाद है: वह अकेले कभी वॉलेट को सत्यापित नहीं करता, इसलिए आपकी अनुपालन टीम उसकी समीक्षा करती है और [`POST .../travel-rule/ownership/`](#स्वामित्व-की-पुष्टि-करना) से `UNCONFIRMED_OWNERSHIP` में पड़े ट्रांसफ़र की पुष्टि करती है।

पूरा प्रवाह, प्रूफ़ के तरीके, और यह महत्वपूर्ण नोट कि विजेट को हमेशा असली ब्राउज़र में खोलना चाहिए, कभी मोबाइल SDK वेबव्यू के भीतर नहीं, इसके लिए [वॉलेट स्वामित्व विजेट](https://docs.didit.me/hi/transaction-monitoring/wallet-ownership-widget.md) देखें।

## डायरेक्टरी

`GET /v3/travel-rule/vasps/` VASP डायरेक्टरी खोजता है: साझा डायरेक्टरी प्रविष्टियाँ और [Didit नेटवर्क](#didit-नेटवर्क) के सदस्य। हर पंक्ति बताती है कि आपका एप्लिकेशन उस VASP तक अभी किस तरह पहुँच सकता है।

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

```json theme={null}
{
  "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": []
    }
  ]
}
```

`search` किसी नाम या उपनाम के अंश, सटीक LEI, या डोमेन (`counterparty.example` या उस पर कोई URL) से मेल खाता है। परिणामों को इन पैरामीटर से सीमित करें:

| पैरामीटर | प्रभाव |
| - | - |
| `network` | `GTR`, `TRUST`, `VERIFYVASP`, `SYGNA` या `TRISA`: केवल वही प्रविष्टियाँ जो उस नेटवर्क की सदस्य डायरेक्टरी में अभी सूचीबद्ध हैं। |
| `jurisdiction` | ISO 3166 alpha-2 या alpha-3 देश कोड। |
| `reachable` | `true`: केवल वे VASP जिन तक आपके एप्लिकेशन का उपलब्ध रूट है। `false`: केवल वे प्रविष्टियाँ जिन तक वह अभी नहीं पहुँच सकता। |
| `kind` | `directory` साझा प्रविष्टियों के लिए, `didit` Didit नेटवर्क सदस्यों के लिए। |
| `risk` | `LOW`, `MEDIUM` या `HIGH`: केवल वे डायरेक्टरी प्रविष्टियाँ जिनका `risk_level` वही बैंड है। देखें [स्कोर और जोखिम स्तर](#स्कोर-और-जोखिम-स्तर)। |
| `responsiveness` | `RESPONSIVE`, `UNRESPONSIVE` या `UNKNOWN`: केवल वे डायरेक्टरी प्रविष्टियाँ जिनका `responsiveness.status` वही है। देखें [प्रतिक्रियाशीलता](#प्रतिक्रियाशीलता)। |

Didit नेटवर्क के सदस्यों को स्कोर नहीं दिया जाता, इसलिए `risk` और `responsiveness` केवल डायरेक्टरी प्रविष्टियाँ लौटाते हैं। परिणाम नाम के अनुसार क्रमबद्ध होते हैं और `limit` (डिफ़ॉल्ट `50`) और `offset` से पेजिनेट किए जाते हैं। अज्ञात नेटवर्क, देश कोड, जोखिम बैंड या प्रतिक्रियाशीलता स्थिति पर `400` आता है, जो फ़ील्ड का नाम बताता है। `GET /v3/travel-rule/vasps/{vasp_id}/` अपने `id` से एक पंक्ति लौटाता है। आपकी अपनी VASP प्रोफ़ाइल आपके अपने परिणामों में कभी नहीं दिखती।

`dd_status`, `dd_score`, `dd_score_breakdown`, `dd_assessed_at`, `dd_score_semantic`, `risk_level`, `responsiveness` और `essential_checks` किसी डायरेक्टरी प्रविष्टि का साझा ड्यू डिलिजेंस मूल्यांकन देते हैं। `decision`, `entity_screening` और `questionnaires` आपके एप्लिकेशन के अपने VASP रिकॉर्ड हैं, और कोई अन्य ग्राहक इन्हें नहीं देखता। हर एक का अर्थ जानने के लिए देखें [प्रतिपक्ष की ड्यू डिलिजेंस](#प्रतिपक्ष-ड्यू-डिलिजेंस)। इन्हें इनलाइन शर्तों में जाँचने के बजाय, [प्रतिपक्ष नियम फ़ील्ड्स](#नियम-फ़ील्ड-और-प्रीसेट) के ज़रिए इन पर निर्णय लें। Didit नेटवर्क के सदस्यों को स्कोर नहीं दिया जाता: `dd_status` `COMPLETED` है, `dd_score` `null` है, `risk_level` खाली है और ब्रेकडाउन खाली है।

### रूट

`routes` उन तरीकों की सूची देता है जिनसे आपका एप्लिकेशन VASP तक डिलीवर कर सकता है, उसी क्रम में जिसमें रूटिंग लैडर उन्हें आज़माता है। `reachable` `true` होता है जब कम से कम एक रूट `available` हो:

* `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 नेटवर्क सदस्य के लिए।

`TRISA` सूची `networks` के अंतर्गत दिखती है और बताती है कि VASP TRISA पर किसके रूप में सूचीबद्ध है। लेकिन Didit के पास TRISA रेल नहीं है, इसलिए वह कभी रूट नहीं होती।

सैंडबॉक्स एप्लिकेशन केवल [Didit Test VASP](https://docs.didit.me/hi/transaction-monitoring/travel-rule-sandbox.md) पर भेजता है, इसलिए उसके लिए कोई डायरेक्टरी रूट उपलब्ध नहीं है: हर रूट `reason: sandbox_application` के साथ `unavailable` है, हर पंक्ति में `reachable: false` है, और `reachable=true` कोई पंक्ति नहीं लौटाता।

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

एक ब्रांड जो कई विनियमित कानूनी इकाइयों के ज़रिए काम करता है, वह एक पंक्ति है जिसकी `entities` वे कानूनी इकाइयाँ हैं जो उसके ट्रांसफ़र प्राप्त करती हैं। कोई इकाई-पंक्ति `umbrella` में अपने ब्रांड की ओर इशारा करती है। जो ट्रांसफ़र ब्रांड का नाम लेता है, वह उसकी सभी इकाइयों में से किसी एक पर जाता है। चुनाव इस क्रम में होता है: वह इकाई जो `beneficiary_data.counterparty_vasp_jurisdiction` में बताए गए क्षेत्राधिकार में है; नहीं तो वह इकाई जिससे गंतव्य वॉलेट के साथ जुड़ी [ब्लॉकचेन एनालिटिक्स एट्रिब्यूशन](#ब्लॉकचेन-एनालिटिक्स-एट्रिब्यूशन) जुड़ी है; नहीं तो ब्रांड की एकमात्र इकाई, जब कोई क्षेत्राधिकार नहीं बताया गया हो। केवल तभी उस इकाई का पहुँच योग्य होना ज़रूरी है। अगर वह पहुँच योग्य नहीं है, तो ट्रांसफ़र कभी किसी दूसरी इकाई या ब्रांड पर नहीं जाता। जब कोई इकाई फ़िट नहीं होती (दो समान रूप से फ़िट होती हैं, या बताया गया क्षेत्राधिकार उनमें से किसी में नहीं है), तो ब्रांड का अपना रूट इस्तेमाल होता है। उसके बिना ट्रांसफ़र `COUNTERPARTY_VASP_NOT_FOUND` हो जाता है। कौन-सी कानूनी इकाई प्रेषक का डेटा प्राप्त करेगी, यह कभी अनुमान से तय नहीं होता, और न ही इस आधार पर कि किस इकाई का कोई संपर्क मौजूद है।

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

### संपर्क

`contacts` वे पते हैं जिन पर `EMAIL` रेल ईमेल भेजती है। `scope: platform` संपर्क हर Didit ग्राहक की सेवा करते हैं: Didit इन्हें क्यूरेट करता है (`source: staff`), या VASP के अपने डोमेन का कोई पता अपने रिस्पॉन्स लिंक के ज़रिए किसी अनुरोध का उत्तर दे चुका है (`source: learned`)। `scope: application` संपर्क आपके एप्लिकेशन के लिए निजी हैं: वे जो आप जोड़ते हैं (`source: application`), और VASP के अपने डोमेन से बाहर का वह पता जिसने आपके किसी अनुरोध का उत्तर दिया (`source: learned`)। कोई ट्रांसफ़र पहले आपके एप्लिकेशन का अपना संपर्क ईमेल करता है, फिर वह प्लेटफ़ॉर्म संपर्क जिसने पहले उत्तर दिया है (`verified_at` सेट), और फिर बाकी।

अपने एप्लिकेशन के संपर्कों को प्रतिपक्ष संपर्क API से प्रबंधित करें:

```bash theme={null}
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` आता है।

`is_invalid: true` के साथ वह संपर्क चिह्नित होता है जिसका ईमेल बाउंस हुआ या जिसने शिकायत की, और उसके साथ `invalid_reason` (`hard_bounce`, `soft_bounce`, `spam_complaint` या `suppressed`), `invalid_detail` और `invalid_at` आते हैं, और `EMAIL` rail उसे छोड़ देता है। प्लेटफ़ॉर्म के संपर्कों और API कुंजी द्वारा जोड़े गए संपर्कों में `created_by` खाली रहता है।

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

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

कोई ग्राहक किसी प्रतिपक्ष के बारे में जो डेटा रिपोर्ट करता है, जैसे इनबाउंड `originating_vasp` या Travel Address, वह उसी ग्राहक के ट्रांसफ़र पर रहता है और कभी साझा प्रविष्टि नहीं बदलता। प्रविष्टियों का मिलान पहले LEI से होता है, फिर सटीक नाम या उपनाम से, और उन्हें डुप्लिकेट बनाने के बजाय समृद्ध किया जाता है।

### Didit नेटवर्क

आपका VASP प्रोफ़ाइल Didit नेटवर्क का सदस्य है, इसलिए अन्य Didit ग्राहक इसे डायरेक्टरी में और अंतिम उपयोगकर्ता के VASP पिकर में तभी पाते हैं जब नीचे की सभी शर्तें पूरी हों:

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

`INTERNAL` rail स्वयं उस वॉलेट पर डिलीवर होती है जिसे आपने सिद्ध किया है, जैसा [ट्रांसफ़र भेजना](#ट्रांसफ़र-भेजना) में बताया गया है: इसके लिए आपका एप्लिकेशन लाइव होना चाहिए, Travel Rule चालू होना चाहिए और `is_discoverable` होना चाहिए, बाकी शर्तों की आवश्यकता नहीं है।

`GET /v3/travel-rule/settings/` `didit_network` लौटाता है, जिसमें `listed` और `compliance_email_confirmed` होते हैं, और `missing` में वह हर शर्त होती है जो अभी पूरी नहीं हुई (`travel_rule_off`, `sandbox_application`, `not_discoverable`, `legal_name_missing`, `compliance_email_missing`, `compliance_email_unconfirmed`, `excluded_by_staff`, `internal_organization`)।

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

जब भी आपका ट्रांसफ़र प्रतिपक्ष को `counterparty_vasp_lei` या `counterparty_vasp_name` से नामित करता है (उपनाम भी काम करता है), तब आउटबाउंड रूटिंग डायरेक्टरी प्रविष्टि की जाँच करती है। हर प्रविष्टि में उस हर नेटवर्क के लिए एक पहचानकर्ता होता है जिस पर उस तक पहुँचा जा सकता है, एक सत्यापित TRP endpoint और उसके अनुपालन संपर्क होते हैं, और `routes` दिखाता है कि इनमें से कौन आपका एप्लिकेशन इस्तेमाल कर सकता है। आप [प्रतिपक्ष रिज़ॉल्यूशन फ़ील्ड्स](#प्रतिपक्ष-समाधान-फ़ील्ड) में बताए गए स्पष्ट फ़ील्ड पास करके किसी एक ट्रांसफ़र पर डायरेक्टरी को हमेशा बायपास कर सकते हैं।

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

आपके ग्राहकों का धन किसी दूसरे VASP तक पहुँचने से पहले आपको यह जानना होगा कि वह VASP कौन है और क्या आप उसे स्वीकार करते हैं। किसी प्रतिपक्ष की ड्यू डिलिजेंस की दो परतें होती हैं:

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

आपके अपने रिकॉर्ड डायरेक्टरी प्रविष्टि और [Didit नेटवर्क](#didit-नेटवर्क) के किसी सदस्य, दोनों के लिए काम करते हैं। उन्हें उस `id` से संबोधित करें जो [डायरेक्टरी](#डायरेक्टरी) दिखाती है।

| endpoint | यह क्या करता है |
| - | - |
| `GET` / `PUT` / `DELETE /v3/travel-rule/vasps/{vasp_id}/decision/` | प्रतिपक्ष पर [आपका निर्णय](#प्रतिपक्ष-पर-आपका-निर्णय) पढ़ें, सेट करें या हटाएँ। |
| `GET` / `POST /v3/travel-rule/vasps/{vasp_id}/screening/` | प्रतिपक्ष की नवीनतम [स्क्रीनिंग](#प्रतिपक्ष-स्क्रीनिंग) पढ़ें, या एक नई स्क्रीनिंग चलाएँ। |
| `GET` / `POST /v3/travel-rule/vasps/{vasp_id}/questionnaires/` | प्रतिपक्ष के साथ अपनी [ड्यू-डिलिजेंस प्रश्नावलियों](#ड्यू-डिलिजेंस-प्रश्नावली) की सूची देखें, या एक प्रश्नावली भेजें। |
| `GET /v3/travel-rule/transfers/?counterparty={vasp_id}` | उस प्रतिपक्ष के साथ आपके [ट्रांसफ़र](#एक-प्रतिपक्ष-वाले-स्थानांतरण)। |

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

`dd_score` 0 से 100 तक होता है, और **यह जितना अधिक होगा, उतना ही अधिक सुरक्षित होगा**। हर परिणाम इसे `dd_score_semantic` में बताता है, जिसका मान हमेशा `higher_is_safer` होता है। `risk_level` वह श्रेणी है जिसमें स्कोर आता है:

| `risk_level` | `dd_score` |
| - | - |
| `LOW` | 70 या उससे अधिक |
| `MEDIUM` | 40 से 69 |
| `HIGH` | 40 से कम |

स्कोर सात घटकों का योग है। `dd_score_breakdown` हर घटक को `{points, max, reason, detail}` के रूप में दिखाता है: `max` घटक का भार है, `reason` एक मशीन-पठनीय कोड है जिसका आप अनुवाद कर सकते हैं, और `detail` एक पंक्ति की अंग्रेज़ी व्याख्या है।

| घटक | भार | स्कोरिंग का तरीका | `reason` कोड |
| - | - | - | - |
| `jurisdiction` | 25 | प्रविष्टि का देश डिफ़ॉल्ट उच्च-जोखिम अधिकार-क्षेत्र सूची (`IRN`, `PRK`, `SYR`, `AFG`, `RUS`, `MMR`) में न हो तो पूरे अंक, सूची में हो तो कोई अंक नहीं, और देश अज्ञात हो तो आधे अंक। | `jurisdiction_not_high_risk`, `jurisdiction_high_risk`, `jurisdiction_unknown` |
| `verification` | 15 | प्रविष्टि की Didit सत्यापन स्थिति (`dd_status`): `COMPLETED` के लिए पूरे अंक, `IN_PROGRESS` के लिए आधे, `NOT_STARTED` के लिए एक-चौथाई, और `REJECTED` के लिए कोई अंक नहीं। | `dd_status_completed`, `dd_status_in_progress`, `dd_status_not_started`, `dd_status_rejected` |
| `protocol` | 15 | जब कोई नेटिव प्रोटोकॉल रेल प्रविष्टि तक पहुँचता है (TRP endpoint या `INTERNAL` रेल) तो पूरे अंक, केवल ईमेल फ़ॉलबैक से पहुँचने पर 40 प्रतिशत, और पहुँच योग्य रेल न होने पर कोई अंक नहीं। | `native_rail`, `email_only`, `no_rail` |
| `lei` | 10 | वैध LEI रिकॉर्ड पर पूरे अंक, और उसके बिना कोई अंक नहीं। | `lei_valid`, `lei_missing` |
| `history` | 10 | प्रविष्टि के तय हो चुके आदान-प्रदानों में से सफल आदान-प्रदानों का अनुपात, और कोई तय आदान-प्रदान न होने पर आधे अंक। | `history`, `no_history` |
| `essentials` | 15 | तय की गई [आवश्यक जाँचों](#आवश्यक-जाँचें) में से उत्तीर्ण जाँचों का अनुपात, और जब तक कोई जाँच तय न हो तब आधे अंक। | `essential_checks`, `no_essential_checks` |
| `responsiveness` | 10 | `RESPONSIVE` के लिए पूरे अंक, `UNRESPONSIVE` के लिए कोई अंक नहीं, और `UNKNOWN` के लिए आधे। देखें [प्रतिक्रियाशीलता](#प्रतिक्रियाशीलता)। | `responsive`, `unresponsive`, `responsiveness_unknown` |

अंक एक दशमलव तक और कुल योग पूर्ण संख्या तक गोल किया जाता है। `history` वही अनुरोध पढ़ता है जो [प्रतिक्रियाशीलता](#प्रतिक्रियाशीलता) पढ़ती है, बिना किसी समय-सीमा के: `COMPLETED` या `FINISHED` आदान-प्रदान सफल माना जाता है, और `EXPIRED`, `COUNTERPARTY_MISMATCHED_DATA` या `COUNTERPARTY_VASP_GENERAL_DECLINE` आदान-प्रदान असफल। रद्द करना प्रेषक का अपना कार्य है, इसलिए यह कभी नहीं गिना जाता।

Didit मूल्यांकन की तब दोबारा गणना करता है जब प्रविष्टि के साथ कोई आदान-प्रदान पूरा होता है, समाप्त होता है, समय-सीमा समाप्त होती है, मेल नहीं खाता या अस्वीकार होता है, जब प्रविष्टि रीफ़्रेश या क्यूरेट की जाती है, और साप्ताहिक डायरेक्टरी अद्यतन में हर प्रविष्टि के लिए। `dd_assessed_at` बताता है कि यह अंतिम बार कब चला; जिस प्रविष्टि का अभी तक मूल्यांकन नहीं हुआ है उसमें `dd_assessed_at` नहीं होता, `dd_score` `0` होता है और `risk_level` खाली होता है, इसलिए कच्चे स्कोर के बजाय `risk_level` पढ़ें। Didit नेटवर्क के सदस्यों का स्कोर नहीं किया जाता: उनका `dd_score` `null` होता है, `risk_level` खाली होता है और `dd_score_breakdown` खाली होता है।

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

`essential_checks` चार जाँचों की एक संक्षिप्त रिपोर्ट है, जिन्हें Didit हर डायरेक्टरी प्रविष्टि पर चलाता है, और ये केवल प्लेटफ़ॉर्म के सत्यापित स्रोतों से होती हैं, ग्राहक द्वारा बताए गए डेटा से कभी नहीं:

| जाँच `id` | कब पास होती है |
| - | - |
| `registration` | कोई आधिकारिक रजिस्टर VASP को सूचीबद्ध करता है: EU की अंतरिम MiCA रजिस्टर ऑफ़ क्रिप्टो-एसेट सर्विस प्रोवाइडर्स, सार्वजनिक TRISA डायरेक्टरी, या जारी किए गए LEI वाला वैश्विक LEI रजिस्टर। |
| `licence` | MiCA रजिस्टर में VASP के लिए एक ऐसा प्राधिकरण दर्ज है जो समाप्त नहीं हुआ है। |
| `domain` | प्रविष्टि का डोमेन उसके TRP endpoint से, या उसके रजिस्टर में दी गई वेबसाइट से मेल खाता है। |
| `lei` | प्रविष्टि का LEI रिकॉर्ड सक्रिय और जारी किया गया है, और उसका कानूनी नाम और देश प्रविष्टि से मेल खाते हैं। |

`checks` में हर जाँच अपना `status` (`pass`, `fail`, या `unknown`, जब रिकॉर्ड पर कोई स्रोत उसका निर्णय नहीं कर सकता), एक मशीन-पठनीय `reason` और एक पंक्ति का अंग्रेज़ी `detail` बताती है। `passed`, `failed`, `unknown` और `total` उन्हें गिनते हैं, `level` `essential` होता है, और `checked_at` बताता है कि रिपोर्ट कब बनी। `essentials` घटक तय जाँचों में से उत्तीर्ण जाँचों का अनुपात स्कोर करता है, इसलिए `unknown` जाँच प्रविष्टि के पक्ष या विपक्ष में नहीं गिनी जाती। जब तक साप्ताहिक डायरेक्टरी अद्यतन किसी प्रविष्टि की पहली बार जाँच नहीं करता, रिपोर्ट खाली रहती है, और Didit नेटवर्क के किसी सदस्य के लिए यह हमेशा खाली रहती है।

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

`responsiveness` बताता है कि VASP Travel Rule अनुरोधों का जवाब देता है या नहीं:

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

`total` उन अनुरोधों की गिनती है जो Didit के ग्राहकों ने पिछले 90 दिनों में VASP की ओर शुरू किए और जिनका परिणाम तय हो चुका है, और `answered` उनमें से वे जिनका VASP ने जवाब दिया:

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

| `status` | कब |
| - | - |
| `UNKNOWN` | विंडो में 5 से कम निर्णय लिए गए अनुरोध हैं, ताकि एक भी समाप्त अनुरोध किसी VASP को लेबल न करे। |
| `UNRESPONSIVE` | VASP ने अपने निर्णय लिए गए अनुरोधों में से 10 प्रतिशत से कम का उत्तर दिया। |
| `RESPONSIVE` | अन्यथा। |

Didit नेटवर्क के सदस्य Didit के भीतर उत्तर देते हैं और हमेशा शून्य गणना के साथ `UNKNOWN` दिखाते हैं। किसी गैर-प्रतिक्रियाशील प्रतिपक्ष पर कार्रवाई करने के लिए [गैर-प्रतिक्रिया नीति](#सनराइज़-और-गैर-प्रतिक्रियाशील-नीतियाँ) या `travel-rule-counterparty-unresponsive` [प्रीसेट](#नियम-फ़ील्ड-और-प्रीसेट) का उपयोग करें।

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

`PUT /v3/travel-rule/vasps/{vasp_id}/decision/` के साथ प्रतिपक्ष पर अपनी अनुपालन टीम का निर्णय दर्ज करें:

```bash theme={null}
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"}'
```

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

| `decision` | अर्थ | इस पर कार्य करने वाला प्रीसेट |
| - | - | - |
| `APPROVED` | आपकी टीम ने प्रतिपक्ष को मंज़ूरी दे दी है। | कोई नहीं |
| `RESTRICTED` | उसे किए गए ट्रांसफ़र समीक्षा के बाद आगे बढ़ सकते हैं। | `travel-rule-counterparty-restricted` उन्हें समीक्षा के लिए रोक देता है। |
| `BLOCKED` | आपकी टीम ने प्रतिपक्ष को अस्वीकार कर दिया है। | `travel-rule-counterparty-blocked` उन्हें अस्वीकार कर देता है। |

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

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

प्रतिपक्ष स्क्रीनिंग स्वयं प्रतिपक्ष VASP की, कंपनी के रूप में, प्रतिबंधों और प्रतिकूल मीडिया के लिए जाँच करती है। यह **ऑप्ट-इन है और इसके लिए शुल्क लिया जाता है**: इसे अपनी [सेटिंग्स](#सेटअप) में `counterparty_screening_enabled` से चालू करें। जब तक यह बंद है, कुछ भी स्क्रीन या बिल नहीं होता।

```bash theme={null}
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}'
```

```json theme={null}
{
  "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 स्क्रीनिंग की [कीमत](https://docs.didit.me/hi/getting-started/pricing.md) लगती है। `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`। इनमें से कोई भी बिलिंग नहीं करता।

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

Didit की मानक प्रश्नावली के साथ प्रतिपक्ष से उसके ड्यू-डिलिजेंस उत्तर माँगें। `POST /v3/travel-rule/vasps/{vasp_id}/questionnaires/` इसे प्रतिपक्ष के लिए रिकॉर्ड पर दर्ज एक अनुपालन पते पर ईमेल करता है, उत्तर पेज के एकल-उपयोग लिंक के साथ:

```bash theme={null}
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"}'
```

```json theme={null}
{
  "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` के रूप में दिखाती है। ये केवल आपके एप्लिकेशन के लिए निजी हैं।

फ़ॉर्म संस्करण `1` में ये बारह प्रश्न हैं:

| प्रश्न आईडी | प्रश्न |
| - | - |
| `legal_name` | कानूनी इकाई का नाम और निगमन का अधिकार-क्षेत्र। |
| `licensing` | वर्चुअल एसेट सेवाओं के लिए धारित लाइसेंस या पंजीकरण: हर अधिकार-क्षेत्र में नियामक, लाइसेंस संख्या और स्थिति। |
| `jurisdictions` | वे अधिकार-क्षेत्र जहाँ आप संचालन करते हैं, और वे जहाँ आपको बाहर रखा गया है या प्रतिबंधित किया गया है। |
| `aml_program` | आपके AML/CFT प्रोग्राम का सारांश: नीतियाँ, प्रक्रियाएँ और अंतिम स्वतंत्र ऑडिट या समीक्षा की तिथि। |
| `compliance_officer` | आपके अनुपालन अधिकारी का नाम और भूमिका, और उनसे संपर्क करने का तरीका। |
| `sanctions_screening` | आप ग्राहकों और प्रतिपक्षों को प्रतिबंधों और प्रतिकूल मीडिया के विरुद्ध कैसे स्क्रीन करते हैं: प्रदाता या सूचियाँ, आवृत्ति और एस्केलेशन। |
| `transaction_monitoring` | आप संदिग्ध गतिविधि के लिए लेन-देन की निगरानी कैसे करते हैं: टूलिंग, थ्रेशोल्ड और रिपोर्ट दाखिल करने की प्रक्रिया। |
| `travel_rule` | आप Travel Rule का पालन कैसे करते हैं: उपयोग किए जाने वाले प्रोटोकॉल और नेटवर्क, और किसी अनुरोध पर आपका सामान्य प्रतिक्रिया समय। |
| `custody` | ग्राहक संपत्तियों के लिए कस्टडी व्यवस्था: योग्य कस्टोडियन, बीमा और पृथक्करण। |
| `ownership` | 25 प्रतिशत या उससे अधिक के वास्तविक स्वामी, और कोई भी मूल कंपनी या छत्र इकाई। |
| `record_keeping` | Travel Rule और लेन-देन डेटा के लिए रिकॉर्ड रखने की प्रक्रिया और प्रतिधारण अवधि। |
| `data_protection` | अनुपालन के लिए साझा किए गए व्यक्तिगत डेटा की सुरक्षा आप कैसे करते हैं, और वह कहाँ संग्रहीत है। |

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

[`GET /v3/travel-rule/transfers/?counterparty={vasp_id}`](https://docs.didit.me/hi/management-api/travel-rule/list-transfers) आपके एप्लिकेशन के ऐसे Travel Rule स्थानांतरणों की सूची देता है जिनमें एक ही प्रतिपक्ष है, सबसे नए पहले। सूची डायरेक्टरी में दिखने वाले `id` के आधार पर सूचीबद्ध करती है: आपके वे स्थानांतरण जिनका प्रतिपक्ष वह डायरेक्टरी प्रविष्टि है, या आपके `INTERNAL` विनिमय जो उस Didit नेटवर्क सदस्य के साथ हुए हैं। जो मान मान्य आईडी नहीं है, उसका उत्तर `400` होता है।
हर पंक्ति में `status` के ठीक बाद `reason` होता है: स्थानांतरण का अपना [`reason`](#ट्रांसफ़र-क्यों-अटका-है)। इससे सूची से ही पता चल जाता है कि कोई वापस लौटा अनुपालन ईमेल है या ऐसा प्रतिपक्ष जिसका कोई मार्ग नहीं है, और आपको हर स्थानांतरण खोलना नहीं पड़ता।

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

जब कोई स्थानांतरण समाप्त होता है (जब वह `AWAITING_COUNTERPARTY` स्थिति में था और `confirmation_timeout_hours` बीत चुके हैं), तो `timeout_outcome` तय करता है कि उसके लेन-देन के साथ क्या होगा। दो सेटिंग्स आपको समय-सीमा समाप्ति के दो सामान्य कारणों के लिए अलग-अलग व्यवहार करने देती हैं:

| सेटिंग | तब लागू होती है जब प्रतिपक्ष ऐसी डायरेक्टरी प्रविष्टि हो जो |
| - | - |
| `sunrise_policy` | `sunrise_jurisdictions` में सूचीबद्ध अधिकार-क्षेत्र में हो: ऐसा देश जो अभी Travel Rule लागू नहीं करता, इसलिए VASP उत्तर देने के लिए बाध्य नहीं है। |
| `non_responsive_policy` | जिसका `responsiveness.status` `UNRESPONSIVE` हो। |

दोनों `HOLD`, `REJECT` या `PROCEED` स्वीकार करते हैं, जिनका अर्थ `timeout_outcome` वाला ही है, या खाली स्ट्रिंग, जिसका अर्थ है `timeout_outcome` का पालन करना। दोनों डिफ़ॉल्ट रूप से खाली होते हैं, इसलिए जब तक आप कोई एक सेट नहीं करते, कुछ नहीं बदलता:

```bash theme={null}
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 नेटवर्क सदस्य के साथ का स्थानांतरण या ऐसे प्रतिपक्ष का स्थानांतरण शामिल है जिसकी कोई डायरेक्टरी प्रविष्टि नहीं है।

`sunrise_jurisdictions` केवल पढ़ने योग्य है और अभी `["CO", "KH", "VN"]` है। सनराइज़ अवधि में केवल ये देश गिने जाते हैं: कोई भी अन्य अधिकार-क्षेत्र, और खाली या अज्ञात अधिकार-क्षेत्र, `timeout_outcome` का पालन करता है, ताकि कोई प्रतिपक्ष गलती से आपकी सनराइज़ नीति न पा जाए। समाप्त स्थानांतरण की टाइमलाइन में वह परिणाम दिखता है जो लागू हुआ था, जैसे `sunrise_policy=PROCEED (counterparty jurisdiction CO does not enforce the Travel Rule yet)`. आपके नियम समाप्ति के बाद भी चलते हैं, इसलिए `PROCEED` के अंतर्गत EU TFR नियम `tr_eu_expired_review` जैसा नियम लेन-देन को अब भी समीक्षा में ले जा सकता है।

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

चार [नियम](https://docs.didit.me/hi/transaction-monitoring/rules.md) फ़ील्ड बताते हैं कि आपका एप्लिकेशन उस प्रतिपक्ष के बारे में क्या जानता है जिस तक किसी लेन-देन का Travel Rule विनिमय पहुँचा: उसकी डायरेक्टरी प्रविष्टि, या `INTERNAL` विनिमय के लिए वह Didit ग्राहक जिसने उसे प्राप्त किया। जब विनिमय किसी ज्ञात प्रतिपक्ष तक नहीं पहुँचा, तो हर फ़ील्ड खाली होता है।

| फ़ील्ड | मान |
| - | - |
| `counterparty_dd_status` | आपका [निर्णय](#प्रतिपक्ष-पर-आपका-निर्णय): `APPROVED`, `RESTRICTED` या `BLOCKED`; इकाई अपने ब्रांड के निर्णय का अनुसरण करती है। जब आपने कोई निर्णय नहीं लिया हो, तो खाली। कभी किसी और ग्राहक का निर्णय नहीं। |
| `counterparty_risk_level` | प्रविष्टि का `risk_level` (`LOW`, `MEDIUM` या `HIGH`), या `HIGH` जब प्रतिपक्ष की आपकी अपनी [स्क्रीनिंग](#प्रतिपक्ष-स्क्रीनिंग) चिह्नित हो। जिस प्रविष्टि का आकलन अभी नहीं हुआ, उसके लिए खाली। Didit नेटवर्क सदस्य के लिए भी खाली, जब तक उसकी आपकी स्क्रीनिंग चिह्नित न हो। |
| `counterparty_jurisdiction` | प्रतिपक्ष का देश, डायरेक्टरी प्रविष्टि या Didit नेटवर्क सदस्य की प्रोफ़ाइल से। ISO-2 और ISO-3 दोनों कोड की तुलना की जाती है, जैसे अन्य देश फ़ील्ड। |
| `counterparty_responsiveness` | प्रविष्टि का `responsiveness.status`: `RESPONSIVE`, `UNRESPONSIVE` या `UNKNOWN`। Didit नेटवर्क सदस्य के लिए खाली। |

`travel_rule` बंडल के पाँच प्रीसेट इन फ़ील्ड पर कार्य करते हैं। इन्हें **Transactions → Rules → Library** से Business Console में या [नियम लाइब्रेरी API](https://docs.didit.me/hi/management-api/transactions/rules-install.md) के साथ इंस्टॉल करें:

| `library_key` | ट्रिगर | डिफ़ॉल्ट कार्रवाई |
| - | - | - |
| `travel-rule-counterparty-blocked` | `counterparty_dd_status` का मान `BLOCKED` है | +90 स्कोर, `DECLINED` |
| `travel-rule-counterparty-restricted` | `counterparty_dd_status` का मान `RESTRICTED` है | +50 स्कोर, `IN_REVIEW` |
| `travel-rule-counterparty-high-risk` | `counterparty_risk_level` का मान `HIGH` है | +40 स्कोर, `IN_REVIEW` |
| `travel-rule-counterparty-high-risk-jurisdiction` | `counterparty_jurisdiction` डिफ़ॉल्ट उच्च-जोखिम सूची (`IRN`, `PRK`, `SYR`, `AFG`, `RUS`, `MMR`) में है | +60 स्कोर, `IN_REVIEW` |
| `travel-rule-counterparty-unresponsive` | `counterparty_responsiveness` का मान `UNRESPONSIVE` है | +30 स्कोर, `IN_REVIEW` |

पाँचों प्रीसेट केवल Travel Rule लेन-देन पर लागू होते हैं।

## वेबहुक

एक webhook गंतव्य को `travel_rule.status.updated` की सदस्यता दें, ताकि आपके एप्लिकेशन के हर ट्रांसफ़र के हर स्थिति परिवर्तन की सूचना मिले, चाहे वह बहिर्गामी हो या आवक, और इसमें `INTERNAL` रेल के लेग भी शामिल हैं।
रूटिंग, लेन-देन बनाने का रिस्पॉन्स लौटने के बाद चलती है, इसलिए `COUNTERPARTY_VASP_NOT_FOUND`, `COUNTERPARTY_VASP_NOT_REACHABLE` जैसे परिणाम, या वह `INTERNAL` एक्सचेंज जो तुरंत निपट जाता है, लेन-देन बनाने वाले रिस्पॉन्स में नहीं, बल्कि इसी इवेंट के माध्यम से आप तक पहुँचते हैं।

```json theme={null}
{
  "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"
}
```

जब तक रेल नहीं चुनी जाती, `rail` खाली रहता है।
एक ही लेन-देन के लिए, Didit `transaction.created` के बाद `travel_rule.status.updated` भेजता है: जब Didit लेन-देन बनाता है (आपका `POST /v3/transactions/`, sunrise पंजीकरण, आवक `TRP` पूछताछ, या `INTERNAL` रेल का आवक लेग), तो वह पहले `transaction.created` भेजता है।
हर इवेंट अलग-अलग डिलीवर किया जाता है और उसका अलग से पुनः प्रयास किया जाता है, इसलिए जिस `transaction.created` को पुनः प्रयास की ज़रूरत पड़ी, वह किसी स्थिति इवेंट के बाद भी पहुँच सकता है: अपने हैंडलर को `transaction_id` के आधार पर कुंजीबद्ध करें, और जब कोई स्थिति इवेंट कोई ऐसा लेन-देन ID बताए जो आपने पहले नहीं देखा, तब लेन-देन को पढ़ें।
`TRUST` के ज़रिए भेजे गए ट्रांसफ़र को `COMPLETED` इवेंट नहीं मिलता: TRUST कोई ऐसा जवाब वापस नहीं भेजता जिसे Didit पढ़ सके, इसलिए जब तक भेजना विफल न हो या आप उसे रद्द न करें, उसका आख़िरी इवेंट `EXPIRED` होता है। `GTR`, `VERIFYVASP` और `SYGNA` पर, इवेंट उस जवाब का पालन करता है जिसे Didit नेटवर्क से पढ़ता है।
सैंडबॉक्स एप्लिकेशन भी यह इवेंट भेजते हैं, जिसमें `"environment": "sandbox"` होता है; वह ट्रांसफ़र जिसका जवाब [Didit Test VASP](https://docs.didit.me/hi/transaction-monitoring/travel-rule-sandbox.md) ने दिया, उसमें `rail: "TEST_VASP"`, `test_vasp: true` और `test_vasp_scenario` होते हैं।

पूरी इवेंट सूची, हस्ताक्षर सत्यापन और पुनः प्रयास नीति के लिए [webhook गाइड](https://docs.didit.me/hi/integration/webhooks.md#इवेंट-प्रकार) देखें।

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

Travel Rule शुल्क **शुरू होने वाले प्रत्येक बहिर्गामी एक्सचेंज के लिए \$0.02** है, जो लेन-देन बनने पर एक बार लिया जाता है, चाहे उसके बाद एक्सचेंज कितने भी स्थिति परिवर्तनों से गुज़रे। `resend` से यह शुल्क दोबारा नहीं लगता।

* यह बहिर्गामी `travelRule` लेन-देन पर लागू होता है, ऐसे एप्लिकेशन पर जिसमें Travel Rule चालू है, और जिसकी राशि आपके `threshold_amount` के बराबर या उससे अधिक है, इसलिए Didit उसके लिए प्रबंधित एक्सचेंज शुरू करता है। स्व-होस्टेड वॉलेट या आपके उपयोगकर्ता के अपने सत्यापित वॉलेट पर भेजा गया ट्रांसफ़र भी इसमें गिना जाता है: स्वामित्व प्रमाण ही उसका एक्सचेंज है।
* बाकी हर बहिर्गामी लेन-देन जिसमें Travel Rule डेटा हो, वह मानक Transaction Screening के रूप में बिल होता है। यह आपके प्लान में उसकी [मासिक लेन-देन सीमा](https://docs.didit.me/hi/getting-started/pricing.md#लेन-देन-निगरानी-kyt) तक शामिल है, और इसके बाद प्रत्येक लेन-देन के लिए \$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 प्रति कॉल)। आपका प्रदाता अंतर्निहित लुकअप का बिल सीधे आपको भेजता है।
* **विफल लुकअप का कभी शुल्क नहीं लिया जाता**, दोबारा भेजने पर बिना नए कॉल या शुल्क के, दर्ज एट्रिब्यूशन फिर से उपयोग होता है, और सैंडबॉक्स एप्लिकेशन से कभी शुल्क नहीं लिया जाता।

तो जिस बहिर्गामी ट्रांसफ़र को एट्रिब्यूशन चाहिए, उसकी लागत \$0.02 (Travel Rule) + एक Wallet Verification & Screening शुल्क होती है। और जब दोनों उत्पाद चालू हों, तब एनालिटिक्स कॉल और उसका शुल्क केवल एक बार होता है।

## EU TFR नियम बंडल

`travel_rule_eu_tfr` बंडल में चार प्रीसेट नियम शामिल हैं, जो EU TFR दायित्वों के लिए विशेष रूप से तैयार किए गए हैं।
अन्य सभी [प्रीसेट बंडल](https://docs.didit.me/hi/transaction-monitoring/rules-library.md) की तरह, इसे Business Console में **Transactions → Rules → Library** के अंतर्गत सक्षम करें।

| नियम (`library_key`) | ट्रिगर | कार्रवाई |
| - | - | - |
| `tr_eu_mismatch_hold` | ट्रांसफ़र की स्थिति `COUNTERPARTY_MISMATCHED_DATA` है | `+50` स्कोर, लेन-देन `IN_REVIEW` पर सेट |
| `tr_eu_unverified_selfhosted_review` | ट्रांसफ़र की स्थिति `UNCONFIRMED_OWNERSHIP` है और डिफ़ॉल्ट मुद्रा में राशि कम से कम `1000` है | लेन-देन `IN_REVIEW` पर सेट |
| `tr_eu_vasp_not_found_score` | ट्रांसफ़र की स्थिति `COUNTERPARTY_VASP_NOT_FOUND` है | `+25` स्कोर, `travel-rule-sunrise` टैग |
| `tr_eu_expired_review` | ट्रांसफ़र की स्थिति `EXPIRED` है | लेन-देन `IN_REVIEW` पर सेट |

ये नियम हर संबंधित स्थिति-परिवर्तन पर चलते हैं: ट्रांसफ़र बनने पर, स्वामित्व की पुष्टि पर, ईमेल पिकअप रिस्पॉन्स मिलने पर, और समाप्ति जाँच प्रक्रिया से। इस तरह जो ट्रांसफ़र कभी हल नहीं होता, वह चुपचाप निपटाए जाने के बजाय अनुपालन समीक्षा के लिए सामने आता रहता है।

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

Travel Rule अनुपालन एक पहचान की समस्या है जो भुगतान का रूप धरे हुए है, और Didit के पास पहचान पहले से मौजूद है:

* **हाथ में सत्यापित डेटा।** हर ट्रांसफ़र से संबंधित पक्ष `vendor_data` द्वारा उस KYC प्रोफ़ाइल से जुड़ा होता है जिसे Didit ने ऑनबोर्डिंग के समय सत्यापित किया था (दस्तावेज़ OCR, लाइवनेस, चेहरा मिलान), ताकि आप उसी प्लेटफ़ॉर्म पर सत्यापित फ़ील्ड से `originator_data` बना सकें।
  जिस उपयोगकर्ता के पास स्वीकृत KYC सत्यापन है, Didit आपके द्वारा टाइप किए गए मान के बजाय सत्यापित पहचान भेजता है (देखें [सत्यापित डेटा और प्रोवेनेंस](#सत्यापित-डेटा-और-स्रोत))।
* **जोखिम भरे ट्रांसफ़र के लिए अतिरिक्त बायोमेट्रिक जाँच।** एक [नियम](https://docs.didit.me/hi/transaction-monitoring/rules.md) किसी भी उच्च-मूल्य ट्रांसफ़र को तब तक रोक सकता है जब तक उपयोगकर्ता ऑनबोर्डिंग के समय लिए गए चेहरे के विरुद्ध बायोमेट्रिक पुनः जाँच पास न कर ले। निकासी के क्षण में खाता अधिग्रहण का यह सबसे मज़बूत संभव जवाब है। [व्यावहारिक उदाहरण](https://docs.didit.me/hi/transaction-monitoring/sdk-transaction-submission.md#उदाहरण-उच्च-मूल्य-निकासी-के-लिए-बायोमेट्रिक-अतिरिक्त-जाँच) देखें।
* **एक डिवाइस ग्राफ़।** SDK से सबमिट किए गए ट्रांसफ़र में KYC सत्रों के समान डिवाइस इंटेलिजेंस होती है, इसलिए "नया डिवाइस + उच्च राशि + पहली बार का लाभार्थी" एक ही नियम है, डेटा-वेयरहाउस जॉइन नहीं।
* **एक ही जगह पर स्क्रीनिंग, नियम, केस और एक्सचेंज।** वॉलेट स्क्रीनिंग, जो counterparty VASP की पहचान करती है, वही स्क्रीनिंग है जिसे आपके नियम और विश्लेषक देखते हैं: एक शुल्क, एक कंसोल, एक ऑडिट ट्रेल।
* **प्रकाशित मूल्य निर्धारण।** [प्रति आउटबाउंड एक्सचेंज \$0.02](#मूल्य-निर्धारण), कोई वॉल्यूम स्तर नहीं, कोई सेल्स कॉल नहीं।

## FAQ

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

> [accordion] क्या Didit VASP-से-VASP आदान-प्रदान स्वयं चलाता है, या वह किसी अन्य नेटवर्क द्वारा हैंडशेक पूरा होने के बाद केवल Travel Rule डेटा रिकॉर्ड करता है?
>
> Didit आदान-प्रदान स्वयं चलाता है।
> जब आप `travelRule` ट्रांसफ़र सबमिट करते हैं, तो Didit लाइव प्रतिपक्ष डिस्कवरी करता है, मूल प्रेषक और लाभार्थी का डेटा उस रेल पर प्राप्तकर्ता VASP को भेजता है जो उसे ले जाती है, और ट्रांसफ़र को `COMPLETED` तभी चिह्नित करता है जब प्रतिपक्ष की ओर से उसकी पुष्टि हो जाती है। यह एक प्रबंधित हैंडशेक है, सेटलमेंट के बाद का लॉग नहीं।
> `TRUST` को छोड़कर हर रेल पर प्रतिपक्ष का उत्तर प्रोसेस किया जाता है, और TRUST केवल भेजता है, इसलिए उस पर किया गया ट्रांसफ़र पूरा होने के बजाय समय-सीमा समाप्त हो जाता है। `GTR`, `VERIFYVASP` और `SYGNA` पर Didit उत्तर को नेटवर्क के रिस्पॉन्स से पढ़ता है या हर 5 मिनट में पोल करता है, और इन पर अभी तक कोई एक्सचेंज लाइव नेटवर्क के विरुद्ध पूरा नहीं हुआ है। `TRP` पर, यदि प्रतिपक्ष तुरंत उत्तर नहीं देता, तो Didit के सार्वजनिक TRP होस्ट की ज़रूरत होती है, जो अभी लाइव नहीं है (देखें [Travel Rule नेटवर्क](https://docs.didit.me/hi/transaction-monitoring/travel-rule-networks.md))।
> Didit हर एक्सचेंज का पूरा रिकॉर्ड और अनुपालन स्थिति भी रखता है (13 अवस्थाओं वाला [जीवनचक्र](#जीवनचक्र), [webhooks](#वेबहुक), और एक ऑडिट ट्रेल)।
> यदि आप Travel Rule को अपनी प्रक्रिया से चलाना पसंद करते हैं, तो Didit इसके बजाय डेटा को निष्क्रिय रूप से रिकॉर्ड कर सकता है, जिसे आप रिकॉर्ड की अपनी एकमात्र प्रणाली के रूप में उपयोग कर सकते हैं (नीचे निष्क्रिय रिकॉर्डिंग वाला प्रश्न देखें)।
> दोनों मोड उपलब्ध हैं: सक्रिय एक्सचेंज तब चलता है जब आप [सेटिंग्स](#सेटअप) में `is_enabled: true` सेट करते हैं (डिफ़ॉल्ट रूप से यह `false` होता है), और तब तक Didit डेटा निष्क्रिय रूप से रिकॉर्ड करता है।

> [accordion] क्या यह आदान-प्रदान Didit का अपना है, या यह किसी बाहरी इंटरऑपरेबिलिटी प्रदाता (Notabene, Sygna, VerifyVASP, TRP) पर निर्भर है?
>
> यह Didit का अपना है। Didit अपना Travel Rule Protocol (TRP) कार्यान्वयन चलाता है, जो सार्वजनिक होस्ट लाइव होने पर `trp.didit.me` पर उपलब्ध होगा (यह अभी उत्तर नहीं देता, इसलिए आज प्रतिपक्ष TRP के ज़रिये आप तक नहीं पहुँच सकते)। यह उद्योग के नेटवर्क प्रोटोकॉल सीधे लागू करता है: `GTR` (Global Travel Rule), `TRUST`, `VerifyVASP`, और `Sygna Bridge` (जिसे Didit सीधे लागू करता है, जिसमें Sygna का ECIES-एन्क्रिप्टेड IVMS 101 और साइन किए गए अनुमति अनुरोध शामिल हैं)। Didit किसी एक तृतीय-पक्ष इंटरऑपरेबिलिटी लेयर का रीसेलर नहीं है। किसी विशेष सदस्यता नेटवर्क पर मौजूद प्रतिपक्ष तक पहुँचना अनिवार्य रूप से उसी नेटवर्क के ज़रिये होता है, क्योंकि Travel Rule में कोई एक सार्वभौमिक चैनल नहीं है। फिर भी डिस्कवरी, हैंडशेक, सत्यापन और रिकॉर्ड रखना सब Didit ही करता है।
> आज हर नेटवर्क रेल के लिए आपकी अपनी सदस्यता चाहिए, और `TRUST` केवल भेजता है: देखें [अवलोकन](#अवलोकन)।

> [accordion] Didit किन Travel Rule नेटवर्क और प्रोटोकॉल को सपोर्ट करता है?
>
> नेटिव रूप से लागू किए गए, कड़े प्राथमिकता क्रम में आज़माए जाते हैं: `INTERNAL` (दोनों VASP Didit पर), `TRP` (OpenVASP Travel Rule Protocol), `GTR`, `TRUST`, `VerifyVASP`, `Sygna Bridge`, और ऐसे प्रतिपक्ष के लिए `EMAIL` फ़ॉलबैक जिनके पास कोई टूलिंग नहीं है।
> नेटवर्क रेल के लिए आज आपकी अपनी सदस्यता चाहिए, `TRUST` केवल भेजता है, और किसी नेटवर्क पर रिसीविंग अभी चालू नहीं है: देखें [Travel Rule नेटवर्क](https://docs.didit.me/hi/transaction-monitoring/travel-rule-networks.md)।
> CODE, TRISA, Notabene, और Veriscope Didit के Marketplace में एक्सेस-अनुरोध टाइल के रूप में दिखते हैं, इनका अभी कोई इंटीग्रेशन नहीं है।
> पूरी रूटिंग तालिका के लिए देखें [Didit एक्सचेंज कैसे रूट करता है](https://docs.didit.me/hi/transaction-monitoring/travel-rule-interoperability.md#didit-एक्सचेंज-को-कैसे-रूट-करता-है), और हर नेटवर्क आज कहाँ तक पहुँचता है, इसके लिए देखें [Travel Rule नेटवर्क](https://docs.didit.me/hi/transaction-monitoring/travel-rule-networks.md)।

> [accordion] मुझे किस नेटवर्क का उपयोग करना चाहिए, और क्या मुझे अपनी सदस्यताओं की आवश्यकता है?
>
> `TRP` वह आधार है जिसकी हम अनुशंसा करते हैं: इसके लिए कोई साझा सदस्यता नहीं चाहिए। अपना [Travel Address](#travel-address) साझा करने पर TRP बोलने वाला कोई भी VASP आप तक पहुँच सकता है। और जब किसी प्रतिपक्ष को केवल वॉलेट पते से जाना जाता है, तब [blockchain-analytics attribution](#ब्लॉकचेन-एनालिटिक्स-एट्रिब्यूशन) उसे TRP पर तभी रूट करता है जब एट्रिब्यूट की गई डायरेक्टरी प्रविष्टि में पहले से TRP endpoint हो।
> आउटबाउंड में, Didit [TRP asset identifiers](#trp-एसेट-पहचानकर्ता) के अंतर्गत सूचीबद्ध एसेट इसी पर भेजता है। जो प्रतिपक्ष तुरंत उत्तर नहीं देता, उसके लिए Didit के सार्वजनिक TRP होस्ट की ज़रूरत होती है, जो अभी लाइव नहीं है।
> सदस्यता नेटवर्क के लिए चुनाव इस आधार पर करें कि आपके प्रतिपक्ष कहाँ काम करते हैं: GTR का वैश्विक स्तर पर व्यापक कवरेज है, TRUST मुख्यतः US VASP पर केंद्रित है, और VerifyVASP (जो अब Sygna Bridge भी चलाता है) एशिया में मज़बूत कवरेज रखता है।
> हाँ, आज आपको अपनी सदस्यता चाहिए: Didit के पास इन नेटवर्क पर अभी कोई प्लेटफ़ॉर्म सदस्यता नहीं है, और वह प्रदाता के रूप में ऑनबोर्ड हो रहा है।
> अपनी सदस्यता **Marketplace** में कनेक्ट करें। आप किसी एक नेटवर्क तक सीमित नहीं हैं।
> याद रखें कि `TRUST` केवल भेजता है, इसलिए उस पर किया गया ट्रांसफ़र पूरा नहीं होता, और किसी भी नेटवर्क पर कोई एक्सचेंज अभी लाइव नेटवर्क के विरुद्ध पूरा नहीं हुआ है।

> [accordion] जब मेरे पास केवल वॉलेट पता हो, तब Didit प्रतिपक्ष VASP कैसे खोजता है?
>
> एक रिज़ॉल्यूशन चेन के ज़रिये: कोई अन्य Didit ग्राहक जिसने उस वॉलेट पर नियंत्रण साबित किया हो (`INTERNAL` रेल), फिर संग्रहीत Travel Address के लिए आपकी अपनी [वॉलेट एड्रेस बुक](#वॉलेट-पता-पुस्तिका), फिर प्रोटोकॉल और नेटवर्क रेल, और अंत में [blockchain-analytics attribution](#ब्लॉकचेन-एनालिटिक्स-एट्रिब्यूशन)।
> यदि ट्रांसफ़र में केवल गंतव्य वॉलेट है, तो Didit उसे blockchain-analytics डेटा के विरुद्ध रिज़ॉल्व करता है ताकि प्रतिपक्ष एक्सचेंज या कस्टडी सेवा की पहचान हो सके, और उसे [VASP डायरेक्टरी](#डायरेक्टरी) में सूचीबद्ध करता है।
> ट्रांसफ़र अपने आप तभी रूट होता है जब उस डायरेक्टरी एंट्री में पहले से कोई रूट हो, जैसे `TRP` endpoint। अन्यथा वह `COUNTERPARTY_VASP_NOT_FOUND` पर समाप्त होता है, और प्रतिपक्ष का नाम रिकॉर्ड हो जाता है। एक रूट मौजूद होने के बाद आप उसे फिर से भेज सकते हैं, उदाहरण के लिए उस वॉलेट की अपनी एड्रेस बुक एंट्री में प्रतिपक्ष का `travel_address` संग्रहीत करने के बाद ([TRP asset identifiers](#trp-एसेट-पहचानकर्ता) के अंतर्गत सूचीबद्ध एसेट के लिए)।

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

> [accordion] Travel Rule की लागत कितनी है, और क्या यह मेरे KYC या सत्यापन प्लान में शामिल है?
>
> Travel Rule एक अलग, उपयोग-आधारित उत्पाद है।
> यह पहचान सत्यापन में शामिल नहीं है।
> यह \*\*हर आउटबाउंड एक्सचेंज की शुरुआत पर $0.02** लेता है ([प्रकाशित मूल्य निर्धारण](#मूल्य-निर्धारण), कोई वॉल्यूम टियर नहीं, कोई सेल्स कॉल नहीं)।
>         जब रूटिंग के लिए प्रतिपक्ष VASP की पहचान हेतु ब्लॉकचेन एनालिटिक्स लुकअप की ज़रूरत होती है, तब वह लुकअप एक बार [attribution दर](#एट्रिब्यूशन-मूल्य-निर्धारण) पर चार्ज होता है: प्रबंधित लुकअप के लिए $0.15 से, या मौजूदा प्रदाता कुंजी के साथ \$0.02।
> यदि क्रिप्टो निगरानी ने उसी वॉलेट को पहले ही स्क्रीन कर लिया हो, तो उसका दोबारा बिल नहीं होता।
> आपके थ्रेशोल्ड से कम का ट्रांसफ़र, या ऐसा ट्रांसफ़र जो Travel Rule बंद होने पर रिकॉर्ड हुआ हो, इसके बजाय Transaction Screening के रूप में बिल होता है। इनबाउंड ट्रांसफ़र, जैसे वे लेग जो Didit लाभार्थी की ओर से बनाता है, पर Travel Rule शुल्क नहीं लगता।

> [accordion] जब Travel Rule और क्रिप्टो निगरानी दोनों चलते हैं, तो क्या मुझसे दोहरा शुल्क लिया जाएगा?
>
> नहीं।
> `travelRule` लेन-देन का बिल एक ही लाइन पर बनता है: जब वह आउटबाउंड एक्सचेंज शुरू करता है, तब Travel Rule शुल्क (\$0.02), और अन्यथा मानक Transaction Screening। blockchain-analytics लुकअप एक बार चार्ज होता है: यदि क्रिप्टो निगरानी ने लेन-देन पर गंतव्य वॉलेट को पहले ही स्क्रीन कर लिया हो, तो [attribution](#ब्लॉकचेन-एनालिटिक्स-एट्रिब्यूशन) उस संग्रहीत परिणाम को अतिरिक्त लागत के बिना दोबारा उपयोग करता है।
> लाभार्थी की ओर से Didit द्वारा बनाए गए इनबाउंड लेग पर कभी भी Travel Rule शुल्क नहीं लगता।

> [accordion] क्या Didit मेरी VASP लाइसेंसिंग या नियामक फ़ाइल के लिए दस्तावेज़ीकरण या क्षमता विवरण दे सकता है?
>
> हाँ। Didit की KYT और लेन-देन निगरानी, AML स्क्रीनिंग और प्रतिबंध स्क्रीनिंग, blockchain-analytics वॉलेट जोखिम, और Travel Rule क्षमताएँ सभी docs.didit.me पर सार्वजनिक रूप से दस्तावेज़ित हैं, और आप नियामक फ़ाइल में इन पेजों का हवाला दे सकते हैं। किसी विशिष्ट आवेदन के लिए तैयार किए गए औपचारिक उत्पाद क्षमता विवरण के लिए, उदाहरण के लिए AIFC/AFSA, MiCA, या किसी अन्य VASP लाइसेंसिंग आवेदन हेतु, नियामक द्वारा अपेक्षित प्रारूप के साथ अपनी Didit खाता टीम से संपर्क करें।

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

> [accordion] मेरे थ्रेशोल्ड से कम वाले ट्रांसफ़र का क्या होता है?
>
> ये तुरंत `NOT_APPLICABLE` पर हल हो जाते हैं: कोई रेल आज़माई नहीं जाती और कोई पहचान डेटा Didit से बाहर नहीं जाता।
> लेन-देन को मानक Transaction Screening के रूप में बिल किया जाता है, Travel Rule शुल्क के रूप में नहीं।
> Didit थ्रेशोल्ड की तुलना उस राशि से करता है जिसे आपके एप्लिकेशन की डिफ़ॉल्ट मुद्रा में बदला गया हो।
> अगर Didit राशि को बदल नहीं सकता, तो थ्रेशोल्ड लागू नहीं होता और ट्रांसफ़र का आदान-प्रदान किया जाता है।
> EU TFR में कोई न्यूनतम सीमा नहीं है, इसलिए EU CASPs को `threshold_amount` को `0.00` पर रखना चाहिए।

> [accordion] अगर प्रतिपक्ष कभी जवाब न दे तो क्या होगा?
>
> ट्रांसफ़र `confirmation_timeout_hours` बीतने तक `AWAITING_COUNTERPARTY` में रहता है, फिर एक स्वीपर उसे `EXPIRED` पर ले जाता है और अंतर्निहित लेन-देन पर आपका `timeout_outcome` लागू करता है: समीक्षा के लिए `HOLD`, अस्वीकार करने के लिए `REJECT`, या उसे जैसा है वैसा छोड़ने के लिए `PROCEED`। `tr_eu_expired_review` प्रीसेट नियम हर समय-सीमा समाप्ति को आपके विश्लेषकों के सामने भी लाता है। जो प्रतिपक्ष संदेश को बिल्कुल भी स्वीकार नहीं करता, उसका मामला अलग है: Didit उसे दोबारा भेजता है, और छठे असफल प्रयास के बाद ट्रांसफ़र `COUNTERPARTY_VASP_NOT_REACHABLE` पर चला जाता है (देखें [डिलीवरी और पुनः प्रयास](#डिलीवरी-और-पुनः-प्रयास))।

> [accordion] मेरे प्रतिपक्ष के पास Travel Rule का कोई टूल नहीं है। क्या फिर भी मैं अनुपालन कर सकता हूँ?
>
> हाँ - यही `EMAIL` रेल है। उनका अनुपालन संपर्क एक बार उपयोग किया जाने वाला पिकअप लिंक पाता है और बिना Didit खाते, बिना API कुंजी और बिना किसी इंटीग्रेशन के, एक होस्टेड पेज से एक्सचेंज की पुष्टि या अस्वीकार कर सकता है। जिन डिपॉज़िट का निपटान किसी भी एक्सचेंज से पहले हो चुका था, उनके लिए [डिपॉज़िट के बाद सनराइज़ पंजीकरण](#डिपॉज़िट-के-बाद-सनराइज़-पंजीकरण) का उपयोग करें।

> [accordion] उपयोगकर्ता के अपने वॉलेट में निकासी कैसे काम करती है?
>
> गंतव्य को स्व-होस्टेड घोषित करें (`payment_method.method_type: "unhosted_wallet"`)। Didit VASP रूटिंग छोड़ देता है और इसके बजाय [वॉलेट-स्वामित्व विजेट](https://docs.didit.me/hi/transaction-monitoring/wallet-ownership-widget.md) के माध्यम से यह प्रमाण इकट्ठा करता है कि आपका ग्राहक उस वॉलेट को नियंत्रित करता है: संदेश पर हस्ताक्षर, Satoshi test, स्क्रीनशॉट, या स्व-घोषणा। यही API रूप में EU TFR की स्व-होस्टेड वॉलेट बाध्यता है।

> [accordion] क्या एक्सचेंज के दौरान प्रतिपक्ष का PII सुरक्षित रहता है?
>
> हाँ।
> जब तक आपकी ओर से वॉलेट का स्वामित्व पक्का नहीं होता, इनबाउंड ट्रांसफ़र पर प्रतिपक्ष का व्यक्तिगत डेटा मास्क किया जाता है, ट्रांसफ़र ऑब्जेक्ट में भी और लेन-देन के प्रतिपक्ष पक्ष में भी (देखें [मास्क किया गया प्रतिपक्ष डेटा](#मास्क-किया-गया-प्रतिपक्ष-डेटा))।
> ईमेल पिकअप पेज केवल ट्रांसफ़र सारांश दिखाते हैं (प्रेषक VASP का नाम, राशि, गंतव्य वॉलेट), व्यक्ति से जुड़ा payload कभी नहीं।
> रेल एक्सचेंज HTTPS पर चलते हैं, और नेटवर्क रेल (`GTR`, `TRUST`, `VERIFYVASP`, `SYGNA`) इसके अतिरिक्त IVMS payload को प्राप्त करने वाले VASP की सार्वजनिक कुंजी से एन्क्रिप्ट करते हैं।

> [accordion] मैं Travel Rule अनुपालन अपनी प्रक्रिया से पहले ही ट्रैक करता हूँ। क्या मैं इसे बस रिकॉर्ड कर सकता हूँ?
>
> हाँ। Travel Rule बंद होने पर आप जो भी `travel_rule_details` सबमिट करते हैं (जिसमें कॉलर द्वारा दिया गया `status`, वर्तमान या पुराना, भी शामिल है) लेन-देन पर निष्क्रिय रूप से रिकॉर्ड होता है: कोई रेल शुरू नहीं होती, कोई बातचीत नहीं होती। इसका उपयोग बैकफ़िल के लिए या अपनी प्रक्रिया चलाते हुए एक ही सिस्टम ऑफ़ रिकॉर्ड रखने के लिए करें।

> [accordion] लाइव होने से पहले मैं इसका परीक्षण कैसे करूँ?
>
> Travel Rule चालू वाला एक सैंडबॉक्स एप्लिकेशन उपयोग करें। सैंडबॉक्स नियम, बिलिंग, और `transaction.created` और `transaction.status.updated` webhook को छोड़ देता है, और हर **आउटबाउंड** एक्सचेंज `TEST_VASP` रेल पर [Didit Test VASP](https://docs.didit.me/hi/transaction-monitoring/travel-rule-sandbox.md) तक जाता है, जो Didit के भीतर ही आपके चुने हुए परिदृश्य के साथ उत्तर देता है: स्वीकार, अस्वीकार, नाम का मेल न खाना, पहुँच से बाहर, टाइमआउट, या स्व-होस्टेड। आपको `environment: sandbox` के साथ चिह्नित `travel_rule.status.updated` webhook मिलते हैं, और कोई संदेश किसी वास्तविक प्रतिपक्ष तक नहीं पहुँचता।
> **इनबाउंड** के लिए, टेस्ट VASP से [Trigger Test VASP Inbound Transfer](https://docs.didit.me/hi/management-api/travel-rule/trigger-test-vasp-inbound.md) के माध्यम से आपको ट्रांसफ़र भेजवाएँ, या `POST /v3/travel-rule/inbound/` से एक ट्रांसफ़र पंजीकृत करें; दोनों का फ़ैसला आपकी वॉलेट पतों की पुस्तिका के आधार पर होता है: `ON_HOLD`, `UNCONFIRMED_OWNERSHIP`, `COUNTERPARTY_MISMATCHED_DATA`, या `COMPLETED` और फिर `FINISHED`।
> किसी अन्य वास्तविक एप्लिकेशन के साथ दो-पक्षीय एक्सचेंज के लिए, `INTERNAL` रेल पर अपने दो **लाइव** एप्लिकेशन का उपयोग करें: प्राप्त करने वाले एप्लिकेशन को खोजे जाने योग्य होना चाहिए और हस्ताक्षरित संदेश या टेस्ट डिपॉज़िट से गंतव्य वॉलेट पर अपना नियंत्रण साबित करना होगा।

## अगले चरण

> [card] [वॉलेट स्वामित्व विजेट](https://docs.didit.me/hi/transaction-monitoring/wallet-ownership-widget.md)
>
> हस्ताक्षर, Satoshi test, स्क्रीनशॉट, या स्व-घोषणा के ज़रिए साबित करें कि कोई ग्राहक वॉलेट को नियंत्रित करता है।

> [card] [इंटरऑपरेबिलिटी](https://docs.didit.me/hi/transaction-monitoring/travel-rule-interoperability.md)
>
> प्रतिपक्ष के लिए उपलब्ध endpoint जिनके ज़रिए अन्य VASP आप तक पहुँचते हैं: TRP, कॉलबैक, ईमेल पिकअप, सनराइज़।

> [card] [नेटवर्क](https://docs.didit.me/hi/transaction-monitoring/travel-rule-networks.md)
>
> आज प्रत्येक रेल और नेटवर्क किन तक पहुँचता है, और किसकी सदस्यता का अभी इंतज़ार है।

> [card] [सैंडबॉक्स में परीक्षण करें](https://docs.didit.me/hi/transaction-monitoring/travel-rule-sandbox.md)
>
> लाइव होने से पहले Didit Test VASP के विरुद्ध हर परिणाम चलाएँ।

> [card] [लेन-देन सबमिट करना](https://docs.didit.me/hi/transaction-monitoring/transactions.md)
>
> Create Transaction payload में Travel Rule डेटा कैसे शामिल करें।

> [card] [नियम लाइब्रेरी](https://docs.didit.me/hi/transaction-monitoring/rules-library.md)
>
> Travel Rule बंडल सहित पूरा प्रीसेट नियम कैटलॉग।

> [card] [webhook](https://docs.didit.me/hi/integration/webhooks.md)
>
> travel\_rule.status.updated और हर अन्य इवेंट परिवार की सदस्यता लें।

> [card] [कंसोल गाइड](https://docs.didit.me/hi/transaction-monitoring/console.md)
>
> लेन-देन विवरण दृश्य में Travel Rule की स्थिति देखना।


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.