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

# लेन-देन निगरानी नियम, स्कोरिंग, वेलोसिटी और शर्तें (KYT)

> Didit के साथ KYT नियम शर्तों, वेलोसिटी विंडो और स्वचालित कार्रवाइयों के साथ कॉन्फ़िगर करें, प्रीसेट बंडल या कस्टम से। हर महीने 1,000 शामिल, फिर $0.001 प्रति।

हर वह लेन-देन जो Didit को भेजा जाता है, आपके एप्लिकेशन के सभी सक्रिय नियमों से जाँचा जाता है। नियम शर्तें, वेग जाँच और कार्रवाइयां तय करते हैं, जो लेन-देन की अंतिम स्थिति और स्कोर निर्धारित करती हैं।

Didit Academy के धोखाधड़ी नियम इंजन पाठ का यह अध्याय नियम बनाने वाले चरण से आगे बढ़ता है।

Didit Academy के रूल-इंजन पाठ में 7:54 पर वीडियो में एक नियम बनाना दिखाया गया है: ट्रिगर, शर्तें, कार्रवाइयां और स्कोरिंग, और फिर डिप्लॉय से पहले बैकटेस्टिंग।

[नियम बनाना: Didit Academy](https://www.youtube.com/embed/Yhm63_n7HuU?start=474\&rel=0\&playsinline=1)

> [!NOTE]
>
> नियमों को **बिजनेस कंसोल**, **Management API** और **Didit MCP** से प्रबंधित किया जा सकता है। जब आपकी अनुपालन टीम का कोई व्यक्ति हर बदलाव की समीक्षा करना चाहे, तो कंसोल का उपयोग करें। जब नियम प्रोग्रामेटिक रूप से बनाए और ट्यून किए जाएं, जैसे किसी दूसरे प्रदाता से नियम सेट माइग्रेट करते समय, तब API या MCP का उपयोग करें। देखें [API संदर्भ](https://docs.didit.me/hi/management-api/transactions/rules-list.md) और [API और MCP के जरिए नियम प्रबंधित करने की गाइड](https://docs.didit.me/hi/transaction-monitoring/rules-api.md)। नियमों का मूल्यांकन [`POST /v3/transactions/`](https://docs.didit.me/hi/management-api/transactions/create) पर भेजे गए हर लेन-देन पर होता है, और परिणाम लेन-देन के `rule_runs[]` सरणी में दिखता है (देखें [रिस्पॉन्स स्कीमा](https://docs.didit.me/hi/transaction-monitoring/response-schema.md))।

## अंतर्निहित नियम बंडल

Didit एक पूर्व-कॉन्फ़िगर्ड नियम लाइब्रेरी उपलब्ध कराता है, जो आम नियामक टाइपोलॉजी को कवर करती है। नियम लाइब्रेरी से वे प्रीसेट (या पूरे बंडल) इंस्टॉल करें जो आपको चाहिए, चाहे [install API](https://docs.didit.me/hi/management-api/transactions/rules-install.md) से, बिजनेस कंसोल में, या MCP टूल्स से, और इंस्टॉल किए गए हर प्रीसेट का मोड नियंत्रित करें। थ्रेशोल्ड और कार्रवाइयों के साथ हर प्रीसेट नियम की पूरी सूची के लिए देखें [नियम लाइब्रेरी](https://docs.didit.me/hi/transaction-monitoring/rules-library.md)।

| बंडल | उदाहरण |
| - | - |
| **वित्त** | स्ट्रक्चरिंग का पता लगाना (आवक/जावक), रिपोर्टिंग थ्रेशोल्ड से ऊपर के बड़े एकल लेन-देन |
| **AML/CTF** | संचयी मात्रा सीमाएं, तेज़ आवक-जावक आवाजाही, प्रतिबंधित प्रतिपक्षों का मिलान, संदिग्ध भुगतान संदर्भ कीवर्ड |
| **विसंगति का पता लगाना** | उच्च वेग आवक/जावक, 12+ महीने की निष्क्रियता के बाद डॉर्मेंट खाते का फिर से सक्रिय होना |
| **FATF** | प्रतिपक्षों और संबंधित IP पतों के लिए उच्च-जोखिम वाले क्षेत्राधिकारों से एक्सपोज़र |
| **डिवाइस इंटेलिजेंस** | एक ही डिवाइस फ़िंगरप्रिंट से बार-बार बोनस अभियान का उपयोग, एक ही संबंधित इकाई के लिए कई डिवाइस फ़िंगरप्रिंट |
| **धोखाधड़ी की रोकथाम** | अलग-अलग संबंधित इकाइयों के बीच साझा डिवाइस फ़िंगरप्रिंट के जरिए एकाधिक खाते बनाना |
| **क्रिप्टो निगरानी** | मिक्सर/ऑब्फ़स्केशन सेवा से एक्सपोज़र, उच्च-जोखिम वाले वॉलेट पते (darknet, प्रतिबंधित, चोरी के फंड) |
| **क्रिप्टो स्क्रीनिंग** | उच्च-जोखिम वाले धन के स्रोत से एक्सपोज़र (>30%), कई जोखिम भरे प्रतिपक्ष, आतंकवाद वित्तपोषण / बाल शोषण पर स्वतः अस्वीकृति, स्क्रीनिंग लंबित होने पर होल्ड, मध्यम वॉलेट जोखिम स्कोर पर फ़्लैगिंग |
| **जिम्मेदार गेमिंग** | छोटी अवधि में जमाओं की तेज़ बौछार |
| **ई-कॉमर्स** | ई-कॉमर्स विशिष्ट लेन-देन पैटर्न |

## नियमों के स्रोत

हर नियम का एक `source` होता है, जो बताता है कि उसे कौन प्रबंधित करता है:

| स्रोत | विवरण |
| - | - |
| **प्रीसेट** | Didit की अंतर्निहित लाइब्रेरी से इंस्टॉल किए गए नियम। आप चुनते हैं कि कौन से प्रीसेट (या पूरे बंडल) इंस्टॉल करने हैं, और इंस्टॉल किए गए हर प्रीसेट का मोड नियंत्रित करते हैं (`Active`, `Test`, `Disabled`)। उनकी शर्तें और थ्रेशोल्ड तय हैं। किसी एक को बदलने के लिए कस्टम नियम बनाएं। उन्हें डिलीट नहीं, बल्कि अनइंस्टॉल करके हटाया जाता है। |
| **कस्टम** | आपकी टीम द्वारा बिजनेस कंसोल से बनाए गए नियम। कस्टम नियमों पर आपका पूरा नियंत्रण है: जरूरत के अनुसार बनाएं, संपादित करें और डिलीट करें। |

## नियम की संरचना

हर नियम में ये घटक होते हैं:

| घटक | विवरण |
| - | - |
| **शीर्षक और विवरण** | मानव-पठनीय नाम और यह स्पष्टीकरण कि नियम क्या पहचानता है |
| **श्रेणी** | तार्किक समूह (जैसे `finance`, `aml_ctf`, `crypto_monitoring`, `device_intelligence`) |
| **मोड** | `Active` (लाइव मूल्यांकन), `Disabled` (छोड़ा जाता है), या `Test` (मूल्यांकन होता है, पर परिणाम लेन-देन को प्रभावित नहीं करते) |
| **मूल्यांकन मोड** | `All` (हर शर्त का मेल होना चाहिए) या `Any` (कम से कम एक शर्त का मेल होना चाहिए) |
| **दायरा** | सीमित करता है कि नियम किन लेन-देन पर लागू होता है। कुंजियां: `transaction_types`, `directions` (`INBOUND`/`OUTBOUND`), `action_types`। खाली या अनुपस्थित होने का अर्थ है कोई प्रतिबंध नहीं |
| **शर्तें** | फ़ील्ड-स्तरीय जाँच, जो लेन-देन के फ़ील्ड की तुलना मानों से `eq`, `lt`, `gte`, `in`, `contains_any`, `exists` जैसे ऑपरेटरों का उपयोग करके करती है |
| **एकत्रीकरण** | वेग विंडो, जो एक समय अवधि में पिछले लेन-देन को एकत्रित करती है (जैसे 1 घंटे, 7 दिन, 30 दिन में गिनती, योग या अलग गिनती) |
| **कार्रवाइयां** | नियम मेल खाने पर क्या होता है (नीचे देखें) |

## कार्रवाइयाँ

जब कोई नियम किसी लेन-देन से मेल खाता है, तो एक या अधिक कार्रवाइयाँ निष्पादित होती हैं। हर नियम में कई कार्रवाइयाँ हो सकती हैं, और वे सभी एक साथ लागू होती हैं:

| कार्रवाई | `type` | कुंजियाँ | विवरण |
| - | - | - | - |
| **स्कोर जोड़ें** | `add_score` | `value` (पूर्णांक, ऋणात्मक भी हो सकता है) | लेन-देन के जोखिम स्कोर में अंक जोड़ता है। सभी मिलान किए गए नियमों का संचयी स्कोर तय करता है कि लेन-देन समीक्षा थ्रेशोल्ड या अस्वीकृति थ्रेशोल्ड पार करता है या नहीं। |
| **स्थिति बदलें** | `change_status` | `value` (`APPROVED`\|`IN_REVIEW`\|`DECLINED`\|`AWAITING_USER`, उपनाम `status`), `workflow_id` (उपनाम `remediation_workflow_id`) | स्कोर की परवाह किए बिना लेन-देन की स्थिति को सीधे सेट करता है। जब `value` `AWAITING_USER` हो, तो `workflow_id` आवश्यक है; इसे छोड़ने पर `400` लौटता है। |
| **टैग जोड़ें** | `add_tags` | `tag_uuid` या `tag_name` (इनमें से एक), `tag_color` | वर्गीकरण और फ़िल्टरिंग के लिए लेन-देन पर टैग लगाता है। मौजूदा टैग का `tag_uuid`, या `tag_name` जो पहली बार उपयोग होने पर बनता है (बड़े अक्षरों में संग्रहीत); `tag_color` नए बने टैग का हेक्स रंग सेट करता है। |
| **नोट जोड़ें** | `add_note` | `note` (उपनाम `value`) | विश्लेषक के संदर्भ के लिए लेन-देन के साथ एक स्वचालित टेक्स्ट नोट संलग्न करता है। |
| **सूची में जोड़ें** | `add_to_list` | `list_id` | विषय के `vendor_data` को ब्लॉकलिस्ट, अनुमति सूची या कस्टम सूची में जोड़ता है। |
| **केस खोलें** | `open_case` | `blueprint` (केस ब्लूप्रिंट UUID, वैकल्पिक), `grouping` (`by_applicant`\|`by_rule_and_applicant`), `attach_matched_transaction` (बूलियन) | जाँच केस खोलता है (या उसमें जोड़ता है)। किसी नियम पर केवल पहली `open_case` कार्रवाई लागू होती है। |

अधिकांश पूर्व-निर्धारित नियम **स्कोर जोड़ें** को **स्थिति बदलें** के साथ जोड़ते हैं; उदाहरण के लिए, प्रतिबंध प्रतिपक्ष नियम स्कोर में 90 अंक जोड़ता है *और* लेन-देन को तुरंत अस्वीकार कर देता है।

### उपयोगकर्ता सत्यापन की आवश्यकता (`AWAITING_USER`)

**स्थिति बदलें → `AWAITING_USER`** कार्रवाई केवल स्थिति सेट करने से अधिक करती है: नियम के सक्रिय होते ही Didit लेन-देन के विषय (वही `vendor_data`) के लिए एक होस्टेड सत्यापन सत्र स्वतः बना देता है।
सत्र लेन-देन के `action_required` ब्लॉक (और `remediation` ऑब्जेक्ट) में बनाने के रिस्पॉन्स और उसके बाद के हर रीड में, तथा दोनों लेन-देन webhook में लौटता है; इसलिए आप उपयोगकर्ता को तुरंत रीडायरेक्ट कर सकते हैं। देखें [आवश्यक उपयोगकर्ता कार्रवाइयाँ](https://docs.didit.me/hi/transaction-monitoring/sdk-transaction-submission.md#आवश्यक-उपयोगकर्ता-क्रियाएँ)।

कस्टम नियमों को कार्रवाई पर ही वर्कफ़्लो का नाम देना होगा (`workflow_id`); कंसोल नियम बिल्डर और नियम API, दोनों इसकी माँग करते हैं।
अंतर्निहित लाइब्रेरी नियमों में कोई वर्कफ़्लो नहीं होता; इनके लिए सत्र का वर्कफ़्लो इस क्रम में तय होता है:

1. आपकी [लेन-देन सेटिंग्स](https://docs.didit.me/hi/transaction-monitoring/settings.md#सुधारात्मक-वर्कफ़्लो) में कॉन्फ़िगर किया गया **सुधार वर्कफ़्लो**।
2. आपके एप्लिकेशन का **बायोमेट्रिक प्रमाणीकरण** वर्कफ़्लो, जब विषय के पास किसी स्वीकृत सत्यापन से सहेजा गया संदर्भ चेहरा पहले से हो।
3. आपके एप्लिकेशन का डिफ़ॉल्ट वर्कफ़्लो।

इसका अर्थ है कि `AWAITING_USER` लाइब्रेरी नियम हमेशा तुरंत कार्रवाई योग्य सत्र बनाते हैं: जिन उपयोगकर्ताओं को आप पहले सत्यापित कर चुके हैं उनके लिए बायोमेट्रिक स्टेप-अप, अन्यथा पूर्ण सत्यापन।
Travel Rule लेन-देन इस स्वचालित विकल्प से बाहर हैं: उनका `AWAITING_USER` इंतज़ार वॉलेट स्वामित्व के प्रमाण के लिए होता है, जिसका [अपना अलग प्रवाह](https://docs.didit.me/hi/transaction-monitoring/wallet-ownership-widget.md) है।

उच्च जोखिम वाले लेन-देन के लिए सबसे मज़बूत विकल्प **बायोमेट्रिक प्रमाणीकरण** वर्कफ़्लो है: क्योंकि विषय वही उपयोगकर्ता है जिसका आपने KYC किया है, Didit उनके ऑनबोर्डिंग के सत्यापित संदर्भ चेहरे का पुनः उपयोग करता है (स्वीकृत लाइवनेस सेल्फ़ी, पासपोर्ट चिप फ़ोटो या दस्तावेज़ का पोर्ट्रेट); उपयोगकर्ता बस एक लाइव सेल्फ़ी लेता है, और Didit उस पहचान के साथ, जिसका उपयोग खाता खोलने के लिए किया गया था, लाइवनेस के साथ 1:1 चेहरा मिलान करता है।
चुराए गए क्रेडेंशियल, फ़िशिंग से मिले OTP और SIM स्वैप, इस गेट पर सभी विफल हो जाते हैं।
पूरा चरण-दर-चरण मार्गदर्शन: [उच्च मूल्य वाली निकासी के लिए स्टेप-अप बायोमेट्रिक्स](https://docs.didit.me/hi/transaction-monitoring/sdk-transaction-submission.md#उदाहरण-उच्च-मूल्य-निकासी-के-लिए-बायोमेट्रिक-अतिरिक्त-जाँच)।

जब सत्र किसी निर्णय पर पहुँचता है, तो लेन-देन स्वतः उसी का अनुसरण करता है और `transaction.status.updated` webhook फ़ायर होता है: स्वीकृत सत्र लेन-देन को स्वीकृत करता है (`decision_reason_code: user_action_approved`), अस्वीकृत सत्र उसे अस्वीकृत करता है (`user_action_declined`), और समीक्षा पर समाप्त होने वाला सत्र लेन-देन को `IN_REVIEW` में भेजता है (`user_action_in_review`)।
समय-सीमा समाप्त या छोड़ा गया सत्र लेन-देन को `AWAITING_USER` में रखता है।

> [!NOTE]
>
> KYB को छोड़कर कोई भी वर्कफ़्लो प्रकार सुधार कार्रवाई के रूप में उपयोग किया जा सकता है।
> बायोमेट्रिक प्रमाणीकरण वर्कफ़्लो (और वे वर्कफ़्लो जहाँ पहचान सत्यापन से पहले चेहरा मिलान चलता है) के लिए विषय का सहेजा गया संदर्भ चेहरा भी आवश्यक है: स्वीकृत लाइवनेस सेल्फ़ी, पासपोर्ट चिप फ़ोटो, दस्तावेज़ का पोर्ट्रेट, या मैन्युअल रूप से दर्ज किया गया प्रोफ़ाइल चेहरा।
> यदि ऐसा कोई चेहरा मौजूद नहीं है, तो उपयोगकर्ता से इसके बजाय आपके एप्लिकेशन का डिफ़ॉल्ट वर्कफ़्लो पूरा करने के लिए कहा जाता है, जो अगली बार के लिए उनका चेहरा भी दर्ज करता है, और लेन-देन पर एक नोट इस प्रतिस्थापन को दर्ज करता है।
> केवल तब सत्र छोड़ा जाता है जब कोई उपयुक्त डिफ़ॉल्ट वर्कफ़्लो भी मौजूद न हो, और नोट इसका कारण बताता है।

## स्कोरिंग

जब कोई लेन-देन एक या अधिक नियमों से मेल खाता है, तो स्कोर जोड़े जाते हैं:

1. हर नियम का मिलान `add_score` कार्रवाई के माध्यम से लेन-देन के समग्र **जोखिम स्कोर** में योगदान देता है
2. अंतिम स्कोर आपके एप्लिकेशन के **स्कोर थ्रेशोल्ड** के आधार पर लेन-देन की स्थिति तय करता है
3. यदि किसी नियम में `change_status` कार्रवाई है, तो वह स्थिति सीधे लागू होती है; `DECLINED` को हमेशा प्राथमिकता मिलती है

डिफ़ॉल्ट स्कोर थ्रेशोल्ड (कंसोल में कॉन्फ़िगर करने योग्य):

| सेटिंग | डिफ़ॉल्ट | विवरण |
| - | - | - |
| **समीक्षा थ्रेशोल्ड** | 75 | इस मान या इससे अधिक स्कोर `IN_REVIEW` को ट्रिगर करते हैं |
| **अस्वीकृति थ्रेशोल्ड** | 500 | इस मान या इससे अधिक स्कोर `DECLINED` को ट्रिगर करते हैं। डिफ़ॉल्ट (`500`) स्कोर के आधार पर कभी अस्वीकार नहीं करता |

## कस्टम नियम बनाना

कस्टम नियम **बिजनेस कंसोल** से बनाए जा सकते हैं, या **Management API** के ज़रिए भी ([Didit MCP](https://docs.didit.me/hi/integration/mcp/tools.md) और किसी भी MCP-कनेक्टेड AI असिस्टेंट से).

> [tab] कंसोल
>
> 1. कंसोल में **लेनदेन** > **नियम** पर जाएँ
> 2. **Create Rule** पर क्लिक करें
> 3. नियम का शीर्षक, विवरण और श्रेणी तय करें
> 4. **mode** सेट करें - लाइव चलाने के लिए `Active`, या लेनदेन पर असर डाले बिना मूल्यांकन के लिए `Test`
> 5. **evaluation mode** चुनें - `All` (हर शर्त का मेल होना ज़रूरी है) या `Any` (कम से कम एक शर्त का मेल)
> 6. **scope** सेट करें - यानी कौन-से लेनदेन प्रकार या दिशाएँ इस नियम पर लागू होंगी
> 7. **conditions** जोड़ें - फ़ील्ड की तुलनाएँ, जैसे राशि की सीमाएँ, देश कोड, कस्टम प्रॉपर्टी की जाँच
> 8. चाहें तो **aggregation** जोड़ें - किसी समय विंडो पर वेलोसिटी जाँच (count, sum, distinct count और अन्य)
> 9. एक या अधिक **कार्रवाइयाँ** तय करें - स्कोर जोड़ना, स्थिति बदलना, टैग जोड़ना, नोट जोड़ना, सूची में जोड़ना, या केस खोलना
> 10. नियम सेव करें और उसे सक्षम करें

> [tab] API
>
> उन्हीं फ़ील्ड के साथ [`POST /v3/transactions/rules/`](https://docs.didit.me/hi/management-api/transactions/rules-create) को कॉल करें: `title`, `category`, `mode`, `evaluation_mode`, `scope`, `conditions`, `aggregation`, `actions`। फ़ील्ड, ऑपरेटर और action का पूरा संदर्भ इसी पेज पर है, और [API और MCP के ज़रिए नियम प्रबंधित करना](https://docs.didit.me/hi/transaction-monitoring/rules-api.md) में अनुशंसित वर्कफ़्लो समझाया गया है: बनाएँ -> बैकटेस्ट करें -> सक्रिय करें। इसमें किसी दूसरे प्रदाता के CSV एक्सपोर्ट से नियम सेट का माइग्रेशन भी शामिल है।

`Active` मोड वाले नियम सभी नए लेनदेन पर तुरंत लागू हो जाते हैं। शीर्षक हर एप्लिकेशन में अद्वितीय होने चाहिए।

## बैकटेस्टिंग

नियम सक्रिय करने से पहले, आप उसे ऐतिहासिक डेटा पर परख सकते हैं:

* किसी नियम को **टेस्ट** मोड में रखें - नियम हर नए लेनदेन पर मूल्यांकित होता है, लेकिन नतीजे लेनदेन की स्थिति या स्कोर पर असर नहीं डालते। निष्पादन के आँकड़े (मेल खाने की संख्या, प्रभावित इकाइयाँ) जमा होते रहते हैं, ताकि लाइव जाने से पहले आप असर का आकलन कर सकें।
* **backtest** फ़ीचर का उपयोग करें - कंसोल में, या [`POST /v3/transactions/rules/backtest/`](https://docs.didit.me/hi/management-api/transactions/rules-backtest) के ज़रिए - ताकि किसी तय समय अवधि के लेनदेन पर नियम की शर्तों और एग्रीगेशन का पिछली तारीख से मूल्यांकन हो सके। बैकटेस्ट मूल्यांकित, मेल खाने वाले लेनदेन की संख्या और प्रभावित इकाइयाँ लौटाता है, और किसी भी ऐतिहासिक डेटा को नहीं बदलता। जिस नियम को आप सक्रिय करना चाहते हैं, उसी के `conditions`, `aggregation`, `evaluation_mode` **और** `scope` भेजें: छूटा हुआ scope कोई प्रतिबंध न होने का मतलब रखता है, इसलिए बैकटेस्ट उन लेनदेन की भी गिनती करेगा जिन्हें सहेजा गया नियम छोड़ देता है।

## वेलोसिटी विंडो (एग्रीगेशन)

वेलोसिटी नियम किसी समय अवधि में ऐतिहासिक लेनदेन डेटा को एग्रीगेट करते हैं, ताकि ऐसे पैटर्न पकड़े जा सकें जो अकेले लेनदेन की जाँच में छूट जाते।

| मीट्रिक | विवरण |
| - | - |
| `count` | विंडो में फ़िल्टर से मेल खाने वाले लेनदेन की संख्या |
| `sum` | विंडो में किसी संख्यात्मक `field` (जैसे `preferred_currency_amount`) का कुल योग |
| `max` / `min` / `avg` | विंडो में किसी संख्यात्मक `field` का सबसे बड़ा, सबसे छोटा, या औसत मान |
| `distinct_count` | विंडो में किसी `field` के अद्वितीय मानों की संख्या (जैसे अलग-अलग डिवाइस फ़िंगरप्रिंट)। `unique_count` भी मान्य उपनाम है |

हर aggregation में ये तय होते हैं:

* **समय विंडो**: `<N>m` (मिनट), `<N>h` (घंटे), या `<N>d` (दिन) - जैसे `30m`, `6h`, `7d`, `30d`। ध्यान दें: `m` का अर्थ **मिनट** है, महीने नहीं।
* **फ़िल्टर**, जिनसे तय होता है कि कौन-से ऐतिहासिक लेनदेन शामिल हों। कुंजियाँ [फ़ील्ड कैटलॉग](#फ़ील्ड-कैटलॉग) से फ़ील्ड पथ होते हैं; विशेष मान `"__current__"` मूल्यांकित किए जा रहे लेनदेन में उसी फ़ील्ड के मान में बदल जाता है (जैसे `"subject_vendor_data": "__current__"` विंडो को उसी इकाई तक सीमित करता है), और सूची वाला मान सदस्यता का अर्थ देता है। फ़िल्टर केवल बराबरी या सदस्यता से तुलना करते हैं - कोई `lt`/`gte` फ़िल्टर नहीं है, इसलिए *10,000 से कम के लेनदेन* जैसी सीमा फ़िल्टर से व्यक्त नहीं की जा सकती। ऐसी सीमा मीट्रिक पर लगाएँ (`max` 10,000 से कम, `min` 1,000 से ऊपर), और याद रखें कि शर्त हमेशा मूल्यांकित हो रहे लेनदेन को सीमित करती है, विंडो को नहीं।
* एक **ऑपरेटर और थ्रेशोल्ड** (`eq`, `ne`, `gt`, `gte`, `lt`, `lte`, जो `value` से तुलना करते हैं, जैसे count >= 20)

### उदाहरण पैटर्न

| पैटर्न | यह कैसे काम करता है |
| - | - |
| **संरचना** | 30 दिनों में एक ही इकाई के लेनदेन की गिनती >= 20, और उसी विंडो में `max` राशि \$10,000 से कम |
| **उच्च गति** | 7 दिनों में एक ही इकाई के आवक लेनदेन की गिनती >= 20 |
| **तेज़ आवक-जावक** | मौजूदा लेनदेन जावक है + 6 घंटों में एक ही इकाई के आवक लेनदेन की गिनती >= 1 |
| **बहु-खाता उपयोग** | 7 दिनों में एक ही डिवाइस फ़िंगरप्रिंट साझा करने वाली इकाइयों की distinct count >= 3 |
| **निष्क्रिय खाते का पुनः सक्रियण** | इकाई के पिछले लेनदेन के बाद बीते दिन >= 365, राशि >= \$1,000 के साथ |

## फ़ील्ड कैटलॉग

शर्तें और एग्रीगेशन फ़िल्टर पथ के ज़रिए लेन-देन के फ़ील्ड का संदर्भ देते हैं:

| फ़ील्ड | विवरण |
| - | - |
| `amount`, `currency` | लेन-देन की राशि और मुद्रा कोड |
| `preferred_currency_amount`, `default_currency_code` | राशि को आपके एप्लिकेशन की पसंदीदा मुद्रा में बदली गई (उपलब्ध न होने पर `amount_in_default_currency` का उपयोग होता है) |
| `direction` | `INBOUND` या `OUTBOUND` |
| `action_type` | आपकी कार्रवाई का प्रकार, जैसे `withdrawal`, `deposit`, `bet` |
| `transaction_type` | `finance`, `kyc`, `travelRule`, `userPlatformEvent` |
| `payment_details` | मुक्त-पाठ भुगतान संदर्भ (मुख्यशब्द नियमों के लिए `contains_any` का लक्ष्य) |
| `score`, `severity` | लेन-देन का वर्तमान जोखिम स्कोर और गंभीरता |
| `subject_vendor_data`, `counterparty_vendor_data` | दोनों पक्षों के लिए आपके पहचानकर्ता |
| `subject_country`, `counterparty_country` | पक्षों के देश कोड (ISO-2 और ISO-3 दोनों स्वीकार्य हैं; तुलना से पहले इन्हें सामान्यीकृत किया जाता है) |
| `subject_device_fingerprint`, `counterparty_device_fingerprint` | डिवाइस फ़िंगरप्रिंट या स्थायी डिवाइस id |
| `subject_browser_family`, `subject_browser_version`, `subject_platform`, `subject_accept_language`, `subject_session_age_ms` | डिवाइस संदर्भ के विवरण (`counterparty_browser_family` भी उपलब्ध है) |
| `subject_ip_address`, `subject_ip_country`, `counterparty_ip_address`, `counterparty_ip_country` | नेटवर्क संदर्भ |
| `subject_payment_method_type`, `subject_payment_method_country`, `subject_payment_method_fingerprint`, `subject_payment_method_account_id` | subject की ओर की भुगतान विधि (यही चार फ़ील्ड `counterparty_payment_method_*` के लिए भी मौजूद हैं) |
| `travel_rule_status`, `travel_rule_required`, `travel_rule_obligations_count` | Travel Rule जाँच की स्थिति |
| `counterparty_dd_status`, `counterparty_risk_level`, `counterparty_jurisdiction`, `counterparty_responsiveness` | उस प्रतिपक्ष VASP के बारे में आपकी जानकारी, जिस तक Travel Rule एक्सचेंज पहुँचा: उस पर आपका निर्णय (`APPROVED`, `RESTRICTED`, `BLOCKED`), उसका जोखिम स्तर (`LOW`, `MEDIUM`, `HIGH`; जब आपकी अपनी प्रतिपक्ष स्क्रीनिंग चिन्हित हो तब `HIGH`), उसका देश, और उसकी प्रतिक्रियाशीलता (`RESPONSIVE`, `UNRESPONSIVE`, `UNKNOWN`)। देखें [Travel Rule में प्रतिपक्ष की उचित जाँच-पड़ताल](https://docs.didit.me/hi/transaction-monitoring/travel-rule.md#नियम-फ़ील्ड-और-प्रीसेट) |
| `subject_days_since_previous_transaction` | इस पक्ष के उसी प्रकार के पिछले लेन-देन के बाद बीते दिन (निष्क्रियता नियम) |
| `tags` | लेन-देन के टैग नाम |
| `custom_values.<key>` | लेन-देन बनाते समय आपके द्वारा `custom_properties` में भेजी गई कोई भी कुंजी |

## शर्त ऑपरेटर

नियम शर्तों के लिए नीचे दिए गए तुलना ऑपरेटरों को सपोर्ट करते हैं:

| ऑपरेटर | विवरण | उदाहरण |
| - | - | - |
| `eq` / `ne` | बराबर / बराबर नहीं | `direction eq "OUTBOUND"` |
| `gt` / `gte` / `lt` / `lte` | संख्यात्मक और तिथि-आधारित तुलनाएँ; जब किसी एक पक्ष में मान अनुपस्थित हो, तो कभी मेल नहीं खाता | `preferred_currency_amount gte 25000` |
| `in` / `not_in` | सूची में सदस्यता (एक अकेला स्केलर मान भी स्वीकार्य है) | `counterparty_country in ["IRN", "PRK", "SYR"]` |
| `contains` / `not_contains` | स्ट्रिंग मान में केस-असंवेदी उप-स्ट्रिंग खोज | `payment_details contains "refund"` |
| `contains_any` | सूची की कोई भी स्ट्रिंग फ़ील्ड में केस-असंवेदी उप-स्ट्रिंग के रूप में मौजूद हो | `payment_details contains_any ["terror", "weapon"]` |
| `regex` | मान का पैटर्न फ़ील्ड से मेल खाता है | `subject_vendor_data regex "^guest-"` |
| `fuzzy_match` | फ़ज़ी स्ट्रिंग समानता; शर्त पर `score` थ्रेशोल्ड (0-100) आवश्यक है | `counterparty_name fuzzy_match "Acme Corp"` के साथ `score: 85` |
| `exists` / `is_not_empty` / `is_not_null` | फ़ील्ड मौजूद है (उपनाम; `value` अनदेखा किया जाता है) | `subject_device_fingerprint exists` |
| `not_exists` / `is_empty` / `is_null` | फ़ील्ड अनुपस्थित या खाली है (उपनाम; `value` अनदेखा किया जाता है) | `subject_ip_address is_empty` |

अन्य सभी ऑपरेटरों के लिए एक गैर-खाली `value` आवश्यक है, और उसके बिना API `400` लौटाता है।
`contains`, `not_contains` और `regex` एक एकल स्ट्रिंग लेते हैं, सूची या ऑब्जेक्ट नहीं; `contains_any` स्ट्रिंग्स की सूची लेता है।

### शर्त मान के प्रकार

शर्त पर वैकल्पिक `value_type` यह बदलता है कि `value` की व्याख्या कैसे हो:

| `value_type` | अर्थ |
| - | - |
| `list` | `value` किसी सूची का UUID है। ब्लॉकलिस्ट, अनुमति सूची (allowlist) या कस्टम सूची की प्रविष्टियाँ तुलना का मान बन जाती हैं, ताकि कोई नियम "मेरी कस्टम वॉचलिस्ट में प्रतिपक्ष" से मेल खा सके। |
| `field` | `value` एक अन्य फ़ील्ड पथ है। शर्त दो लेन-देन फ़ील्ड की तुलना करती है, जैसे `subject_payment_method_account_id ne counterparty_payment_method_account_id`। |
| `relative_date` | `value` एक सापेक्ष तिथि है, जैसे `{"direction": "past", "unit": "days", "amount": 30}`, जो `txn_date` जैसे तिथि फ़ील्ड के लिए है। |

### समूहीकृत शर्तें

सादी शर्त सूची नियम के `evaluation_mode` (`ALL`/`ANY`) के अनुसार जुड़ती है। मिश्रित तर्क के लिए शर्तों को `group_index` दें: एक ही इंडेक्स वाली शर्तें एक समूह बनाती हैं। `group_logic` (`AND`/`OR`, डिफ़ॉल्ट `AND`) समूह के भीतर की शर्तों को जोड़ता है, और पहली शर्त पर `groups_logic` (`AND`/`OR`, डिफ़ॉल्ट `OR`) समूह परिणामों को जोड़ता है। जब कोई शर्त `group_index` रखती है, तो समूहीकृत मूल्यांकन `evaluation_mode` की जगह ले लेता है।

### कस्टम गुणों का संदर्भ

[`POST /v3/transactions/`](https://docs.didit.me/hi/transaction-monitoring/transactions) के `custom_properties` ऑब्जेक्ट में भेजी गई हर कुंजी लेन-देन पर `custom_values` के रूप में सहेजी जाती है। उसे फ़ील्ड पथ `custom_values.<key>` से शर्तों में इस्तेमाल किया जा सकता है। उदाहरण के लिए, `"custom_properties": {"channel": "mobile_app"}` के साथ भेजा गया लेन-देन शर्त `custom_values.channel eq "mobile_app"` से मेल खाता है। ऊपर के सभी ऑपरेटर कस्टम गुणों के साथ काम करते हैं, और उन्हें अन्य फ़ील्ड से तुलना करने या वेलोसिटी फ़िल्टर में भी इस्तेमाल किया जा सकता है।

Console के नियम बिल्डर में, हाल ही में इनजेस्ट किए गए लेन-देन पर दिखी कुंजियाँ शर्त फ़ील्ड चयनकर्ता में **कस्टम गुण** के अंतर्गत अपने आप दिखती हैं। आप किसी कुंजी का संदर्भ उससे पहले भी दे सकते हैं जब कोई लेन-देन उसे नहीं रखता: उसी समूह में **कस्टम प्रॉपर्टी दर्ज करें** चुनें और कुंजी को ठीक वैसे लिखें जैसे आपका इंटीग्रेशन उसे भेजता है (कुंजियाँ केस-सेंसिटिव होती हैं)। जब तक उस कुंजी वाले लेन-देन नहीं आते, नियम का मूल्यांकन बस मेल न खाने वाले के रूप में होता है।

## स्वचालित ब्लॉकलिस्ट अस्वीकृति

किसी भी नियम के मूल्यांकन से पहले, Didit आपके एप्लिकेशन की ब्लॉकलिस्ट के विरुद्ध लेन-देन की इकाइयों की जाँच करता है। यदि **कोई भी** मेल मिलता है, तो लेन-देन **तुरंत अस्वीकृत** कर दिया जाता है और नियमों का मूल्यांकन नहीं होता।

निम्नलिखित इकाइयों की जाँच होती है:

| इकाई | ब्लॉकलिस्ट प्रकार | क्या जाँचा जाता है |
| - | - | - |
| **उपयोगकर्ता (आवेदक)** | उपयोगकर्ता ब्लॉकलिस्ट | आवेदक का `vendor_data` पहचानकर्ता |
| **व्यवसाय** | व्यवसाय ब्लॉकलिस्ट | व्यवसाय का `vendor_data` पहचानकर्ता |
| **पता (वॉलेट)** | पता ब्लॉकलिस्ट | क्रिप्टो वॉलेट भुगतान विधियों का `account_id` |
| **बैंक खाता** | बैंक खाता ब्लॉकलिस्ट | बैंक ट्रांसफ़र भुगतान विधियों का `account_id` |
| **पता (IP)** | पता ब्लॉकलिस्ट | पक्ष के डिवाइस संदर्भ का पता (CIDR रेंज समर्थित) |
| **डिवाइस फ़िंगरप्रिंट** | डिवाइस फ़िंगरप्रिंट ब्लॉकलिस्ट | डिवाइस फ़िंगरप्रिंट या स्थायी डिवाइस ID |

जब ब्लॉकलिस्ट से मिलान होता है:

* लेन-देन की स्थिति `DECLINED` पर सेट होती है
* निर्णय का कारण `blocklisted` पर सेट होता है
* ऑडिट ट्रैकिंग के लिए एक गतिविधि रिकॉर्ड बनता है

> [!NOTE]
>
> ब्लॉकलिस्ट जाँच नियम मूल्यांकन से पहले चलती है। ब्लॉकलिस्ट में मौजूद इकाई नियम कॉन्फ़िगरेशन या स्कोर थ्रेशोल्ड की परवाह किए बिना हमेशा अस्वीकृत होगी।

## लेन-देन स्क्रीनिंग

Didit लेन-देन को जोखिम जानकारी से समृद्ध करने के लिए बाहरी AML और ब्लॉकचेन विश्लेषण प्रदाताओं के साथ एकीकृत होता है। जब कोई लेन-देन सबमिट होता है, तो सिस्टम यह कर सकता है:

* **प्रतिपक्ष की जाँच करें** वैश्विक प्रतिबंध और वॉचलिस्ट डेटाबेस के विरुद्ध
* **वॉलेट पते का मूल्यांकन करें** (क्रिप्टो लेन-देन के लिए) ब्लॉकचेन इंटेलिजेंस डेटा के विरुद्ध, जिसमें मिक्सर एक्सपोज़र, प्रतिबंधित इकाइयों से संबंध और उच्च-जोखिम सेवा इंटरैक्शन शामिल हैं
* **आवेदक की AML स्थिति जाँचें**, इसके लिए लेन-देन से जुड़े उपयोगकर्ता की नवीनतम AML स्क्रीनिंग के परिणामों से उसकी स्थिति की तुलना करें

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

## अगले चरण

> [card] [लेन-देन सबमिट करना](https://docs.didit.me/hi/transaction-monitoring/transactions.md)
>
> नियम मूल्यांकन के लिए लेन-देन की संरचना कैसी होती है।

> [card] [क्रिप्टो स्क्रीनिंग](https://docs.didit.me/hi/transaction-monitoring/aml-screening.md)
>
> क्रिप्टो स्क्रीनिंग के परिणाम और प्रीसेट नियम उनका उपयोग कैसे करते हैं।

> [card] [सेटिंग्स](https://docs.didit.me/hi/transaction-monitoring/settings.md)
>
> स्कोर थ्रेशोल्ड और सुधारात्मक वर्कफ़्लो कॉन्फ़िगर करें।

> [card] [API संदर्भ](https://docs.didit.me/hi/management-api/transactions/create.md)
>
> Create Transaction API endpoint.


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