क्लाउड के साथ क्रिप्टो एक्सचेंज ऑनबोर्डिंग: एक ऑपरेटर निर्णय अनुक्रम

मुख्य बातें

• क्लाउड एक क्रिप्टो एक्सचेंज के ऑनबोर्डिंग निर्णयों का समन्वय कर सकता है, लेकिन ग्राहक चैट के अंदर नहीं, बल्कि डिडिट के होस्ट किए गए सत्यापन UI में नो योर कस्टमर (KYC) कैप्चर पूरा करता है।
• didit_session_create को एक मौजूदा workflow_id की आवश्यकता होती है। यह एक URL लौटाता है जिसे एक्सचेंज ग्राहक को देता है।
• didit_transaction_screen_wallet केवल स्क्रीनिंग परिणाम लौटाता है। यह फंड को रोककर नहीं रखता, कोई केस नहीं बनाता, या किसी अनुपालन टीम को सूचित नहीं करता।
• didit_transaction_create को शीर्ष स्तर पर transaction_id, transaction_category, transaction_details, और subject की आवश्यकता होती है। लेनदेन फ़ील्ड श्रेणी के अनुसार भिन्न होते हैं।
• ऑपरेटर का मूल्य निर्णय अनुक्रम है: सही सबूत इकट्ठा करना, एक्सचेंज नीति के तहत उसकी व्याख्या करना, प्रत्येक निर्णय को रिकॉर्ड करना और किसी भी अनुवर्ती कार्रवाई को स्पष्ट रूप से ट्रिगर करना।

एक क्रिप्टो एक्सचेंज के पास एक ऑनबोर्डिंग निर्णय नहीं होता है। इसमें निर्णयों की एक श्रृंखला होती है: क्या यह व्यक्ति पहचान सत्यापन शुरू कर सकता है, क्या होस्ट किया गया चेक पूरा हो गया है, क्या नाम-स्क्रीनिंग परिणाम की समीक्षा की आवश्यकता है, नीति के तहत वॉलेट परिणाम का क्या अर्थ है, और क्या सबमिट किए गए लेनदेन को निगरानी के लिए स्वीकार किया जाना चाहिए?

डिडिट मॉडल कॉन्टेक्स्ट प्रोटोकॉल (MCP) सर्वर क्लाउड को एक प्रमाणित टूल सतह के माध्यम से उन चरणों का समन्वय करने देता है। यह ग्राहक अनुभव को बातचीत में नहीं समेटता है, और यह जोखिम प्रतिक्रिया को स्वचालित फंड-नियंत्रण प्रणाली में नहीं बदलता है। उपयोगी पैटर्न स्पष्ट हैंडऑफ़ और स्पष्ट कार्रवाइयों के साथ एक ऑपरेटर कोपायलट है।

यह लेख उस ऑपरेटिंग अनुक्रम पर केंद्रित है। यांत्रिकी के पास पहले से ही MCP पर KYC, MCP पर वॉलेट स्क्रीनिंग, और MCP पर लेनदेन निगरानी के लिए समर्पित गाइड हैं।

निर्णय 0: ग्राहक को छूने से पहले दायरे को स्थापित करें

एक ऑपरेटर didit_context_get से शुरू होता है। यह टूल प्रमाणित उपयोगकर्ता के लिए उपलब्ध संगठनों और अनुप्रयोगों को सूचीबद्ध करता है, ताकि क्लाउड ग्राहकों या वातावरण को मिलाए बिना इच्छित ऑपरेटिंग संदर्भ की पुष्टि कर सके।

एक्सचेंज को एक मौजूदा सत्यापन वर्कफ़्लो की भी आवश्यकता होती है। वर्कफ़्लो डिज़ाइन ग्राहक हैंडऑफ़ से पहले होता है और यह निर्धारित करता है कि कौन से चेक चलते हैं। एक सामान्य क्रिप्टो ऑनबोर्डिंग प्रवाह के लिए, इसमें आईडी सत्यापन, पैसिव लाइवनैस, फेस मैच और आईपी विश्लेषण शामिल हो सकते हैं। इन चेकों के लिए प्रकाशित पूर्ण KYC बंडल मूल्य $0.33 है।

