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

# लेन-देन निगरानी स्टेटस संदर्भ: लेन-देन और केस

> Didit के लेन-देन, केस और Travel Rule स्टेटस, उनके ट्रांज़िशन और अर्थ के साथ। हर महीने 1,000 लेन-देन शामिल, उसके बाद प्रत्येक के लिए $0.001।

Transaction Monitoring में लेन-देन निगरानी में तीन अलग-अलग स्थिति मशीनें हैं: **लेन-देन**, प्रत्येक **केस**, और (जहाँ लागू हो) **Travel Rule जाँच**। यह पेज संदर्भ है।

## लेन-देन की स्थिति

बनाते समय सेट होती है और जीवनचक्र के दौरान अपडेट होती है।

| स्थिति | अर्थ |
| - | - |
| `APPROVED` | लेन-देन नीचे दिए सभी नियमों में पास हुआ, जो समीक्षा थ्रेशोल्ड से कम थे। |
| `IN_REVIEW` | स्कोर समीक्षा थ्रेशोल्ड को पार कर गया, या किसी नियम ने स्पष्ट रूप से समीक्षा की माँग की। विश्लेषक के ध्यान की आवश्यकता है। |
| `DECLINED` | स्कोर अस्वीकार थ्रेशोल्ड को पार कर गया, या किसी नियम ने स्पष्ट रूप से अस्वीकार किया। लेन-देन अस्वीकृत है। |
| `AWAITING_USER` | लेन-देन का निपटारा होने से पहले उपयोगकर्ता को कार्रवाई करनी होगी। Didit इसे केवल किसी नियम के माध्यम से सेट करता है: किसी नियम की `change_status` कार्रवाई (उदाहरण के लिए ऑप्ट-इन लाइब्रेरी नियम `travel-rule-pending-action`, जो `ON_HOLD` में मौजूद Travel Rule ट्रांसफ़र पर चलता है), या कोई नियम कार्रवाई जिसके लिए अतिरिक्त सत्यापन की ज़रूरत थी (एक सुधार सत्र बनाया गया)। जिस Travel Rule ट्रांसफ़र को वॉलेट नियंत्रण के प्रमाण की ज़रूरत है, वह अपने आप इसे सेट नहीं करता: लेन-देन को वही स्थिति मिलती है जो आपके नियम देते हैं (आम तौर पर `APPROVED`), और जब भी विजेट सत्र लंबित हो, `action_required` ब्लॉक में वॉलेट-स्वामित्व URL होता है। ठोस कार्रवाई और URL के लिए लेन-देन का `action_required` ब्लॉक पढ़ें। |

### संक्रमण

```mermaid theme={null}
stateDiagram-v2
    [*] --> APPROVED: Score < review threshold, no blocking rules
    [*] --> IN_REVIEW: Score >= review threshold
    [*] --> DECLINED: Score >= decline threshold, or rule decline action
    [*] --> AWAITING_USER: Rule action change_status → AWAITING_USER
    IN_REVIEW --> APPROVED: Analyst cleared
    IN_REVIEW --> DECLINED: Analyst declined
    AWAITING_USER --> APPROVED: Remediation session approved
    AWAITING_USER --> DECLINED: Remediation session declined
    AWAITING_USER --> IN_REVIEW: Remediation session ended in review
```

नोट: Travel Rule के बाहर `APPROVED` या `DECLINED` से किसी अन्य स्थिति में सीधा संक्रमण नहीं होता।
Travel Rule की समय-सीमा समाप्त होने पर आपका `timeout_outcome` मौजूदा स्थिति चाहे जो भी हो, `IN_REVIEW` (`HOLD`) या `DECLINED` (`REJECT`) सेट करता है। और Travel Rule संक्रमण के बाद चलने वाला कोई नियम `APPROVED` लेन-देन को बदल सकता है।
सुधार के लिए कंसोल के माध्यम से स्थिति पैच का उपयोग करें; ये ऑडिट ट्रेल में लॉग होते हैं।

## अलर्ट

