ऑन-डिमांड वॉलेट स्क्रीनिंग API: लेन-देन की आवश्यकता नहीं

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

इसे कब उपयोग करें

उपयोग का मामला	Endpoint
बिना दर्ज करने लायक लेन-देन के पते की पूर्व-जाँच	वॉलेट स्क्रीनिंग — `POST /v3/wallet-screening/`
दर्ज किए गए जमा/निकासी के हिस्से के रूप में वॉलेट की स्क्रीनिंग	Create Transaction के साथ `currency_kind: "crypto"`

वॉलेट स्क्रीनिंग लेन-देन तालिका में कुछ नहीं लिखती। यदि आपको स्क्रीनिंग को किसी मॉनिटर किए गए लेन-देन से जोड़ना है (नियमों, अलर्ट और webhook के साथ), तो इसके बजाय लेन-देन सबमिट करें।

पूर्वापेक्षाएँ

एप्लिकेशन के लिए लेन-देन निगरानी या तो किसी प्रबंधित प्रदाता के साथ, या मौजूदा प्रदाता कुंजी के साथ कॉन्फ़िगर होनी चाहिए। इसे Business Console में लेनदेन > सेटिंग्स > Provider Preferences में कॉन्फ़िगर करें। यदि कोई प्रदाता कॉन्फ़िगर नहीं है, तो endpoint 409 Conflict लौटाता है।

अनुरोध

POST https://verification.didit.me/v3/wallet-screening/ x-api-key हेडर के साथ प्रमाणित करें।

फ़ील्ड	प्रकार	आवश्यक	विवरण
`wallet_address`	string	हाँ	स्क्रीन किया जाने वाला पता या नेटवर्क पहचानकर्ता। यह चुने गए नेटवर्क से मेल खाना चाहिए, जैसे EVM चेन के लिए `0x` + 40 हेक्स वर्ण, या आपके प्रदाता द्वारा स्वीकृत Lightning पहचानकर्ता। उपनाम: `address`।
`blockchain`	string	नहीं	एसेट / नेटवर्क पहचानकर्ता। छोड़ने पर Didit पते के फ़ॉर्मैट से नेटवर्क पढ़ता है: `bc1`, `1` और `3` पते Bitcoin (`BTC`) हैं, `T` पते Tron (`TRX`) हैं, और base58 सार्वजनिक कुंजियाँ Solana (`SOL`) हैं। `0x` पता हर EVM नेटवर्क पर वैध है, इसलिए यह `candidate_chains` के साथ `422` लौटाता है और न कोई स्क्रीनिंग होती है, न बिलिंग; नेटवर्क सेट करके इसे फिर से भेजें। कोई और फ़ॉर्मैट `400` लौटाता है। स्वीकृत मान: `BTC`, `LIGHTNING`, `ETH`, `LTC`, `XRP`, `BCH`, `DOGE`, `TRX`, `SOL`, `MATIC`, `BNB`, `BASE`, `OP`, `ARB`, `AVAX`, `ADA`, `XLM`, `HBAR`, `CELO`, `MODE`, `PLUME`, `USDT`, `USDC`। सामान्य नेटवर्क नाम भी स्वीकार होते हैं, जैसे `MATIC` के लिए `POLYGON` या `POL`, `BNB` के लिए `BSC`, और `TRX` के लिए `TRON`। उपनाम: `currency`।
`direction`	string	नहीं	`inbound`, `outbound`, `deposit` या `withdrawal`। प्रदाता के लिए वैकल्पिक संदर्भ; तटस्थ पूर्व-हस्तांतरण स्क्रीन के लिए इसे छोड़ दें। यह लौटाए गए `risk_score`, `severity` या फ़ंड-फ़्लो विवरण को नहीं बदलता (नीचे रिस्पॉन्स के अंतर्गत नोट देखें)।

चेन कवरेज