MCP कॉल को "वर्कफ़्लो कॉन्फ़िगरेशन" प्राप्त नहीं होता है। didit_session_create को एक workflow_id प्राप्त होता है जो पहले से मौजूद है। यह अंतर ऑपरेटर के पहले प्रश्न को ठोस बनाता है: इस ग्राहक और बाज़ार पर कौन सा अनुमोदित वर्कफ़्लो लागू होता है?

निर्णय 1: ग्राहक को होस्ट किए गए KYC प्रवाह पर भेजें

क्लाउड चयनित वर्कफ़्लो और एक स्थिर ग्राहक संदर्भ के साथ सत्र बनाता है। प्रतिक्रिया में session_id, url, और session_token शामिल होते हैं।

didit_session_create के साथ एक सत्यापन सत्र बनाएँ:
{
  "workflow_id": "<existing-crypto-onboarding-workflow-uuid>",
  "vendor_data": "customer_18427",
  "callback": "https://exchange.example/onboarding/complete",
  "language": "en"
}

URL को ग्राहक को लौटाएँ और निर्णय लुकअप के लिए session_id को बनाए रखें।

ग्राहक उस URL को खोलता है और डिडिट के होस्ट किए गए UI में आवश्यक कैप्चर पूरा करता है। पहचान-दस्तावेज़ की छवियां और सेल्फी वहीं सबमिट की जाती हैं। वे क्लाउड चैट के अंदर नहीं रहते हैं।

ग्राहक के पूरा होने के बाद, क्लाउड session_id के साथ didit_session_get_decision को कॉल करता है। यह टूल कॉन्फ़िगर किए गए वर्कफ़्लो के लिए पूर्ण सत्यापन निर्णय और निकाले गए डेटा को लौटाता है। ऑपरेटर तब वास्तविक प्रतिक्रिया पर एक्सचेंज की समीक्षा नीति लागू कर सकता है। यह एक हैंडऑफ़ और पुनर्प्राप्ति लूप है, न कि यह दावा कि Approved हर डाउनस्ट्रीम अनुपालन प्रश्न को हल करता है।

निर्णय 2: पहचान के सबूत को नाम के जोखिम से अलग करें

पहचान सत्यापन और एंटी-मनी लॉन्ड्रिंग (AML) स्क्रीनिंग अलग-अलग सवालों के जवाब देते हैं। सत्यापित पहचान डेटा पढ़ने के बाद, क्लाउड व्यक्ति के पूरे नाम के साथ didit_verify_aml को कॉल कर सकता है। जन्मतिथि और राष्ट्रीयता जैसे वैकल्पिक इनपुट मिलान सटीकता में सुधार कर सकते हैं। AML स्क्रीनिंग 1,300+ सूचियों में प्रति चेक $0.20 है।

ऑपरेटर का निर्णय केवल "हिट या नो हिट" नहीं है। एक परिणाम को सत्यापित ग्राहक डेटा के साथ तुलना, तर्क का दस्तावेजीकरण, या एक्सचेंज की नीति के तहत मैन्युअल समीक्षा की आवश्यकता हो सकती है। यदि ऑपरेटर यह तय करता है कि एक केस की आवश्यकता है, तो didit_case_create एक अलग स्पष्ट टूल कॉल है। KYC सत्र के बारे में कुछ भी चुपचाप उस केस को नहीं बनाता है।

यह अलगाव ऑडिट ट्रेल को पठनीय रखता है:

• KYC सबूत: होस्ट किए गए सत्यापन वर्कफ़्लो ने क्या लौटाया।
• AML सबूत: नाम-स्क्रीनिंग प्रतिक्रिया ने क्या लौटाया।
• ऑपरेटर निर्णय: एक्सचेंज की नीति ने उन प्रतिक्रियाओं को कैसे अनुमोदित, समीक्षा या अस्वीकार करने के लिए मैप किया।

निर्णय 3: वॉलेट को स्क्रीन करें, फिर तय करें कि क्या करना है