अलग से कोई अलर्ट स्थिति नहीं है।
खुला अलर्ट वह लेन-देन है जो `IN_REVIEW` या `AWAITING_USER` में है, इसलिए ऊपर दी गई लेन-देन की स्थिति का उपयोग करें।
देखें [अलर्ट](https://docs.didit.me/hi/transaction-monitoring/alerts.md)।

## केस की स्थिति

पूरी जानकारी के लिए [केस प्रबंधन](https://docs.didit.me/hi/console/case-management/cases.md) देखें।

| स्थिति | अर्थ |
| - | - |
| `OPEN` | सक्रिय जाँच के अधीन। |
| `AWAITING_USER` | उपयोगकर्ता की ओर से इनपुट की प्रतीक्षा। |
| `RESOLVED` | समाधान के साथ बंद: `FALSE_POSITIVE`, `VALID_THREAT`, `INCONCLUSIVE`, `REQUIREMENTS_NOT_MET` या `REQUIREMENTS_SATISFIED`। |

केस की अलग **प्राथमिकता** होती है (`LOW`, `MEDIUM`, `HIGH`)।

## Travel Rule जाँच की स्थिति

FATF Travel Rule के अंतर्गत वर्चुअल-एसेट ट्रांसफ़र एक समर्पित **13-स्थिति एक्सचेंज** चलाते हैं, जो ऊपर की लेन-देन की स्थिति से अलग है।
आउटबाउंड ट्रांसफ़र `AWAITING_COUNTERPARTY`, `NOT_APPLICABLE` (`threshold_amount` से कम), `UNCONFIRMED_OWNERSHIP` (प्रतिपक्ष वॉलेट को स्व-होस्टेड घोषित किया गया), `COMPLETED` या `COUNTERPARTY_MISMATCHED_DATA` (सत्यापित वॉलेट पर `INTERNAL` मिलान, नाम मिलान पर निर्भर) से शुरू होता है, या `COUNTERPARTY_VASP_NOT_FOUND`, या `COUNTERPARTY_VASP_NOT_REACHABLE` से शुरू होता है।
इनबाउंड ट्रांसफ़र `ON_HOLD` या `NOT_ENOUGH_COUNTERPARTY_DATA` से भी शुरू हो सकता है, और जो sunrise पंजीकरण किसी सत्यापित वॉलेट से मेल खाता है, जिसका लाभार्थी नाम मेल खाता है या अनुपस्थित है, वह सीधे `COMPLETED` से होकर `FINISHED` तक जाता है।
एक्सचेंज `FINISHED`, `CANCELLED`, या `EXPIRED` पर समाप्त होता है।

| स्थिति | अर्थ |
| - | - |
| `AWAITING_COUNTERPARTY` | प्रतिपक्ष को भेजा गया; उनके जवाब की प्रतीक्षा। TRUST के माध्यम से भेजा गया ट्रांसफ़र समाप्ति तक इसी स्थिति में रहता है, क्योंकि TRUST कोई ऐसा डेटा वापस नहीं भेजता जिसे Didit पढ़ सके। सैंडबॉक्स एप्लिकेशन में ट्रांसफ़र [Didit टेस्ट VASP](https://docs.didit.me/hi/transaction-monitoring/travel-rule-sandbox.md) को जाता है, जो आपके चुने हुए परिदृश्य के साथ Didit के भीतर ही जवाब देता है। |
| `UNCONFIRMED_OWNERSHIP` | लाभार्थी वॉलेट का स्वामित्व अभी सिद्ध नहीं हुआ है। |
| `ON_HOLD` | Didit इसे केवल इनबाउंड ट्रांसफ़र पर सेट करता है: ऐसा sunrise पंजीकरण या इनबाउंड `TRP` पूछताछ जिसका वॉलेट आपकी पता पुस्तिका में नहीं है (या, केवल नाम वाली पूछताछ के लिए, जिसका नाम किसी एक सत्यापित धारक से मेल नहीं खाता), या इनबाउंड `TRP` पूछताछ जिसके लिए आपके मैन्युअल निर्णय की ज़रूरत है (ऑटो-स्वीकार बंद है, या स्वचालित जवाब डिलीवर नहीं किया जा सका)। यह अपने आप लेन-देन की स्थिति नहीं बदलता; ऑप्ट-इन लाइब्रेरी नियम `travel-rule-pending-action` `AWAITING_USER` सेट करता है। इसे `POST /v3/transactions/{id}/travel-rule/ownership/` से हल करें। |
| `COMPLETED` | प्रेषक और लाभार्थी का डेटा मेल खा गया; ऑन-चेन प्रसारित करना सुरक्षित है। |
| `FINISHED` | ऑन-चेन हैश रिपोर्ट हुआ; एक्सचेंज बंद। |
| `CANCELLED` | गैर-अंतिम स्थिति से रद्द किया गया। |
| `EXPIRED` | पुष्टि की समय-सीमा बीत गई। केवल वह ट्रांसफ़र जो अपनी समय-सीमा पर अब भी `AWAITING_COUNTERPARTY` में है, समाप्त होता है, जिसे हर 15 मिनट में जाँचा जाता है; अन्य स्थितियाँ कभी समय-सीमा से समाप्त नहीं होतीं। आपका `timeout_outcome` लेन-देन पर लागू होता है, और यह बदलाव कोई `transaction.status.updated` webhook नहीं भेजता। |
| `COUNTERPARTY_MISMATCHED_DATA` | लाभार्थी का नाम मेल नहीं खाया। |
| `COUNTERPARTY_VASP_NOT_FOUND` | किसी भी रेल से प्रतिपक्ष का पता नहीं चला। |
| `COUNTERPARTY_VASP_NOT_REACHABLE` | प्रतिपक्ष की पहचान हो गई, पर Didit डिलीवर नहीं कर सका: उसका `TRP` endpoint पहुँच से बाहर था या उसने एक अलग या गायब LEI, या एक अलग नाम बताया, या कोई नेटवर्क रेल (GTR, TRUST, VerifyVASP, Sygna Bridge) संदेश डिलीवर नहीं कर सकी। |
| `COUNTERPARTY_VASP_GENERAL_DECLINE` | प्रतिपक्ष ने एक्सचेंज को अस्वीकार किया। |
| `NOT_ENOUGH_COUNTERPARTY_DATA` | इनबाउंड `TRP` पूछताछ ने लाभार्थी की पहचान न नाम से की, न वॉलेट पते से। इसकी कोई समय-सीमा नहीं है और स्वामित्व endpoint इसे हल नहीं कर सकता, इसलिए इसे `action: "cancel"` से रद्द करें; प्रेषक को सूचना नहीं जाती। Didit किसी आउटबाउंड ट्रांसफ़र पर इसे कभी सेट नहीं करता; यह वहाँ केवल तभी दिखता है जब आप इसे स्वयं दर्ज करते हैं, और ऐसे ट्रांसफ़र को `action: "resend"` से पुनः प्रयास किया जा सकता है। |
| `NOT_APPLICABLE` | `threshold_amount` से कम, इसलिए कोई आदान-प्रदान नहीं हुआ, या किसी ऐसे ट्रांसफ़र पर आपने जो मान दर्ज किया है जिसे Didit नहीं चलाता (Travel Rule बंद है, ऐसा लेन-देन जिसका प्रकार `travelRule` नहीं है, या पुराना मान)। |

पुराने इंटीग्रेशन अब भी लेगेसी मान `UNKNOWN`, `COMPLIANT`, `PENDING_ACTION`, `PENDING_COUNTERPARTY`, `FAILED`, और `EXEMPT` भेज सकते हैं; Didit इन्हें ऊपर की स्थितियों में अपने आप मैप कर देता है।

आधिकारिक संदर्भ के लिए [Travel Rule](https://docs.didit.me/hi/transaction-monitoring/travel-rule.md#जीवनचक्र) देखें।

## प्रोवाइडर परिणाम स्थिति

हर बाहरी प्रोवाइडर परिणाम (वॉलेट स्क्रीनिंग, फ़िएट निगरानी, प्रतिबंध स्क्रीनिंग) की अपनी स्थिति अलग से सहेजी जाती है। यह लेन-देन रिस्पॉन्स में `provider_results[]` के अंतर्गत दिखाई देती है।

| स्थिति | अर्थ |
| - | - |
| `PENDING` | प्रोवाइडर क्वेरी चल रही है। |
| `COMPLETED` | परिणाम सफलतापूर्वक प्राप्त हुआ। |
| `FAILED` | प्रोवाइडर से त्रुटि आई या समय सीमा समाप्त हो गई। |
| `SKIPPED` | प्रोवाइडर को जानबूझकर छोड़ा गया (उदाहरण के लिए, लेन-देन थ्रेशोल्ड से कम होने पर)। |

## नियम रन के परिणाम

हर `TransactionRuleRun` में ये फ़ील्ड होते हैं:

* `matched` (boolean): क्या नियम लागू हुआ?
* `is_test` (boolean): क्या नियम TEST मोड में था?
* `mode`: मूल्यांकन के समय `ACTIVE`, `DISABLED` या `TEST`।
* `score_delta`: स्कोर में योगदान (यदि नियम लागू हुआ और सक्रिय था)।
* `status_target`: वह स्थिति जो नियम ने माँगी (यदि `change_status` कार्रवाई थी)।

नियम की संरचना के लिए [नियम](https://docs.didit.me/hi/transaction-monitoring/rules.md) देखें।

## निर्णय के कारण कोड

स्थिति परिवर्तनों पर सामान्य `reason` मान:

| कारण | अर्थ |
| - | - |
| `rule_score_threshold` | स्कोर समीक्षा या अस्वीकृति थ्रेशोल्ड को पार कर गया। |
| `rule_change_status` | किसी नियम की `change_status` कार्रवाई ने स्थिति को बदलने के लिए मजबूर किया। |
| `analyst_approved` / `analyst_declined` / `analyst_cleared` | मैन्युअल विश्लेषक कार्रवाई। |
| `user_action_approved` / `user_action_declined` / `user_action_in_review` | जुड़े सुधार सत्र का परिणाम (वह उपयोगकर्ता कार्रवाई जो `AWAITING_USER` के दौरान माँगी गई थी)। |
| `provider_update` | बाहरी प्रोवाइडर ने परिणाम अपडेट किया। |
| `aml_confirmed_sanction` | AML स्क्रीनिंग ने प्रतिबंध मिलान की पुष्टि की। |
| `blocklist_applicant` / `blocklist_counterparty` | किसी पक्ष पर ब्लॉकलिस्ट लागू की गई। |

## अगले चरण

> [card] [जोखिम स्कोरिंग](https://docs.didit.me/hi/transaction-monitoring/risk-scoring.md)
>
> स्कोर स्थितियों से कैसे मैप होते हैं।

> [card] [अलर्ट](https://docs.didit.me/hi/transaction-monitoring/alerts.md)
>
> अलर्ट जीवनचक्र।

> [card] [केस](https://docs.didit.me/hi/transaction-monitoring/cases.md)
>
> केस जीवनचक्र।


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