प्रबंधित स्क्रीनिंग Base (BASE), Optimism (OP) और Arbitrum One (ARB) को वॉलेट और लेन-देन हैश, दोनों की स्क्रीनिंग के लिए सपोर्ट करती है। जुड़े प्रदाताओं का कवरेज अलग हो सकता है; किसी चेन को आपके चुने हुए प्रदाता और खाते द्वारा भी समर्थित होना चाहिए। Celo (CELO), Mode (MODE) और Plume (PLUME) की स्क्रीनिंग एक जुड़े TRM Labs खाते के माध्यम से होती है (Marketplace, अपनी कुंजी लाएँ); प्रबंधित स्क्रीनिंग इन्हें कवर नहीं करती और 400 लौटाती है। किसी दूसरे EVM नेटवर्क के लिए ETH सबमिट न करें: एक ही पते की हर चेन पर गतिविधि और जोखिम अलग हो सकते हैं। प्रबंधित स्क्रीनिंग में USDT और USDC Ethereum के लिए पुराने उपनाम हैं; ये उन सभी नेटवर्कों पर खोज नहीं करते जहाँ ये टोकन मौजूद हैं। वॉलेट की वास्तविक चेन के लिए नेटवर्क पहचानकर्ता का उपयोग करें (ETH, TRX, SOL, MATIC, BNB, BASE, OP, ARB, AVAX, ADA, XLM, HBAR, या TRM Labs के साथ CELO, MODE या PLUME)। दर्ज लेन-देन में टोकन के लिए, टोकन को transaction_details.currency में रखें और नेटवर्क को transaction_details.crypto_params.crypto_chain में अलग से निर्दिष्ट करें। देखें एसेट और नेटवर्क चयन।

LIGHTNING केवल तभी उपलब्ध है जब एप्लिकेशन के पास कंसोल के Marketplace में कोई जुड़ा हुआ Elliptic या Chainalysis BYOK प्रदाता हो। यह प्रबंधित Merkle Science या Crystal अथवा TRM Labs के साथ उपलब्ध नहीं है। समर्थित जुड़े प्रदाता के बिना अनुरोध 400 लौटाते हैं और उन्हें न स्क्रीन किया जाता है, न बिल किया जाता है।

curl -X POST https://verification.didit.me/v3/wallet-screening/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "wallet_address": "0x94f1b9b64e2932f6a2db338f616844400cd58e8a",
    "blockchain": "ETH"
  }'

रिस्पॉन्स

रिस्पॉन्स मानकीकृत स्क्रीनिंग परिणाम है, जिसका आकार लेन-देन स्क्रीनिंग से लौटाए गए WALLET_SCREENING प्रदाता परिणाम जैसा ही है।

फ़ील्ड	प्रकार	विवरण
`provider`	string	वह प्रदाता जिसने पते की स्क्रीनिंग की (`merklescience`, `crystal`, `chainalysis`, `elliptic`, `trmlabs`)।
`screening_type`	string	हमेशा `WALLET_SCREENING`।
`risk_score`	integer	सामान्यीकृत 0–100 जोखिम स्कोर। Merkle Science किसी पते को `0-5` ग्रेड देता है, जो `0`, `15`, `35`, `55`, `75` या `95` में मैप होता है।
`severity`	string	`risk_score` से निकला जोखिम वर्ग (नीचे नोट देखें): `UNKNOWN`, `LOW`, `MEDIUM`, `HIGH`, या `CRITICAL`।
`status`	string	`SCREENED`, `PENDING`, या `ERROR`।
`summary`	string	मनुष्य द्वारा पढ़े जाने योग्य सारांश।
`wallet_address`	string	स्क्रीन किया गया पता।
`blockchain`	string	स्क्रीन की गई चेन।
`sanctions_hit`	boolean	`true` तब होता है जब स्क्रीन किया गया वॉलेट प्रतिबंधित हो, या जब उसके किसी प्रतिपक्ष के फंड प्रतिबंधित संस्थाओं से आए हों (एक्सपोज़र)। यह दोनों में फ़र्क नहीं करता।
`pep_counterparty`	boolean \| null	राजनीतिक रूप से उजागर व्यक्ति (PEP) का एक्सपोज़र। जब कोई PEP निष्कर्ष उपलब्ध न हो तब `null` होता है, और आज हर परिणाम में यही होता है, क्योंकि कोई प्रदाता इसकी रिपोर्ट नहीं करता। `false` केवल स्पष्ट नकारात्मक स्क्रीनिंग परिणाम के लिए होता है। `null` को पूरी हुई PEP जाँच न समझें।
`dominant_risk_category`	string \| null	सबसे अधिक भार वाली उच्च-जोखिम श्रेणी, या `null`।
`risk_factors`	array	`risk_score` की रैंक्ड व्याख्या: इस निर्णय तक किन कारकों ने पहुँचाया। देखें जोखिम कारक।
`source_of_funds`	array	किन संस्थाओं से फंड प्राप्त हुए, संस्था के अनुसार। देखें एक्सपोज़र विवरण।
`destination_of_funds`	array	किन संस्थाओं को फंड भेजे गए, संस्था के अनुसार। प्रविष्टि की संरचना `source_of_funds` जैसी ही है।
`counterparty_connections`	array	वे संस्थाएँ जिनसे प्रदाता इस पते को जोड़ता है। देखें प्रतिपक्ष संबंध।
`network_nodes`, `network_edges`	array	लेन-देन स्क्रीनिंग के लिए एक्सपोज़र का ग्राफ़। वॉलेट स्क्रीनिंग परिणाम पर खाली होता है।
`transaction_hash`, `block_timestamp`, `total_value_usd`, `fee_usd`, `transaction_flows_status`, `transaction_flows_error`	null	लेन-देन स्क्रीनिंग फ़ील्ड, जो परिणाम की संरचना में साझा किए जाते हैं। वॉलेट स्क्रीनिंग परिणाम पर हमेशा `null` होते हैं।
`sender_rows`, `receiver_rows`, `transaction_flows`	array	लेन-देन स्क्रीनिंग फ़ील्ड। वॉलेट स्क्रीनिंग परिणाम पर हमेशा खाली होते हैं।
`raw_response`	object	प्रदाता का अपना payload। इसका आकार प्रदाता-विशिष्ट है और बिना सूचना के बदल सकता है, इसलिए इसे पार्स करने के बजाय ऊपर के सामान्यीकृत फ़ील्ड पढ़ें।
`report_signature`	string	इस परिणाम पर अपारदर्शी हस्ताक्षर, जो आपके एप्लिकेशन तक सीमित है। PDF के रूप में रेंडर करने के लिए रिस्पॉन्स को, इस फ़ील्ड सहित, बिना किसी बदलाव के फिर से पोस्ट करें।