didit_transaction_screen_wallet wallet_address, blockchain, और एक वैकल्पिक direction स्वीकार करता है। blockchain एनम एक मिश्रित संपत्ति-या-श्रृंखला पहचानकर्ता है: इसमें BTC, ETH, SOL, और TRX जैसे श्रृंखला पहचानकर्ता, और USDT और USDC जैसे संपत्ति पहचानकर्ता शामिल हैं। USDT और USDC संपत्ति हैं, ब्लॉकचेन नहीं।

निम्नलिखित सटीक MCP पेलोड आकार के साथ एक चलने योग्य क्लाउड प्रॉम्प्ट है। ग्राहक के वॉलेट के साथ उदाहरण पते को बदलें:

didit_transaction_screen_wallet को ठीक इस पेलोड के साथ कॉल करें:
{
  "wallet_address": "0x0000000000000000000000000000000000000000",
  "blockchain": "ETH",
  "direction": "deposit"
}

प्रतिक्रिया फ़ील्ड risk_score, severity, sanctions_hit, और फंड के रिपोर्ट किए गए स्रोत और गंतव्य लौटाएँ। फंड को रोककर न रखें, कोई केस न बनाएँ, या किसी को सूचित न करें। स्क्रीनिंग परिणाम का सारांश देने के बाद एक स्पष्ट अनुवर्ती निर्देश पूछें।

प्रतिक्रिया का आकार एक स्क्रीनिंग परिणाम है: risk_score, severity, sanctions_hit, और फंड की स्रोत/गंतव्य जानकारी। जब लेनदेन निगरानी का स्क्रीनिंग कॉन्फ़िगरेशन अनुपलब्ध होता है तो टूल 409 प्रतिक्रिया लौटा सकता है।

वॉलेट स्क्रीनिंग, जिसे उत्पाद कैटलॉग में नो योर ट्रांजेक्शन (KYT) भी कहा जाता है, प्रति चेक $0.15 खर्च होता है। परिणाम स्वयं पैसे नहीं ले जाता है। एक होल्ड, रिलीज़, केस, एस्केलेशन, या अधिसूचना एक्सचेंज की अपनी नीति से संबंधित है और इसके लिए एक अलग सिस्टम या टूल कार्रवाई की आवश्यकता होती है। उदाहरण के लिए, क्लाउड didit_case_create को तभी कॉल कर सकता है जब ऑपरेटर या एक अधिकृत नीति परत स्पष्ट रूप से उस कार्रवाई को चुनती है।

निर्णय 4: वास्तविक स्कीमा के साथ एक लेनदेन सबमिट करें

didit_transaction_create निगरानी और नियम मूल्यांकन के लिए एक लेनदेन सबमिट करता है। इसके आवश्यक शीर्ष-स्तरीय फ़ील्ड हैं:

• transaction_id: एक्सचेंज का अद्वितीय लेनदेन पहचानकर्ता।
• transaction_category: प्रलेखित श्रेणी मूल्यों में से एक, जिसमें finance, kyc, travel_rule, और user_event शामिल हैं।
• transaction_details: श्रेणी-विशिष्ट लेनदेन पेलोड।
• subject: लेनदेन शुरू करने वाली पार्टी।

वैकल्पिक शीर्ष-स्तरीय वस्तुओं में counterparty, travel_rule_details, network_snapshot, और custom_properties शामिल हैं। टूल लेनदेन हैश, स्रोत पता, गंतव्य पता, संपत्ति, या राशि को सार्वभौमिक शीर्ष-स्तरीय फ़ील्ड के रूप में परिभाषित नहीं करता है। यदि वे मान किसी श्रेणी के डेटा का हिस्सा हैं, तो वे प्रासंगिक श्रेणी-विशिष्ट वस्तु के अंदर होते हैं।

didit_transaction_create के लिए शीर्ष-स्तरीय अनुबंध है:
{
  "transaction_id": "<exchange-unique-transaction-id>",
  "transaction_category": "finance",
  "transaction_details": { "<finance-category fields>": "<values>" },
  "subject": { "<initiating-party fields>": "<values>" },
  "counterparty": { "<other-party fields>": "<values>" },
  "transaction_at": "<ISO timestamp>"
}

