> ## 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.

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

> Didit के साथ बिना लेन-देन बनाए एक क्रिप्टो वॉलेट पते की AML जोखिम स्क्रीनिंग करें। धन का स्रोत, प्रतिबंध संपर्क और जोखिम स्कोर तुरंत पाएँ।

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

यह [स्वचालित क्रिप्टो स्क्रीनिंग](https://docs.didit.me/hi/transaction-monitoring/aml-screening.md) का स्टैंडअलोन समकक्ष है, जो [लेन-देन सबमिशन](https://docs.didit.me/hi/transaction-monitoring/transactions.md) के दौरान चलती है। दोनों एक ही ब्लॉकचेन एनालिटिक्स प्रदाताओं और एक ही परिणाम संरचना का उपयोग करते हैं।

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

| उपयोग का मामला | Endpoint |
| - | - |
| बिना दर्ज करने लायक लेन-देन के पते की पूर्व-जाँच | **वॉलेट स्क्रीनिंग** — `POST /v3/wallet-screening/` |
| दर्ज किए गए जमा/निकासी के हिस्से के रूप में वॉलेट की स्क्रीनिंग | [Create Transaction](https://docs.didit.me/hi/transaction-monitoring/transactions.md) के साथ `currency_kind: "crypto"` |

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

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

एप्लिकेशन के लिए लेन-देन निगरानी या तो किसी प्रबंधित प्रदाता के साथ, या [मौजूदा प्रदाता कुंजी](https://docs.didit.me/hi/transaction-monitoring/aml-screening.md#समर्थित-प्रदाता) के साथ कॉन्फ़िगर होनी चाहिए। इसे [Business Console](https://business.didit.me) में **लेनदेन** > **सेटिंग्स** > **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` में अलग से निर्दिष्ट करें।
देखें [एसेट और नेटवर्क चयन](https://docs.didit.me/hi/transaction-monitoring/aml-screening.md#एसेट-और-नेटवर्क-चयन)।

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

```bash theme={null}
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 के रूप में रेंडर करने](#pdf-रिपोर्ट) के लिए रिस्पॉन्स को, इस फ़ील्ड सहित, बिना किसी बदलाव के फिर से पोस्ट करें। |

> [!NOTE]
>
> **`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)`। |

> [!NOTE]
>
> **बिना `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 | इकाई के लिए प्रदाता का अपना पहचानकर्ता। |

> [!WARNING]
>
> `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` बदला गया है:

```json theme={null}
{
  "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`।
देखें [नियमों के लिए स्क्रीनिंग फ़ील्ड](https://docs.didit.me/hi/transaction-monitoring/aml-screening.md#नियमों-के-लिए-स्क्रीनिंग-फ़ील्ड)।
एट्रिब्यूशन और एक्सपोज़र में अंतर समझने के लिए `risk_factors`, `source_of_funds` और `destination_of_funds` पढ़ें।
चरण-दर-चरण मार्गदर्शन के लिए देखें [क्रिप्टो और वॉलेट स्क्रीनिंग](https://docs.didit.me/hi/transaction-monitoring/aml-screening.md#स्क्रीनिंग-परिणाम)।

## PDF रिपोर्ट

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

```bash theme={null}
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 स्क्रीन करें](https://docs.didit.me/hi/management-api/transactions/screen-wallet-pdf.md)।

## बिलिंग

AML निगरानी का एक उपयोग प्रति सफल स्क्रीनिंग बिल होता है, और इसकी दर लेन-देन से जुड़ी क्रिप्टो स्क्रीनिंग वाली दर के बराबर होती है। managed और connected-key दरों के लिए [मूल्य निर्धारण](https://docs.didit.me/hi/transaction-monitoring/aml-screening.md#समर्थित-प्रदाता) देखें। सैंडबॉक्स एप्लिकेशन पर कोई शुल्क नहीं लगता। सत्यापन त्रुटियों (`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` | प्रदाता स्क्रीनिंग पूरी नहीं कर सका; बाद में पुनः प्रयास करें। |

## अगले चरण

> [card] [API संदर्भ](https://docs.didit.me/hi/management-api/transactions/screen-wallet.md)
>
> Screen Wallet endpoint के लिए पूर्ण अनुरोध और रिस्पॉन्स स्कीमा।

> [card] [वॉलेट स्क्रीनिंग PDF](https://docs.didit.me/hi/management-api/transactions/screen-wallet-pdf.md)
>
> स्क्रीनिंग परिणाम को Didit ब्रांड वाले PDF के रूप में रेंडर करें।

> [card] [क्रिप्टो और वॉलेट स्क्रीनिंग](https://docs.didit.me/hi/transaction-monitoring/aml-screening.md)
>
> लेन-देन बनने के दौरान स्वचालित स्क्रीनिंग और परिणाम मॉडल।


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