severity कैसे सेट होता है। severity सामान्यीकृत risk_score का बैंड है: 0-9 → UNKNOWN, 10-39 → LOW, 40-69 → MEDIUM, 70-89 → HIGH, 90-100 → CRITICAL। UNKNOWN सबसे निचला बैंड है, कोई अलग “कोई डेटा नहीं” स्थिति नहीं। risk_score: 0 (साफ़ पते का सामान्य मामला) का अर्थ है कि प्रदाता ने कोई प्रतिकूल आकलन नहीं लौटाया, जबकि 1-9 सीमा में शून्येतर स्कोर एक वास्तविक लेकिन LOW से नीचे का संकेत है, इसलिए केवल बैंड नहीं, risk_score स्वयं पढ़ें। किसी भी स्थिति में UNKNOWN को सकारात्मक “साफ़” या “पास” के रूप में न दिखाएँ।direction जोखिम मॉडल नहीं बदलता। वैकल्पिक direction फ़ील्ड केवल संदर्भ के रूप में प्रदाता को भेजा जाता है। यह risk_score, severity, या कौन सी ब्रेकडाउन सूचियाँ लौटाई जाएँ, इन्हें प्रभावित नहीं करता: source_of_funds और destination_of_funds दोनों हमेशा लौटाई जाती हैं। इसलिए direction बदलने या छोड़ने से पहले से स्क्रीन किए गए पते को दोबारा स्क्रीन करना ज़रूरी नहीं है।

जोखिम कारक

risk_factors वह रैंक्ड उत्तर है जो बताता है कि “इस पते को यह स्कोर क्यों मिला है।” प्रदाता किसी पते को अपने मॉडल पर ग्रेड करते हैं और केवल एक निर्णय लौटाते हैं (Merkle Science पूर्णांक 0-5 लौटाता है), इसलिए अकेला risk_score कार्रवाई योग्य नहीं है। हर प्रविष्टि एक ड्राइवर का नाम देती है, पहले उच्च-जोखिम वाले, फिर उस मूल्य के अनुसार क्रमबद्ध जो उसके माध्यम से गुज़रा।