प्लेसहोल्डर जानबूझकर हैं। MCP स्कीमा बताता है कि transaction_details और subject transaction_category पर निर्भर करते हैं; यह एक सार्वभौमिक नेस्टेड पेलोड प्रकाशित नहीं करता है। एक ऑपरेटर को कॉन्फ़िगर की गई श्रेणी के लिए परिभाषित फ़ील्ड का उपयोग करना चाहिए बजाय इसके कि एक आविष्कार किए गए क्रिप्टो स्कीमा की नकल करें।

travel_rule के लिए, वही शीर्ष-स्तरीय अनुबंध लागू होता है, जिसमें transaction_details में श्रेणी-विशिष्ट स्थानांतरण डेटा, subject में प्रारंभिक पार्टी, counterparty में दूसरी पार्टी, और travel_rule_details में ट्रैवल रूल डेटा होता है। इस टूल पर कोई metadata फ़ील्ड नहीं है। travel_rule का चयन श्रेणी-विशिष्ट पेलोड की पहचान करता है; यह स्वचालित रूप से लाभार्थी की जांच या स्थानांतरण को साफ़ नहीं करता है।

लेनदेन सबमिट होने पर उसका मूल्यांकन किया जाता है। एक ही सबमिट किए गए रिकॉर्ड को लगातार हमेशा के लिए पुनर्मूल्यांकन के रूप में वर्णित करना गलत है। क्लाउड didit_transaction_get के साथ मॉनिटर किए गए लेनदेन और उसके नियम-मूल्यांकन परिणाम को पुनः प्राप्त कर सकता है।

निर्णय 5: नीति लेखन को बिज़नेस कंसोल में रखें

बिज़नेस कंसोल का ट्रांजेक्शन मॉनिटरिंग नियम बिल्डर वह जगह है जहाँ टीमें निगरानी नियमों और नीति तर्क को कॉन्फ़िगर करती हैं। यह सत्यापन वर्कफ़्लो संपादक नहीं है। MCP सतह लेनदेन सबमिट करती है, परिणाम पुनः प्राप्त करती है, रिकॉर्ड खोजती है, और स्पष्ट केस संचालन का समर्थन करती है; यह नियम लेखन को प्रतिस्थापित नहीं करती है।

केस कार्रवाइयां भी सीमित हैं। didit_case_manage assign, comment, escalate, reopen, resolve, और update का समर्थन करता है। संदिग्ध गतिविधि रिपोर्ट (SAR) वर्कफ़्लो बिज़नेस कंसोल संचालन बने रहते हैं। यह सीमा एक एक्सचेंज को एजेंट को एक स्वायत्त अनुपालन प्राधिकरण के रूप में वर्णित किए बिना सबूत इकट्ठा करने और ऑपरेटर सहायता के लिए क्लाउड का उपयोग करने देती है।

ऑपरेटर कोपायलट को कनेक्ट करें

डिडिट का होस्ट किया गया MCP एंडपॉइंट स्ट्रीमबल HTTP पर 115 टूल को उजागर करता है और प्रूफ की फॉर कोड एक्सचेंज (PKCE) के साथ OAuth 2.1 का उपयोग करता है। MCP सर्वर मुफ्त है; अंतर्निहित चेक उनकी प्रकाशित कीमतों का पालन करते हैं। मुफ्त टियर प्रति माह 500 मुफ्त सत्यापन है।

होस्ट किए गए क्लाउड को डिडिट कनेक्टर डीप लिंक से कनेक्ट करें। MCP अवलोकन, प्रमाणीकरण गाइड, और टूल संदर्भ की समीक्षा करें। कार्यान्वयन MIT-लाइसेंस प्राप्त GitHub रिपॉजिटरी में उपलब्ध है, और उत्पाद अवलोकन didit.me/developers/mcp पर रहता है।

टिकाऊ ऑपरेटिंग पैटर्न पहले सबूत, दूसरी नीति, तीसरी कार्रवाई है। क्लाउड KYC निर्णय, AML परिणाम, वॉलेट परिणाम, और लेनदेन मूल्यांकन एकत्र करता है। एक्सचेंज यह स्पष्ट रखता है कि किस प्रतिक्रिया के कारण कौन सा निर्णय हुआ और कौन सी अलग कार्रवाई हुई।