फ़ील्ड	प्रकार	विवरण
`source`	string	`attribution` (प्रदाता के अनुसार पता क्या है, यानी उसका अपना टैग या क्लस्टर) या `exposure` (जहाँ उसके फंड वास्तव में गए)।
`category`	string	सामान्यीकृत जोखिम श्रेणी, वही शब्दावली जो एक्सपोज़र ब्रेकडाउन में है।
`label`	string	प्रदाता का अपना शब्द-प्रयोग, जैसे `Gambling / Crypto only`। UI में इसका उपयोग करें, क्योंकि यह वही दिखाता है जो प्रदाता के कंसोल में दिखता है।
`entity_name`	string \| null	जिम्मेदार ठहराई गई संस्था, जैसे कोई जुआ साइट या एक्सचेंज। इस पेज के उदाहरण `Example Gambling` जैसे प्लेसहोल्डर उपयोग करते हैं।
`direction`	string	`incoming`, `outgoing`, `connected`, `attribution` (पते का अपना टैग), या `unknown` जब प्रदाता ने दिशा नहीं बताई।
`exposure_type`	string	`direct` (1 हॉप), `indirect` (मल्टी-हॉप), `attribution` (पते का अपना टैग), या `unknown` जब प्रदाता ने नहीं बताया कि प्रतिपक्ष कितने हॉप दूर है। `unknown` को अवर्गीकृत समझें, कभी `direct` नहीं।
`amount_usd`	number \| null	इस ड्राइवर से संबद्ध USD मूल्य।
`percentage`	number	पते की कुल स्क्रीन की गई मात्रा का हिस्सा, दोनों दिशाएँ मिलाकर। यह `source_of_funds` / `destination_of_funds` के भीतर के `percentage` से अलग है, जो प्रति दिशा सामान्यीकृत होता है। पूरी सूची में यह तुलनीय है और जोड़ा जा सकता है।
`is_high_risk`	boolean	क्या श्रेणी को Didit उच्च जोखिम मानता है (`sanctioned`, `mixer`, `stolen_funds`, `ransomware`, `scam`, `darknet_market`, `terrorist_financing`, `child_exploitation`, `hacked_exchange`, `high_risk_exchange`, `seized_funds`)।
`description`	string	ड्राइवर की एक-पंक्ति प्रस्तुति, जैसे `9.01% indirect outgoing exposure to Gambling / Crypto only (Example Gambling)`।

बिना is_high_risk कारक के उच्च स्कोर एक वास्तविक और सार्थक परिणाम है। इसका अर्थ है कि प्रदाता ने पते को अपने एक्सपोज़र मॉडल पर ग्रेड किया, बिना किसी प्रतिबंध, PEP या जिम्मेदार ठहराई गई संस्था के मिलान की रिपोर्ट किए। सूचीबद्ध कारक ही वे फंड प्रवाह हैं जो ग्रेड के पीछे हैं। summary इसे स्पष्ट रूप से बताता है, इसलिए ऐसे पतों को “प्रवाह की समीक्षा करें” मानें, पुष्ट हिट नहीं। risk_factors सबसे मज़बूत पाँच ड्राइवरों तक सीमित है, जबकि source_of_funds और destination_of_funds हमेशा पूरा ब्रेकडाउन रखते हैं।risk_factors एक टॉप-लेवल फ़ील्ड है, नेस्टेड फ़ील्ड नहीं। इससे पहले स्क्रीन किए गए परिणामों में यह कुंजी पूरी तरह अनुपस्थित होती है: इसे खाली सूची के रूप में पढ़ें, खाली स्पष्टीकरण मान कर नहीं।

एक्सपोज़र विवरण

source_of_funds / destination_of_funds में हर एंट्री उस एक इकाई का वर्णन करती है जिसके साथ पते ने फ़ंड का आदान-प्रदान किया:

फ़ील्ड	प्रकार	विवरण
`category`	string	सामान्यीकृत जोखिम श्रेणी (`exchange_licensed`, `dex`, `defi`, `mixer`, `sanctioned`, `darknet_market`, `stolen_funds`, …)।
`entity_name`	string \| null	एट्रिब्यूट की गई इकाई, जैसे कोई एक्सचेंज, मिक्सर या प्रतिबंधित समूह। इस पेज के उदाहरणों में प्लेसहोल्डर नाम इस्तेमाल हुए हैं।
`entity_type`	string \| null	प्रदाता की इकाई का प्रकार (`Exchange`, `DeFi`, `Sanctions`)।
`entity_subtype`	string \| null	विस्तृत उप-प्रकार (`Mandatory KYC and AML`, `OFAC`)।
`description`	string \| null	`entity_type / entity_subtype`, जैसा प्रदाता इकाई को लेबल करता है।
`exposure_direction`	string	`incoming`, `outgoing`, या `connected`।
`exposure_type`	string	`direct` (1 हॉप) या `indirect` (कई हॉप)।
`is_direct`	boolean	`true` तब होता है जब `exposure_type` `direct` हो।
`amount_usd`	number \| null	इकाई को एट्रिब्यूट किया गया USD मूल्य।
`percentage`	number	उस दिशा के कुल एक्सपोज़र में हिस्सा (0–100)।
`hops`	integer \| null	इकाई तक हॉप की संख्या (सीधे प्रतिपक्ष के लिए `1`), जब प्रदाता इसकी रिपोर्ट करता है। Merkle Science के लिए यह हमेशा `null` होता है, क्योंकि वह केवल बताता है कि एक्सपोज़र direct है या indirect: `exposure_type` इस्तेमाल करें।
`country`	string \| null	इकाई का प्राथमिक ISO 3166-1 alpha-2 देश। जब प्रदाता इसे नहीं जानता, तो खाली या `null` होता है।
`provider_entity_id`, `provider_entity_type_id`, `provider_entity_subtype_id`	string \| null	इकाई और उसके प्रकार के लिए प्रदाता के अपने पहचानकर्ता।
`raw_amount`, `raw_currency`	number \| null, string \| null	एसेट की अपनी इकाई में राशि, जब प्रदाता इसकी रिपोर्ट करता है।

प्रतिपक्ष संबंध

counterparty_connections उन इकाइयों की सूची देता है जिनसे प्रदाता स्क्रीन किए गए पते को जोड़ता है। Merkle Science के लिए ये पते के अपने स्वामी और उपयोगकर्ता टैग से आते हैं, इसलिए एक ही इकाई दो बार आ सकती है, और इनमें कोई फ़ंड फ़्लो नहीं होता: received_usd, sent_usd, received_hops और sent_hops null होते हैं, और percentage 0.0 होता है। फ़ंड फ़्लो source_of_funds और destination_of_funds से पढ़ें।

फ़ील्ड	प्रकार	विवरण
`entity_name`	string \| null	एट्रिब्यूट की गई इकाई।
`entity_type`	string \| null	प्रदाता की इकाई का प्रकार।
`entity_subtype`	string \| null	विस्तृत उप-प्रकार।
`categories`	array	इकाई की सामान्यीकृत जोखिम श्रेणियाँ।
`risk_level`	string	लोअरकेस, प्रदाता पर निर्भर। Merkle Science के लिए यह पते का अपना 0-5 जोखिम ग्रेड है (`no_risk`, `low`, `medium_low`, `medium`, `high`, `critical`), जो इकाई की श्रेणी उच्च जोखिम वाली होने पर `high` तक बढ़ा दिया जाता है; यह इकाई का अलग ग्रेड नहीं है।
`is_direct`	boolean	Merkle Science के लिए हमेशा `true`, क्योंकि उसके संबंध प्रतिपक्ष नहीं बल्कि एट्रिब्यूशन हैं।
`received_usd`, `sent_usd`	number \| null	इकाई से प्राप्त और इकाई को भेजे गए USD, जब प्रदाता इसकी रिपोर्ट करता है।
`received_hops`, `sent_hops`	integer \| null	हर दिशा में इकाई तक हॉप, जब प्रदाता इन्हें रिपोर्ट करता है।
`percentage`	number	पते के एक्सपोज़र में हिस्सा, जब प्रदाता इसकी रिपोर्ट करता है; अन्यथा `0.0`।
`country`	string \| null	इकाई का देश, जब ज्ञात हो।
`provider_entity_id`	string \| null	इकाई के लिए प्रदाता का अपना पहचानकर्ता।

counterparty_connections[].risk_level या counterparty_connections[].is_direct पर रूटिंग न करें: Merkle Science के लिए पहला पते के अपने ग्रेड को दोहराता है (risk_score पढ़ें) और दूसरा हमेशा true होता है। निर्णय के लिए sanctions_hit, dominant_risk_category और risk_factors[].is_high_risk इस्तेमाल करें, और direct या indirect होने के लिए source_of_funds / destination_of_funds में exposure_type।

उदाहरण

OFAC प्रतिबंध सूची में मौजूद एक पते का वास्तविक रिस्पॉन्स, Merkle Science से स्क्रीन किया गया। केवल raw_response छोटा किया गया है और report_signature बदला गया है:

{
  "provider": "merklescience",
  "screening_type": "WALLET_SCREENING",
  "risk_score": 95,
  "severity": "CRITICAL",
  "status": "SCREENED",
  "summary": "Merkle Science risk: Critical (5/5). SANCTIONS HIT. Dominant risk: sanctioned. Driven by: the address is attributed to Sanctions / OFAC (Example Sanctions)",
  "wallet_address": "0x94f1b9b64e2932f6a2db338f616844400cd58e8a",
  "transaction_hash": null,
  "blockchain": "ETH",
  "block_timestamp": null,
  "total_value_usd": null,
  "fee_usd": null,
  "sender_rows": [],
  "receiver_rows": [],
  "transaction_flows": [],
  "transaction_flows_status": null,
  "transaction_flows_error": null,
  "source_of_funds": [
    {
      "category": "sanctioned",
      "percentage": 100.0,
      "amount_usd": 9813695.0,
      "entity_name": "Example Sanctions",
      "entity_type": "Sanctions",
      "entity_subtype": "OFAC",
      "hops": null,
      "description": "Sanctions / OFAC",
      "is_direct": true,
      "exposure_direction": "incoming",
      "exposure_type": "direct",
      "provider_entity_id": "118885",
      "provider_entity_type_id": "30",
      "provider_entity_subtype_id": "125",
      "country": "",
      "raw_amount": null,
      "raw_currency": null
    }
  ],
  "destination_of_funds": [
    {
      "category": "defi",
      "percentage": 84.824453,
      "amount_usd": 7783414.38,
      "entity_name": "Example DeFi 7",
      "entity_type": "DeFi",
      "entity_subtype": "Bridges",
      "hops": null,
      "description": "DeFi / Bridges",
      "is_direct": false,
      "exposure_direction": "outgoing",
      "exposure_type": "indirect",
      "provider_entity_id": "118459",
      "provider_entity_type_id": "33",
      "provider_entity_subtype_id": "143",
      "country": "",
      "raw_amount": null,
      "raw_currency": null
    },
    {
      "category": "defi",
      "percentage": 15.175547,
      "amount_usd": 1392494.37,
      "entity_name": "Example DeFi 2",
      "entity_type": "DeFi",
      "entity_subtype": "Yield Aggregator",
      "hops": null,
      "description": "DeFi / Yield Aggregator",
      "is_direct": false,
      "exposure_direction": "outgoing",
      "exposure_type": "indirect",
      "provider_entity_id": "90192",
      "provider_entity_type_id": "33",
      "provider_entity_subtype_id": "142",
      "country": "",
      "raw_amount": null,
      "raw_currency": null
    }
  ],
  "counterparty_connections": [
    {
      "entity_name": "Example Sanctions",
      "entity_type": "Sanctions",
      "entity_subtype": "OFAC",
      "risk_level": "critical",
      "categories": [
        "sanctioned"
      ],
      "received_usd": null,
      "sent_usd": null,
      "received_hops": null,
      "sent_hops": null,
      "percentage": 0.0,
      "is_direct": true,
      "country": null,
      "provider_entity_id": null
    },
    {
      "entity_name": "Example Sanctions",
      "entity_type": "Sanctions",
      "entity_subtype": "OFAC",
      "risk_level": "critical",
      "categories": [
        "sanctioned"
      ],
      "received_usd": null,
      "sent_usd": null,
      "received_hops": null,
      "sent_hops": null,
      "percentage": 0.0,
      "is_direct": true,
      "country": null,
      "provider_entity_id": null
    }
  ],
  "network_nodes": [],
  "network_edges": [],
  "sanctions_hit": true,
  "pep_counterparty": null,
  "dominant_risk_category": "sanctioned",
  "risk_factors": [
    {
      "source": "attribution",
      "category": "sanctioned",
      "label": "Sanctions / OFAC",
      "entity_name": "Example Sanctions",
      "direction": "attribution",
      "exposure_type": "attribution",
      "amount_usd": null,
      "percentage": 0.0,
      "is_high_risk": true,
      "description": "the address is attributed to Sanctions / OFAC (Example Sanctions)"
    },
    {
      "source": "exposure",
      "category": "sanctioned",
      "label": "Sanctions / OFAC",
      "entity_name": "Example Sanctions",
      "direction": "incoming",
      "exposure_type": "direct",
      "amount_usd": 9813695.0,
      "percentage": 51.679304,
      "is_high_risk": true,
      "description": "51.6793% direct incoming exposure to Sanctions / OFAC (Example Sanctions)"
    },
    {
      "source": "exposure",
      "category": "defi",
      "label": "DeFi / Bridges",
      "entity_name": "Example DeFi 7",
      "direction": "outgoing",
      "exposure_type": "indirect",
      "amount_usd": 7783414.38,
      "percentage": 40.987766,
      "is_high_risk": false,
      "description": "40.9878% indirect outgoing exposure to DeFi / Bridges (Example DeFi 7)"
    },
    {
      "source": "exposure",
      "category": "defi",
      "label": "DeFi / Yield Aggregator",
      "entity_name": "Example DeFi 2",
      "direction": "outgoing",
      "exposure_type": "indirect",
      "amount_usd": 1392494.37,
      "percentage": 7.33293,
      "is_high_risk": false,
      "description": "7.33293% indirect outgoing exposure to DeFi / Yield Aggregator (Example DeFi 2)"
    }
  ],
  "raw_response": {
    "...": "provider-specific details"
  },
  "report_signature": "<hmac-sha256 over the result, scoped to your application>"
}

ये उदाहरण रिस्पॉन्स की संरचना दिखाते हैं, किसी वास्तविक पते के लिए गारंटीशुदा निर्णय नहीं देते। जोखिम स्कोर और प्रतिबंध एक्सपोज़र चुने गए नेटवर्क, मौजूदा इंटेलिजेंस और कॉन्फ़िगर की गई जोखिम नीति पर निर्भर करते हैं। किसी एक्सचेंज का एट्रिब्यूशन यह संकेत नहीं देता कि जोखिम स्कोर शून्य है: एक्सचेंज वॉलेट के फ़ंड फ़्लो के ज़रिए प्रतिबंध एक्सपोज़र हो सकता है। sanctions_hit: true का अर्थ यह हो सकता है कि वॉलेट स्वयं प्रतिबंधित है, या केवल यह कि उसके फ़ंड का प्रतिबंध एक्सपोज़र है, इसलिए इससे अपने आप यह निष्कर्ष नहीं निकलता कि स्क्रीन किए गए वॉलेट का मालिक प्रतिबंधित है। जब वही स्क्रीनिंग किसी रिकॉर्ड किए गए ट्रांज़ैक्शन पर चलती है, तो नियम custom_values.wallet_sanctioned भी पढ़ सकते हैं, जो केवल तब true होता है जब प्रदाता वॉलेट को स्वयं किसी प्रतिबंधित इकाई से जोड़ता है, और custom_values.aml_sanctions_exposure_pct। देखें नियमों के लिए स्क्रीनिंग फ़ील्ड। एट्रिब्यूशन और एक्सपोज़र में अंतर समझने के लिए risk_factors, source_of_funds और destination_of_funds पढ़ें। चरण-दर-चरण मार्गदर्शन के लिए देखें क्रिप्टो और वॉलेट स्क्रीनिंग।

PDF रिपोर्ट

स्क्रीनिंग परिणाम की Didit-ब्रांडेड PDF पाने के लिए, report_signature सहित ठीक वही रिस्पॉन्स बॉडी POST /v3/wallet-screening/pdf/ पर फिर से भेजें। यह स्टेटलेस है: कोई प्रदाता कॉल नहीं, कोई अतिरिक्त बिलिंग नहीं, और कुछ भी स्टोर नहीं होता। फिर से भेजने से पहले किसी भी साइन्ड फ़ील्ड (risk_score, severity, sanctions_hit, …) को बदलने पर अनुरोध 400 के साथ विफल होता है।

RESULT=$(curl -s -X POST https://verification.didit.me/v3/wallet-screening/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"wallet_address": "0x94f1b9b64e2932f6a2db338f616844400cd58e8a", "blockchain": "ETH"}')

curl -X POST https://verification.didit.me/v3/wallet-screening/pdf/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d "$RESULT" \
  -o wallet_screening_report.pdf

पूरे अनुरोध/रिस्पॉन्स स्कीमा और एरर के रूप के लिए देखें वॉलेट PDF स्क्रीन करें।

बिलिंग

AML निगरानी का एक उपयोग प्रति सफल स्क्रीनिंग बिल होता है, और इसकी दर लेन-देन से जुड़ी क्रिप्टो स्क्रीनिंग वाली दर के बराबर होती है। managed और connected-key दरों के लिए मूल्य निर्धारण देखें। सैंडबॉक्स एप्लिकेशन पर कोई शुल्क नहीं लगता। सत्यापन त्रुटियों (400) और प्रदाता कॉन्फ़िगर न होने की त्रुटियों (409) पर कभी बिल नहीं किया जाता।

त्रुटियाँ

स्थिति	अर्थ
`400`	वॉलेट पता गलत रूप में है, `wallet_address` गायब है, या `blockchain` समर्थित नहीं है।
`401`	`x-api-key` गायब है या अमान्य है।
`409`	इस एप्लिकेशन के लिए कोई AML प्रदाता कॉन्फ़िगर नहीं है। पहले लेन-देन निगरानी कॉन्फ़िगर करें।
`409`	प्रदाता ने आपकी कनेक्ट की गई API कुंजी अस्वीकार कर दी (`wallet_screening_provider_credentials_rejected`)। Marketplace कनेक्शन पर कुंजी अपडेट करें, या यदि कुंजी लेन-देन निगरानी सेटिंग्स में कॉन्फ़िगर है तो वहाँ अपडेट करें। उसी कुंजी से दोबारा प्रयास करने से कोई मदद नहीं मिलती।
`409`	कॉन्फ़िगर किया गया AML प्रदाता अभी वॉलेट स्क्रीनिंग का समर्थन नहीं करता (`wallet_screening_provider_unavailable`)।
`422`	`0x` पता `blockchain` के बिना भेजा गया (`wallet_screening_chain_undetermined`)। रिस्पॉन्स बॉडी में `candidate_chains` सूचीबद्ध होते हैं; उनमें से किसी एक के साथ दोबारा भेजें। कुछ भी स्क्रीन या बिल नहीं किया जाता।
`502`	प्रदाता स्क्रीनिंग पूरी नहीं कर सका; बाद में पुनः प्रयास करें।

अगले चरण

API संदर्भ

Screen Wallet endpoint के लिए पूर्ण अनुरोध और रिस्पॉन्स स्कीमा।

वॉलेट स्क्रीनिंग PDF

स्क्रीनिंग परिणाम को Didit ब्रांड वाले PDF के रूप में रेंडर करें।

क्रिप्टो और वॉलेट स्क्रीनिंग

लेन-देन बनने के दौरान स्वचालित स्क्रीनिंग और परिणाम मॉडल।

शुरुआत करें

सुविधाएँ

संदर्भ

कंसोल

ऑन-डिमांड वॉलेट स्क्रीनिंग API: लेन-देन की आवश्यकता नहीं

इसे कब उपयोग करें

पूर्वापेक्षाएँ

अनुरोध

चेन कवरेज

रिस्पॉन्स

जोखिम कारक

एक्सपोज़र विवरण

प्रतिपक्ष संबंध

उदाहरण

PDF रिपोर्ट

बिलिंग

त्रुटियाँ

अगले चरण

API संदर्भ

वॉलेट स्क्रीनिंग PDF

क्रिप्टो और वॉलेट स्क्रीनिंग

​इसे कब उपयोग करें

​पूर्वापेक्षाएँ

​अनुरोध

​चेन कवरेज

​रिस्पॉन्स

​जोखिम कारक

​एक्सपोज़र विवरण

​प्रतिपक्ष संबंध

​उदाहरण

​PDF रिपोर्ट

​बिलिंग

​त्रुटियाँ

​अगले चरण

API संदर्भ

वॉलेट स्क्रीनिंग PDF

क्रिप्टो और वॉलेट स्क्रीनिंग

इसे कब उपयोग करें

पूर्वापेक्षाएँ

अनुरोध

चेन कवरेज

रिस्पॉन्स

जोखिम कारक

एक्सपोज़र विवरण

प्रतिपक्ष संबंध

उदाहरण

PDF रिपोर्ट

बिलिंग

त्रुटियाँ

अगले चरण